March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problems using java code importer with inFusion under windows

by David T. Lewis

On Tue, Mar 02, 2010 at 02:18:20PM +0100, Fabrizio Perin wrote: > Because the discussion about this topic happened on the moose mailing list i > just update also the pharo mailing list. To summarize: > > I had problems using the importer of java code with inFusion on Windows, at > the end i discovered that the primitives into WindowsOSProcessAccessor just > fails during the initialization and that the process is not able to access > the OS. There is also a bug report here: > > http://code.google.com/p/moose-technology/issues/detail?id=321&q=OSProcess&… Hi Fabrizio, The failure that you are seeing is because the OSProcessPlugin is not present in your VM, and therefore the primitives are not there (so really there is nothing to debug). OSProcess is not fully implemented on Windows. You can find some information about OSProcess at http://wiki.squeak.org/squeak/708 If you have the option to use Unix/Linux or Mac, you should get better results. Sorry, Dave (author of OSProcess)

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by John M McIntosh

Ah, well if you can build your own VM, then it would be easy to add as a named primitive. On 2010-03-02, at 4:34 PM, Alexandre Bergel wrote: >> Well it seems rather special purpose. What are you using it for? >> Why is the cost impacting your work? > > There is an excellent paper at oopsla'09 that shows the method call graph can be effectively inferred using the method call stack depth: http://www-plan.cs.colorado.edu/klipto/mytkowicz-oopsla09.pdf > > Executing "[ running sender notNil ] whileTrue: [ running := running sender. depth := depth + 1]" before each method execution of my application terribly slows it down. > > Cheers, > Alexandre -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Alexandre Bergel

> Well it seems rather special purpose. What are you using it for? > Why is the cost impacting your work? There is an excellent paper at oopsla'09 that shows the method call graph can be effectively inferred using the method call stack depth: http://www-plan.cs.colorado.edu/klipto/mytkowicz-oopsla09.pdf Executing "[ running sender notNil ] whileTrue: [ running := running sender. depth := depth + 1]" before each method execution of my application terribly slows it down. Cheers, Alexandre > > On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote: > >> Will it be of any use for you? If yes, then I will do it. >> >> Alexandre >> >> >> On 2 Mar 2010, at 21:00, John M McIntosh wrote: >> >>> Maybe you could write a plugin/primitive to do the work? >>> >>> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: >>> >>>> Dear List, >>>> >>>> I was wondering whether there is a fast way to know the method call >>>> stack depth. Something like what follows does the job: >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> | depth running | >>>> depth := 0. >>>> running := thisContext. >>>> [ running sender notNil ] whileTrue: [ running := running sender. >>>> depth := depth + 1]. >>>> depth >>>> -=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> But it is rather slow. Anyone has a suggestion? >>>> >>>> Cheers, >>>> Alexandre >>>> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by John M McIntosh

Well it seems rather special purpose. What are you using it for? Why is the cost impacting your work? On 2010-03-02, at 4:06 PM, Alexandre Bergel wrote: > Will it be of any use for you? If yes, then I will do it. > > Alexandre > > > On 2 Mar 2010, at 21:00, John M McIntosh wrote: > >> Maybe you could write a plugin/primitive to do the work? >> >> On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: >> >>> Dear List, >>> >>> I was wondering whether there is a fast way to know the method call >>> stack depth. Something like what follows does the job: >>> >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> | depth running | >>> depth := 0. >>> running := thisContext. >>> [ running sender notNil ] whileTrue: [ running := running sender. >>> depth := depth + 1]. >>> depth >>> -=-=-=-=-=-=-=-=-=-=-=-= >>> >>> But it is rather slow. Anyone has a suggestion? >>> >>> Cheers, >>> Alexandre >>> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 3, 2010

[Pharo-project] [ANN] ConfigurationOfTeachable

by Torsten Bergmann

"Teachable" (see [1] and [2]) is now available via Metacello: Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfTeachable'; load. ((Smalltalk at: #ConfigurationOfTeachable) project version: '1.0') load: 'all' Bye T. [1] http://astares.blogspot.com/2005/04/teaching-behavior.html [2] http://lists.squeakfoundation.org/pipermail/squeak-dev/2002-April/038279.ht… -- GMX DSL: Internet, Telefon und Entertainment fÃ¼r nur 19,99 EUR/mtl.! http://portal.gmx.net/de/go/dsl02

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Alexandre Bergel

Will it be of any use for you? If yes, then I will do it. Alexandre On 2 Mar 2010, at 21:00, John M McIntosh wrote: > Maybe you could write a plugin/primitive to do the work? > > On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: > >> Dear List, >> >> I was wondering whether there is a fast way to know the method call >> stack depth. Something like what follows does the job: >> >> -=-=-=-=-=-=-=-=-=-=-=-= >> | depth running | >> depth := 0. >> running := thisContext. >> [ running sender notNil ] whileTrue: [ running := running sender. >> depth := depth + 1]. >> depth >> -=-=-=-=-=-=-=-=-=-=-=-= >> >> But it is rather slow. Anyone has a suggestion? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by John M McIntosh

Maybe you could write a plugin/primitive to do the work? On 2010-03-02, at 3:50 PM, Alexandre Bergel wrote: > Dear List, > > I was wondering whether there is a fast way to know the method call > stack depth. Something like what follows does the job: > > -=-=-=-=-=-=-=-=-=-=-=-= > | depth running | > depth := 0. > running := thisContext. > [ running sender notNil ] whileTrue: [ running := running sender. > depth := depth + 1]. > depth > -=-=-=-=-=-=-=-=-=-=-=-= > > But it is rather slow. Anyone has a suggestion? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 3, 2010

[Pharo-project] Quickly getting the method call stack depth

by Alexandre Bergel

Dear List, I was wondering whether there is a fast way to know the method call stack depth. Something like what follows does the job: -=-=-=-=-=-=-=-=-=-=-=-= | depth running | depth := 0. running := thisContext. [ running sender notNil ] whileTrue: [ running := running sender. depth := depth + 1]. depth -=-=-=-=-=-=-=-=-=-=-=-= But it is rather slow. Anyone has a suggestion? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 2, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by Schwab,Wilhelm K

There might be not guarantee that it *can* run the code (an exception might be raised ending the block, it might find itself waiting on an unsignaled semaphore, etc.), but it should be **guaranteed** an opportunity to begin. IIRC, Dolphin provides special handling to temporarily restart processes in order to get this right. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Tuesday, March 02, 2010 4:57 PM To: The general-purpose Squeak developers list Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available) 2010/3/2 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: > >> >>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!' Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>> >>> Why don't we get it printing? >> >> Forgot a . there, supposed to be >> >> |proc| >> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >> 'Finish!'. Processor yield.]] newProcess. >> proc resume. >> Processor yield. >> proc suspend. >> proc terminate. >> >> on my machine it prints: >> *Start!Start!Finish! > > The problem occurs because Transcript >> #endEntry (sent from #show:) > takes a while to execute, so the process (proc) prints 'Start!', but > it gets terminated before execution reaches #resetContents (#reset in > Squeak). So 'Start!' is still in the stream. Then our process executes > the > #ensure: block and it prints 'Start!' and 'Finish!' too. > > There's worse problem with #ensure: and #terminate is that, a process > executing an #ensure: block can be terminated. If you evaluate this code: > > | process stage1 stage2 stage3 counter | > stage1 := stage2 := stage3 := false. > counter := 0. > process := [ > Â Â Â Â [ stage1 := true ] ensure: [ > Â Â Â Â Â Â Â Â stage2 := true. > Â Â Â Â Â Â Â Â 1000000 timesRepeat: [ counter := counter + 1 ]. > Â Â Â Â Â Â Â Â stage3 := true ] ] newProcess. > process resume. > Processor yield. > process suspend. > process terminate. > 1000 milliSeconds asDelay wait. > { stage1. stage2. stage3. counter } explore > > you will find that stage1 and stage2 is reached as expected, but > stage3 is not and counter is less than 1000000. That's because the > forked process started evaluating the #ensure: block, but it was terminated by our process. > > Is this the expected behavior when sending #terminate to a process > which is evaluating an #ensure: block? > > What you think is expected behavior here: a) process termination should start (be triggered) only when process is outside of any #ensure: closure? b) #ensure: block should always run to the end, despite anything? Since you can't predict, what code will run inside ensure block, the only guarantee that you having is actually that your process will always enters such blocks during the normal flow, or exception handling. But there is no guarantees that it will be able to run the code inside it, when you terminating it. > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * > > > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 2, 2010

Re: [Pharo-project] [squeak-dev] #ensure: issues (was: Re: Pharo by Example vol 2: new chapter available)

by Igor Stasenko

2010/3/2 Levente Uzonyi <leves(a)elte.hu>: > On Tue, 2 Mar 2010, Henrik Sperre Johansen wrote: > >> >>>> PS. For the not-so-faint-of-heart, open a Transcript and try evaluating: >>>> |proc| >>>> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >>>> 'Finish!' Processor yield.]] newProcess. >>>> proc resume. >>>> Processor yield. >>>> proc suspend. >>>> proc terminate. >>> >>> Why don't we get it printing? >> >> Forgot a . there, supposed to be >> >> |proc| >> proc := [[Transcript show: 'Start!'. ] ensure: [Transcript show: >> 'Finish!'. Processor yield.]] newProcess. >> proc resume. >> Processor yield. >> proc suspend. >> proc terminate. >> >> on my machine it prints: >> *Start!Start!Finish! > > The problem occurs because Transcript >> #endEntry (sent from #show:) > takes a while to execute, so the process (proc) prints 'Start!', but > it gets terminated before execution reaches #resetContents (#reset in > Squeak). So 'Start!' is still in the stream. Then our process executes the > #ensure: block and it prints 'Start!' and 'Finish!' too. > > There's worse problem with #ensure: and #terminate is that, a process > executing an #ensure: block can be terminated. If you evaluate this code: > > | process stage1 stage2 stage3 counter | > stage1 := stage2 := stage3 := false. > counter := 0. > process := [ > Â Â Â Â [ stage1 := true ] ensure: [ > Â Â Â Â Â Â Â Â stage2 := true. > Â Â Â Â Â Â Â Â 1000000 timesRepeat: [ counter := counter + 1 ]. > Â Â Â Â Â Â Â Â stage3 := true ] ] newProcess. > process resume. > Processor yield. > process suspend. > process terminate. > 1000 milliSeconds asDelay wait. > { stage1. stage2. stage3. counter } explore > > you will find that stage1 and stage2 is reached as expected, but stage3 is > not and counter is less than 1000000. That's because the forked process > started evaluating the #ensure: block, but it was terminated by our process. > > Is this the expected behavior when sending #terminate to a process which is > evaluating an #ensure: block? > > What you think is expected behavior here: a) process termination should start (be triggered) only when process is outside of any #ensure: closure? b) #ensure: block should always run to the end, despite anything? Since you can't predict, what code will run inside ensure block, the only guarantee that you having is actually that your process will always enters such blocks during the normal flow, or exception handling. But there is no guarantees that it will be able to run the code inside it, when you terminating it. > Cheers, > BalÃ¡zs & Levente > > >> >> *yay >> Henry* >> * > > > > -- Best regards, Igor Stasenko AKA sig.

March 2, 2010