Subject: Just some general questions and a request.

From: Moonchilde <[email-masked]>
Date: Fri, 31 Jul 1992 11:48:09 -0700

Okay, questions first.
Haakon: do you have any plans to add the GodNET regexp and listassoc
code to the standard MOO release? it's really a pain to keep patching them
in. :)

Also, compiling MOO under a MACH 3.0 system led to some interesting
difficulties which I will summarize along with how I needed to fix them.
I was using the ultrix cc compiler since it produces faster and tighter code
on pmaxen.

First:  in my-time.h, MACH systems need the sys/types include.
Second: in server.c.  remove() wasn't found as a function. Unlink() seems to
        be more standard.
Third:  in add_property(): ultrix cc doesn't like the automatic initialization
        of value.  Just decalre value and initialize it seperately.

Lastly, a request
  I would like a function similar to notify() that does not append the output
text with a newline/line feed.  This would make interactive prompting look
a little cleaner, and shouldn't be all that hard to do.  However, it would
be rather extensive to do, and I haven't had the time to take the time to 
actually go and do what needs to be done to make it work.  So this is a 
request if anyone else has the time and energy and is willing to do it.

--Moonchilde

---

From: Pavel Curtis <[email-masked]>
Date: Fri, 7 Aug 1992 10:21:36 -0700

> Date:	Fri, 31 Jul 1992 11:48:09 -0700
> From:	Moonchilde <[email-masked]>

I could *swear* that I replied to this message when it came in, but I can't
find any evidence of that in the MOO-Cows archive, so...  Sorry if this is,
indeed, some kind of repeat.

> code to the standard MOO release? it's really a pain to keep patching them

The next release, in a week or so, will very likely contain new built-in
functions covering the functionality of the GodNet regexp functions.  Almost
certainly, however, those functions will not have the same interface/names as
on GodNet; I believe that better names (and perhaps somewhat more flexible
functionality) are possible.

As for the listassoc() and listiassoc() functions, I do not have any plans at
this time to include those in the release.  Instead, I believe that the second
release from now (scheduled for the end of August and including reference
counting instead of ubiquitous value copying) will perform so much better,
especially on applications that manipulate large list structures, that it will
no longer be useful to move those functions into C.

> a little cleaner, and shouldn't be all that hard to do.

There are some tricky questions concerning the design of a good MUD client that
copes both with asynchronous output from the server and with maintaining a
readable prompt for the user.  For example, how do you know that an incomplete
line of output is a prompt and not simply a packet boundary in the TCP stream?
[Assume that you fix this by having prompt lines end in a special character for
easy recognition, say ASCII NUL.]  Now, suppose you, the client, have received
a prompt that the user hasn't responded to yet, so you're keeping the prompt
intact while letting all the later, asynchronously-generated output scroll by.
What if another prompt comes in before the user has responded to this one?
Should you just queue it up?  Maybe throwm away the old one and use the new one
instead?

And then there are the issues about user confusion, when some nasty task prints
a prompt but then doesn't try to read any input; the poor user thinks he's
answering the prompt when in fact he's typing a MOO command.  Just think of the
possibilities for fun!  :-)  This sort of thing could be handled by proper core
database design, but it's certainly an issue that must be addressed.

Anyhow, it wouldn't be very hard at all to implement such an addition; I just
haven't been motivated to put it very high on my long list of things to do,
pending some resolution of the issues I sketched out above.

	Pavel