Hi Stefan, On Wed, Sep 29, 2010 at 11:04 AM, Stefan Marr <[email protected]> wrote:
> Hi Eliot: > > I had tried Squeak 4.1 before, also updated, but same result. > > However, after your mail I tried an updated Squeak 4.2 alpha ( > http://ftp.squeak.org/trunk/Squeak4.2-10382-alpha.zip) and here it works. > Try comparing the result of (Erlang>>#spawn) abstractSymbolic in 4.2 & Pharo (and also check (Erlang>>#spawn) symbolic) and email the results. It might jog my memory. best Eliot > Thanks for the hint. > > Best regards > Stefan > > > On 29 Sep 2010, at 19:48, 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 > > > > > > -- > 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 > > -- > 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
