# MOO-Cows Digest V1 #328

"Rion D. Wulfe" (wulfe@iglou.com)
Tue, 14 May 1996 19:35:50 PDT

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    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. |-_-_-_-_-_-_-_