On Tue, Feb 23, 2010 at 3:55 AM, Fernando olivero <olive...@lu.unisi.ch>wrote:
>
> On Feb 23, 2010, at 4:19 AM, John M McIntosh wrote:
>
> >
> > On 2010-02-22, at 6:48 PM, Javier Pimás wrote:
> >
> >>
> >
> >> Lastly, as I said when I loaded Alien Core the first time, I got this
> error while loading it:
> >>
> >> Alien class>>#ensureInSpecialObjectsArray: "Index probably wrong".
> >>
> >> What should I do about that? ignore it?
> >
> > Well it seems to be related to
> >
> > ((Smalltalk includesKey: #ObjectMemory)
> > and: [((Smalltalk at: #ObjectMemory) classPool at: #ClassAlien
> ifAbsent: []) ~~ (index - 1)]) ifTrue:
> > [self error: 'index probably wrong'].
> >
> > Usually people don't have ObjectMemory loaded in their image, and I"m not
> sure what it is check for.
> > Why don't you try it in a regular Pharo image versus your VMMaker image.
>
> Great work Jorge! Nice to know you won the battle against VMMaker!
>
>
Haha, it's Javier but you were very close, keep trying :P
> The ensure in special objects array error, has to do with some missing
> classes as John pointed out.
>
> The smalltalk special objects array has hardcoded indexes for some relevant
> classes ( Globals) in the system.
> In the alien configuration i've just ensured that the size should be 53,
> before loading Alien, because the Alien code installs itself in that array
> at positions 54 and 55.
>
>
Before loading my image has 50 items, last one being #run:with:in:. After
loading alien I've got 55. The new ones are:
[51] : nil
[52] : nil
[53] : Alien
[54] : #invokeCallback:stack:registers:jmpbuf:
[55] : UnsafeAlien
Other strange stuff is that while inspecting (Smalltalk at: #Interpreter)
classPool I found that
[#PrimErrBadArgument] : nil
[#PrimErrBadIndex] : nil
[#PrimErrBadNumArgs] : nil
[#PrimErrBadReceiver] : nil
[#PrimErrGenericFailure] : nil
[#PrimErrInappropriate] : nil
[#PrimErrNoCMemory] : nil
[#PrimErrNoMemory] : nil
[#PrimErrNoModification] : nil
[#PrimErrNotFound] : nil
[#PrimErrTableIndex] : nil
[#PrimErrUnsupported] : nil
[#PrimNoErr] : nil
Which means that initializePrimitiveErrorCodes hasn't been called, which
explains why special object #52 is nil. Analysing it a bit more I discover
that initializePrimitiveErrorCodes has no senders, is that right?
Regards,
Javier.
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
--
Javier Pimás
Ciudad de Buenos Aires
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
