- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream

by StÃ©phane Ducasse

On Apr 12, 2010, at 7:53 PM, Philippe Marschall wrote: > On 11.04.2010 21:46, Levente Uzonyi wrote: >> On Sun, 11 Apr 2010, Philippe Marschall wrote: >> >>> Hi >>> >>> While I was optimizing some Seaside code I found out that SocketStream >>> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >>> method that allows one to write a subcollection of a collection to a >>> stream without making a copy. In our case it would allow the codec to >>> directly write to the socket stream. >>> >>> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >>> >>> [1] http://code.google.com/p/pharo/issues/detail?id=2292 >> >> FYI: http://code.google.com/p/pharo/issues/detail?id=2244 > > Oops, sorry. > > The merged code is a bit different, it's oriented more towards the > current #nextPutAll: > - it answers self like #nextPutAll: and not the collection passed > in. ANSI says it's unspecified and current implementations are not > conclusive, most answer the collection but not all. That probably means > we should change #nextPutAll: as well. > - it explicitly checks for n = 0 as a guarding clause. That's certainly > discussable, I found algorithms easier to write when I don't have to > check for n = 0 at the send site. > - it had an off by one error > - like #nextPutAll: it does type conversion based on the mode. > > To sum up: > - #nextPutAll: and #next:putAll:startingAt: should probably be changed > to answer the collection and fix other implementations. nicolas did the inverse in squeak > - if the type conversion is needed (I believe so) then SocketStream > should do it > - the n = 0 guarding clause is discussable > - IMO consistency with #nextPutAll: is important do you have some code? Because it seems that you have more knowledge than me on that :) Stef

April 12, 2010

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

by StÃ©phane Ducasse

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

April 12, 2010

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

by Igor Stasenko

On 12 April 2010 20:49, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 4/12/2010 10:43 AM, Igor Stasenko wrote: >> >> On 12 April 2010 19:32, Andreas Raab<andreas.raab(a)gmx.de> Â wrote: >>> >>> On 4/12/2010 7:17 AM, Igor Stasenko wrote: >>>> >>>> what you think? >>> >>> I think "no, no, no". Two reasons: 1) the extension of the splObjs >>> implies a >>> hardcoded contract with the VM; having it externally settable makes it >>> look >>> as if one could just stick in stuff for fun. >> >> By 'For fun', you mean writing a plugin, which needs own a special >> objects to work? > > You don't need special objects. Their use in FFI and Alien is a historical > accident. What you'd do today is register the classes directly with your > plugin instead of sticking them into splObjs. > >> I wanted to add a special objects couple of times in plugins, but then i >> had to >> step back , knowing that it will require overriding the >> #recreateSpecialObjects >> method, which is tedious and error prone, because you never know if people >> who may use your plugin could also use FFI, Alien or something else. > > Precisely. All of these are good reasons why you shouldn't modify splObjs to > begin with. What you do instead is to provide a primitive in your plugin > that accepts the classes / objects you intend to use. This wouldn't work in > the past because you had no way of handling GC correctly. > > 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? > Cheers, > Â - Andreas > >> -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] add #next:putAll:startingAt: to SocketStream

by Philippe Marschall

On 11.04.2010 21:46, Levente Uzonyi wrote: > On Sun, 11 Apr 2010, Philippe Marschall wrote: > >> Hi >> >> While I was optimizing some Seaside code I found out that SocketStream >> does not understand #next:putAll:startingAt: [1]. It's quite a helpful >> method that allows one to write a subcollection of a collection to a >> stream without making a copy. In our case it would allow the codec to >> directly write to the socket stream. >> >> Anyway what I wanted to say is this is fixed in Network-Kernel-pmm.29 ;-) >> >> [1] http://code.google.com/p/pharo/issues/detail?id=2292 > > FYI: http://code.google.com/p/pharo/issues/detail?id=2244 Oops, sorry. The merged code is a bit different, it's oriented more towards the current #nextPutAll: - it answers self like #nextPutAll: and not the collection passed in. ANSI says it's unspecified and current implementations are not conclusive, most answer the collection but not all. That probably means we should change #nextPutAll: as well. - it explicitly checks for n = 0 as a guarding clause. That's certainly discussable, I found algorithms easier to write when I don't have to check for n = 0 at the send site. - it had an off by one error - like #nextPutAll: it does type conversion based on the mode. To sum up: - #nextPutAll: and #next:putAll:startingAt: should probably be changed to answer the collection and fix other implementations. - if the type conversion is needed (I believe so) then SocketStream should do it - the n = 0 guarding clause is discussable - IMO consistency with #nextPutAll: is important Cheers Philippe

April 12, 2010