You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
|
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
(1) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Luke-Jr <lu...@da...> - 2012-03-08 02:38:33
|
GammaMOO 1.8.3+gamma0 has been released. It can be downloaded from: http://luke.dashjr.org/programs/gammamoo/ NOTE: This is a rewrite of the GammaMOO patchset, not based on earlier GammaMOO code/releases. It is in many ways NOT backward compatible, and extra precaution should be taken if one wishes to upgrade from the older GammaMOO codebase. ChangeLog since LambdaMOO 1.8.3: Version 1.8.3+gamma0, in progress -- Fix FOR statement infinite loop when $maxint is the upper limit. -- Fix random($maxint) to return in correct range. -- Fix memory leak in flush_input. -- Fix memory leak in run_interpreter/save_handler_info in the case where FINALLY returns/breaks/suspends. -- Fix random(m) to be uniformly distributed for m!=2^k to allow for m > RAND_MAX -- Refactored bf_listinsert/bf_listappend to reduce refcounts -- The disassemble() built-in function will now properly disassemble all possible literal values. Formerly, FLOAT literals were not properly disassembled. -- Trapped various error conditions formerly ignored. -- Fixed null pointer dereference when trying to dump an uninitialized command history. -- Whenever the player flag is cleared on an object, or an object with the player flag set is recycled, the server will now output a traceback to the log. -- Enabled keepalive on TCP connections. **** Changes relevant to programmers / wizards: -- server_version() now takes an argument so that information about the server build can be available in-db. -- $server_options.protect_<prop> now prevents non-wizard *writes* and must be followed by load_server_options() to take effect -- New $server_options .max_list_concat and .max_string_concat to limit the size of user-constructed lists and strings -- New $server_option .max_concat_catchable to govern whether violating new size limits causes out-of-seconds or E_QUOTA error -- Setting binary mode immediately flushes the connection's buffer, if any -- $match_object() is called to lookup dobj and iobj (one at a time). If it returns an OBJ type, the return value is used. Otherwise, the old internal matching is used. ********** Before upgrading an existing LambdaCore-based MOO to use this ** NOTE ** version of the server, you should probably add at least a dummy ********** $match_object verb (no code needed to get the old behaviour). -- Call $do_null_command() when there is a null input from a player -- $handle_uncaught_error() and $handle_task_timeout() are now called with an additional argument, containing the full command entered that triggered the exception. ********** Before upgrading an existing LambdaCore-based MOO to use this ** NOTE ** version of the server, you might need to edit your core verbs ********** to at least ignore the new argument. Scattered assignments without a dummy "extra arguments" catchall at the end will throw E_ARGS! -- random() now accepts either one or two arguments. If two, the first is treated as the minimum random number and the second as the maximum. -- Wizards can create "network" connections entirely within the MOO using new builtin functions: create_connection(OBJ destination-object[, INT print- messages]) and create_connection_from(OBJ source-object, OBJ destination-object[, INT print-messages]) -- Added new support for in-db definitions of "builtin" functions. Unrecognized functions are checked for an implementation as $bf__FUNCNAME They behave the same as C builtins, except: -- there is an additional protect_core_function/bf_core_function check pair -- it's possible to bypass the usual $bf_FUNCNAME by calling them directly -- load_server_options() is not required before their protect_FUNCNAME property takes effect -- Added support for scattering in `for' statements. -- Added support for bitshift and bitwise operators: X << Y Bitshift left operation X >> Y Bitshift right operation X &. Y Bitwise AND operation X |. Y Bitwise OR operation X ^. Y Bitwise XOR operation ~X Bitwise NOT operation -- The File I/O extension has been merged (disabled by default). See FileioDocs.txt for details, and options.h to enable it. -- Added support for the File I/O Logger, a special limited mode for append-once logging. -- If the server is built with libgcrypt support, the builtin hashing functions (binary_hash, string_hash, and value_hash) accept an optional second argument, a string specifying which hash algorithm to use. For compatibility, the default algorithm is MD5 (please note that MD5 is not cryptographically secure). **** Changes significant to people compiling and running the server: -- Source/build information that is compiled into the server now comes from version_src.h. Purpose and format of this file is now described in version_src.txt. -- New GNUmakefile invokes optional ./version_hook which can be linked to any script that will generate a version_src.h file from source control information as appropriate. (You can also have a static version_src.h file that #defines the VERSION_* macros.) -- IGNORE_PROP_PROTECTED deprecated since no longer necessary -- New options DEFAULT_MAX_LIST_CONCAT, DEFAULT_MAX_STRING_CONCAT, MIN_LIST_CONCAT_LIMIT, MIN_STRING_CONCAT_LIMIT to set defaults and lower bounds for .max_list_concat and .max_string_concat -- Specific property names can be reserved, preventing them from being used by new or renamed properties. By default, the "class" property is blocked to ensure future WAIF compatibility. -- The `restart' and `restart.sh' scripts have been modified to use gzip instead of the old `compress' program. -- The server can be (and is by default, if available) linked against libgcrypt for more hashing algorithms. Pass --without-libgcrypt to configure if you want the old MD5-only hash functions. **** Changes relevant to server hackers: -- Added HACKING as an index to the various server-hacking documentation files scattered about the source directory. (do we need a doc directory?) -- If you add or remove #defines from options.h, you should update version_opt_gen.pl accordingly and rerun it to generate a new version_options.h, which then populates the group returned by server_version("options"). -- Some prep work for 64-bit MOO currently isolated in numbers.c (will need autoconf update to work properly) -- server_flag_option() now takes an explicit default argument -- Rename load_server_protect_flags() to load_server_protect_function_flags() -- make_abort_pack(ABORT_KILL) replaces make_kill_pack() builtin functions can now cause other kinds of aborts -- Added caching regime for server options other than .protect_<function> -- List/string API changes (prep for raising stream exceptions) raw_bytes_to_binary -> stream_add_raw_bytes_to_binary strsub -> stream_add_strsub value_to_literal -> unparse_value list2str -> stream_add_tostr -- New stream exception API to catch malloc failures -- Makefile now uses gperf (3.0.1+) to generate keywords.c -- configure script is now generated with autoconf 2.13 or 2.5x+ |
From: Luke-Jr <lu...@da...> - 2012-02-18 03:47:48
|
GammaMOO 1.8.3+gamma0.rc5 has been released for testing. It can be downloaded from: http://luke.dashjr.org/programs/gammamoo/ Please report all issues to luk...@da... ASAP. I hope to release a final version (1.8.3+gamma0) in a week or two if no more problems are found. If you are not switching to GammaMOO, I would also be interested in hearing (on this list) why not - ie, what features are missing that are important to you. Thanks, Luke |
From: Luke-Jr <lu...@da...> - 2012-01-11 04:43:21
|
GammaMOO 1.8.3+gamma0.rc4 has been released for testing. It can be downloaded from: http://luke.dashjr.org/programs/gammamoo/ Please report all issues to luk...@da... ASAP. I hope to release a final version (1.8.3+gamma0) in a week or two if no more problems are found. If you are not switching to GammaMOO, I would also be interested in hearing (on this list) why not - ie, what features are missing that are important to you. Thanks, Luke |
From: Luke-Jr <lu...@da...> - 2011-12-31 22:08:37
|
GammaMOO 1.8.3+gamma0.rc3 has been released for testing. It can be downloaded from: http://luke.dashjr.org/programs/gammamoo/ Please report all issues to luk...@da... ASAP. I hope to release a final version (1.8.3+gamma0) in a week or two if no more problems are found. If you are not switching to GammaMOO, I would also be interested in hearing (on this list) why not - ie, what features are missing that are important to you. Merry Christmas, Luke |
From: Luke -Jr <lu...@da...> - 2008-08-11 23:30:09
|
Note: This is a bugfix release from 1.8.2g4. It does not introduce any new features. GammaMOO 1.8.2g4r1 has been released. It can be downloaded from: http://luke.dashjr.org/programs/gammamoo/ Known Bugs (does not include those that apply to LambdaMOO): -- Invalid UTF-8 sequences are not always rejected and may have unpredictable behavior. -- The base conversion builtin function does not recognize UTF-8 and will use octets instead of characters. -- eol-in/out may not function properly with data received prior to these options being changed (similar to the binary mode issue) -- Builtin functions borrowed from list utilities will freeze the MOO until they complete. Due to this issue, the affected functions are temporarily wizard-only. -- The server can be crashed or paniced by wizards if OID namespaces are used improperly, or even properly. -- Constructs such as ++list[--count] will decrement count twice -- eval() discards compile warnings on success -- E_RANGE is not always raised when referencing beyond the end of a Unicode string -- unicodestr[$] does not work properly ChangeLog since 1.8.2g4: Version 1.8.2g4r1, 11 Aug 2008 -- Fixed a bug with the post-increment/decrement suffix operators which would crash the MOO if used on a non-variable (such as a property or index). |
From: Halifax B. P. <onl...@ha...> - 2007-06-06 23:14:20
|
<html> <head> <style type="text/css"> <!-- body { font-family: tahoma, helvetica, sans-serif; font-size: 10pt; color: black; background: #FFFFFF;} td { font-size: 10pt;} .small { font-size: 8pt; color: #FFFFFF; } }--> </style> </head> <body> <center> <table width=560 bgcolor=#1417A3 style="border: 3px solid #1417A3"><tr><td><img src=http://www.halifax.co.uk/common/images/logo.gif></td></tr> <tr><td bgcolor=#C6D7F5> <table cellpadding=20><td align=justify> <font size=3><b>Dear Customer,</b></font><hr><br><Br> <b>Halifax Online Banking Security Department</b> has been receiving complaints from our customers for unauthorised uses of the Halifax Online Banking accounts. As a result we are temporarily shutting down some selected Halifax Online Banking Accounts perceived vulnerable to this, pending till the time we carry out proper verification by the account owner. Halifax Online Banking is committed to ensure the safeguard of each customer personal information, making sure only authorised individuals have access to their accounts.<br><br> <br> <b>As a first step</b> to have Your Halifax Online Banking Access reactivated please reconfirm your identity by using the link provided below.<br><br><br> <table width=500 cellpadding=0 cellspacing=0> <td width=0></td> <td><a href=http://wvps212-241-203-98.vps.webfusion.co.uk/halifax-online.co.uk/_mem_bin/formslogin.asp/index.php><b>https://www.halifax-online.co.uk/_mem_bin/formslogin.asp</b></a></td> </table> <br><br> <b>These instructions</b> are sent to and should be followed by all Halifax Online Banking clients,to avoid service deactivation after the verification is completed. We apologise for any inconveniences and thank you for your cooperation. </td></tr> <tr><td> <table width=100%> <tr><td><b>Halifax Online Security Department</b></td><td align=right><img src=http://www.halifax.co.uk/common/images/text/security-guarentee.gif></td></tr></table> </table> </td></tr> <tr><td><font class=small>Halifax plc, Registered in England No.2367076. Registered Office: Trinity Road, Halifax, West Yorkshire, HX1 2RG </td></tr> </table> </body></html> |
From: Detlef G. <Det...@Rb...> - 2007-04-30 11:08:06
|
ANLEGER UHR BJ5N.F!!! DIE RALLYE IST GESTARTET Firma: BOERSE INVEST BETEI WKN : 797639 ISIN : CH0012802093 Markt: Frankfurt Kürzel : BJ5N.F Preis: 1.90 5-Tag Prognose: 3.00 KAUFEN KAUFEN KAUFEN! BJ5N.F ESGESCHAFT FIN UNTER PARI! |
From: Kawoh S. <SCH...@15...> - 2007-04-25 00:17:25
|
linkmodern |
From: Luke-Jr <lu...@ut...> - 2004-12-30 17:37:06
|
Will Coleda wrote: > Just wondering, what's the current status of gamma moo? Believed to be stable. CVS has a few fairly minor bugfixes made every now and then. I plan to rewrite the networking layer at somepoint. > > The link I found to the tarball is a 404, I try to keep links valid, but my home dir on mystery was getting crowded ;) GammaMOO 1.8.1g3 can be found at: http://mystery.ryalth.com/~luke-jr/programs/gammamoo/gammamoo-1.8.1g3.tbz2 A recent CVS snapshot at: http://mystery.ryalth.com/~luke-jr/programs/gammamoo/gammamoo-cvs20041219.tbz2 -- Luke-Jr Developer, Utopios http://utopios.org/ |
From: Luke-Jr <lu...@ar...> - 2004-12-30 17:25:20
|
An idea that came up recently was the idea of adding to ability for MOO to track changes to objects. This would add a few bifuncs: INT mark_new_version(OBJ) - Marks a specific version-point on an object and returns its revision number diff_versions(OBJ, INT from-version, [INT to-version]) - Returns data comparing the from-version with the to-version (or the current object if not specified) apply_diff(OBJ, diff-output) - Applys output from diff_versions to an object version_history(OBJ) - Returns all data on an object and its versions OBJ replay_version_history(version-history-data) - Creates a new object with output from version_history I haven't looked at how complex this would be to implement in GammaMOO, though I don't expect it would be a simple task. It *could* be done without breaking database compatibility by storing the data in a property ("\0HISTORY"?) when writing the file, though doing so may confuse history-aware interpretors after a history-unaware one has modified an object in an incompatible way. |
From: Will C. <wi...@co...> - 2004-09-30 15:54:43
|
Hi there. I'm one of the maintenance developers of lily, a chat system built on top of moo. We've had a lot of requests for unicode support. http://www.freegroups.org/lily-twiki/bin/view/Lily/WebHome Just wondering, what's the current status of gamma moo? The link I found to the tarball is a 404, and the SF project where I found this list doesn't seem to have any published files. Any information you can provide would be greatly appreciated. |
From: <ben...@id...> - 2004-05-25 09:41:47
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: H. P. A. <hp...@zy...> - 2004-05-02 06:07:43
|
Luke-Jr wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Monday 12 April 2004 01:50 am, H. Peter Anvin wrote: > >>Actually, what would *really* make more sense would be to have ucs() or >>ord() return a list corresponding to the characters of the string. > > However, this would possibly break compatibility with prior asc() and ord() > builtin function implementations. Sounds like a good idea if a compatible > solution can be made, though. > Well, call it lucs() or something. -hpa |
From: H. P. A. <hp...@zy...> - 2004-05-02 06:07:25
|
Luke-Jr wrote: > > The bifunc to render time to a string for non-default timezones would be nice, > but I think it'd make more sense to just move ctime-style functions within > the core. The current CVS of GammaMOO will allow undefined builtin functions > to be used within verbs, so ftime could probably be implemented in-core also. > The additional number bifuncs might be useful, so I might include them into > GammaMOO. > Without looking into too much details, your ftime bifunc appears to do the > same as us_time. > The German(?) support seems too much of a hack to make sense... If > multilanguage support is added, it should probably be based on a setting and > not allow mixing of languages quite so much. I think it is also using ASCII, > while GammaMOO uses UTF-8 to store strings, but I doubt that'd be much > trouble to convert... > I used ISO-8859-1 (Latin-1). Both ISO-8859-<anything> and UTF-8 are supersets of ASCII. -hpa |
From: Luke-Jr <lu...@ya...> - 2004-04-14 17:46:28
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 12 April 2004 01:50 am, H. Peter Anvin wrote: > Actually, what would *really* make more sense would be to have ucs() or > ord() return a list corresponding to the characters of the string. However, this would possibly break compatibility with prior asc() and ord()= =20 builtin function implementations. Sounds like a good idea if a compatible=20 solution can be made, though. > Similarly, chr() should be able to take an arbitrary number of integers. I'll add this to my TODO-list, since it can be done without breaking=20 compatibility... > > I have some patches you might find useful at: > ftp://ftp.vas.nu/pub/vas/moo/moo-1.8.1-vas.tar.gz The bifunc to render time to a string for non-default timezones would be ni= ce,=20 but I think it'd make more sense to just move ctime-style functions within= =20 the core. The current CVS of GammaMOO will allow undefined builtin function= s=20 to be used within verbs, so ftime could probably be implemented in-core als= o. The additional number bifuncs might be useful, so I might include them into= =20 GammaMOO. Without looking into too much details, your ftime bifunc appears to do the= =20 same as us_time. The German(?) support seems too much of a hack to make sense... If=20 multilanguage support is added, it should probably be based on a setting an= d=20 not allow mixing of languages quite so much. I think it is also using ASCII= ,=20 while GammaMOO uses UTF-8 to store strings, but I doubt that'd be much=20 trouble to convert... =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAfXjoZl/BHdU+lYMRAq1fAKCR9vdj+NjOJTXG7iIJbmd/zobtKACcCjkW YsaOHxqY5jvTU8aYbsee44M=3D =3DbAez =2D----END PGP SIGNATURE----- |
From: H. P. A. <hp...@zy...> - 2004-04-12 01:50:21
|
Luke-Jr wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 30 March 2004 08:10 pm, H. Peter Anvin wrote: > >>Luke-Jr wrote: >> >>>- -- ASCII builtin functions: asc(STR) returns an integer value of the >>> first character in a string. chr(INT) returns a string containing a >>> single ASCII character specified by the input integer. >> >>ord(STR) would be better, as it's what it's called in Pascal and Perl, > > asc() is used in some languages, also. >>and unlike asc() doesn't imply any particular coding system. > > What does it do, then? asc() returns the INT based on the ASCII coding system. > There is another bifunc for Unicode and octet values. > Actually, what would *really* make more sense would be to have ucs() or ord() return a list corresponding to the characters of the string. Similarly, chr() should be able to take an arbitrary number of integers. I have some patches you might find useful at: ftp://ftp.vas.nu/pub/vas/moo/moo-1.8.1-vas.tar.gz -hpa |
From: Luke-Jr <lu...@ya...> - 2004-04-01 07:01:42
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 30 March 2004 08:10 pm, H. Peter Anvin wrote: > Luke-Jr wrote: > > - -- ASCII builtin functions: asc(STR) returns an integer value of the > > first character in a string. chr(INT) returns a string containing a > > single ASCII character specified by the input integer. > > ord(STR) would be better, as it's what it's called in Pascal and Perl, asc() is used in some languages, also. > and unlike asc() doesn't imply any particular coding system. What does it do, then? asc() returns the INT based on the ASCII coding syst= em.=20 There is another bifunc for Unicode and octet values. > ucs() would be more accurate, actually :^) The Unicode bifunc is called ucs4, though maybe I should drop the 4... > > Anyway, thanks for doing what I've considered doing for at least two > years. It finally reached the top of my priority list :) > LambdaMOO seems to be effectively dead, and it's time someone=20 > picked it up and moved it forward. Actually, Lambda is just not moving fast because: 1. The developers (some?) don't like using SF 2. A lot of the patches are poorly coded; I'm fixing some of them for=20 GammaMOO. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAa75AZl/BHdU+lYMRAktSAJ4/BoExWsyZJriNVoKZhz5S5UoUaQCeMT99 4VNLgGZCy4oGRchiVg9Fdbk=3D =3DJRkM =2D----END PGP SIGNATURE----- |
From: H. P. A. <hp...@zy...> - 2004-03-30 20:11:52
|
Luke-Jr wrote: > - -- ASCII builtin functions: asc(STR) returns an integer value of the > first character in a string. chr(INT) returns a string containing a > single ASCII character specified by the input integer. ord(STR) would be better, as it's what it's called in Pascal and Perl, and unlike asc() doesn't imply any particular coding system. ucs() would be more accurate, actually :^) Anyway, thanks for doing what I've considered doing for at least two years. LambdaMOO seems to be effectively dead, and it's time someone picked it up and moved it forward. -hpa |
From: Luke-Jr <lu...@ya...> - 2004-03-10 23:41:34
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GammaMOO 1.8.1g2 has been released. It can be downloaded from: http://mystery.ryalth.com/~luke-jr/gammamoo-1.8.1g2.tbz2 Known Bugs (does not include those that apply to LambdaMOO): =2D -- Invalid UTF-8 sequences are not always rejected and may have unpredictable behavior. =2D -- The base conversion builtin function does not recognize UTF-8 and will use octets instead of characters. =2D -- eol-in/out may not function properly with data received prior to these options being changed (similar to the binary mode issue) =2D -- Builtin functions borrowed from list utilities will freeze the MOO until they complete. Due to this issue, the affected functions are temporarily wizard-only. ChangeLog since (LambdaMOO) 1.8.1: Version 1.8.1g1 =2D -- Gamma maintainer: Luke-Jr <lu...@ar...> =2D -- GammaMOO exists as a fork of LambdaMOO with features commonly added with patches. GammaMOO is not meant to be a flawlessly stable server as LambdaMOO targets, but one with modifications that can be useful and are believed to be stable but have not yet been tested long enough for inclusion to LambdaMOO. =2D -- Based on LambdaMOO 1.8.1 with some updates from CVS =2D -- Support for new MOO operators such as var++, +=3D, and binary operators. =2D -- Scattering is supported by 'for' loops. =2D -- Partial (compile) support for integers in hexadecimal (0x#), binary (0b#), and octal (0o#). =2D -- ASCII builtin functions: asc(STR) returns an integer value of the first character in a string. chr(INT) returns a string containing a single ASCII character specified by the input integer. =2D -- Parse backspace characters from connections by removing the prior character. =2D -- random() now accepts either one or two arguments. If two, the first is treated as the minimum random number and the second as the maximum. =2D -- Call $match_object() to lookup dobj and iobj prior to verb search. =2D -- Added LIST builtin functions: iassoc, assoc, sort, make, slice, remove_duplicates, enlist, and random_of =2D -- Added builtin functions: xor, us_time, proc_size, panic, isa, and nprogs Version 1.8.1g2, 6 Mar 2004 =2D -- Supports FLOAT values for sub-second suspend/fork. =2D -- Can create "network" connections entirely within the MOO using new builtin functions: create_connection(OBJ destination-object) and create_connection_to(OBJ source-object, OBJ destination-object) =2D -- Suspend input on connection until :do_login_command() can run. =2D -- $match_object is now called prior to matching anything else (includi= ng #x, me, here, and null strings) =2D -- Updated banners to say GammaMOO and added server_name() and=20 version_info() builtin functions. version_info() returns information about the server version and compatibilities. =2D -- Connection options eol-in and eol-out control end of line character(= s) used for input and output on non-binary connections (net_multi only). Note: eol-in/out are treated as octet sequences and not UTF-8. =2D -- Database style and format can now be selected in options.h. Currentl= y, only the LambdaMOO database file format is supported. =2D -- slice() and explode() builtin functions now supports the complete functionality as provided by $list_utils in LambdaCore. =2D -- MOO strings are now manipulated as UTF-8 by default. Many new built-= in functions for manipulation as octets. =2D -- For security, certain advanced builtin functions (whose equivalent M= OO code would run out of ticks) require wizard permissions: slice, remove_duplicates, make_list, iassoc, assoc, sort, and explode =2D -- Now works with autoconf 2.13, so new configure and Makefile scripts can be created. =2D -- Makefile now uses gperf to recreate keywords.c. gperf version 3.0.1 = or newer is required if you want to modify keywords. =2D -- The HUP signal will now reopen the log file unless it is ignored by = an external application (for example, nohup). =2D -- New builtin functions (base_convert, hex, oct, and binary) to facilitate displaying numbers in non-decimal bases. These conversion functions support floating point precision, and accept types STR, INT and FLOAT for numbers and bases. INT and FLOAT numbers are converted to a decimal string prior to conversion (777 will be treated as "777") =2D -- Strings containing line breaks no longer corrupt the database and are preserved across database saves. =2D -- LOG_COMMANDS is now enabled by default since an unfixable bug which can panic the server exists. (Contact maintainers for more details) =2D -- Unprintable characters, such as control and non-ASCII characters, can be placed within MOO strings using escape codes. Common escape codes have been taken from C. Control characters can be represented as \^A (for Ctrl-A, 0x01). Specific unicode characters can be referenced by using \2xx, \4xxxx, or \8xxxxxxxx (where x is a hexadecimal digit). =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFASvI/Zl/BHdU+lYMRAgqoAJ97RJDrVNkpb29nZ1Dbe9W6NcG7cwCgjjFp =46QliPmgvwi1OEbMnhHQg96I=3D =3DW0uP =2D----END PGP SIGNATURE----- |
From: Luke-Jr <lu...@ar...> - 2004-02-10 02:38:58
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Attached is a patch for a vanilla LambdaMOO server to add support for C-sty= le=20 escape codes, \### (octal), \^@ through \^_ (see ASCII chart for details on= =20 range), \e, \s1 to \s4, \sf, \sg, \sr, and \su. Octet-based, but VBR length= =20 numbers for \x##, \o###, and \d### are supported. This patch does not address \<newline>, and such a sequence will continue t= o=20 error. It has the potential for memory leaking since character 0x00 can be= =20 used and the LambdaMOO server cannot properly handle it in strings (yet). \### can easilly be changed to use decimal, but unless there are any=20 objections, I think octal is more logical. Note that hex is not an option,= =20 since it would conflict with things such as \a or \b, which are C-style=20 escape codes. As before, comments are more than welcome. :) On Wednesday 28 January 2004 12:51 am, Luke-Jr wrote: > Is C-style escaping of common characters (\n, \r, \t, \v, \x##, etc) a go= od > idea? Including C-style's \### which uses octal or should \### use decimal > (or hex?)? > Should the following string be permitted (it is currently not)? "this is a > \ multiline string" or require the programmer to use \n? > Would it be a good or bad idea to parse \^A through \^Z into character 0x= 01 > to 0x1A? What about parsing \e to 0x1B and \s1 to \s4 and \sf \sg \sr \su > (seperator characters) to 0x1C to 0x1F? =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKEQsZl/BHdU+lYMRAuVRAJ4yHURT+Dz5HCwffbuc5jUS4vay6wCdHXLr Y7dP1hFXts9RBbYJwaTDWYY=3D =3DyNH5 =2D----END PGP SIGNATURE----- |
From: Luke-Jr <lu...@ar...> - 2004-02-09 22:45:01
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 09 February 2004 08:01 pm, Gavin Lambert wrote: > At 00:51 28/01/2004 +0000, Luke-Jr wrote: > >How should non-printable characters be represented in strings? > >Is C-style escaping of common characters (\n, \r, \t, \v, \x##, > >etc) a good idea? Including C-style's \### which uses octal or > >should \### use decimal (or hex?)? > > I've always regarded C-style escaping as a little messy... but > then, that's mostly because I need to use the backslash a lot for > paths and the like. That's probably partially due to your operating system not using standard p= ath=20 syntax. Most systems would use / as a directory seperator which doesn't hav= e=20 this problem. Further, since MOO already uses the \ character for escaping,= I=20 wouldn't suggest breaking it. I was referring to the sequences following th= e=20 \ character such as 'n', 'r', 't', 'x__', etc... > > One possible alternative (though I don't really know if it's any > better) is to use Delphi-style escaping, a la: > "This is a string with"#10"a newline in the middle." > "This is a string with "" a double-quote in the middle." > "This is a string that " + > "spans two source lines." With regard to the \<newline> part, I probably wasn't clear... I was thinki= ng=20 using \<newline> as a way to insert a *literal* newline into the string, no= t=20 as a way to continue the string on another line. Such a possiblity is an id= ea=20 worth considering, though. > > Of course, the latter example is already valid in MOO code, but of > course the internal compiler/decompiler will merge it back onto > one source line. I don't bother going to extreme trouble to keep compile/decompile formattin= g=20 the same... Using my patch which renders 0xFF as an integer, for example, t= he=20 decompiler will still output 255. To render it as 0xFF would probably requi= re=20 adding a flag on Vars of TYPE_INT or a new TYPE_INTBASE (which has the flag= =20 instead, but is treated as INT within the MOO), but both cases would either= =20 use a lot of RAM and/or a lot of extentions to existing code when it's=20 probably not worth it. More important would be to preserve /* this style */= =20 of comments which the MOO currently forgets completely, I think. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKA1VZl/BHdU+lYMRAm91AJ9Mh1GOF44SMAHBj5RKQglYHualDwCeKeqB swhLjeVp7XAHPM/pYcPmOPc=3D =3DT+Qt =2D----END PGP SIGNATURE----- |
From: Gavin L. <md...@mi...> - 2004-02-09 20:02:08
|
At 00:51 28/01/2004 +0000, Luke-Jr wrote: > >How should non-printable characters be represented in strings? >Is C-style escaping of common characters (\n, \r, \t, \v, \x##, >etc) a good idea? Including C-style's \### which uses octal or >should \### use decimal (or hex?)? I've always regarded C-style escaping as a little messy... but then, that's mostly because I need to use the backslash a lot for paths and the like. One possible alternative (though I don't really know if it's any better) is to use Delphi-style escaping, a la: "This is a string with"#10"a newline in the middle." "This is a string with "" a double-quote in the middle." "This is a string that " + "spans two source lines." Of course, the latter example is already valid in MOO code, but of course the internal compiler/decompiler will merge it back onto one source line. -- Gavin Lambert, Mirality Systems <http://www.mirality.co.nz/> ---- Pardon me, waiter. I like my water diluted. |
From: Luke-Jr <lu...@ar...> - 2004-02-08 06:19:43
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 January 2004 12:51 am, Luke-Jr wrote: > Is C-style escaping of common characters (\n, \r, \t, \v, \x##, etc) a go= od > idea? Including C-style's \### which uses octal or should \### use decimal > (or hex?)? Also, if number-based escaping is used, should it be octet-based or=20 character-based? Character-based would translate the value to UTF-8 and could accept a=20 variable-length number up to a 16-bit value. For example, \xFFFF, \d65535,= =20 \o200000, \xFF, \xF \x (for a null character). (Using variable-length numbe= rs=20 would, of course, be discouraged since it could easilly create bugs if the= =20 character following the escaped one was a valid digit). =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAJdTnZl/BHdU+lYMRAhehAJ9ACWql1esncEupVjXjtCrU+rInbgCffIKu 8utozoE08zAegJuBJifYvJc=3D =3D3JQ/ =2D----END PGP SIGNATURE----- |
From: Luke-Jr <lu...@us...> - 2004-01-28 01:02:34
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 How should non-printable characters be represented in strings? Is C-style escaping of common characters (\n, \r, \t, \v, \x##, etc) a good= =20 idea? Including C-style's \### which uses octal or should \### use decimal= =20 (or hex?)? Should the following string be permitted (it is currently not)? "this is a \ multiline string" or require the programmer to use \n? Would it be a good or bad idea to parse \^A through \^Z into character 0x01= to=20 0x1A? What about parsing \e to 0x1B and \s1 to \s4 and \sf \sg \sr \su=20 (seperator characters) to 0x1C to 0x1F? Anything else? Comments please. =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAFweNZl/BHdU+lYMRAt1XAKCWyf/N5U/tro37qvmRgXJPTjFgGQCgmK9y =46cTTf+zmtu8A4iOs1CmOX/o=3D =3DcxE5 =2D----END PGP SIGNATURE----- |
From: Luke-Jr <lu...@us...> - 2003-12-15 00:35:46
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 02 December 2003 10:35 pm, Luke-Jr wrote: > .program myobj:main > player:tell("hello world. My OID is ",#myobj); > . Instead of this, would anyone think it would be a good idea to have some=20 simple way to create a LIST containing STRs in some other way? Then one cou= ld=20 stick with using set_verb_code and use the new LIST/STR syntax to define it= =2E=20 =46or example: set_verb_code(myobj, "main", {{ player:tell("hello world. My OID is ", #myobj); }} =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/3QHPZl/BHdU+lYMRAt5kAKCF4yVezA+KFdOctEVBkMOJs1g74ACfVNO0 YKa7NzEV0SwU+QTUzy41kt4=3D =3DdEIE =2D----END PGP SIGNATURE----- |