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

Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes

by Igor Stasenko

Okay, then i propose to: 1. fix the interpreterProxy spec, so all VMs will include addRoot() & friends 2. create a single and _final_ version of #recreateSpecialObjectsArray 3. remove overrides of this method from both FFI and Alien packages. 4. Optionally, rewrite plugins to use own special objects at initialization, so they no longer need extending specialObjectsArray, and hence use of #recreateSpecialObjectsArray -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] Open Pharo debugger from a Seaside wallback

by Facundo Vozzi

Stef, It took to me over 20 minutes to complete the Seaside 2.8 installation and when I interrupted it the debugger opened when the system was writting the pharoXXX.changes always but I couldn't check what is happening. I will check it again. Facu ps: I refered to pharoXXX.changes as "log" because of Visual Smalltalk where the "changes" are called changes.log, excuse me. On Mon, Apr 12, 2010 at 3:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > Marcus, > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > Thank you, > > > > Facu > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > which log? > > Stef > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > >> Lukas, > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > >> > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > > >> to open de smalltalk debugger. > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > >> > > > > > > Did you check with Pharo 1.1? > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE… > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > but Pharo 1.1 > > > > > > > My theory for your bug is that it's this: > > > > http://code.google.com/p/pharo/issues/detail?id=860 > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > to be released > > "very soon". > > > > Marcus > > > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542-9999 x108 > > fvozzi(a)infoil.com.ar > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542-9999 x108 fvozzi(a)infoil.com.ar

April 12, 2010

Re: [Pharo-project] Open Pharo debugger from a Seaside wallback

by Facundo Vozzi

Marcus, it's took to me over 20 minutes complete the Seaside 2.8 instalation and the problem persist. It takes 15 seconds to open the smalltalk debugger from the seaside wallback page. Facu On Mon, Apr 12, 2010 at 12:41 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > Lukas, > > It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > > > But I test it on the same machine with Squeak 4.1 RC4 and it go very very > fast > > to open de smalltalk debugger. > > Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > > > Did you check with Pharo 1.1? > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE… > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, but > Pharo 1.1 > > Marcus > > > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Facundo Vozzi InfOil S.A. Project Leader (+54-11) 4542-9999 x108 fvozzi(a)infoil.com.ar

April 12, 2010

Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes

by John M McIntosh

It's in the Alien directory. somehow it never got promoted to the cross platform directory. So check the sqVirtualMachine.h You may need to adjust it. On 2010-04-12, at 12:01 PM, Igor Stasenko wrote: > On 12 April 2010 21:52, Andreas Raab <andreas.raab(a)gmx.de> wrote: >> On 4/12/2010 11:46 AM, Igor Stasenko wrote: >>> >>> Ah, that's cool.. Except that most recent SVN repository >>> sqVirtualMachine.h (revision 1955) having no addGCroot: defined in >>> InterpreterProxy struct. >>> I am using wrong SVN repository? >>> http://squeakvm.org/svn/squeak/trunk/ >> >> Err, weird. The code is in VMMaker but it seems as if SVN hasn't been >> updated. It should include this: >> > > Yes. I remember seeing that code before. > This is twice strange that its not in SVN repo. > > [snip] > >> >> Cheers, >> - Andreas >> >> > > > > -- > 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 -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

April 12, 2010

Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes

by Igor Stasenko

On 12 April 2010 21:52, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/12/2010 11:46 AM, Igor Stasenko wrote: >> >> Ah, that's cool.. Except that most recent SVN repository >> sqVirtualMachine.h (revision 1955) having no addGCroot: defined in >> InterpreterProxy struct. >> I am using wrong SVN repository? >> http://squeakvm.org/svn/squeak/trunk/ > > Err, weird. The code is in VMMaker but it seems as if SVN hasn't been > updated. It should include this: > Yes. I remember seeing that code before. This is twice strange that its not in SVN repo. [snip] > > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

[Pharo-project] Regex Chapter for PBE 2 is now online

by Oscar Nierstrasz

The draft chapter on Regular Expressions in Pharo planned for Pharo by Example 2 is now available online for review: https://gforge.inria.fr/frs/download.php/26818/Regex.pdf Please send feedback to the discussion list for SBE and PBE: https://www.iam.unibe.ch/mailman/listinfo/sbe-discussion Thanks, - on

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Andreas Raab

On 4/12/2010 11:46 AM, Igor Stasenko wrote: > Ah, that's cool.. Except that most recent SVN repository > sqVirtualMachine.h (revision 1955) having no addGCroot: defined in > InterpreterProxy struct. > I am using wrong SVN repository? > http://squeakvm.org/svn/squeak/trunk/ Err, weird. The code is in VMMaker but it seems as if SVN hasn't been updated. It should include this: #if VM_PROXY_MINOR > 7 /* New methods for proxy version 1.8 */ /* callbackEnter: Re-enter the interpreter loop for a callback. Arguments: callbackID: Pointer to a location receiving the callback ID used in callbackLeave Returns: True if successful, false otherwise */ sqInt (*callbackEnter)(sqInt *callbackID); /* callbackLeave: Leave the interpreter from a previous callback Arguments: callbackID: The ID of the callback received from callbackEnter() Returns: True if succcessful, false otherwise. */ sqInt (*callbackLeave)(sqInt callbackID); /* addGCRoot: Add a variable location to the garbage collector. The contents of the variable location will be updated accordingly. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*addGCRoot)(sqInt *varLoc); /* removeGCRoot: Remove a variable location from the garbage collector. Arguments: varLoc: Pointer to the variable location Returns: True if successful, false otherwise. */ sqInt (*removeGCRoot)(sqInt *varLoc); #endif Cheers, - Andreas

April 12, 2010

Re: [Pharo-project] [squeak-dev] Re: #recreateSpecialObjectsArray woes

by Igor Stasenko

On 12 April 2010 21:08, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/12/2010 10:57 AM, Igor Stasenko wrote: >> >> On 12 April 2010 20:49, Andreas Raab<andreas.raab(a)gmx.de> Â wrote: >>> >>> Today, you can give your plugin an array of your own special objects that >>> is >>> used by your plugin, registered with the VM as a GC root and there's no >>> need >>> to modify splObjs. >>> >> Looks like i missed something. HOW? >> Suppose a primitive needs to answer an instance of a special class, known >> by it. >> How it can instantiate it, if it having no any clues, where its >> invoked from, and it can't rely on a receiver, nor any of method's >> arguments? > > You make it work just like splObjs, i.e., > > FooPlugin>>primitiveSetSplObjs > Â Â Â Â "Sets the special objects for my plugin" > Â Â Â Â splObjs := interpreterProxy stackObjectValue: 0. > Â Â Â Â "... should have sanity checks ..." > Â Â Â Â interpreterProxy addGCRoot: (self cCode: '&splObjs'). > > FooPlugin>>instantiateNewBar > Â Â Â Â "Instantiates a new Bar (at index 2 in the splObjs)" > > Â Â Â Â "... should have sanity checks ..." > Â Â Â Â foo := interpreterProxy instantiateClass: (interpreterProxy > fetchPointer: 2 ofObject: splObjs) indexableSize: 0. > Â Â Â Â interpreterProxy pop: 1 thenPush: foo. > > then you use it like here: > > Foo class>>startUp: resuming > Â Â Â Â "Install my special objects on system startup" > Â Â Â Â resuming ifTrue:[ > Â Â Â Â Â Â Â Â self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}. > Â Â Â Â ]. > > Foo class>>newBar > Â Â Â Â ^self primitiveNewBar > > The "trick" is that your plugin can register whatever it wants for GC > tracing (in fact you should probably set the variable to nilObj and call > addGCRoot from initialiseModule exactly once and release it via > shutdownModule). This removes the need for abusing splObjs to stick in stuff > that you'd like to preserve between prim calls. > Ah, that's cool.. Except that most recent SVN repository sqVirtualMachine.h (revision 1955) having no addGCroot: defined in InterpreterProxy struct. I am using wrong SVN repository? http://squeakvm.org/svn/squeak/trunk/ After some research i found another file in plugins/IA32ABI/, which includes new proxy functions, but its not used by builder. > Cheers, > Â - Andreas > > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] Open Pharo debugger from a Seaside wallback

by Mariano Martinez Peck

Another difference maybe the tools that are loaded in Squeak and Pharo. I am not aware what is loaded in Squeak images, but in PharoDev you have OB, OCompletion, RefactoringBrowser, TrueType fonts, Shout, etc. Some of these tools make Pharo a bit more slower than the PharoCore. If they Squeak image you are using doesn't have all those tools, then you should compare to a PharoCore image, not Dev. Pharo core images doesn't have all the dev tools. Cheers Mariano On Mon, Apr 12, 2010 at 3:05 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Apr 12, 2010, at 7:45 PM, Facundo Vozzi wrote: > > > Marcus, > > I can't install Seaside on Pharo 1.1(*) but then i'll try again at home. > > > > It isn't my point to compare Pharo to Squeak performance but I used > Squeak to test this particular situation. > > > > Thank you, > > > > Facu > > > > (*) it's very slow to write the log taking minutes to complete the > instalation > > which log? > > Stef > > > > > On Mon, Apr 12, 2010 at 12:54 PM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > On Apr 12, 2010, at 5:41 PM, Marcus Denker wrote: > > > > > > > > On Apr 12, 2010, at 5:37 PM, Facundo Vozzi wrote: > > > > > >> Lukas, > > >> It happens on my machine with Windows/(Firefox-Chrome-IE 8) and Pharo. > > >> > > >> But I test it on the same machine with Squeak 4.1 RC4 and it go very > very fast > > >> to open de smalltalk debugger. > > >> Furthermore, Squeak 4.1 RC4 seem to be faster than Pharo, did you note > that too or it's only my sensations? > > >> > > > > > > Did you check with Pharo 1.1? > > > > > > > https://gforge.inria.fr/frs/download.php/26762/PharoCore-1.1-11301-UNSTABLE… > > > > > > In general, Squeak 4.1 should not be compared to Pharo 1.0 speed-wise, > but Pharo 1.1 > > > > > > > My theory for your bug is that it's this: > > > > http://code.google.com/p/pharo/issues/detail?id=860 > > > > We added it to 1.1 on Nov. 01, 2009. Not to 1.0, because 1.0 was supposed > to be released > > "very soon". > > > > Marcus > > > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Facundo Vozzi > > InfOil S.A. > > Project Leader > > (+54-11) 4542-9999 x108 > > fvozzi(a)infoil.com.ar > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Andreas Raab

On 4/12/2010 10:57 AM, Igor Stasenko wrote: > On 12 April 2010 20:49, Andreas Raab<andreas.raab(a)gmx.de> wrote: >> Today, you can give your plugin an array of your own special objects that is >> used by your plugin, registered with the VM as a GC root and there's no need >> to modify splObjs. >> > Looks like i missed something. HOW? > Suppose a primitive needs to answer an instance of a special class, known by it. > How it can instantiate it, if it having no any clues, where its > invoked from, and it can't rely on a receiver, nor any of method's arguments? You make it work just like splObjs, i.e., FooPlugin>>primitiveSetSplObjs "Sets the special objects for my plugin" splObjs := interpreterProxy stackObjectValue: 0. "... should have sanity checks ..." interpreterProxy addGCRoot: (self cCode: '&splObjs'). FooPlugin>>instantiateNewBar "Instantiates a new Bar (at index 2 in the splObjs)" "... should have sanity checks ..." foo := interpreterProxy instantiateClass: (interpreterProxy fetchPointer: 2 ofObject: splObjs) indexableSize: 0. interpreterProxy pop: 1 thenPush: foo. then you use it like here: Foo class>>startUp: resuming "Install my special objects on system startup" resuming ifTrue:[ self primitiveSetSplObjs: {Foo. Bar. DukeNukem. 42}. ]. Foo class>>newBar ^self primitiveNewBar The "trick" is that your plugin can register whatever it wants for GC tracing (in fact you should probably set the variable to nilObj and call addGCRoot from initialiseModule exactly once and release it via shutdownModule). This removes the need for abusing splObjs to stick in stuff that you'd like to preserve between prim calls. Cheers, - Andreas

April 12, 2010