[DGD] Re: DGD Intermud-3 Channel

[Jason Cone]

>I have a note in my mudos save/restore implementations to convert to
>parse_string in the restore case, which is essentially the same task as
>parsing the incoming I3 packet.  I think that would probably be a good use
>of parse_string but I need to find time to study parse_string a bit more
>first (vaguely following it in this mailing list doesn't quite cut it :).

Actually, that is a good idea.  But, as you said, it would only work in the
restore case.  It would also take forming a competent grammar.  That alone
might take a while to get right.

>This of course raises the issue of updating to the experimental branch as
>I've currently been sticking to the stable branch (however parse_string is
>one of the big things I was waiting for so its certainly a motivation to
>swap).  Do people have opinions on whether mudlibs should be developed for
>the stable or experimental branches I wonder?

I, too, have been waiting for the parse_string() functionality and,
admittedly, it was one of the deciding factors to upgrade the driver.  I
think that you have to look at the development effort to answer that
question, though.  Is the code being patched on a regular basis?  Is there
an acceptable medium for communication between users of the code and the
developer(s)?  What are the long term goals of the developer?  I think in
the case of DGD, I can feel pretty safe about developing with the
developmental branches.  Dworkin is actively working towards added
functionality and is good about communicating with us, the end users.  I
think you have to look at your own code, too.  Myself, I won't be done for a
while no matter which branch I go with.  I'd rather develop with the future
in mind than what's currently accepted as de-facto; I don't want to get done
and have all this new funtionality waiting to be used.  For what it's worth,
I haven't had any problems with 1.1.34.  Granted, I haven't pushed it much,
but it seems fine at face value.

>With parse_string available I'd quite like to see the development of a
fairly
>standard closure/function pointer syntax for DGD using it.  I think this is
>one area DGD is somewhat lacking (IMHO).

I totally agree about the need of a function pointer.  How would you go
about fixing this with parse_string()?  I'd be willing to take a break from
lib coding to develop something like this.

jc


||==================================================================||
||                         ||  "Hard work spotlights the character  ||
|| Jason H. Cone           ||   of people:  some turn up their      ||
|| Dept. Computer Science  ||   sleeves, some turn up their noses,  ||
|| Texas A&M University    ||   and some don't turn up at all."     ||
|| jcone at cs.tamu.edu       ||             - Sam Ewing               ||
||==================================================================||





List config page:  http://list.imaginary.com/mailman/listinfo/dgd