[DGD] Recursion in recompile(), is this correct?

[Noah Gibbs]

--- Robert Forshaw <iouswuoibev at hotmail.com> wrote:
> Now I am totally confused. The docs are
> very unclear as to what conditions 
> causes recompile() to be called.

  No they aren't.  You keep quoting a line that tells
you *exactly* when recompile will be called.  You know
that "A inherits B inherits C" thing you mentioned? 
It reads pretty darn clearly from my point of view.

  I assume that's an "if and only if" sort of thing --
i.e. recompile() is called *only* if that's true. 
That's the way Felix tends to write documentation.  A
description like that tends to be a definition, not an
example.

> The name of the
> function would suggest [...]. The doc 
> would have me believe [...]

  Well...  Which do you trust?  What the documentation
says, or something vaguely implied by the name of the
function?  There's a single, obvious right answer in
this case.

> I have read the docs and they aren't
> concise enough.

  This is probably the first time I've *ever* heard
Felix's documentation describes as "not concise
enough".  Good God, how short do you need them to be? 
It takes more than a couple of pages to describe DGD
in a user-friendly manner.  You've proven to us very
nicely that if it's described in the shortest
unambiguous way, many people will misunderstand (or
just decide that the docs are less important than
their own interpretations of the function names).

> I have browsed through 
> the kernel code and it is not helpful, and
> would take too long to interpret 

  This is probably that arrogance thing they were
talking about.  You mean it's not helpful on first
browse -- i.e. it's not helpful *until* you've taken
the time to interpret it.

  I will note briefly that each and every person
currently on the list has learned what he knows about
DGD with no more documentation that you have available
to you now.  Most of them have done it with less,
because my site is significantly newer than, say, Par
Winzell's involvement in DGD.

> I am 
> going to write only what I need and I am
> going to write it all myself, but I 
> need to have sufficient documentation and I lack
> that.

  You're asking for minimal-yet-sufficient
documentation for exactly your problem.  This is
probably why they said you're looking for pre-chewed
answers.  Usually, somebody attacking an uncommon
problem (I'll get to why this is uncommon in a second)
will look at the available information (such as
existing solutions to similar problems) and derive a
result from there.  You're unwilling to do so, and
claim it wastes your time.

> What I am trying to 
> do is make it possible to update libraries
> without shutting down the MUD 
> with minimal code.

  And yet you refuse to understand the normal
solutions to this problem.  You demand to be given the
necessary information to do it with minimal code, and
you claim that the normal rebuilding solution (Kernel
Lib plus an existing ObjectD) is unacceptable -- you
want *only* a minimal-code solution, or the
documentation to write the same.

  In other words, you've decided you'll build (to use
an analogy) a racecar.  When we try and tell you how
one goes about building a regular car, you're saying
"no, I don't want to learn to build a sedan.  I'm only
interested in racecars.  If it's not immediately
relevant to racecars, it's a waste of my time to
learn".  Then you don't understand why we think you're
being pig-headed about accepting advice.

> Are there any other functions called by the
> driver, or kfuns, that would 
> help achieve the effect I want? What are they?

  Many.  The driver and Auto object can notify you
when an object is being compiled, when it includes or
inherits a file, when it is destructed or recompiled
(you see it with compile_object(), not recompile()). 
All of this is trackable information.  You'd like us
to derive the absolute fastest way to do exactly what
you want (you haven't fully said what it is -- do you
need to rebuild children when a lib is recompiled? 
What if there's a set of libs recompiled, do you
rebuild things more than once or combine them?  How
about header files, do you rebuild when those
change?).  Instead, we're pointing you at solutions
that will do what you want and override the correct
functions.  And you're giving us that "racecar" guff
-- you don't want to know the *usual* or *accepted*
way to do it, you just want us to give you exactly
enough to fully solve your own poorly-defined problem.

> I am trying to be 
> minimalistic here, as I'm writing the lib only
> for a single purpose. So if 
> you tell me 'Go see how the kernel lib does
> it' I'm not interested because 
> where kernel does one thing to achieve a
> task, it does a load of other 
> things to.

  Imagine you wrote to an algorithms mailing list and
you asked for instructions on how to write a
breadth-first shortest-path algorithm for some data
structure.  You'd already read some (fairly cryptic)
instructions in an algorithms textbook, but decided
they were "too concise", or perhaps otherwise useless,
or maybe you didn't understand why it was a
breadth-first search but they were using a queue when
the name of the routine was *search*, not *queue*.
(notice how these problems sound really stupid when
you  apply them in another case?  Yeah, we do too).

  You post to the algorithms list about this problem,
receiving some acerbic answers along the way.  They
point you at an application that uses a breadth-first
search for a different data structure.  You post that
that's not acceptable, because the application does a
whole bunch of other stuff, and you're not going to
bother to sift through it for an example of the one
simple thing you want to do.

  Suddenly they get prickly with you.  The nerve!

  Do you see why this example makes you look bad?  Do
you see how it applies to your current behavior here? 
I'm not posting because I think you haven't suffered
enough, or any such thing.  Nor to drive the point
home.  You seem like a decent fellow.  You also seem
like you'll eventually be a good programmer, when and
if you can learn basic etiquette and cooperation.  If
you were incompetent as well I'd have started ignoring
you long ago.

  No, I'm writing this because, as Felix has noted,
you rarely seem to absorb anything the first time
somebody posts it.  I'm trying to be clear, to say
things in more than one way and to make it obvious
what I'm trying to accomplish, in the hope that you'll
understand and absorb it.  You've been stubbornly
opposed to recognizing your own behavior problems for
your last few posts, and perhaps quoting them in a
different context (and in *this* context) will help
you see them again, and realize what they are.

  This is a very small community.  In free DGD stuff,
everybody knows everybody else because there aren't
very many of us.  This allows a certain degree of
quirkiness from members -- I ask the occasional stupid
question or give the occasional stupid answer, Erwin
gets short with frustrating newbies, and so on.  But
it also means there's a very immediate sort of
reputation system.  As somebody else pointed out, if
you piss us off, collectively, you've pissed off
everybody in the *world* who is capable of answering
your questions.

  Please bear that in mind, it's important.

  And when you post questions to this list that are in
the archive, you're not helping posterity.  People
willing to read the archive have already *got* their
answers.  You're just helping yourself, and doing so
at our expense (yes, yes, we don't have to reply, at
which point you'll feel picked on and claim you're not
getting the information you need and that the
community is unhelpful.  That's beside the point, and
Steven Schmidt already addressed it anyway).

  Anyway, that's enough on that topic for this
morning.



=====
------
noah_gibbs at yahoo.com

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd