MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: MOO-Cows Digest V1 #328

On Thu, 8 Feb 1996 MOO-Cows-Errors@parc.xerox.com wrote:

>
> MOO-Cows Digest          Thursday, 8 February 1996     Volume 01 : Number 328
>
> In this issue:
>
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Support for alt. language
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: Support for alt. language
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: clear_property() bug
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
> 	Re: Support for alt. language
>
> See the end of the digest for information on subscribing to the MOO-Cows
> or MOO-Cows-Digest mailing lists and on how to retrieve the list archives.
>
> ----------------------------------------------------------------------
>
> From: mcmudge@mailbox.syr.edu (Kipp the Kidd)
> Date: Thu, 8 Feb 1996 01:14:45 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> >   If one of X or Y is an integer and the other is a floating-point number,
> >   then most of these operators raise E_TYPE; there are no automatic coercions
> >   of integers to floating-point numbers.
>
> How about making a server options property:
> dont_care_wether_a_variable_is_integer_or_float ... When it exists and is
> true, comparisons and calculations wouldn't raise E_TYPE... Not that I'd
> enable it for my whole MOO... but maybe even a verb flag instead of
> $server_options prop...
> Any calculcation that contains a FLOAT would return a FLOAT value.  Anything
> that contains COMPLETELY INT values will return integers...  It would keep
> people from complaining either way.
>
> Also.. is it possible to make '.1' unparse into '0.1'?
> Do you think either both should work, or both shouldn't?:
>   tostr("$",tofloat(".02")) -> "$0.02"
>   tostr("$",.02) -> {"Line 1: parse error"}
>
> - - Kipp
>
>
>
>
> ------------------------------
>
> From: Kondratiev Dima <DIMA@edge.paragraph.com>
> Date: Thu, 8 Feb 1996 10:07:00 -0800
> Subject: Support for alt. language
>
> I am looking for is a 'clean' way to support alternative character sets in
> strings, Cyrillic for example.
> I need  to support alternative language in string properties such as
> object names and descriptions.
> As I understand this problem now (correct me please, if I am wrong) parser
> should pass
> extended ASCII chars in strings. Do I need to hack parser code to achieve
> this ?
>
> Thank you,
> Dima
>
>
>
> ------------------------------
>
> From: bmgustav@bioinformatics.weizmann.ac.il (Gustavo Glusman)
> Date: Thu, 8 Feb 1996 03:54:28 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> >-- Added support for in-DB handling of all tracebacks, of which there are two
> >   kinds: unhandled errors and tasks that have timed out.
> ...
> >      In both situations, the indicated verb call is made with the same
> >   task_id() as the task that caused the traceback.
>
> I asked this without looking at the code first, sorry:
> Is the special verb call done immediately, or is it added to somebody's
> task queue? In other words, is there guarantee that nothing else will
> happen in between?
>
> >If the handler verb call
> >   either suspends or returns a true value, then that code is considered to
> >   have handled the traceback and no further processing will be done by the
> >   server.
>
> It would be quite useful if the actual value returned were used by the
> server to consider what to do next with the failing task, other than
> letting it die.
> For example, if $handle_task_timeout returned -
>    {seconds-to-suspend, new-tick-count, new-second-count}
> ...and both counts were positive, the original task that ran out of
> resources might be allowed to resume as if nothing happened, with the new
> tick/second counts as specified, after suspending for the specified number
> of seconds. (If this 'seconds-to-suspend' were -say- -1, the task might be
> allowed to continue immediately, which might be needed for tasks that
> assume they're atomic.)
>
> As you can see, I haven't really thought this out fully, but one of the
> things that always bothered me in MOO programming is that all the tasks
> have to keep wasting time suspending-if-needed, and there is no method for
> providing a safety net for important tasks. The new functionality is a big
> step in this direction (i.e. not just a dumb traceback), but the task dies
> anyway, no matter what you do...
>
> - -------------------------------------------------------------
> Gustavo Glusman               Founder/administrator of BioMOO
> - -- Gustavo@bioinformatics.weizmann.ac.il
> - -- http://bioinformatics.weizmann.ac.il/Gustavo
> - -- BioMOO: telnet bioinformatics.weizmann.ac.il 8888
>            WWW:   http://bioinfo.weizmann.ac.il:8888
>
>
>
>
>
> ------------------------------
>
> From: Richard Connamacher <phantom@baymoo.sfsu.edu>
> Date: Thu, 8 Feb 1996 13:08:15 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> is #0:handle_uncaught_error() and #0:handle_task_timeout() only called
> on #0, or is it MPL-friendly? I'm working on a WWW server that uses
> 1.8.0's MPL, and I'd like for it to be able to use its own error
> handlers for tasks that are initialized by connections to it.
>
> Phantom
>
>
>
> ------------------------------
>
> From: Richard Connamacher <phantom@baymoo.sfsu.edu>
> Date: Thu, 8 Feb 1996 13:21:19 -0800
> Subject: Re: Support for alt. language
>
> If you find a way to input extended ASCII characters, let me know.  I've
> tried before and never worked.. whether the extended (MacOS-only)
> character set was stripped out on the client end because of some
> tradition or the MOO parser strips them out I don't know.
>
> This brings up a question.. this may be a stupid question, but I'll ask
> anyway... what happens if you set the connection option of a standard
> telnet connection, on line by line mode, to binary?  Since the telnet
> client is thinking in line by line mode, it sends out the input in 1
> line chunks.. would the MOO then receive it in 1 line chunks?  Could you
> use a read() loop to handle commands, and the read() inputs it as a
> binary string, yet it's still separated into lines by the client end?
> This would solve the problem of alternate character sets, assuming that
> you had a client which would automatically slice the input into
> individual lines and the MOO would pay attention to that.  Ofcourse, you
> would have to do the parsing entirely in-database if you did such a
> thing.
>
> Phantom
>
>
>
> ------------------------------
>
> From: cadams@weather.brockport.edu (Chuck Adams)
> Date: Thu, 8 Feb 1996 09:20:40 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> Kipp the Kidd drew these hieroglyphs:
> > How about making a server options property:
> > dont_care_wether_a_variable_is_integer_or_float ... When it exists and is
> > true, comparisons and calculations wouldn't raise E_TYPE... Not that I'd
> > enable it for my whole MOO... but maybe even a verb flag instead of
> > $server_options prop...
>
> There's about as much chance of that as President Alan Keyes.
>
>
>
> ------------------------------
>
> From: Pavel Curtis <pavel@parc.xerox.com>
> Date: Thu, 8 Feb 1996 09:36:38 -0800
> Subject: Re: clear_property() bug
>
> Don Schwarz writes:
> > I've been asked to post about a bug in 1.8.0a6's clear_property built-in.
>
> I have to say, I kind of wish you'd sent this message a day earlier... :-)
>
> > Apparently, when clear_property() is used on a property that is defined on
> > the object, rather than being inherited from it's parents, the built-in
> > should return E_INVARG, but instead it returns an invalid variable type
> > which panics the server if you try to tostr() it.
>
> Yes, this is certainly a bug and the fix will be in beta2.  Until then, don't
> do that... :-)
>
> 	Pavel
>
>
>
> ------------------------------
>
> From: Pavel Curtis <pavel@parc.xerox.com>
> Date: Thu, 8 Feb 1996 09:39:21 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> Kipp the Kidd writes:
> > > If one of X or Y is an integer and the other is a floating-point number,
> > > then most of these operators raise E_TYPE; there are no automatic coercions
> > > of integers to floating-point numbers.
> >
> > How about making a server options property:
>
> I think this would be a really bad idea; we should simply come to an agreement
> about which way to go on this one and then do it.  Anything else leads to *way*
> too many porting and code-copying problems.
>
> > Also.. is it possible to make '.1' unparse into '0.1'?
> > Do you think either both should work, or both shouldn't?:
> >   tostr("$",tofloat(".02")) -> "$0.02"
> >   tostr("$",.02) -> {"Line 1: parse error"}
>
> I agree that there ought to be consistency here; I'll look into fixing it in
> beta2.
>
> 	Pavel
>
>
>
> ------------------------------
>
> From: Pavel Curtis <pavel@parc.xerox.com>
> Date: Thu, 8 Feb 1996 09:42:35 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> Gustavo Glusman writes:
> > >-- Added support for in-DB handling of all tracebacks, of which there are
> > >   two kinds: unhandled errors and tasks that have timed out.
> > ...
> > >      In both situations, the indicated verb call is made with the same
> > >   task_id() as the task that caused the traceback.
> >
> > Is the special verb call done immediately, or is it added to somebody's
> > task queue? In other words, is there guarantee that nothing else will
> > happen in between?
>
> Yes; it happens entirely within the virtual machine, before returning to the
> task manager.
>
> > >If the handler verb call
> > >   either suspends or returns a true value, then that code is considered to
> > >   have handled the traceback and no further processing will be done by the
> > >   server.
> >
> > It would be quite useful if the actual value returned were used by the
> > server to consider what to do next with the failing task, other than
> > letting it die.
> > For example, if $handle_task_timeout returned -
> >    {seconds-to-suspend, new-tick-count, new-second-count}
> > ...and both counts were positive, the original task that ran out of
> > resources might be allowed to resume as if nothing happened, with the new
> > tick/second counts as specified, after suspending for the specified number
> > of seconds.
>
> This would be non-trivial to add; right now, the task has already been blown
> away by the time your handler runs.
>
> > As you can see, I haven't really thought this out fully, but one of the
> > things that always bothered me in MOO programming is that all the tasks
> > have to keep wasting time suspending-if-needed, and there is no method for
> > providing a safety net for important tasks. The new functionality is a big
> > step in this direction (i.e. not just a dumb traceback), but the task dies
> > anyway, no matter what you do...
>
> I agree that this is a major failing of MOO, but no solution made it to the
> fully-designed stage before beta.  Now, it's too late (for me, anyway).
>
> 	Pavel
>
>
>
> ------------------------------
>
> From: Pavel Curtis <pavel@parc.xerox.com>
> Date: Thu, 8 Feb 1996 09:43:49 -0800
> Subject: Re: BETA-TEST release of LambdaMOO version 1.8.0beta1
>
> Richard Connamacher writes:
> > is #0:handle_uncaught_error() and #0:handle_task_timeout() only called
> > on #0, or is it MPL-friendly? I'm working on a WWW server that uses
> > 1.8.0's MPL, and I'd like for it to be able to use its own error
> > handlers for tasks that are initialized by connections to it.
>
> Sorry; they're only called on #0.  I don't have the information necessary at
> the right time, and I'm not even sure I understand the `right' semantics for
> this idea.
>
> 	Pavel
>
>
>
> ------------------------------
>
> From: Pavel Curtis <pavel@parc.xerox.com>
> Date: Thu, 8 Feb 1996 09:57:33 -0800
> Subject: Re: Support for alt. language
>
> Kondratiev Dima writes:
> > I am looking for is a 'clean' way to support alternative character sets in
> > strings, Cyrillic for example.
> > I need  to support alternative language in string properties such as
> > object names and descriptions.
> > As I understand this problem now (correct me please, if I am wrong) parser
> > should pass
> > extended ASCII chars in strings. Do I need to hack parser code to achieve
> > this ?
>
> Actually, it has nothing to do with the parser; it has to do with the network
> module's input handler.  Right now, for non-binary connections, it discards any
> input character that isn't an ASCII printing character, space, or tab.  You
> could change that test to allow other characters and things would work fine.
> For example, you might use
> 	if ((c & 0x7F) >= 0x20  &&  (c & 0x7F) != 0x7F) {...}
> if you wanted to allow all of the eight-bit non-control characters, such as all
> of those in the Latin-1 character set.  Of course, the interpretation of those
> bytes as characters is partially fixed by the MOO language, which believes that
> it knows the identity of most codes corresponding to printing ASCII characters.
> Also, your client program is going to need to understand the `proper'
> interpretation of the codes.
>
> However, if your intended character set only *adds* to ASCII, presumably by
> giving meaning to the codes in the upper half of the one-byte space, then you
> should be in good shape.  NOTE: you *must not* allow input of the character
> codes 0x00 (the null character) or 0x0A (the line-feed/newline character); if
> either of those appears in a MOO string, you will definitely lose.
>
> Now, if you're trying to handle multi-byte character sets, like Japanese, then
> you have even more problems, like support for discovering the true length (in
> characters, not bytes) of strings, etc.
>
> 	Pavel
>
>
>
> ------------------------------
>
> End of MOO-Cows Digest V1 #328
> ******************************
>
> To subscribe to MOO-Cows-Digest, send the command:
>
>     subscribe MOO-Cows-Digest
>
> in the body of a message to "MOO-Cows-Request@PARC.Xerox.Com".  If you
> want to subscribe something other than the account the mail is coming from,
> such as a local redistribution list, then append that address to the
> "subscribe" command; for example, to subscribe "local-moo-cows":
>
>     subscribe MOO-Cows-Digest local-moo-cows@your.domain.net
>
> A non-digest (message-by-message) version of this list is also available; to
> subscribe to that instead, replace all instances of "MOO-Cows-Digest" in the
> commands above with simply "MOO-Cows".
>
> The archives of the MOO-Cows mailing list is available from the files
>     ftp://ftp.parc.xerox.com/pub/MOO/mail/MOO-Cows-*
>



-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Rion Wulfe, aka wulfe@iglou.com aka Orion@FurryMUCK aka Colt@FurryMUCK
        Long Live the Great Teutonic Squirrel Uprising!
"Who's that.. Oh. That's Cupid. He's with me, wearin' a shirt that
says `I'm with stupid!`" --- MC 9000 Foot Jesus
_-_-_-_-_-_-_-|  People like us, us two, we own the Moon. |-_-_-_-_-_-_-_
Home | Subject Index | Thread Index