On Mon, Dec 06, 2004 at 02:36:47PM -0800, H. Peter Anvin wrote:
> Sean Davis wrote:
> >
> >It does seem that way. I've rewritten most of the network code in
> >LambdaMOO 1.8.1+foo, since it was, well, ancient and disgusting. (sorry, 
> >but
> >there hasn't been a need to use /dev/tcp on Solaris in the last, oh, ten
> >years :P)
> >
> >Now the network stuff at least is sane. Too bad I've still gotta eventually
> >rewrite the memory stuff / ref counting - it's horribly broken on Alpha, 
> >and
> >very very poorly designed in the first place. (don't believe me? watch the
> >infinite loop you get when trying to load a working core into a lambdamoo
> >binary linked against electricfence..)
> >
> >The lambda+foo project is basically aimed at (some day) having a good MOO
> >server based on the old code but with all the glaring problems fixed. Some
> >day might be quite a while away, but we have improved things a bit, at
> >least.
> >
> 
> So we have lambda+foo, GammaMOO, etc, ... it seems awful that we need 
> all this forking.

Agreed. Very wholeheartedly. Maintaining a fork with a bunch of code changes
and then picking up the (rare!!) change from the lambdamoo sf project sucks:
it usually needs to be manually merged, due to, for instance, the fact that
I took $Log$ out of my sources a long long time ago (all it does is bloat
them, and I can run cvs log ;), among other changes.

> Also, with 32-bit computers on the way out, dumping the use of symlinks 
> for floating-point numbers is a good thing, and similarly, we should 
> enable Unicode handling.

Yes. In fact, it surprises me very much that I can load a core on a MSB LP64
machine (UltraSPARC in this case) and have it work just fine. Then again,
UltraSPARC is not nearly as picky as Alpha when it comes to unaligned memory
access.

> 
> I guess what I'm asking is: is there any reason to not do this kind of 
> work against the CVS tree on Sourceforge, and to pick someone as release 
> coordinator, for something we can call 1.9.0 or 2.0.0?

Well, I would like to say this is a good idea, but I'm not sure. Different
people want different feature sets in their server... for example, I have
the lists builtins (modified), both FileIO and FUP (both of which I use),
and some extensions I've written myself. Many people might not want any of
that. Many might want some of it. Many might want more. So... since we don't
have a stable base we can just maintain patches against, we end up with a
handful of forks, all of which I would be signifigantly differ from each
other. Whoever ends up with the task as release coordinator... I pity them,
having to put all the pieces together in a way that causes the least burning
at the stake ;-)

-Sean

-- 
/~\ The ASCII
\ / Ribbon Campaign                   Sean Davis
 X  Against HTML                       aka dive
/ \ Email!

#############################################################
This message is sent to you because you are subscribed to
  the mailing list <[EMAIL PROTECTED]>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to