Re: Theodore Adorno, a prophet of data systems design
From: Randy Howard (randy.howard_at_FOOmegapathdslBAR.net)
Date: Fri, 9 Jan 2004 04:51:06 -0600
In article <email@example.com>,
> >> My dear fellow, I have long since fallen prey to the false idea that
> >> the more elaborate the test and bug prevention facilities, the more
> >> likely they are to create, themselves, bugs, or to interact with other
> >> facilities to create bugs.
> > Can you translate the above into English please? Or, are you still
> > hiding from me?
> It is indeed ambiguous. See my parallel reply for my own interpretation of
> the sentence. Quick summary: I think he means he doesn't understand
> debugging tools.
I'll accept your translation. emoti:-)
> > Algorithms can be tested on PC hardware then moved over, for example
> > I/O can be stubbed out, with memory allocation(s) left in.
> Right; in fact, it doesn't have to be stubbed out, because (if you choose)
> you can write the code in such a way as to decide at runtime whether to
> call the logging stuff (and at what depth).
I was probably reading too much of my own into it, I like to get core
algorithms for embedded work written and tested on the PC first, ignoring
whatever bit twiddling inevitably has to happen to make something useful
happen on the embedded platform. This usually results in a bit of
stubbing (often in the form of a log file that shows what would have
happened I/O wise if it had been over on the target device) at the very
beginning until I'm happy with the bulk of the logic, then I move on
to the bit twiddling. In either case, he is wrong yet again, and knows
nothing about which he speaks.
> Your guess is roughly right. The wrappers are there, and configurable at
> compile time (i.e. you can specify whether you want the wrappers or the raw
> malloc and free). If you choose to use the wrappers, you can choose (either
> at compile time or runtime, up to you) what level of logging you wish.
Makes perfect sense. I do not understand why Nilges has never experienced
anything similar in 30 years time. Furrfu
> >> (3) The solution won't work for multiple threads or processes.
> > Further proof that you do not understand threads and/or multi-process
> > development. Pray tell, why won't it work? It's trivial to write to
> > a single log file from multiple threads for anyone with even a beginner's
> > knowledge of the topic.
> Actually, I can't guarantee that it will work in a multithreaded program,
> because I am determined to keep the code as portable as possible.
Fair enough. I'm constantly working with threaded code for a suite of
tools that all use threading and also support very detailed log files.
It's "portable", but not "Portable" in the sense that it will run on
any platform that supports Posix Pthreads but not in the "c.l.c" sense
obviously. Suffice it to say that making such logging with threads is not
particularly difficult, once you give up running it on the DS9K.
> > I do this for conventional log file usage all
> > the time. If you think it won't work, please let us know why?
> Because two threads might try to write to the same stream at the same time.
Obviously. The point I was getting to was that if you had intended to
use it with threaded programs, solving that issue would be about 5 minutes
worth of typing on a clumsy keyboard.
-- Randy Howard 2reply remove FOOBAR