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

[Lambdamoo-server] LambdaMOO down?

[JP Carnes-S. <jpc...@gm...>]

Hi all! Mars from LambdaMOO here. Is there anything I / we can do to help get LMoo back online? I’m experiencing withdrawal symptoms :)

-JP Carnes-Stine / Mars
jpc...@gm...

[Lambdamoo-server] (no subject)

[Emry <em...@dv...>]

   Greetings 


https://bit.ly/2O962g6





Emry

[Lambdamoo-server] hello

[Emry <em...@te...>]

Hello 

http://binarencanaagung.com/fog.php?love=166dmdkvz9a1y




Emry

[Lambdamoo-server] Fw: new important message

[<no...@no...>]

Hello!

 

New message, please read <http://www.narc-charity.ca/simple.php?0v>

 

no...@no...

Re: [Lambdamoo-server] [ANN] Release 9 of the Stunt Extensions to LambdaMOO

[Todd S. <tod...@gm...>]

Agreed on both points.  If I were going to build MOO up from scratch, I
think I would have started with objects that were anonymous and garbage
collected, and added "permanence" to a subset of those.  Maybe it's not too
late...

As it is, I picked a set of constraints that made the introduction of
anonymous objects easier.  However, there are good reasons for finding
solutions that remove those constraints.  For example, finding a way to
lazily update the structure of child objects would remove the constraint I
mentioned below.  It might also lend itself to better cache performance for
permanent objects with many children because the server wouldn't have to
hit many points in memory immediately updating the children.

Todd


On Wed, Jan 16, 2013 at 1:17 AM, H. Peter Anvin <hp...@zy...> wrote:

> On 12/18/2012 02:34 AM, Todd Sundsted wrote:
>
>>
>> There are a few exceptions to the "anonymous objects are just like
>> permanent objects" guideline.  Anonymous objects cannot be parents of
>> other objects.  Anonymous objects don't show up in an another objects's
>> contents, location, parents, or children, nor can an anonymous object
>> own other objects; since anonymous objects are not tracked as children
>> of other objects, there's no easy way to fix up the properties layout if
>> parents/properties change in an ancestor -- so an anonymous object
>> simply becomes invalid when structural changes happen up the line.  Some
>> of these restrictions may be lifted in the future.
>>
>>
> A more logical way to do this may simply be to treat managed objects
> simply as a special case of anonymous objects -- assigning them a permanent
> number just bumps the count.  Similarly, keep the anonymous objects as
> children and parents as normal; being a parent occupies a count.
>
> As usual, with reference-counting garbage collectors you have the problems
> with recursive structures.
>
>         -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel.  I don't speak on their behalf.
>
>

Re: [Lambdamoo-server] [ANN] Release 9 of the Stunt Extensions to LambdaMOO

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

On 12/18/2012 02:34 AM, Todd Sundsted wrote:
>
> There are a few exceptions to the "anonymous objects are just like
> permanent objects" guideline.  Anonymous objects cannot be parents of
> other objects.  Anonymous objects don't show up in an another objects's
> contents, location, parents, or children, nor can an anonymous object
> own other objects; since anonymous objects are not tracked as children
> of other objects, there's no easy way to fix up the properties layout if
> parents/properties change in an ancestor -- so an anonymous object
> simply becomes invalid when structural changes happen up the line.  Some
> of these restrictions may be lifted in the future.
>

A more logical way to do this may simply be to treat managed objects 
simply as a special case of anonymous objects -- assigning them a 
permanent number just bumps the count.  Similarly, keep the anonymous 
objects as children and parents as normal; being a parent occupies a count.

As usual, with reference-counting garbage collectors you have the 
problems with recursive structures.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Re: [Lambdamoo-server] [MOO-talk] [ANN] Release 9 of the Stunt Extensions to LambdaMOO

[Todd S. <tod...@gm...>]

Chris, thanks for asking!

Stunt is a fork of the LambdaMOO server, so you would use it to load and
run your database, rather than include it in your database.  Information is
available in the following places:

  http://stunt.io/
  https://github.com/toddsundsted/stunt

A few warnings: 1) Make a backup of your original database!!!  Stunt uses a
different database format, and there is no way back!  2) Stunt is
relatively untested in production, in relation to LambdaMOO.  It's really
intended for hackers only at this point in time.

Best of luck!

Todd



On Tue, Dec 18, 2012 at 7:08 AM, Chris <chr...@go...> wrote:

> Hi Tod,
> Where can I read about including stunt in my current db? Is this even
> possible?
>
> Cheers,
>
> Sent from my iPad
>
> On 18 Dec 2012, at 10:34, Todd Sundsted <tod...@gm...> wrote:
>
> Release 9 of the Stunt Extensions to the LambdaMOO Server is now available.
>
>   https://github.com/toddsundsted/stunt
>
> The major new feature of this release is anonymous (garbage collected)
> objects.  The release also includes more documentation and
> fixes/enhancements to JSON parsing/generation, multiple inheritance,
> map/list limits.
>
> Anonymous objects are objects without an assigned object number, and
> without a slot in the array of permanent/managed objects.  In many ways
> they look like permanent objects -- they can inherit verbs and properties
> from one or more parent objects, and they can have verb and property
> definitions of their own.  However, unlike permanent objects, they are
> garbage collected when no longer used (more specifically, when no value or
> code holds a reference to them).  Perhaps more importantly, their anonymity
> makes them easier to secure -- it's impossible to forge a reference to an
> anonymous object.
>
> To create an anonymous object, pass the integer `1' as the final argument
> to `create()' (e.g. "create(#123, 1);"). The resulting object is bare (it's
> basically a pointer directly to the `Object' struct).  Only wizards and
> owners can create anonymous objects, however, there is a new `a' flag that
> indicates (in a manner similar to the `f' flag) that an object can be the
> parent of anonymous children.
>
> There are a few exceptions to the "anonymous objects are just like
> permanent objects" guideline.  Anonymous objects cannot be parents of other
> objects.  Anonymous objects don't show up in an another objects's contents,
> location, parents, or children, nor can an anonymous object own other
> objects; since anonymous objects are not tracked as children of other
> objects, there's no easy way to fix up the properties layout if
> parents/properties change in an ancestor -- so an anonymous object simply
> becomes invalid when structural changes happen up the line.  Some of these
> restrictions may be lifted in the future.
>
> The database format changed again, so make sure you create a backup of
> your database before trying this release out!
>
> If you want to try out a core that uses this functionality, check out
> Improvise:
>
>   https://github.com/toddsundsted/improvise
>
> For more information and the complete list of available packages:
>
>   http://stunt.io/
>
> Todd
>
> --
> You received this message because you are subscribed to the Google Groups
> "MOO Talk" group.
> To post to this group, send email to MOO...@go....
> To unsubscribe from this group, send email to
> MOO...@go....
> For more options, visit this group at
> http://groups.google.com/group/MOO-talk?hl=en.
>
>

Re: [Lambdamoo-server] [MOO-talk] [ANN] Release 9 of the Stunt Extensions to LambdaMOO

[Chris <chr...@go...>]

Hi Tod,
Where can I read about including stunt in my current db? Is this even possible?

Cheers,

Sent from my iPad

On 18 Dec 2012, at 10:34, Todd Sundsted <tod...@gm...> wrote:

> Release 9 of the Stunt Extensions to the LambdaMOO Server is now available.
> 
>   https://github.com/toddsundsted/stunt
> 
> The major new feature of this release is anonymous (garbage collected) objects.  The release also includes more documentation and fixes/enhancements to JSON parsing/generation, multiple inheritance, map/list limits.
> 
> Anonymous objects are objects without an assigned object number, and without a slot in the array of permanent/managed objects.  In many ways they look like permanent objects -- they can inherit verbs and properties from one or more parent objects, and they can have verb and property definitions of their own.  However, unlike permanent objects, they are garbage collected when no longer used (more specifically, when no value or code holds a reference to them).  Perhaps more importantly, their anonymity makes them easier to secure -- it's impossible to forge a reference to an anonymous object.
> 
> To create an anonymous object, pass the integer `1' as the final argument to `create()' (e.g. "create(#123, 1);"). The resulting object is bare (it's basically a pointer directly to the `Object' struct).  Only wizards and owners can create anonymous objects, however, there is a new `a' flag that indicates (in a manner similar to the `f' flag) that an object can be the parent of anonymous children.
> 
> There are a few exceptions to the "anonymous objects are just like permanent objects" guideline.  Anonymous objects cannot be parents of other objects.  Anonymous objects don't show up in an another objects's contents, location, parents, or children, nor can an anonymous object own other objects; since anonymous objects are not tracked as children of other objects, there's no easy way to fix up the properties layout if parents/properties change in an ancestor -- so an anonymous object simply becomes invalid when structural changes happen up the line.  Some of these restrictions may be lifted in the future.
> 
> The database format changed again, so make sure you create a backup of your database before trying this release out!
> 
> If you want to try out a core that uses this functionality, check out Improvise:
> 
>   https://github.com/toddsundsted/improvise
> 
> For more information and the complete list of available packages:
> 
>   http://stunt.io/
> 
> Todd
> 
> -- 
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To post to this group, send email to MOO...@go....
> To unsubscribe from this group, send email to MOO...@go....
> For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.

[Lambdamoo-server] [ANN] Release 9 of the Stunt Extensions to LambdaMOO

[Todd S. <tod...@gm...>]

Release 9 of the Stunt Extensions to the LambdaMOO Server is now available.

  https://github.com/toddsundsted/stunt

The major new feature of this release is anonymous (garbage collected)
objects.  The release also includes more documentation and
fixes/enhancements to JSON parsing/generation, multiple inheritance,
map/list limits.

Anonymous objects are objects without an assigned object number, and
without a slot in the array of permanent/managed objects.  In many ways
they look like permanent objects -- they can inherit verbs and properties
from one or more parent objects, and they can have verb and property
definitions of their own.  However, unlike permanent objects, they are
garbage collected when no longer used (more specifically, when no value or
code holds a reference to them).  Perhaps more importantly, their anonymity
makes them easier to secure -- it's impossible to forge a reference to an
anonymous object.

To create an anonymous object, pass the integer `1' as the final argument
to `create()' (e.g. "create(#123, 1);"). The resulting object is bare (it's
basically a pointer directly to the `Object' struct).  Only wizards and
owners can create anonymous objects, however, there is a new `a' flag that
indicates (in a manner similar to the `f' flag) that an object can be the
parent of anonymous children.

There are a few exceptions to the "anonymous objects are just like
permanent objects" guideline.  Anonymous objects cannot be parents of other
objects.  Anonymous objects don't show up in an another objects's contents,
location, parents, or children, nor can an anonymous object own other
objects; since anonymous objects are not tracked as children of other
objects, there's no easy way to fix up the properties layout if
parents/properties change in an ancestor -- so an anonymous object simply
becomes invalid when structural changes happen up the line.  Some of these
restrictions may be lifted in the future.

The database format changed again, so make sure you create a backup of your
database before trying this release out!

If you want to try out a core that uses this functionality, check out
Improvise:

  https://github.com/toddsundsted/improvise

For more information and the complete list of available packages:

  http://stunt.io/

Todd

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Todd S. <to...@su...>]

As of this morning, the API should be complete, and the code is reasonably
solid.  I'm now working on the garbage collector --
http://www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf,
which still seems to be the best available for non-concurrent reference
counting cycle collection.

Todd

Re: [Lambdamoo-server] [MOO-talk] Re: ANN: Stunt Release 9 Work in Progress

[Todd S. <to...@su...>]

Jay,

I haven't decided what to do about the verb cache, but you are right, it's
effects can't be ignored. I'm not planning on rolling a new verb anywhere
near as often as one per request, but the current severe penalty imposed by
invalidating the entire cache is going to always force (unwanted IMHO)
trade-off thinking between doing what I want to do and performance.  One
the other hand, I think I found your patch.  If there must be a performance
penalty, I'd like to see it apply to the objects/verbs that are using the
feature, rather than globally.  I am looking at it.

I could accomodate most of what I want to do with blocks, I believe,
although in reorganizing the internals I'll have paid the price for full
lambdas.  And there's something soothing/entertaining/whatever, in finally
giving lambdamoo a lambda.  The problem with things like $runnable is that
I want access to enclosing scope.

I read the threads on lua-l.  I don't think you recanted, as much as just
acknowledged that you want concise lambda syntax to solve a problem that
you can't currently/easily solve in Lua.  That said, inexperienced or
overly-creative or poor or whatever programmers often misuse language
features and/or write crappy code using a feature -- I've certainly done my
fair share of exactly that.  But that doesn't make me wish the feature
didn't exist.  (On the other hand, LambdaMOO/Stunt has the concept of verb
flags.  Maybe I'll make that language feature switchable via a verb flag
that requires wiz-perms to set...)

Great things to think about.

Todd





On Fri, Sep 14, 2012 at 4:17 PM, Jay Carlson <no...@no...> wrote:

> On Sep 9, 2012, at 6:26 AM, Todd Sundsted wrote:
>
> >   temp = create({<controller>, <request/response>, <session>}, 1);
> >   temp:(<action>)(<params>);
>
> This doesn't create propdefs or verbdefs obviously.
>
> Something I've puzzled about for a long time is why Pavel did not
> implement the find_callable_verb cache I did. Run a profiler on 1.8.0 and
> verb lookup is way at the top of the charts, at least once you clear away
> string intrinsics. Given f_c_v's bottleneck, there are a bunch of ways of
> going after this, and Deutsch-style inline caches were probably worth a try
> first if you knew anything about the VM, which I didn't.
>
> The best argument I can think of (besides, well, doing actual work) is
> that some of the speedups in easy reach made assumptions about usage
> patterns in the language, and in turn shaped how people would use it.
> Adding verbdefs a lot is one of those things which really doesn't happen
> very on lambda.moo.mud.org, or at least not at the scale of the BEEELIONS
> of tnt verb calls. Creating a verbdef per web request invalidates the
> cache. So by the way I build the verb lookup cache, I made a particular
> usage pattern far less attractive.
>
> In my defense, people were already distorting their code for performance
> with abominations like the lag-free $player class.
>
> > 1) WAIFs -- I used them before, but they didn't solve my problem this
> time around.  However, there's nothing that I am aware of that precludes
> using both WAIFs and anonymous objects.
>
> I don't see why you would use WAIFs if you had anonymous objects working
> well enough. Anon objects seem like a superset of functionality and are a
> lot cleaner.
>
> > 2) $runnable -- no way!  I'll add real lambdas soon enough.
>
> You might not want to. See
> http://lua-users.org/lists/lua-l/2012-02/msg00917.html for me making the
> case for them, and http://lua-users.org/lists/lua-l/2012-02/msg00964.htmlfor me recanting.
>
> Jay
>
> --
> You received this message because you are subscribed to the Google Groups
> "MOO Talk" group.
> To post to this group, send email to MOO...@go....
> To unsubscribe from this group, send email to
> MOO...@go....
> For more options, visit this group at
> http://groups.google.com/group/MOO-talk?hl=en.
>
>

Re: [Lambdamoo-server] [MOO-talk] Re: ANN: Stunt Release 9 Work in Progress

[Jay C. <no...@no...>]

On Sep 9, 2012, at 6:26 AM, Todd Sundsted wrote:

>   temp = create({<controller>, <request/response>, <session>}, 1);
>   temp:(<action>)(<params>);

This doesn't create propdefs or verbdefs obviously.

Something I've puzzled about for a long time is why Pavel did not implement the find_callable_verb cache I did. Run a profiler on 1.8.0 and verb lookup is way at the top of the charts, at least once you clear away string intrinsics. Given f_c_v's bottleneck, there are a bunch of ways of going after this, and Deutsch-style inline caches were probably worth a try first if you knew anything about the VM, which I didn't.

The best argument I can think of (besides, well, doing actual work) is that some of the speedups in easy reach made assumptions about usage patterns in the language, and in turn shaped how people would use it. Adding verbdefs a lot is one of those things which really doesn't happen very on lambda.moo.mud.org, or at least not at the scale of the BEEELIONS of tnt verb calls. Creating a verbdef per web request invalidates the cache. So by the way I build the verb lookup cache, I made a particular usage pattern far less attractive.

In my defense, people were already distorting their code for performance with abominations like the lag-free $player class.

> 1) WAIFs -- I used them before, but they didn't solve my problem this time around.  However, there's nothing that I am aware of that precludes using both WAIFs and anonymous objects.

I don't see why you would use WAIFs if you had anonymous objects working well enough. Anon objects seem like a superset of functionality and are a lot cleaner.

> 2) $runnable -- no way!  I'll add real lambdas soon enough.

You might not want to. See http://lua-users.org/lists/lua-l/2012-02/msg00917.html for me making the case for them, and http://lua-users.org/lists/lua-l/2012-02/msg00964.html for me recanting.

Jay

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Todd S. <to...@su...>]

Gavin,

The following list is based purely on my needs, and possibly no one else's:

(Some of the following is rehash of discussion on the MOO Talk group, where
I think this has come up before.)

1) I need the ability to dynamically create anonymous objects from ad hoc
sets of parent objects.  The means of instantiating a new WAIF is firmly
rooted in a single parent, even in a server like Stunt, which supports
multiple inheritance.

2) I need the ability to add verbs and properties to an anonymous object.

3) I want verbs and properties on anonymous objects to have the same
behaviors/constraints as verbs and properties on permanent objects.  Beyond
support for a dot accessor, properties on WAIFs differ in many ways from
properties on objects -- some obvious and some subtle.

Basically, I just need MOO objects that are/can be anonymous and garbage
collected.  Despite the superficial resemblance, WAIFs are simply not MOO
objects, regardless of how useful that can be.

Todd


On Sun, Sep 9, 2012 at 7:03 AM, Gavin Lambert
<ue...@us...>wrote:

> At 22:26 9/09/2012, Todd Sundsted wrote:
> >1) WAIFs -- I used them before, but they didn't solve my problem
> >this time around.  However, there's nothing that I am aware of
> >that precludes using both WAIFs and anonymous objects.
>
> I don't think you've actually said yet what problem you were
> trying to solve, and why WAIFs weren't sufficient for it...
>
> Seems kinda silly to reinvent the wheel unless there's something
> wrong with the old wheel.
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Lambdamoo-server mailing list
> Lam...@li...
> https://lists.sourceforge.net/lists/listinfo/lambdamoo-server
>

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Gavin L. <ue...@us...>]

At 22:26 9/09/2012, Todd Sundsted wrote:
>1) WAIFs -- I used them before, but they didn't solve my problem 
>this time around.  However, there's nothing that I am aware of 
>that precludes using both WAIFs and anonymous objects.

I don't think you've actually said yet what problem you were 
trying to solve, and why WAIFs weren't sufficient for it...

Seems kinda silly to reinvent the wheel unless there's something 
wrong with the old wheel.

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Todd S. <to...@su...>]

As always, thanks for the feedback and discussion.  Special thanks to Tim
and Albori for testing!

I just pushed more changes to the MOOCode API.  For the most part, this
consisted of opening up built-ins like `verbs()', `properties()', etc. to
accept an anonymous object as the first argument.  Internally, a lot has
changed, and I'm still testing things like db dump/load **so make sure you
keep a backup of your database**.

That said, I'm starting to rework my apps to use this new capability.  A
good example, from my perspective, is request handling in Dialog.

The old way, requests were dispatched to verbs on a user-defined controller
object for handling.  Verbs were handed `request' and `response' frobs,
which represented the HTTP-request-specific and transient aspects of the
workflow.  The controller was static.  Because a controller was static, it
wasn't easy/convenient to implement request-specific state.  It also wasn't
easy to mix in context-specific functionality in a duck-typed sort of way
-- verbs that act one way in a testing context vs. a development or
production context.

The new way, a new anonymous child of the controller is created for each
request.  Context-specific helpers are mixed in as well: in production,
`request()' and `response()' verbs return the corresponding request and
response objects; in a test, they return mocks, for example.  The Dialog
framework is doing something like the following for each request:

  temp = create({<controller>, <request/response>, <session>}, 1);
  temp:(<action>)(<params>);

Other than testing, the big remaining to do is garbage collecting cyclic
references among anonymous objects.

Replies to other comments in the thread:

1) WAIFs -- I used them before, but they didn't solve my problem this time
around.  However, there's nothing that I am aware of that precludes using
both WAIFs and anonymous objects.

2) $runnable -- no way!  I'll add real lambdas soon enough.

Todd

Re: [Lambdamoo-server] [MOO-talk] Re: ANN: Stunt Release 9 Work in Progress

[Jay C. <no...@no...>]

[hopefully there's a happy medium between fading memory and greater perspective]

On Sep 6, 2012, at 11:49 AM, Josh Benner wrote:

> I always found those aspects of WAIFs nice. Colon are instance members, otherwise they are static methods. Does a great job forming a traditional class/object relationship.

Class/instance is a subset of prototype/delegation. But the subset allows some easy optimizations. chparent() is expensive because the server kinda keeps objects in instance form and has to redo the prototype->class transformation for all the descendants. [handwaving] 

The restrictions on WAIFs similarly reduce the complexity over general anonymous objects, both in use and in the server implementation. YMMV.

One continued source of pain for MOO is a lack of first class references to verbs. I'd imagine one of the first things you'd do with "lightweight" objects which could take verbdefs is build $runnable so you could have a crappy lambda substitute. After being smacked around on lua-l, I've become a lot more wary of "if lambda isn't solving your problem, use more." Sometimes you want a weaker abstraction, like the (original, non-closure) Smalltalk blocks.

> And, they have a different (and again, rather traditional OO) method of instantiation because they are very different than persistent objects.

In standard MOO, everything first-class has value semantics: values have no distinguishable identity, and therefore it makes no sense to talk about whether any particular one exists. (This assumes you think of objids as funny numbers, not pointers.) Frobs mostly preserve this. WAIFs...are weird. 

Like other MOO values, WAIFs don't need to be explicitly destroyed. They are explicitly created rather than just existing when named; two with the same contents are distinguishable. Unlike objids, code holding WAIF references has the ability to keep them private. WAIF code can therefore be less paranoid about stuff like "caller == this.location || lose;". This is a nice combination, but it's fragile: implementors and clients need to agree on who's responsible for protecting what. The unlimited extent of WAIFs means rogue code given a reference can hold onto it and screw with you later.

Originally the people crazy enough to run WAIFs on production servers were tacitly aware of these kinds of issues--I mean, this is the first time I've thought about it this way, but IIRC my code got this right. 

> I really believe that WAIFs got many things right, and provide a better foundation to build on. They have some issues, but I suspect they are solvable.

Anybody building values with reference semantics (i.e., mutable ones) into the language is going to run into some of the same difficulties, I think. WAIFs seem to match up OK with a lot of design patterns. I think they're creepy, but the other designs I know of are worse. 

Anonymous objects highlight the extent MOO treats VR objects (those with locations, contents, owners, etc) as the base type with more abstract things like $player_db as degenerate cases. You may have better luck tearing up the floorboards and making #-1 the true root of all VR objects and have it in turn inherit from a bare #object.

Jay

Re: [Lambdamoo-server] [MOO-talk] Re: ANN: Stunt Release 9 Work in Progress

[Josh B. <jos...@gm...>]

I always found those aspects of WAIFs nice. Colon are instance members, otherwise they are static methods. Does a great job forming a traditional class/object relationship. And, they have a different (and again, rather traditional OO) method of instantiation because they are very different than persistent objects.

I really believe that WAIFs got many things right, and provide a better foundation to build on. They have some issues, but I suspect they are solvable. 

-- 
Josh Benner


On Thursday, September 6, 2012 at 11:46 AM, Michael Munson wrote:

> Additionally, I was never super fond of the way waifs had that colon prefix on the waif class object, or how generating one was so different from real objects.
> 
> Sent from my iPad
> 
> On Sep 6, 2012, at 8:19 AM, Todd Sundsted <tod...@gm... (mailto:tod...@gm...)> wrote:
> 
> > But I _need_ the ability to add properties and verbs!
> > 
> > Todd
> > 
> > 
> > 
> > On Sep 6, 2012, at 8:34 AM, Jay Carlson <no...@no... (mailto:no...@no...)> wrote:
> > 
> > > On Aug 28, 2012, at 9:04 AM, Todd Sundsted wrote:
> > > 
> > > > The current work adds an anonymous object type to Stunt. To create one, pass the integer `1' as the final argument to `create()' (e.g. "create(#123, 1);"). The resulting object is bare (it's basically a pointer directly to the `Object' struct). An anonymous object is recycled when the last reference to it is released. In general, the plan is to make anonymous objects as nearly indistinguishable from permanent objects as possible, with a few caveats: anonymous objects won't show up in an another objects's contents, location, parents, or children, nor can one own other objects; since anonymous objects are not tracked as children of other objects, there's no easy way to fix up the properties layout if parents/properties change in an ancestor -- so one simply becomes invalid when structural changes happen.
> > > 
> > > Once you've nuked location and the other intrinsics from an object, and made it automatically collected, you're left with a named-slot list with a method suite. Remove the ability to add prop and verb defs and you get waifs.
> > > 
> > > Jay
> > 
> > -- 
> > You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> > To post to this group, send email to MOO...@go... (mailto:MOO...@go...).
> > To unsubscribe from this group, send email to MOO...@go... (mailto:MOO...@go...).
> > For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
> > 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To post to this group, send email to MOO...@go... (mailto:MOO...@go...).
> To unsubscribe from this group, send email to MOO...@go... (mailto:MOO...@go...).
> For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
> 
> 

Re: [Lambdamoo-server] [MOO-talk] Re: ANN: Stunt Release 9 Work in Progress

[Michael M. <mic...@gm...>]

Additionally, I was never super fond of the way waifs had that colon prefix on the waif class object, or how generating one was so different from real objects.

Sent from my iPad

On Sep 6, 2012, at 8:19 AM, Todd Sundsted <tod...@gm...> wrote:

> But I _need_ the ability to add properties and verbs!
> 
> Todd
> 
> 
> 
> On Sep 6, 2012, at 8:34 AM, Jay Carlson <no...@no...> wrote:
> 
>> On Aug 28, 2012, at 9:04 AM, Todd Sundsted wrote:
>> 
>>> The current work adds an anonymous object type to Stunt.  To create one, pass the integer `1' as the final argument to `create()' (e.g. "create(#123, 1);").  The resulting object is bare (it's basically a pointer directly to the `Object' struct).  An anonymous object is recycled when the last reference to it is released.  In general, the plan is to make anonymous objects as nearly indistinguishable from permanent objects as possible, with a few caveats: anonymous objects won't show up in an another objects's contents, location, parents, or children, nor can one own other objects; since anonymous objects are not tracked as children of other objects, there's no easy way to fix up the properties layout if parents/properties change in an ancestor -- so one simply becomes invalid when structural changes happen.
>> 
>> Once you've nuked location and the other intrinsics from an object, and made it automatically collected, you're left with a named-slot list with a method suite. Remove the ability to add prop and verb defs and you get waifs.
>> 
>> Jay
> 
> -- 
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To post to this group, send email to MOO...@go....
> To unsubscribe from this group, send email to MOO...@go....
> For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.
> 

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Todd S. <tod...@gm...>]

But I _need_ the ability to add properties and verbs!

Todd



On Sep 6, 2012, at 8:34 AM, Jay Carlson <no...@no...> wrote:

> On Aug 28, 2012, at 9:04 AM, Todd Sundsted wrote:
> 
>> The current work adds an anonymous object type to Stunt.  To create one, pass the integer `1' as the final argument to `create()' (e.g. "create(#123, 1);").  The resulting object is bare (it's basically a pointer directly to the `Object' struct).  An anonymous object is recycled when the last reference to it is released.  In general, the plan is to make anonymous objects as nearly indistinguishable from permanent objects as possible, with a few caveats: anonymous objects won't show up in an another objects's contents, location, parents, or children, nor can one own other objects; since anonymous objects are not tracked as children of other objects, there's no easy way to fix up the properties layout if parents/properties change in an ancestor -- so one simply becomes invalid when structural changes happen.
> 
> Once you've nuked location and the other intrinsics from an object, and made it automatically collected, you're left with a named-slot list with a method suite. Remove the ability to add prop and verb defs and you get waifs.
> 
> Jay

Re: [Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Jay C. <no...@no...>]

On Aug 28, 2012, at 9:04 AM, Todd Sundsted wrote:

> The current work adds an anonymous object type to Stunt.  To create one, pass the integer `1' as the final argument to `create()' (e.g. "create(#123, 1);").  The resulting object is bare (it's basically a pointer directly to the `Object' struct).  An anonymous object is recycled when the last reference to it is released.  In general, the plan is to make anonymous objects as nearly indistinguishable from permanent objects as possible, with a few caveats: anonymous objects won't show up in an another objects's contents, location, parents, or children, nor can one own other objects; since anonymous objects are not tracked as children of other objects, there's no easy way to fix up the properties layout if parents/properties change in an ancestor -- so one simply becomes invalid when structural changes happen.

Once you've nuked location and the other intrinsics from an object, and made it automatically collected, you're left with a named-slot list with a method suite. Remove the ability to add prop and verb defs and you get waifs.

Jay

Re: [Lambdamoo-server] [MOO-talk] ANN: Stunt Release 9 Work in Progress

[michael m. <mic...@gm...>]

I've been pretty busy with work so I haven't got a chance to look at this
until now, but this looks really nice Todd!

On Tue, Aug 28, 2012 at 7:04 AM, Todd Sundsted <to...@su...> wrote:

> I just pushed the work in progress branch of the ninth release of Stunt to
> Github:
>
>   https://github.com/toddsundsted/stunt/tree/release_9_wip
>
> More than any previous release, this release (and this branch, in
> particular) is *for hackers only*.  The main feature (anonymous objects)
> required more comprehensive internal changes than even the
> multiple-inheritance work.  That said, I am happy with the
> programmer-visible API, and the code is ready to play with.  NOTE: the
> database format changed dramatically, so **do not use this on any database
> without first making a backup**.  I'm going to say this twice: do not use
> this on any database without first making a backup!  In fact, make two
> backups.
>
> After building Plastic (http://stunt.io/packages/plastic) it was obvious
> that building moderately complicated applications/libraries in
> Stunt/LambdaMOO is still several times harder than other languages (no
> surprise to many of you, I'm sure).  Part of the problem is that objects is
> Stunt/LambdaMOO are too precious.  Every object is a record in the
> database, every object gets its own public ID, every object has to be
> explicitly managed -- it ends up being a lot of code/mental overhead.
>  Contrast that to almost every other modern OO programming language in
> which many/most objects are ephemeral entities that are used up in a
> computation and discarded (cleanup by by the GC or the stack).
>
> The current work adds an anonymous object type to Stunt.  To create one,
> pass the integer `1' as the final argument to `create()' (e.g.
> "create(#123, 1);").  The resulting object is bare (it's basically a
> pointer directly to the `Object' struct).  An anonymous object is recycled
> when the last reference to it is released.  In general, the plan is to make
> anonymous objects as nearly indistinguishable from permanent objects as
> possible, with a few caveats: anonymous objects won't show up in an another
> objects's contents, location, parents, or children, nor can one own other
> objects; since anonymous objects are not tracked as children of other
> objects, there's no easy way to fix up the properties layout if
> parents/properties change in an ancestor -- so one simply becomes invalid
> when structural changes happen.
>
> There are still a few items on my To Do list:
>
> 1) Add support for adding verbs/properties to anonymous objects (coming in
> the next commit).
> 2) Add support for cleaning up cyclic reference patterns/chains, which
> currently escape the reference counting mechanism.
>
> Hit me up with comments, especially bugs.
>
> Enjoy,
> Todd
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "MOO Talk" group.
> To post to this group, send email to MOO...@go....
> To unsubscribe from this group, send email to
> MOO...@go....
> For more options, visit this group at
> http://groups.google.com/group/MOO-talk?hl=en.
>

[Lambdamoo-server] ANN: Stunt Release 9 Work in Progress

[Todd S. <to...@su...>]

I just pushed the work in progress branch of the ninth release of Stunt to
Github:

  https://github.com/toddsundsted/stunt/tree/release_9_wip

More than any previous release, this release (and this branch, in
particular) is *for hackers only*.  The main feature (anonymous objects)
required more comprehensive internal changes than even the
multiple-inheritance work.  That said, I am happy with the
programmer-visible API, and the code is ready to play with.  NOTE: the
database format changed dramatically, so **do not use this on any database
without first making a backup**.  I'm going to say this twice: do not use
this on any database without first making a backup!  In fact, make two
backups.

After building Plastic (http://stunt.io/packages/plastic) it was obvious
that building moderately complicated applications/libraries in
Stunt/LambdaMOO is still several times harder than other languages (no
surprise to many of you, I'm sure).  Part of the problem is that objects is
Stunt/LambdaMOO are too precious.  Every object is a record in the
database, every object gets its own public ID, every object has to be
explicitly managed -- it ends up being a lot of code/mental overhead.
 Contrast that to almost every other modern OO programming language in
which many/most objects are ephemeral entities that are used up in a
computation and discarded (cleanup by by the GC or the stack).

The current work adds an anonymous object type to Stunt.  To create one,
pass the integer `1' as the final argument to `create()' (e.g.
"create(#123, 1);").  The resulting object is bare (it's basically a
pointer directly to the `Object' struct).  An anonymous object is recycled
when the last reference to it is released.  In general, the plan is to make
anonymous objects as nearly indistinguishable from permanent objects as
possible, with a few caveats: anonymous objects won't show up in an another
objects's contents, location, parents, or children, nor can one own other
objects; since anonymous objects are not tracked as children of other
objects, there's no easy way to fix up the properties layout if
parents/properties change in an ancestor -- so one simply becomes invalid
when structural changes happen.

There are still a few items on my To Do list:

1) Add support for adding verbs/properties to anonymous objects (coming in
the next commit).
2) Add support for cleaning up cyclic reference patterns/chains, which
currently escape the reference counting mechanism.

Hit me up with comments, especially bugs.

Enjoy,
Todd

[Lambdamoo-server] [ANN] Release 8 of the Stunt Extensions to the LambdaMOO Server is Available

[Todd S. <tod...@gm...>]

Release 8 of the Stunt Extensions to the LambdaMOO Server is now available.

  https://github.com/toddsundsted/stunt

This release focuses primarily on putting the map datatype on par with the
existing list datatype.

The release adds:

 * An enhanced for-loop designed for iterating over maps
 * Support for `$' (as well as the new `^') in map index/range operations
 * Range access and assignment for maps

The for-loop now sports the following syntax:

  for v, i in ([...])
    ...
  endfor

When used this way, the first variable is assigned the value from the
sequence and the second variable is assigned the index (in the case of
lists and strings) or key (in the case of maps).  Iteration works correctly
in conjunction with suspends, database dumps/loads, etc.  The original
for-loop continues to work as it always did, of course.

This release also greatly increases the speed of nested index/range
assignment operations (expressions that look like `xyz[a][b][c][d] = ...')
by removing another layer of unnecessary dup'ing in the VM.  In my specific
real-world test case, it knocked off ~20% of the total time required to
import a large package (the whole of LambdaCore, for example).
 Various contrived benchmarks show increases that are 10x that.

If you want to give Stunt a try without investing a lot of time and energy,
consider starting with Improvise (AKA the Stunt core):

  https://github.com/toddsundsted/improvise

Improvise gives you a full-on, opinionated suite of pre-installed packages
and tools.  If you want to build a web-ready MOO, it's not a bad place to
begin.  If you're *really* impatient, you can try it out on the web:

  http://stunt.io:8888/

For more information and the complete list of available packages:

  http://stunt.io/

Todd

[Lambdamoo-server] [ANN] GammaMOO 1.8.3+gamma0

[Luke-Jr <lu...@da...>]

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+

Re: [Lambdamoo-server] [ANN] GammaMOO 1.8.3+gamma0.rc5

[Jay C. <no...@no...>]

On Mar 4, 2012 11:30 PM, "H. Peter Anvin" <hp...@zy...> wrote:
>
> On 02/27/2012 04:22 PM, Ben Jackson wrote:
> > On Mon, Feb 27, 2012 at 04:12:20PM -0800, H. Peter Anvin wrote:
> >>
> >> 64-bit integers and Unicode support would matter for me.  Unfortunately
> >> it looks like the Codepoint project has stalled out :(
> >
> > Waterpoint is running on a codepoint derivative now.  I didn't think it was
> > stalled at all, but then I was not much involve in it.  Give me good old
> > fashioned USA ASCII any day.  ;-)
> >
>
> There hasn't been a checkin for 9 months.

...and?

If somebody wants a project, implement something like Parrot's NFG.
Instead of negative 32-bit characters, use the no-longer-valid UTF-8
sequences above U+10FFFF to represent dynamically allocated codepoints
for grapheme clusters.

Miles Bader pointed out that iteration over characters is rarely used
in Lua 5, since iterators over regexp matches are usually closer to
your intent anyway. It's not even fully general regular expressions;
you frequently see stuff reducible to a generalized :split, something
in the neighborhood of
"(.-)([start-class]+)([body-class]*)([end-class]+)", where the first
capture, ".-", is idiomatic for "everything before the match". ("-" is
a non-greedy version of "*".) It's particularly interesting that
byte/codepoint offsets are not visible to code using this pattern;
those are normally a sticking point for multibyte encodings like
UTF-8. (Whether MOO should just steal Lua's for-loop iterator design
is a separate question.)
-- 
Jay

Strong authentication just proves which chump is in front of the keyboard.