[ANN] GammaMOO 1.8.3+gamma0.rc2

[Luke-Jr]

GammaMOO 1.8.3+gamma0.rc2 has been released for testing. It can be
downloaded from:
http://luke.dashjr.org/programs/gammamoo/

Please report all issues to luke+g...@dashjr.org 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

[Todd Sundsted]

Congratulations on the release Luke. It's great seeing development
happening again.

Todd

On Dec 26, 3:53 pm, "Luke-Jr" <l...@dashjr.org> wrote:
> GammaMOO 1.8.3+gamma0.rc2 has been released for testing. It can be
> downloaded from:
>        http://luke.dashjr.org/programs/gammamoo/
>

> Please report all issues to luke+gamma...@dashjr.org ASAP.

[Luke-Jr]

GammaMOO 1.8.3+gamma0.rc3 has been released for testing. It can be

[Luke-Jr]

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 luke+g...@dashjr.org 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

[Luke-Jr]

GammaMOO 1.8.3+gamma0.rc5 has been released for testing. It can be

[Josh Benner]

I haven't inspected the recent Gammas closely, but I've seen you asking why we wouldn't switch, so here's my answer:

For years I've been doing my own set of enhancements to the server to suit my needs. On top of this I have built a rather large in-DB codebase. Essentially, I'd consider moving to Gamma if I could migrate my current codebase to it without significant refactoring or migration effort.

In order to do that, I'd look for a series of features:

* 64-bit integers

* ++/--/+=/-=

* LIST tail operator (ie: mylist[] = 5 is equivalent to mylist = {@mylist, 5})

* A map datatype with syntax compatibility with the HASH patches

* WAIFs

* ... I think everything else is related to custom extensions I'd be able to add (JSON, PCRE, MySQL)

However, I'd expect migration to potentially be non-trivial in any case due to data type IDs stored in the database and/or the value storage of some of the advanced types (ie: if your map implementation were actually LISTS, the DB storage would be fundamentally different). The IDs I have stored are unlikely to match any other server implementation, so I'd probably need to modify the server temporarily to do some data type migration. I'd need to do even more migration code if the value storage were different.

So as it stands... I'm more likely to write in features from the other servers out there into my server than to try to migrate to something like stunt or Gamma.

-- 

Josh Benner

--

You received this message because you are subscribed to the Google Groups "MOO Talk" group.

To post to this group, send email to MOO-...@googlegroups.com.

To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.

[Jayson Smith]

Hi,

This actually sounds interesting. What type of MOO are you running, with
what kind of in-DB codebase? I take it you're using 64-bit ints? What
happens if someone provides an int to time() or ctime() that's outside the
range of 32-bit $minint to $maxint which is acceptable? For instance,
although Python lets you use ints much larger than $maxint, trying to use
one as a timespec doesn't work.
Jayson

--
Josh Benner

> (mailto:luke+g...@dashjr.org) 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
>
> --
> You received this message because you are subscribed to the Google Groups
> "MOO Talk" group.
> To post to this group, send email to MOO-...@googlegroups.com

> (mailto:MOO-...@googlegroups.com).

> To unsubscribe from this group, send email to
> MOO-talk+u...@googlegroups.com

> (mailto:MOO-talk+u...@googlegroups.com).

[Josh Benner]

Yes, I'm using 64-bit integers. The only problem I've encountered with ctime occurs when the timestamp yields a year greater than a 32-bit integer... so I introduced a limit that throws E_INVARG if the input is beyond the (approximate) capability of ctime().

-- 

Josh Benner

[Todd Sundsted]

Josh, are object ids 64 bit, as well?

Is there any chance you'd put your code up on GitHub?

Todd

> > > Please report all issues to luke+gamma...@dashjr.org (mailto:luke+gamma...@dashjr.org)
> > > (mailto:luke+gamma...@dashjr.org) ASAP.

[Josh Benner]

Objects, in theory, are also 64-bit, though this is (obviously?) not really tested.

I might consider putting the code up... but I admit some vanity-based hesitation since it was certainly never been written with releasing in mind, and it was the mechanism by which I learned C. These are the same reasons I doubt my code would be much use to any respectable effort to implement 64-bit integers in MOO.

-- 

Josh Benner

To post to this group, send email to MOO-...@googlegroups.com.

To unsubscribe from this group, send email to MOO-talk+u...@googlegroups.com.