Re: asynchronous task communication

[Charles Hixson <charleshixsn@earthlink.net>]

On 01/03/2013 12:50 AM, Dmitry A. Kazakov wrote:
> On Wed, 02 Jan 2013 16:20:11 -0800, Charles Hixson wrote:
>
>> On 01/02/2013 12:35 PM, Dmitry A. Kazakov wrote:
>
>>> You make node a discriminated record type. Usually when a node is created
>>> it is already known how many children and/or parents it will have. E.g.
>
>> That's not true in this case.  The node adds references depending on the
>> data that it encounters.
>
> OK, that does not look like NN.
>
>> Even the "base layer", such as it is, isn't
>> allocated all at once, but only as appropriate stimuli arrive.
>
> That looks like a design choice. Why should it be this way? I mean, it is
> not a RT system, but anyway this kind of allocation policy would inflict
> heavy latencies at least initially. It may have sense only if you had a
> huge number of nodes of which only a minor part were actually involved in
> actual computations. Such loosely coupled systems are not very common.
Well, it's a design choice, but it's one driven by circumstance.  The 
number of possible input stimuli is exceedingly large.  Basically it's 
the set of space delimited strings of characters that it could 
encounter...that's not quite right, and the final decision of what the 
input will be is still being thought about, but that's about what it is. 
  I'm contemplating how to deal with non-ASCII chars, and with 
punctuation both internally and terminally, but almost all of the input 
is english text.  Even if I used unicode chars as the basic stimulus, 
though (more flexible, but LOTS more processing required) there would 
still be more possible inputs than I would want to pre-allocate, and 
most of them would never show up.  But some would.  There are occasional 
Greek, Hindi, and Chinese words or characters, though embedded in 
English text.  And I can't say that something I haven't thought of won't 
show up soon.  Musical notation, perhaps (if that can be done in unicode).
>
>>> By hands. I write docs manually. It is tedious, I admit. Consider it as an
>>> extra code review step, helps finding inconsistencies and gaps which
>>> otherwise slip through.
>> In my experience, code that's documented that way tends to have
>> documentation that's incomplete, out of date, or both.
>
> That depends. I consider documentation as an integral part of the process.
> I never release/update anything without documenting it first.
>
> Generated documentation is a chaotic collection of comments you once wrote
> around declarations. If you don't write/update them no tool could fix that.
>
There's more that one purpose for documentation.  What the documentation 
should be depends on who it's directed at.  I've written user manuals 
for programs (that I've written), and they don't mention ANY of the 
internals, but developer documentation NEEDS those comments, yet it 
needs to be compact enough that it doesn't take up too much screen 
space.  And library user documentation (which is what AdaBrowse can 
generate) is yet something else again.

For my current needs, developer documentation, it's looking as if 
NaturalDocs will fill the bill.