access(FULLPATH, xxx);

[Da Rock]

On 01/16/12 16:19, Polytropon wrote:
> On Mon, 16 Jan 2012 12:03:52 +1000, Da Rock wrote:
>> On 01/14/12 22:06, Polytropon wrote:
>>> On Sat, 14 Jan 2012 20:37:14 +1000, Da Rock wrote:
>>>> On 01/14/12 19:54, Robert Bonomi wrote:
>>>>>>      From owner-freebsd-questions at freebsd.org  Sat Jan 14 02:32:15 2012
>>>>>> Date: Sat, 14 Jan 2012 09:28:21 +0100
>>>>>> From: Polytropon<freebsd at edvax.de>
>>>>>> To: Robert Bonomi<bonomi at mail.r-bonomi.com>
>>>>>> Cc: freebsd-questions at freebsd.org
>>>>>> Subject: Re: access(FULLPATH, xxx);
>>>>>>
>>>>>> On Sat, 14 Jan 2012 02:00:12 -0600 (CST), Robert Bonomi wrote:
>>>>>>> To repeat some advice from one of my Computer Science professors, many years
>>>>>>> ago, whenever I asked 'how does it work' questions: "Try it and find out."
>>>>>> I bet my professor can beat up your professor. :-)
>>>>>>
>>>>>> Mine used to say several times: "Trial and error is NOT
>>>>>> a programming concept!"
>>>>> As far as writing applications goes, that is _somewhat_ correct.
>>>>>
>>>>> However, 'trial and error' is _not_ the same thing as 'try it and find out'.
>>>>> See the entire subject area of 'benchmarking'.
>>>>>
>>>>> And,  the only way to definitively establish if an alternate approach is
>>>>> 'better' -- i.e. 'faster', or 'smaller', or 'more efficient', etc. -- *IS*
>>>>> to run a trial.
>>>>>
>>>>> Your professor undoubtedly would not of approved when I wrote bubble-sort
>>>>> code that _out-performed_ any other sorting technique -- up to the limits
>>>>> of memory.  Or when I re-wrote an application that used binary searches
>>>>> of records, with a new version that used a brute-force linear search.  I
>>>>> thought I could 'do it better/faster' than the existing code, but the only
>>>>> way to "definitively" find out was to 'try it'.  And the 'trial' proved
>>>>> out -- the replacement code was 'merely' somewhat over 100 times faster.
>>>>> *grin*
>>>> Ha! Love it... :D
>>> Mee too - except that I didn't want to show that
>>> "typical attitude". In fact, I tried to make a
>>> (kinf of humourical) statement about a habit that
>>> I could observe at many students when I was at
>>> university.
>>>
>>> Background:
>>>
>>> When you write source code, you can make errors.
>>> Compiler shows errors. Some students started
>>> with "trial&   error" to just silence the compiler.
>>> One form was that all functional parts of the
>>> program were enclosed in /* and */ (it was a
>>> C class) - no errors, but no action. A different
>>> approach was to arbitrarily (!) change the source
>>> code, something like that:
>>>
>>> 	void *foo(int blah, void *meow())(int ouch);
>>>
>>> Hmmm... gives me segfaults. Maybe something's
>>> wrong with the pointers?
>>>
>>> 	void *foo(int blah, void **meow())(int ouch);
>>>
>>> Not much better, segfaults too. How about that?
>>>
>>> 	void *foo(int blah, void meow())(int *ouch);
>>>
>>> Well... also not better. I've heared about parentheses,
>>> maybe those can help?
>>>
>>> 	void *foo(int blah), void *meow)(int ouch);
>>>
>>> Shit, doesn't even compile anymore! Uhm... _what_ did
>>> I change? Oh wait, I know:
>>>
>>> 	void *foo(int blah, (void *)meow())(int ouch);
>>>
>>> Just produces garbage, then segfaults... what could I
>>> change next?
>>>
>>> I think you get the idea.
>>>
>>> Other students could not understand that even if a
>>> program compiles without any errors, there _may_ be
>>> the possibility that it doesn't do what they intended
>>> it to do. They seemed to believe in some kind of
>>> magical "semantic compiler":
>>>
>>> 	int x, y, sum;
>>> 	x = 100;
>>> 	y = 250;
>>> 	sum = a - b;
>>>
>>> They expected the compiler to notice what's wrong here
>>> if you consider the _meaning_ of the identifiers. It's
>>> not that obvious if you use x, y, and z. :-)
>>>
>>>
>>>
>>>>> As far as 'doing it once' for the purpose of answering a 'how does it work'
>>>>> question -- where one has _not_ read the documentation, *OR* the existing
>>>>> documentation is _not_clear_, then simple experimentation -- to get *the*
>>>>> authoritative answer -- is entirly justified.
>>>>>
>>>>> When I got the 'try it and find out' advice, I was asking questions about
>>>>> situations where the language _specification_ was unclear -- there were
>>>>> two 'reasonable interpretations' of what the language inthe speciication
>>>>> said, and I just wanted to  know which one was the proper interpretation.
>>>>>
>>>>> Now, given that the language in the specification _was_ abiguous and both
>>>>> interpretations were reasonsble, different compiler builders could have
>>>>> implemented differently, and 'try it and find out' was _necessary_ to
>>>>> establish what that particular implementation did.<grin>
>>>> There appears to be 2 schools of thought on this subject: a classic case
>>>> of the "old" vs the "new", in this case "punchcards/slow compilers" vs
>>>> "gcc/all-in-one compile, link and go"of todays tech. I saw a similar
>>>> conversation about 5 years ago on the linux lists... :)
>>> I didn't want to complain about using a test case,
>>> with determined variables (relative path vs. absolute
>>> path) to see if the interpretation of "man 2 access"
>>> was matching the actual inner workings of the function
>>> in use. In fact, I would even judge this the _preferred_
>>> method to be sure.
>>>
>>>
>>>
>>>> In the light of this conversation and given todays tech I'd say give it
>>>> a shot unless you think something could break (as in fatal to service
>>>> quality in production/hardware).
>>> Fully agree. Know your variables and construct a
>>> test within a fixed environment. The result will
>>> be a valid source of conclusion.
>>>
>>> Now back to "trial&   error": what if I use
>>> brackets instead?
>>>
>>> 	void *foo(int blah, void *meow[])(int ouch);
>>>
>>> Hmmm... :-)
>> I think the problem these days is a combination of many things.
>>
>> Firstly, in the old days (I sound like grandpa... :/ ) punch cards were
>> hard to do, time consuming, and machine time was very expensive. So
>> programmers had to get it right the first time (or close to it), and
>> documentation was paramount.
> Old man want history? Read this! :-)
> http://www.columbia.edu/cu/computinghistory/fisk.pdf
That was a good read- funny too. Its amazing to think how far it has all 
come in such a short time... All that happened before I was even a 
thought, and when my mum was a little one, yet it has always fascinated 
me how things were done then.

If had the space and money I'd love to get a hold some of that old stuff 
to play with or just display. I picked up an old Amiga, a Tandy, an 
Apple II, and a Commodore 64 for that purpose. I lost them through some 
disasters, but I did like that kind of "antiquing".
> In ye olden tymes, you could measure IT efficiency (even
> though the term was probably quite different) in megawatts
> per square foot, or even $ per square foot. This kind of
> measuring "expensive machinery" (in terms of operating
> them) has become present in our modern times again. And
> documentation... well, that depends.
Amazing how history keeps repeating... :)

Also amazing how the old suddenly comes to the rescue again. Case in 
point: NASA didn't take very good care of data collected during its 
missions. For eg the Australians came to the rescue with footage of the 
moon landings- NASA recorded over it. That'd be like recording over your 
wedding video, right? There musn't be a woman in NASA's admin then... :)

But more importantly, what happened when they decided to go to the moon 
again and they hunted around for necessary data to help them prepare? 
They found that the data of say dust levels was kept on old tapes that 
hadn't been transferred to new medium, and so was still kept by the 
scientist in charge of that in his garage- with no means to retrieve the 
data recorded. Now they're spending millions to restore a 40-50 year old 
tape drive!
> However, obtaining
> learing resources for efficiently _using_ what's available
> have become much more easily to access today, primarily
> because of the WWW. As failing to properly program does
> not turn into accumulating costs ("charged per CPU time")
> right away, you luckily don't have to pay that much
> attention when you perform "learning by doing", which
> in my opinion is the _only_ way to learn "IT stuff"
> that works.
That was something that was mentioned in that article you posted. Things 
really picked up speed when the cards were replaced by the new, more 
"direct" methods. Now its takes only minutes. You really do wonder how 
they managed to do it... They really deserve a lot of respect for 
getting unix going and keep it going.
>> Secondly, in the early years the internet wasn't exactly up and running
>> (as such), and so global programming teams weren't a problem with
>> language differences (and people were taught far better english and
>> speling- whoops spelling :) none of this and other shortenings;
>> ambiguity kept to a minimum).
> The ability to use the english language was neccessary
> in the earlier days, especially when 8-bit microcomputers
> became available nearly everywhere. Internationalization
> and localization wasn't done. CP/M messages and BASIC
> keywords were all english. Whole programs such as WordStar
> were used in their original (english) language by people
> speaking a different language (e. g. german), still being
> able to produce excellent work. Looking back at those times,
> I think the language barrier is much stronger present in
> our today's society than it was in the past. But maybe
> that's just my individual observation here in Germany. :-)
I suppose thats true, but to continue in that fashion would mean the 
death of variety in languages and new dialects. It would also alienate 
others. But, worst of all, to destroy the world with such a coarse, 
illogical, bastardised language as english would be a complete travesty!

I'm just in the process of working out exactly how to teach reading, 
writing, spelling and grammar to our kids (1-5), and we're just finding 
out exactly how bad it really is. We knew, but we were horrified by the 
extent of it.
>> Thirdly, when things did become easier (gcc era?) the documentation
>> slipped, and programmers started getting more sloppy, as the mistakes
>> were easily fixed.
> Compile modern software with -Wall and see the results
> of "more sloppy". :-)
Tell me about! I see it when compiling ports, and I don't mind so much 
if its a difference of arch's or maybe a deprecation or two, but most 
are just sloppy casts and the like. Surely that _has_ to affect the 
running of the program, creating unexpected behavior? Again that article 
was funny how the error messages came back and he's wondering why it 
didn't fix itself- unfortunately these days it seems it does, and 
everyone relies on the spell-checker... ergo we have documents _AND_ 
programs going out with speling erors ;)
>> The docs became more ambiguous, and language did
>> start slipping (globally- not just in computing).
> In the past, those who provided software typically
> also provided documentation. And those who provided
> hardware also did. Today, documentation is typically
> left to others, to the users, the communities, and
> it is scattered across the web, into Wikis, web forums,
> individual pages. The ability to use a search engine
> has become mandatory. Software engineering strategies
> that emphasize the _fast_ production of software seem
> to judge documentation as optional, consuming resources
> that could be spent better - and why not? When the
> documentation is complete, the product it belongs to
> has already been obsoleted and withdrawn.
True again, but shouldn't the "core" principles of the program be 
intact? Proper use of MVC should ensure that so that the user docs 
should be fine, and the as for the code itself the engineers should be 
better able to articulate what is going on? I looked at java and its 
documentation and it really was a clever design: surely other coding 
should be able to do the same?
>> Fourthly, globalisation occured, internet was up and running on a global
>> scale, international teams were working on programs, and people were
>> attempting to translate japanese manuals into english (if you catch my
>> drift... :) I used to be a Xeroid and this was a standing joke). So not
>> all docs were as clear anymore.
> It's worth noting that the _means_ of documentation
> production have vastly improved (authoring systems,
> text processors, use of graphics and so on), while
> the quality of documentation produced that way does
> not always have.
>
> Setzen Kopfphon in Kopfphon Wagenwinde ein, gemappt
> die Pfeife lange wie die Form B. :-)
I'll have to get you translate that for me- I have an idea, but I'd like 
to know for sure. Its kind of like only getting half the joke atm :)
>> Lastly, we have the travesty of a lack of discipline in skills. Near
>> enough's good enough, and so on. No one is taking the time anymore to
>> become "skilled" - they want it now or never. Take a 6 week course and
>> become an expert. The masters and gurus are becoming few and far between
>> now (although there appears to be a nice concentration here- thats why I
>> stick around. Linux lists seem to have the cranky ones :) ). And so we
>> have the case as you have outlined Poly. That said the docs are getting
>> to be of not much help either unless you're partly clairvoyant too in
>> more cases than should be.
> A big step in achieving to be a "skilled master" isn't
> just bare knowledge, it's experience. And this requires
> time. Nobody is willing to spend time in order to get
> experience. Knowledge... well, you can easily obtain
> knowledge today by "only" knowing how to properly search
> for (and _find_) it. And for sure, you need to know how
> to interpret the knowledge you find. But without experience,
> what is knowledge worth? Knowledge without application
> is ballast. On the other hand, knowledge is needed in
> order to understand what's going on - especially in cases
> where you're _supposed_ to know it. And by _using_ that
> knowledge, you gain experience. In my opinion there is
> no other way to gain it.
I can speak from experience with exactly that. Hands on is the only 
way... those who can't do teach, and those who can't teach become 
university professors (at least here anyway) :D
> People make mistakes. And that's no problem as you can
> learn from mistakes. Of course, you cannot do _all_ the
> mistakes possible, so when you can, learn from other's
> mistakes. But for a learning experience, always make
> your own mistakes. No one is born a master.
>> Myself I believe that one needs to read the docs thoroughly and then if
>> it is ambiguous then run a test case, if all else fails: ask.
> Exactly my suggestion.
>> But one
>> needs to be as exact as possible when doing anything.
> That's what you learn in science theory 101: Determine
> your variables as strict as possible. Change _one_ thing
> per time, so you can conclude by observing your results
> (that have changed, _if_ they have changed). Formulate
> your algorithm to "answer a question" as precise as
> possible, therefor: Know your question.
I see many programs out there that _don't_ do exactly that. They don't 
get the parameters and/or couldn't be bothered to implement them 
correctly. The ones where the developers do "know" work far better. See 
Bind and DHCP.
>> "Any job worth
>> doing is worth doing properly", and "god/devil is in the details" - Is
>> say "God _and_ the devil is in the details": if you don't pay attention
>> to the details the devil _will_ make sure it bites you in the ass!
> Details always matter. In small scale, when you write a
> C program and miss a *, the whole program can do something
> totally different, or even doesn't compile anymore. In
> large scale, if you deal, for example, with database
> request, be sure to do it _properly_ to get the results
> you want. Only the correct results are the results you're
> interested in - or you would be querying /dev/random instead
> without the need of a database. :-)
>
> This little thing hasn't changed in over 50 years that
> computers are around. Many things have changed - but
> details _still_ matter. Die, history, die!!! :-)
>
>
>
>> Its a crazy world, though, isn't it? :)
> It may belong to Arthur Brown. :-)
Yeah, it just might be...