On Tue, Feb 23, 2010 at 3:55 AM, Fernando olivero
<oliverof@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.