Hi:
The naive approach of subclassing Process and writing my own fork/spawn does not seem to work for some reason. I tried: Erlang>>spawn: aBlock "Answer an ErlProcess running the code given in the parameter. The process is scheduled." | proc | proc := ErlProcess forContext: [aBlock value. Processor terminateActive] asContext priority: Processor activePriority. proc resume. ^ proc This is basically what happens in BlockClosure newProcess. However, since I do not want to modify BlockClosure, it is not operating on self anymore ('self value' became 'aBlock value', which seems to pose a problem. For some reason, the created process crashes on accessing aBlock, were I would expect it to be available since the block is a closure, right? Looks to me like asContext is doing something I would have to replicate, too. Has someone done something similar before? Thanks 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
no idea but I want to know that too so keep us posted.
On Sep 29, 2010, at 9:59 AM, Stefan Marr wrote: > Hi: > > The naive approach of subclassing Process and writing my own fork/spawn does not seem to work for some reason. > > I tried: > > Erlang>>spawn: aBlock > "Answer an ErlProcess running the code given in the parameter. > The process is scheduled." > | proc | > proc := ErlProcess > forContext: > [aBlock value. > Processor terminateActive] asContext > priority: Processor activePriority. > proc resume. > ^ proc > > This is basically what happens in BlockClosure newProcess. > > However, since I do not want to modify BlockClosure, it is not operating on self anymore ('self value' became 'aBlock value', which seems to pose a problem. For some reason, the created process crashes on accessing aBlock, were I would expect it to be available since the block is a closure, right? > Looks to me like asContext is doing something I would have to replicate, too. > > Has someone done something similar before? > > Thanks > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 29 September 2010 11:11, Stéphane Ducasse <[hidden email]> 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. > On Sep 29, 2010, at 9:59 AM, Stefan Marr wrote: > >> Hi: >> >> The naive approach of subclassing Process and writing my own fork/spawn does not seem to work for some reason. >> >> I tried: >> >> Erlang>>spawn: aBlock >> "Answer an ErlProcess running the code given in the parameter. >> The process is scheduled." >> | proc | >> proc := ErlProcess >> forContext: >> [aBlock value. >> Processor terminateActive] asContext >> priority: Processor activePriority. >> proc resume. >> ^ proc >> >> This is basically what happens in BlockClosure newProcess. >> >> However, since I do not want to modify BlockClosure, it is not operating on self anymore ('self value' became 'aBlock value', which seems to pose a problem. For some reason, the created process crashes on accessing aBlock, were I would expect it to be available since the block is a closure, right? >> Looks to me like asContext is doing something I would have to replicate, too. >> >> Has someone done something similar before? >> >> Thanks >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
On 29 Sep 2010, at 11:01, Igor Stasenko wrote: > On 29 September 2010 11:11, Stéphane Ducasse <[hidden email]> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 <[hidden email]> 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 > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 <[hidden email]> wrote: Further testing reveals a strange behavior in the debugger. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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. 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 <[hidden email]> 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 <[hidden email]> 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 >> [hidden email] >> 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 > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Hi Stefan,
On Wed, Sep 29, 2010 at 11:04 AM, Stefan Marr <[hidden email]> wrote:
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stefan Marr-4
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 <[hidden email]> 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 <[hidden email]> 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 > > [hidden email] > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stefan Marr-4
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 <[hidden email]> 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 <[hidden email]> 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 >>> [hidden email] >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Stef, I had a look at the description of these fixes, but it does not look like there is something related in it.
Eliot, the requested output is below. But as far as I can see, it is identical. Have verified it also in the Squeak 4.1 image, all three produce the same bytecode. Perhaps it not the compiler directly but some closure related code? Thanks Stefan Pharo 1.1: (Erlang class>>#spawn:) abstractSymbolic '<primitive: 19> pushLit: Process pushTemp: 0 closureNumCopied: 1 numArgs: 0 bytes 51 to 59 pushConstant: 1 send: #halt (0 args) pop pushTemp: 0 send: #value (0 args) pop pushLit: Processor send: #terminateActive (0 args) blockReturn send: #asContext (0 args) pushLit: Processor send: #activePriority (0 args) send: #forContext:priority: (2 args) popIntoTemp: 1 pushTemp: 1 send: #resume (0 args) pop pushTemp: 1 returnTop ' Pharo 1.1: (Erlang class>>#spawn:) symbolic. '<primitive: 19> 45 <41> pushLit: Process 46 <10> pushTemp: 0 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 51 <76> pushConstant: 1 52 <D3> send: halt 53 <87> pop 54 <10> pushTemp: 0 55 <C9> send: value 56 <87> pop 57 <45> pushLit: Processor 58 <D4> send: terminateActive 59 <7D> blockReturn 60 <D2> send: asContext 61 <45> pushLit: Processor 62 <D6> send: activePriority 63 <F0> send: forContext:priority: 64 <69> popIntoTemp: 1 65 <11> pushTemp: 1 66 <D7> send: resume 67 <87> pop 68 <11> pushTemp: 1 69 <7C> returnTop ' Squeak 4.2: (Erlang class>>#spawn:) abstractSymbolic. '<primitive: 19> pushLit: Process pushTemp: 0 closureNumCopied: 1 numArgs: 0 bytes 51 to 59 pushConstant: 1 send: #halt (0 args) pop pushTemp: 0 send: #value (0 args) pop pushLit: Processor send: #terminateActive (0 args) blockReturn send: #asContext (0 args) pushLit: Processor send: #activePriority (0 args) send: #forContext:priority: (2 args) popIntoTemp: 1 pushTemp: 1 send: #resume (0 args) pop pushTemp: 1 returnTop ' Squeak 4.2: (Erlang class>>#spawn:) symbolic. '<primitive: 19> 45 <41> pushLit: Process 46 <10> pushTemp: 0 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 51 <76> pushConstant: 1 52 <D3> send: halt 53 <87> pop 54 <10> pushTemp: 0 55 <C9> send: value 56 <87> pop 57 <45> pushLit: Processor 58 <D4> send: terminateActive 59 <7D> blockReturn 60 <D2> send: asContext 61 <45> pushLit: Processor 62 <D6> send: activePriority 63 <F0> send: forContext:priority: 64 <69> popIntoTemp: 1 65 <11> pushTemp: 1 66 <D7> send: resume 67 <87> pop 68 <11> pushTemp: 1 69 <7C> returnTop ' On 29 Sep 2010, at 20:29, Stéphane Ducasse wrote: > and http://code.google.com/p/pharo/issues/list?cursor=2818 > > Stef > > >>> spawn: aBlock >>> "Answer an ErlProcess running the code given in the parameter. The process isscheduled." >>> | proc | >>> <primitive: 19> "Simulation guard" >>> proc := Process >>> forContext: >>> [1 halt. aBlock value. >>> Processor terminateActive] asContext >>> priority: Processor activePriority. >>> proc resume. >>> ^ proc -- 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stéphane Ducasse
Stefan the first link I sent was wrong (obviously) did you check the second?
Stef On Sep 29, 2010, at 9:55 PM, Stefan Marr wrote: > Stef, I had a look at the description of these fixes, but it does not look like there is something related in it. > > Eliot, the requested output is below. > But as far as I can see, it is identical. Have verified it also in the Squeak 4.1 image, all three produce the same bytecode. > > Perhaps it not the compiler directly but some closure related code? > > Thanks > Stefan > > > > Pharo 1.1: (Erlang class>>#spawn:) abstractSymbolic > > '<primitive: 19> > pushLit: Process > pushTemp: 0 > closureNumCopied: 1 numArgs: 0 bytes 51 to 59 > pushConstant: 1 > send: #halt (0 args) > pop > pushTemp: 0 > send: #value (0 args) > pop > pushLit: Processor > send: #terminateActive (0 args) > blockReturn > send: #asContext (0 args) > pushLit: Processor > send: #activePriority (0 args) > send: #forContext:priority: (2 args) > popIntoTemp: 1 > pushTemp: 1 > send: #resume (0 args) > pop > pushTemp: 1 > returnTop > ' > > Pharo 1.1: (Erlang class>>#spawn:) symbolic. > '<primitive: 19> > 45 <41> pushLit: Process > 46 <10> pushTemp: 0 > 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 > 51 <76> pushConstant: 1 > 52 <D3> send: halt > 53 <87> pop > 54 <10> pushTemp: 0 > 55 <C9> send: value > 56 <87> pop > 57 <45> pushLit: Processor > 58 <D4> send: terminateActive > 59 <7D> blockReturn > 60 <D2> send: asContext > 61 <45> pushLit: Processor > 62 <D6> send: activePriority > 63 <F0> send: forContext:priority: > 64 <69> popIntoTemp: 1 > 65 <11> pushTemp: 1 > 66 <D7> send: resume > 67 <87> pop > 68 <11> pushTemp: 1 > 69 <7C> returnTop > ' > > Squeak 4.2: (Erlang class>>#spawn:) abstractSymbolic. > '<primitive: 19> > pushLit: Process > pushTemp: 0 > closureNumCopied: 1 numArgs: 0 bytes 51 to 59 > pushConstant: 1 > send: #halt (0 args) > pop > pushTemp: 0 > send: #value (0 args) > pop > pushLit: Processor > send: #terminateActive (0 args) > blockReturn > send: #asContext (0 args) > pushLit: Processor > send: #activePriority (0 args) > send: #forContext:priority: (2 args) > popIntoTemp: 1 > pushTemp: 1 > send: #resume (0 args) > pop > pushTemp: 1 > returnTop > ' > > Squeak 4.2: (Erlang class>>#spawn:) symbolic. > > '<primitive: 19> > 45 <41> pushLit: Process > 46 <10> pushTemp: 0 > 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 > 51 <76> pushConstant: 1 > 52 <D3> send: halt > 53 <87> pop > 54 <10> pushTemp: 0 > 55 <C9> send: value > 56 <87> pop > 57 <45> pushLit: Processor > 58 <D4> send: terminateActive > 59 <7D> blockReturn > 60 <D2> send: asContext > 61 <45> pushLit: Processor > 62 <D6> send: activePriority > 63 <F0> send: forContext:priority: > 64 <69> popIntoTemp: 1 > 65 <11> pushTemp: 1 > 66 <D7> send: resume > 67 <87> pop > 68 <11> pushTemp: 1 > 69 <7C> returnTop > ' > > > On 29 Sep 2010, at 20:29, Stéphane Ducasse wrote: > >> and http://code.google.com/p/pharo/issues/list?cursor=2818 >> >> Stef >> >> >>>> spawn: aBlock >>>> "Answer an ErlProcess running the code given in the parameter. The process isscheduled." >>>> | proc | >>>> <primitive: 19> "Simulation guard" >>>> proc := Process >>>> forContext: >>>> [1 halt. aBlock value. >>>> Processor terminateActive] asContext >>>> priority: Processor activePriority. >>>> proc resume. >>>> ^ proc > > > -- > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Yes, had a look at http://code.google.com/p/pharo/issues/detail?id=2818
There are a lot todos but nothing which sounds like it is related to my symptoms. However, since the bytecode is equal to what Squeak 4.2 produces and where it works, I would guess, that the compiler is not the problem. Best regards Stefan On 29 Sep 2010, at 22:32, Stéphane Ducasse wrote: > Stefan the first link I sent was wrong (obviously) did you check the second? > > Stef > > On Sep 29, 2010, at 9:55 PM, Stefan Marr wrote: > >> Stef, I had a look at the description of these fixes, but it does not look like there is something related in it. >> >> Eliot, the requested output is below. >> But as far as I can see, it is identical. Have verified it also in the Squeak 4.1 image, all three produce the same bytecode. >> >> Perhaps it not the compiler directly but some closure related code? >> >> Thanks >> Stefan >> >> >> >> Pharo 1.1: (Erlang class>>#spawn:) abstractSymbolic >> >> '<primitive: 19> >> pushLit: Process >> pushTemp: 0 >> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 >> pushConstant: 1 >> send: #halt (0 args) >> pop >> pushTemp: 0 >> send: #value (0 args) >> pop >> pushLit: Processor >> send: #terminateActive (0 args) >> blockReturn >> send: #asContext (0 args) >> pushLit: Processor >> send: #activePriority (0 args) >> send: #forContext:priority: (2 args) >> popIntoTemp: 1 >> pushTemp: 1 >> send: #resume (0 args) >> pop >> pushTemp: 1 >> returnTop >> ' >> >> Pharo 1.1: (Erlang class>>#spawn:) symbolic. >> '<primitive: 19> >> 45 <41> pushLit: Process >> 46 <10> pushTemp: 0 >> 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 >> 51 <76> pushConstant: 1 >> 52 <D3> send: halt >> 53 <87> pop >> 54 <10> pushTemp: 0 >> 55 <C9> send: value >> 56 <87> pop >> 57 <45> pushLit: Processor >> 58 <D4> send: terminateActive >> 59 <7D> blockReturn >> 60 <D2> send: asContext >> 61 <45> pushLit: Processor >> 62 <D6> send: activePriority >> 63 <F0> send: forContext:priority: >> 64 <69> popIntoTemp: 1 >> 65 <11> pushTemp: 1 >> 66 <D7> send: resume >> 67 <87> pop >> 68 <11> pushTemp: 1 >> 69 <7C> returnTop >> ' >> >> Squeak 4.2: (Erlang class>>#spawn:) abstractSymbolic. >> '<primitive: 19> >> pushLit: Process >> pushTemp: 0 >> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 >> pushConstant: 1 >> send: #halt (0 args) >> pop >> pushTemp: 0 >> send: #value (0 args) >> pop >> pushLit: Processor >> send: #terminateActive (0 args) >> blockReturn >> send: #asContext (0 args) >> pushLit: Processor >> send: #activePriority (0 args) >> send: #forContext:priority: (2 args) >> popIntoTemp: 1 >> pushTemp: 1 >> send: #resume (0 args) >> pop >> pushTemp: 1 >> returnTop >> ' >> >> Squeak 4.2: (Erlang class>>#spawn:) symbolic. >> >> '<primitive: 19> >> 45 <41> pushLit: Process >> 46 <10> pushTemp: 0 >> 47 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 51 to 59 >> 51 <76> pushConstant: 1 >> 52 <D3> send: halt >> 53 <87> pop >> 54 <10> pushTemp: 0 >> 55 <C9> send: value >> 56 <87> pop >> 57 <45> pushLit: Processor >> 58 <D4> send: terminateActive >> 59 <7D> blockReturn >> 60 <D2> send: asContext >> 61 <45> pushLit: Processor >> 62 <D6> send: activePriority >> 63 <F0> send: forContext:priority: >> 64 <69> popIntoTemp: 1 >> 65 <11> pushTemp: 1 >> 66 <D7> send: resume >> 67 <87> pop >> 68 <11> pushTemp: 1 >> 69 <7C> returnTop >> ' >> >> >> On 29 Sep 2010, at 20:29, Stéphane Ducasse wrote: >> >>> and http://code.google.com/p/pharo/issues/list?cursor=2818 >>> >>> Stef >>> >>> >>>>> spawn: aBlock >>>>> "Answer an ErlProcess running the code given in the parameter. The process isscheduled." >>>>> | proc | >>>>> <primitive: 19> "Simulation guard" >>>>> proc := Process >>>>> forContext: >>>>> [1 halt. aBlock value. >>>>> Processor terminateActive] asContext >>>>> priority: Processor activePriority. >>>>> proc resume. >>>>> ^ proc >> >> >> -- >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stefan Marr-4
On 29 September 2010 12:21, Stefan Marr <[hidden email]> wrote:
> > On 29 Sep 2010, at 11:01, Igor Stasenko wrote: > >> On 29 September 2010 11:11, Stéphane Ducasse <[hidden email]> 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. > Yeah, this not an issue. Sorry for wrong info. > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |