> Hi Stefan,
>
> � �this sounds a lot like an issue that bit someone in squeak 4.x recently and was due to a bytecode compiler bug that I fixed. �I can't find or remember the email associated with this, so if anyone does remember please speak up. �Stefan, you might try running this in an updated squeak 4.1 image and compare the bytecodes. �If you get different bytecodes then we need to port the compiler fixes from 4.1 trunk to Pharo.
>
> HTH
> Eliot
>
>
> On Wed, Sep 29, 2010 at 10:22 AM, Stefan Marr <
pharo@stefan-marr.de> wrote:
> Further testing reveals a strange behavior in the debugger.
> So, I am not sure where the problem is actually caused.
>
> I added a new local variable block to the method.
> block gets assigned aBlock (the parameter).
>
> If I executed Erlang spawn: [Transcript show: 'foo'], the '1 halt.' is executed as I mentioned before.
> However, the debugger does not allow me to access aBlock, there is a subscript out of bound exception.
> Interestingly, 'block' is accessible without error.
>
>
> If I now actually use 'block' instead of 'aBlock' in the executed block, then phenomena is reversed.
> Thus, the variable which is actually referenced in the code is not accessible anymore but gets somehow lost. They also get lost if I use both.
>
>
> I would still like to understand what is going on here.
> So any remarks are welcome.
>
> Thanks
> Stefan
>
>
>
>
> spawn: aBlock
> � � � "Answer an ErlProcess running the code given in the parameter. The process isscheduled."
> � � � | proc block |
> � � � <primitive: 19> "Simulation guard"
> � � � block := aBlock.
> � � � proc := Process
> � � � � � � � forContext:
> � � � � � � � � � � � [1 halt. aBlock value.
> � � � � � � � � � � � �Processor terminateActive] asContext
> � � � � � � � priority: Processor activePriority.
> � � � proc resume.
> � � � ^ proc
>
>
>
> On 29 Sep 2010, at 11:21, Stefan Marr wrote:
>
>>
>> On 29 Sep 2010, at 11:01, Igor Stasenko wrote:
>>
>>> On 29 September 2010 11:11, St�phane Ducasse <
stephane.ducasse@inria.fr> wrote:
>>>> no idea but I want to know that too so keep us posted.
>>>>
>>> Smalltalk specialObjectsArray at: 28.
>>> Thats it, Process is a special object, recognized by VM.
>>> No other Process (sub)classes can be accepted by it.
>> Could you elaborate on that? No other process can be accepted for what?
>> Being scheduled, or being executed?
>>
>> There is also a comment in the comment of Process which suggests that it should be possible:
>> "(If anyone ever makes a subclass of Process, be sure to use allSubInstances in anyProcessesAbove:.)"
>> But even after making the change, that does not seem to be the actual problem.
>>
>>
>> The process gets execute fine. With a '1 halt.' as the first statement of the aBlock block I even get a debugger. It only fails on accessing variables referenced by the closure with an index out of bound error or something similar.
>>
>>>> Erlang>>spawn: aBlock
>>>> � � "Answer an ErlProcess running the code given in the parameter.
>>>> � � � The process is scheduled."
>>>> � � | proc |
>>>> � � proc := ErlProcess
>>>> � � � � � � forContext:
>>>> � � � � � � � � � � [1 halt. aBlock value.
>>>> � � � � � � � � � � �Processor terminateActive] asContext
>>>> � � � � � � priority: Processor activePriority.
>>>> � � proc resume.
>>>> � � ^ proc
>>
>>
>> Thanks and best regards
>> Stefan
>>
>>
>> --
>> Stefan Marr
>> Software Languages Lab
>> Vrije Universiteit Brussel
>> Pleinlaan 2 / B-1050 Brussels / Belgium
>>
http://soft.vub.ac.be/~smarr
>> Phone: +32 2 629 2974
>> Fax: � +32 2 629 3525
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>>
Pharo-project@lists.gforge.inria.fr
>>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> --
> Stefan Marr
> Software Languages Lab
> Vrije Universiteit Brussel
> Pleinlaan 2 / B-1050 Brussels / Belgium
>
http://soft.vub.ac.be/~smarr
> Phone: +32 2 629 2974
> Fax: � +32 2 629 3525
>
>
> _______________________________________________
> Pharo-project mailing list
>
Pharo-project@lists.gforge.inria.fr
>
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>