and http://code.google.com/p/pharo/issues/list?cursor=2818

Stef

On Sep 29, 2010, at 8:28 PM, Stéphane Ducasse wrote:

> we still should integrate your changes but they require momentum and 
> concentration which we do not have.
> Stefan if you want to help you are welcome
> 
> http://code.google.com/p/pharo/issues/detail?id=2897
> 
> Stef
> 
> On Sep 29, 2010, at 7:49 PM, Eliot Miranda wrote:
> 
>> 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 <[email protected]> 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 <[email protected]> 
>>>> 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
>>> [email protected]
>>> 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
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to