Lambdacore 0.0.5 package
10 views
Skip to first unread message
d. kajsh
May 24, 2012, 11:56:33 AM5/24/12
to MOO-...@googlegroups.com
Very cool.
Maybe it's just me, but I don't know how I would feel about distributing
Stunt-related tweaks as a new version of the LambdaCore package. From
what I could tell, version 0.0.4 is mostly identical to LambdaCore-
17May04, the only mayor addition being the authenticate() verb.
How likely is it that we'll see another core dump from LambdaMOO?
Having Stunt-related tweaks in a different package might make things
easier in that case.
Since $composed doesn't have an upgrading mechanism yet, keeping
tweaks to LambdaCore in a seperate package might be the better choice?
It could make updating an existing Stunt server with the LambdaCore
package installed a lot easier because you would only have to reapply
an updated "lambdacore_stunt" package.
Anyhow, that's just my 2 cents. I propose keeping a "vanilla"
LambdaCore package and have the Stunt-related changes in a different
package. That would leave us with a static, agreed upon base package
and would keep Stunt changes and tweaks which are going to change more
frequently in a smaller, manageable package. What do you guys think?
As for the tweaks, I see you changed lots of checks for "callers()" to
"callers() && (caller != #0)". Couldn't this be "callers() && (caller
!= $system)" instead? Or completely replaced with a call to Stunt's
$restrict_to_server()?
Daniel.
Maybe it's just me, but I don't know how I would feel about distributing
Stunt-related tweaks as a new version of the LambdaCore package. From
what I could tell, version 0.0.4 is mostly identical to LambdaCore-
17May04, the only mayor addition being the authenticate() verb.
How likely is it that we'll see another core dump from LambdaMOO?
Having Stunt-related tweaks in a different package might make things
easier in that case.
Since $composed doesn't have an upgrading mechanism yet, keeping
tweaks to LambdaCore in a seperate package might be the better choice?
It could make updating an existing Stunt server with the LambdaCore
package installed a lot easier because you would only have to reapply
an updated "lambdacore_stunt" package.
Anyhow, that's just my 2 cents. I propose keeping a "vanilla"
LambdaCore package and have the Stunt-related changes in a different
package. That would leave us with a static, agreed upon base package
and would keep Stunt changes and tweaks which are going to change more
frequently in a smaller, manageable package. What do you guys think?
As for the tweaks, I see you changed lots of checks for "callers()" to
"callers() && (caller != #0)". Couldn't this be "callers() && (caller
!= $system)" instead? Or completely replaced with a call to Stunt's
$restrict_to_server()?
Daniel.
Stephen Gigante
May 24, 2012, 12:32:17 PM5/24/12
to d. kajsh, MOO-...@googlegroups.com
The way I see it, the lambdacore package should be as similar to running a lambdacore server. Most of the tweaks I included can be better-akin to bug fixes. (There were almost a dozen verbs that would immediately throw errors, or silently return because the lambdacore $sysobj is #13.
(Imagine the effort I needed to go through to work out why $housekeeper wasn't being called, only to find that #13:user_client_disconnected refused to run because it had a caller (#0:user_client_disconnected)
Stunt related tweaks in another package are good in concept (And probably the better answer once stunt is fully established and deemed stable), but honestly, who wants to install two packages to get a fully working lambdacore installation?
- Stephen
(Imagine the effort I needed to go through to work out why $housekeeper wasn't being called, only to find that #13:user_client_disconnected refused to run because it had a caller (#0:user_client_disconnected)
Stunt related tweaks in another package are good in concept (And probably the better answer once stunt is fully established and deemed stable), but honestly, who wants to install two packages to get a fully working lambdacore installation?
- Stephen
--
You received this message because you are subscribed to the Google Groups "MOO Talk" group.
To view this discussion on the web visit https://groups.google.com/d/msg/MOO-talk/-/ewXS2Orexf0J.
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.
d. kajsh
May 24, 2012, 8:09:33 PM5/24/12
to MOO-...@googlegroups.com, d. kajsh
Hm, true. I just spent some time trying to get a few more things in
lambdacore working and ran across similar problems myself, mostly
objects expecting things to be located in #-1 which are now in the
lambdacore package and lots of stuff related to the caller checks
and #0 not being #0.
Well, if we have to fix up code to get everything working anyway, we
could use the permission checks stunt provides and replace most of
the "(callers() && (caller != this) return E_PERM)" etc checks in
LambdaCore.
In that case, would it make sense to modify the $restrict_to_server
verb to allow things like
$system:server_started -> $sysobj:server_started ->
$checkpointer:server_started when used on
$checkpointer:server_started, or should we use $restrict_to_caller
instead?
I'll see if I have some spare time this weekend to work on some of this.
To unsubscribe from this group, send email to MOO-talk+unsubscribe@googlegroups.com.
Todd Sundsted
May 24, 2012, 10:22:17 PM5/24/12
to moo-talk
I successfully loaded it into a database with only kernel 1.0.7 installed with no problems. I did a little building and everything I tried worked as advertised. Nice job!
I see the problem with @list'ing verb code mentioned in another thread, and I have a pretty good idea why it's happening. It shouldn't be too hard to fix.
The uploaded package had some trailing garbage that I had to remove. I have attached the version that I successfully loaded. Do you want to hack on this more, or do you want to call it version 0.0.5 final? It'd definitely more complete than 0.0.4, which I have no problem retiring.
Todd
On Thu, May 24, 2012 at 4:19 AM, Stephen Gigante <yeold...@gmail.com> wrote:
Here's my tweaked lambdacore package. I've already bumped the version identifier to 0.0.5.
-Stephen
--
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.
Todd Sundsted
May 24, 2012, 10:30:18 PM5/24/12
to MOO Talk
On May 24, 11:56 am, "d. kajsh" <hsja...@hotmail.com> wrote:
> How likely is it that we'll see another core dump from LambdaMOO?
> Having Stunt-related tweaks in a different package might make things
> easier in that case.
going to come from this group, right here.
> As for the tweaks, I see you changed lots of checks for "callers()" to
> "callers() && (caller != #0)". Couldn't this be "callers() && (caller
> != $system)" instead? Or completely replaced with a call to Stunt's
> $restrict_to_server()?
never going to be a reliable way to relocate them.
Todd
Todd Sundsted
May 24, 2012, 10:35:34 PM5/24/12
to MOO Talk
I can see breaking lambdacore into pieces -- the package would be both
smaller and faster to load if Mr. Spell were in a separate package.
However, making lambdacore work seamlessly in Stunt alongside the
kernel and other packages is going to take some re-engineering.
Keeping that separate, while attractive, will be a lot more work. If
LambdaCore were being maintained, I'd probably feel differently...
Todd
smaller and faster to load if Mr. Spell were in a separate package.
However, making lambdacore work seamlessly in Stunt alongside the
kernel and other packages is going to take some re-engineering.
Keeping that separate, while attractive, will be a lot more work. If
LambdaCore were being maintained, I'd probably feel differently...
Todd
Stephen Gigante
May 25, 2012, 12:43:27 AM5/25/12
to Todd Sundsted, MOO Talk
I didn't want to hardcode, but at the same time, the server always calls #0. My prefered solution would be to tweak $restrict_to_server to also allow length(callers()) == 1 && callers()[1] = #0 && callers()[2] == verb; Then I could just put $restrict_to_server in all dictionary verbs too. [Best solution in my mind].
I think I missed a couple places where caller is locked to #0, so let me tweak it a bit more.
- Stephen
I think I missed a couple places where caller is locked to #0, so let me tweak it a bit more.
- Stephen
Tim van Dijen
May 25, 2012, 5:14:00 AM5/25/12
to MOO-...@googlegroups.com
I have a similar verb for permission checks.. It is tweaked to use
as few ticks as possible..
Perhaps it's useful to take a look at?? See attachment..
Code was originally writen by Timo Frenay.
Op 25-5-2012 6:43, Stephen Gigante schreef:
Perhaps it's useful to take a look at?? See attachment..
Code was originally writen by Timo Frenay.
Op 25-5-2012 6:43, Stephen Gigante schreef:
Todd Sundsted
May 25, 2012, 6:55:45 AM5/25/12
to MOO Talk
On May 24, 8:09 pm, "d. kajsh" <hsja...@hotmail.com> wrote:
> Well, if we have to fix up code to get everything working anyway, we
> could use the permission checks stunt provides and replace most of
> the "(callers() && (caller != this) return E_PERM)" etc checks in
> LambdaCore.
>
> In that case, would it make sense to modify the $restrict_to_server
> verb to allow things like
> $system:server_started -> $sysobj:server_started ->
> $checkpointer:server_started when used on
> $checkpointer:server_started, or should we use $restrict_to_caller
> instead?
to verb calls from #0 is keeping the surface area of security-related
verbs small. Unless we add further implicit restrictions on the verbs
on #0 that can make the calls, we have to have a blanket policy of no
user/package defined verbs added dynamically to #0. Since #0 already
has special powers in regards to bf_<builtin> verbs (like
bf_set_verb_code()) this is probably a safe bet, but... is there
legacy code out there that _does_ expect to be able to install verbs
on #0 that someone depends on?
Todd
Todd Sundsted
May 25, 2012, 10:17:15 AM5/25/12
to MOO Talk
I'm rethinking my thinking. It looks like the example above is trying
to do the right thing when LambdaCore is a package on top of the Stunt
kernel, and when it is running standalone, which is not a bad goal.
I'd recommend either adding a verb to $sysobj or (maybe more
idiomatic) add the verb to $perm_utils. And have it make both
checks. Other packages that depend on lambdacore could use it, or one
of the kernel helpers.
Todd
to do the right thing when LambdaCore is a package on top of the Stunt
kernel, and when it is running standalone, which is not a bad goal.
I'd recommend either adding a verb to $sysobj or (maybe more
idiomatic) add the verb to $perm_utils. And have it make both
checks. Other packages that depend on lambdacore could use it, or one
of the kernel helpers.
Todd
Stephen Gigante
May 26, 2012, 1:46:36 AM5/26/12
to Todd Sundsted, MOO Talk
As for modularizing lambdacore, quite a bit of it needs to be done anyway. (Or, if not needs, at least would be very nice).
I've found that even when I don't work off lambdacore, I always port the lambda utils, and if that's going to be packaged separately, we may as well start modularizing the rest too. (I've noticed there are a lot of places lambdacore has a fit if it sees something that isn't a $root_class, and when I manage to fix that (I see that as the milestone for 0.0.6), it shouldn't be too much harder to modularize it completely. My end goal with the 'lambdacore' package is an empty package with an afterinstall that pulls down all the separate lambdacore modules in one simple command.
-Stephen
--
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.
Todd Sundsted
May 26, 2012, 8:56:56 AM5/26/12
to MOO Talk
Is 0.0.5 ready for the package server?
Do you want to post a short changelog so people know what they're
getting?
Todd
> lambdacore.json.gz
> 1472KViewDownload
Do you want to post a short changelog so people know what they're
getting?
Todd
> 1472KViewDownload
Stephen Gigante
May 26, 2012, 9:53:10 AM5/26/12
to Todd Sundsted, MOO Talk
Yeah, I'd say it's ready.
I've modified the following:
* Fixed $sysobj perm checks to allow for being called by #0 rather than directly by the server.
* Added $prog:@properties verb [It was bugging me]
* Changed $object_utils:isa, :ancestors, :descendants to use stunt builtins [and thereby handle MI properly]
* Changed $object_utils:all_properties all_verbs to search all parents. [Easily seen by comparing @show #0]
A short list, but it's made a very large improvement in my eyes.
- Stephen
I've modified the following:
* Fixed $sysobj perm checks to allow for being called by #0 rather than directly by the server.
* Added $prog:@properties verb [It was bugging me]
* Changed $object_utils:isa, :ancestors, :descendants to use stunt builtins [and thereby handle MI properly]
* Changed $object_utils:all_properties all_verbs to search all parents. [Easily seen by comparing @show #0]
A short list, but it's made a very large improvement in my eyes.
- Stephen
Stephen Gigante
May 26, 2012, 10:20:07 AM5/26/12
to Todd Sundsted, MOO Talk
Oh, and modified $prog:@list to pass back to $composed:@list when appropriate.
- Stephen
- Stephen
Todd Sundsted
May 26, 2012, 12:49:15 PM5/26/12
to MOO Talk
That's a good plan. On the roadmap is transitive dependency
resolution and automatic installation of dependencies. In the
meantime, you can definitely accomplish what you want to do with an
`after_install()' verb.
Todd
resolution and automatic installation of dependencies. In the
meantime, you can definitely accomplish what you want to do with an
`after_install()' verb.
Todd
Todd Sundsted
May 26, 2012, 1:03:26 PM5/26/12
to MOO Talk
The lambdacore version 0.0.5 is now generally available!
Thanks Stephen!
On May 26, 10:20 am, Stephen Gigante <yeoldest...@gmail.com> wrote:
> Oh, and modified $prog:@list to pass back to $composed:@list when
> appropriate.
>
> - Stephen
>
Thanks Stephen!
On May 26, 10:20 am, Stephen Gigante <yeoldest...@gmail.com> wrote:
> Oh, and modified $prog:@list to pass back to $composed:@list when
> appropriate.
>
> - Stephen
>
> On Sat, May 26, 2012 at 11:53 PM, Stephen Gigante <yeoldest...@gmail.com>wrote:
>
>
>
>
>
>
>
> > Yeah, I'd say it's ready.
>
> > I've modified the following:
> > * Fixed $sysobj perm checks to allow for being called by #0 rather than
> > directly by the server.
> > * Added $prog:@properties verb [It was bugging me]
> > * Changed $object_utils:isa, :ancestors, :descendants to use stunt
> > builtins [and thereby handle MI properly]
> > * Changed $object_utils:all_properties all_verbs to search all parents.
> > [Easily seen by comparing @show #0]
>
> > A short list, but it's made a very large improvement in my eyes.
>
> > - Stephen
>
>
>
>
>
>
>
>
> > Yeah, I'd say it's ready.
>
> > I've modified the following:
> > * Fixed $sysobj perm checks to allow for being called by #0 rather than
> > directly by the server.
> > * Added $prog:@properties verb [It was bugging me]
> > * Changed $object_utils:isa, :ancestors, :descendants to use stunt
> > builtins [and thereby handle MI properly]
> > * Changed $object_utils:all_properties all_verbs to search all parents.
> > [Easily seen by comparing @show #0]
>
> > A short list, but it's made a very large improvement in my eyes.
>
> > - Stephen
>
Reply all
Reply to author
Forward
0 new messages