stunt lambdacore package

[Stephen Gigante]

Cna someone else try installing the lambdacore package? 
I've tried it a few times now, both with improvise, and just  the kernel,  and I keep getting the same two errors.

May  2 21:00:16: WIZARDED: #86 by programmer #5
May  2 21:00:16: #8:write_value (this == #8), line 36:  Wizard bit set.
May  2 21:00:16: ... called from #8:write_object (this == #8), line 85
May  2 21:00:16: ... called from #9:import (this == #9), line 127
May  2 21:00:16: ... called from #9:import_package_from_archive (this == #9), line 5
May  2 21:00:16: ... called from #9:@install (this == #9), line 43
May  2 21:00:16: ... called from #5:huh (this == #5), line 6
May  2 21:00:16: (End of traceback)
 This one I think might be more of a warning, and nothing to worry about (Tell me if I'm wrong)

May  2 21:17:56: > #9:@install (this == #9), line 54:  Invalid argument
May  2 21:17:56: > ... called from #5:huh (this == #5), line 6
May  2 21:17:56: > (End of traceback)
 This one also shows up for the player that executed the command, and seems to be the real issue.

Note that installing other packages worked fine for me.

 - Stephen

[Todd Sundsted]

The first one is just the usual warning the server output when some
object's wizbit is set. The LambdaCore package contains the player
"Wizard" (the default wizard you first connect as) -- this warning
represents him/her/it getting his/her/its bit set.

Look at the second one now...

Todd

[michael munson]

Youre getting this traceback when it tries to chparent the Lambda MOO package $sysobject to #0, there is a property intersection somewhere. I remember I had it too.  The first one is just because it is making player #86 the #2 Wizard in Lambda.

I can't remember how I fixed this, I think I evalled a search to see every property on each of the parents of #0 and to see if they intersected with the Lambda object.

This is probably a case where the package manager should fail a bit more gracefully and offer you more information, but thats all the info chparents() tells you.

michael

 - 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.
For more options, visit this group at http://groups.google.com/group/MOO-talk?hl=en.

[Todd Sundsted]

The second one is happening on this line:

chparents($system, parents);

Composed adds the dictionary object (in some packages) to the parents
of #0, to pick up the '$' properties and verbs.

Here's my guess: you have the "player" package installed, which
defines "$player" (AKA has a property named "player" on the
dictionary) and "chparents()" is failing because it's trying to add
another parent (from lambdacore) that also defines the "player"
property.

If this is the case, remove the "player" package (and probably the
"identity" package) and then install "lambdacore". If you are using
lambdacore, you really don't need these packages because lambdacore
already provides player generics and handles authentication.
Alternatively, you can delete the conflicting "player" property
(you'll have to hunt down the object it's defined on).

I'll have to address this in the documentation and/or decide how to
handle this conflict if there is a reason to mix packages like this.

I hope this made sense... long day...

Todd



On May 2, 10:23 pm, Stephen Gigante <yeoldest...@gmail.com> wrote:

[michael munson]

Yes, I just checked this and the property intersection is "player".

> ;; props = {}; for x in ({#0,@parents(#0)}) for y in (properties(x)) props = setadd(props,y); endfor endfor for x in (props) check = `#81.(x) ! E_PROPNF'; if (check != E_PROPNF) player:tell(x); endif endfor

player

0

[Todd Sundsted]

Thanks Michael!

Stephen, I'm going to rename the Player package, which will have the
beneficial effect of fixing this conflict. I'll send out instructions
later today.

Todd

On May 2, 10:47 pm, michael munson <michael.d.mun...@gmail.com> wrote:
> Yes, I just checked this and the property intersection is "player".
>
> > ;; props = {}; for x in ({#0,@parents(#0)}) for y in (properties(x))
>
> props = setadd(props,y); endfor endfor for x in (props) check = `#81.(x) !
> E_PROPNF'; if (check != E_PROPNF) player:tell(x); endif endfor
> player
> 0
>

[Todd Sundsted]

Okay, the "Player" package has been renamed to "Alt", and as a result,
the $player property it created on #0 is $alt, which no longer
conflicts with the $player property in LambdaCore. The Alt package
will appear in the global repo shortly. The Stunt.db in the Improvise
project on GitHub has already been updated. If you want to upgrade
the naming without grabbing a new database, the following steps should
work (you may have to adjust the object numbers -- #62 is the to-be-
renamed Player package in Stunt.db).

; #62.name = "Alt, Player Package"
; #62.identifier = "alt"
; #62.description = "The Alt Package contains the basic player
hierarchy and defines a basic set of VR verbs."
; #62.homepage = "http://stunt.io/packages/alt"
; $composed:reinitialize(@$composed.packages)
; set_property_info(#0, "player", {#62, "r", "alt"})

(As an aside, the `reinitialize()' step reinitializes the package
manager data structures from the list of packages. If you are working
on a package and want to bump up the version in place, a quick way to
do that is to change the version property and then reinitialize. This
registers the new version with Composed without a export/renumber/
import.)

If you update your copy/clone of Improvise, you will also pull down a
replacement for the clunky command-line in-the-browser I built.
Improvise now sports a in-browser console/terminal based off of
jquery.console with improvements for dealing with asynchronous
communication.

Todd


On May 2, 10:23 pm, Stephen Gigante <yeoldest...@gmail.com> wrote: