lambdamoo-server — Discussions of the code of the server itself

Re: [Lambdamoo-server] refcount question

[Phil S. <ph...@of...>]

On Sun, Dec 03, 2000 at 09:29:21PM -0600, Phil Schwan wrote:
> Could someone explain new_list() in list.c a little bit?  In particular,
> why is there an addref() in the inner block, but not the outer?

D'oh.  I see the 'static' now.  Don't mind me...

-Phil

[Lambdamoo-server] refcount question

[Phil S. <ph...@of...>]

Could someone explain new_list() in list.c a little bit?  In particular,
why is there an addref() in the inner block, but not the outer?

Thanks--

-Phil

Re: [Lambdamoo-server] user-visible hash table datatype

[Phil S. <ph...@of...>]

On Fri, Dec 01, 2000 at 10:47:08PM -0800, H. Peter Anvin wrote:
> 
> There seems to be a fair amount of interest in a builtin hash type, as
> far as I can tell.

Alrighty; I've updated the patch which now includes parser and codegen
bits.  I'm not positive that my codegen/execute code is 100% correct,
so I'd especially appreciate a critical eye in these areas.

The new grammar defines [] to be an empty hash, [key->value] to be a
hash with one item, and [k1->v1, k2->v2, h3->v3, ..., hn->vn] to be a
hash with n values.  table[key] is an expression which resolves to
either 'value' or E_PROPNF, depending on whether there exists such a
mapping in the hash table.  I haven't thought of a good way to encode
hash_remove(), so I've left that builtin function for now.

Thanks--

-Phil

[Lambdamoo-server] Greetings, and some patches

[Garance A D. <dr...@rp...>]

Hi.

I work at RPI in Troy NY.  Several RPI alumni have developed
a "chat" server called "lily", which is based on lambdaMOO.
LambdaMOO has worked fairly well for this, but we have made
a number of changes over the years, and I thought I should
try to feed some of those back into the lambdaMOO project.

I don't know how active the project is, but I did track
down this mailing list at sourceforge, so I thought I'd
join it and see who's listening.

We (lily-ites) are in the process of upgrading the moo
database we use to implement lily, and in the process I've
tracked down version 1.8.1 of lambdamoo, and have been
recreating our updates.  What should I do to get these
updates applied to the "official source"?

What I have done is created my own CVS repository based on
1.8.1 that I picked up from
    ftp://ftp.place.org/pub/moo/LambdaMOO-1.8.1.tar.gz
a few months ago.  I guess that's now also available from
sourceforge.net.  I then redid all our updates, and added
a few more.  (I'm developing on freebsd, if that makes a
difference.  I'm also a committer to the freebsd project,
although I mainly work on 'lpr' for that).  I might also
try to test these changes on openbsd, if I have enough time.

At the moment I don't remember all the updates I have
added to that base, but here's a few of them just to see
if I can stir up some interest in them:

  1) I fixed configure.in to work with the most recent
     version of autoconf.  This should get lambdamoo
     to compile on more platforms.
  2) I picked up the change someone wrote so 'moo'
     can accept ssl-ed connections.  I also changed
     configure.in so that the code is only compiled
     in for systems where 'openssl' is defined.  (the
     check that I used might only recognize openssl
     under freebsd).
  3) add support for 'kill -HUP' processing.  If a
     SIGHUP is received, and if the program was
     started with the -l (logfile) parameter, then
     moo will close and re-open the logfile.  Given
     that RPI's lily server has been up for over a
     year at a stretch, and it's used by a few
     hundred people, it was important that we could
     rotate the logfile!
  4) add a '-p' option to the command-line parameters.
     If specified, this will write the processID of
     the initial moo process to a file (which is
     based on the database name || ".pid").  This is
     useful for scripts which want to automatically
     rotate the logfile, so they know WHICH process
     to send the 'kill -HUP' to!
  5) when starting up 'moo' with many parameters,
     the processing in 'set_server_cmdline()' does
     not result in a pretty result in 'ps' (at least,
     not under freebsd 3).  I have an update which
     improves that.  It also stuffs the active
     database-name into the line that 'ps' will
     display, for the benefit of those who are
     running multiple lambdaMOO-based servers on
     the same machine.
  6) add a PROMPT_PREFIX option to options.h, which
     (if it is #defined) will allow a lambdaMOO
     service to send "prefix lines" (lines without
     a trailing '\n') to it's clients.
  7) add a PROGCMD_USEAT option to options.h, which
     (if it is defined) will cause '.program' to be
     '@program'.  A dumb name, but for lily's use
     we didn't want '.program', and I wanted to put
     this in as a compile-time option...  :-)
  9) added some braces to some if-commands to avoid
     warnings about "ambiguous 'else's".

I think that's pretty close to all of the interesting
updates, but I'd have to search thru the whole CVS
repository to know for sure, and I don't feel like
doing that right now.

Since we are still in the middle of this upgrade of
lily, there might be a few more updates which will
suggest themselves for lambdaMOO.

So, are these interesting?  if so, how should I make
the patches available.  (I'm not really familiar with
how projects are run on sourceforge, or even if there
were some other route to send changes for this project).
-- 
Garance Alistair Drosehn            =   ga...@ec...
Senior Systems Programmer           or  ga...@fr...
Rensselaer Polytechnic Institute    or  dr...@rp...

Re: [Lambdamoo-server] user-visible hash table datatype

[H. P. A. <hp...@tr...>]

Phil Schwan wrote:
> 
> On Fri, Dec 01, 2000 at 10:39:52PM -0800, H. Peter Anvin wrote:
> > >
> > > HASH hash_create(void)
> > >   Returns an empty hash table; saved me from having to deal with parser.y
> > >   and codegen.
> >
> > That sounds like the wrong tradeoff.  I would be a lot happier to seem
> > something with a reasonable syntax.
> 
> That's fine--so would I--but I wanted to make sure that this was of
> interest before I spent at least another day, more likely several,
> just dealing with a nicer syntax.
> 
> (In fact, there are people on this list who could churn out the
> necessary code much faster, but I'll do it if necessary)
> 

There seems to be a fair amount of interest in a builtin hash type, as
far as I can tell.

-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: [Lambdamoo-server] user-visible hash table datatype

[Phil S. <ph...@of...>]

On Fri, Dec 01, 2000 at 10:39:52PM -0800, H. Peter Anvin wrote:
> > 
> > HASH hash_create(void)
> >   Returns an empty hash table; saved me from having to deal with parser.y
> >   and codegen.
> 
> That sounds like the wrong tradeoff.  I would be a lot happier to seem
> something with a reasonable syntax.

That's fine--so would I--but I wanted to make sure that this was of
interest before I spent at least another day, more likely several,
just dealing with a nicer syntax.

(In fact, there are people on this list who could churn out the
necessary code much faster, but I'll do it if necessary)

-Phil

Re: [Lambdamoo-server] user-visible hash table datatype

[H. P. A. <hp...@tr...>]

Phil Schwan wrote:
> 
> Greetings--
> 
> I found myself really wanting hash tables in LambdaMOO, so I spent today
> hacking them (mostly) in.  The patch at
> https://sourceforge.net/patch/?func=detailpatch&patch_id=102615&group_id=3692
> implements the following functionality:
> 
> HASH hash_create(void)
>   Returns an empty hash table; saved me from having to deal with parser.y
>   and codegen.
> 

That sounds like the wrong tradeoff.  I would be a lot happier to seem
something with a reasonable syntax.

	-hpa

-- 
<hp...@tr...> at work, <hp...@zy...> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

[Lambdamoo-server] user-visible hash table datatype

[Phil S. <ph...@of...>]

Greetings--

I found myself really wanting hash tables in LambdaMOO, so I spent today
hacking them (mostly) in.  The patch at
https://sourceforge.net/patch/?func=detailpatch&patch_id=102615&group_id=3692
implements the following functionality:

HASH hash_create(void)
  Returns an empty hash table; saved me from having to deal with parser.y
  and codegen.

void hash_insert(HASH table, ANY key, ANY value)
  Adds or replaces a key => value mapping.

ANY hash_lookup(HASH table, ANY key)
  Searches for 'key' in table, returning the value if found or (currently)
  0 otherwise. (see below)

INT hash_remove(HASH table, ANY key)
  Attempts to remove the key-value pair from table.  Returns 1 if
  successful, 0 if no mapping was found.

...along with tostr(), toliteral(), length(), db_io, 'in', equality, etc.

It's not as complete a patch as I'd like, though, and some polishing
remains:

- hash loops (ie, inserting a hash into itself) are hazardous.  Don't do
  it.  You'll crash your server.
  - the code still lets you do it, however; I haven't decided if there's
    a good way to allow loops, so I haven't written code that prevents it
- do_hash isn't portable or very efficient.  portable is easy, efficient
  might be harder.
- hash_lookup() should return something less ambiguous than 0.  Maybe a
  new error code?

That being said, it does seem to work quite well here, and I'm interested
in hearing what thoughts people have.  Comments?

-Phil

Re: [Lambdamoo-server] SGI

[Ashley M. K. <as...@pc...>]

"H. Peter Anvin" wrote:

> I think this one has to be blamed squarely on the compiler/library
> installation.  There isn't much we can do about that.
>
> Perhaps you shouldn't -U__EXTENSIONS__ and perhaps use gcc -ansi.

    That got me nowhere.  Removing -U__EXTENSIONS__ and adding -ansi resulted
into this:

$ make
gcc -ansi -Wall -Wwrite-strings -g  -O -finline-functions  -c -o \
    ast.o ast.c
In file included from ast.c:27:
storage.h:50: syntax error before `void'
In file included from ast.c:28:
utils.h:45: syntax error before `void'
utils.h:52: syntax error before `Var'
utils.h:61: syntax error before `Var'
make: *** [ast.o] Error 1
$


    If I just remove -U__EXTENSIONS__ and don't ass -ansi, I get the
following:

$ make
gcc -Wall -Wwrite-strings -g  -O -finline-functions  -c -o \
    ast.o ast.c
gcc -Wall -Wwrite-strings -g  -O -finline-functions  -c -o \
    code_gen.o code_gen.c
In file included from code_gen.c:29:
my-stdlib.h:63: conflicting types for `random'
/usr/include/stdlib.h:212: previous declaration of `random'
make: *** [code_gen.o] Error 1
$

    And just adding -ansi AND -U__EXTENSIONS__ got me the same result as the
previous -ansi attempt.

    Basically I cannot compile the server on an SGI running IRIX 6.2 with GCC
installed?  Is that what this is boiling down to?  It makes me wonder how
come there are numerous other packages out there that compile without a
problem on it.

    Hrm, there's got to be a way, dangit.

    AMK4

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  |____________________________________________________________________
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Director of Internet Operations / SysAdmin    .     800.441.3873 x130
  Photo Craft Laboratories, Inc.             .        eFax 248.671.0909
  http://www.pcraft.com                  .         3550 Arapahoe Ave #6
  .................. .  .  .     .               Boulder, CO 80303, USA

[Lambdamoo-server] SGI

[Ashley M. K. <as...@pc...>]

    Considering the amount of subscribers on this list, I'm not sure
what kind of response to expect, but anyways.

    I noticed there is (some sort of) support for IRIX (SGI), so I
thought I'd try it on my Indy running IRIX 6.2, with GCC installed.

    This is the result:

$ make moo
gcc -Wall -Wwrite-strings -g -U__EXTENSIONS__  -O -finline-functions  \
   -c -o ast.o ast.c
gcc -Wall -Wwrite-strings -g -U__EXTENSIONS__  -O -finline-functions  \
   -c -o code_gen.o code_gen.c
In file included from my-stdlib.h:25,
                 from code_gen.c:29:
/usr/include/stdlib.h:235: parse error before `ssize_t'
make: *** [code_gen.o] Error 1
$

    This is how it's defined in /usr/include/stdlib.h:

    extern void swab(const void *, void *, ssize_t);


    Suggestions anyone?  I've compiled stuff before on this machine, so
I know I can't put all the blame on the include files being...um...odd.

    AMK4

--
H | Hi, I'm currently out of my mind.  Please leave a message.  BEEEEP!
  |____________________________________________________________________
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Ashley M. Kirchner <mailto:as...@pc...>   .   303.442.6410 x130
  Websmith / SysAdmin                           .     800.441.3873 x130
  Photo Craft Laboratories, Inc.             .        eFax 248.671.0909
  http://www.pcraft.com                  .         3550 Arapahoe Ave #6
  .................. .  .  .     .               Boulder, CO 80303, USA

[Lambdamoo-server] *thok* *thok* Is this thing on?

[David G. <dg...@ta...>]

Hi. Is this mailing list live? I'm looking for a decent list with some 
LambdaMOO programming gurus on it, but the-b.org seems to have died (which 
house the Moo-Cows mailing list).

If it is... I'm writing a multiplayer space conquest game with a web front 
end, called Stellation. You can find it at http://stellation.sourceforge.net; 
currently it's in a playable state and claims to have about 90 registered 
players (but I've got no idea how many of those are actually active, however).

I'm using a LambdaMOO server as the VM behind it all. The game is written as a 
custom database; I've started from scratch with minimal.db. MOO-Code makes an 
*excellent* web application platform, by the way.

I have a number of questions about some MOO-Code programming details, however. 
For example: does anyone know a decent sorting algorithm? I could use 
quicksort, but the big disparity in speed between MOO-Code and the VM means 
that it may not be optimal (or even particularly fast). My current effort is 
here:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/stellation/numutils.moo?rev=1.4&c
ontent-type=text/x-cvsweb-markup&cvsroot=stellation

(It's at the bottom of the file; $numutils:sort().) This is a kind of 
insertion sort that makes heavy use of listinsert() and listappend(). I've 
recently discovered that the algorithm is flawed and doesn't actually sort 
properly, though I've no idea why. But is this kind of approach any better 
than a conventional sorting routine? Surely someone's already implemented this 
sort of thing?

I'll stop now and wait to see if anyone replies...

Cheers,

--David/Hjalfi

-- 
+- David Given ---------------McQ-+ "I smell a rat; I see him forming in the
|  Work: dg...@ta...         | air & darkening the sky; but I'll nip him
|  Play: dg...@in...         | in the bud." --- Sir Boyle Roche           
+- http://wired.st-and.ac.uk/~dg -+