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

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

Re: [Pharo-project] pharo on sparc solaris

by Mariano Martinez Peck

On Mon, Apr 12, 2010 at 11:42 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I would need to run a Pharo RC4 image on a Sparc Solaris station. Looking > on the www.squeakvm.org/unix/, I see that there is no VM for such a > station, only for Intel Solaris. > > Unfortunately, I also do not have access to any compiling tools on this > machine (it's a server). not even gcc or cmake ? weird.... > Can anyone help me with this issue? > > Maybe you can cc vm mailing list ? cheers mariano > The machine says it is: > $ uname -a > SunOS ejpdxa9017 5.10 Generic_142900-03 sun4v sparc > SUNW,SPARC-Enterprise-T5220 > > > Cheers, > Doru > > -- > www.tudorgirba.com > > "To lead is not to demand things, it is to make them happen." > > > > > _______________________________________________ > 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 Andreas Raab

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. Cheers, - Andreas > > By keeping things intact, we're having a bottleneck which doesn't > allows developers > to use a special objects array in their plugins for own purposes (i > guess you're not > assuming that FFI and Alien are the only exceptional plugins which > having an ultimate right to > touch a special objects array). > >> 2) The recreation of the >> splObjs implies specific knowledge about which values should be added and >> which values should be removed. >> > Sure, each part of a system knows wery well which objects should be > there and at what place. > But there is no need to recreate an array (unless it needs to grow) , > and it could be done automatically, > by copying old objects into a new, bigger array, while revoking the > #recreateSpecialObjects from system completely. > For replacing an object(s) in array there is a simple as #at:put: > Ensuring an array size doesn't means automatically that it should be > rebuilt from scratch, in same way as OrderedCollection > doesn't forcing you to add all items from scratch into it, once it > needs to grow. > >> In any case, there are only two packages that have ever made mods to the >> splObjs array (FFI and Alien) for *very* specialized reasons. We should just >> add these definitions manually and remove the patch from the Alien package. >> > I think you are mixing the cause and consequence here. As to me, the > reason, why there's only two > plugins who extending a special objects array is because its very > tedious and error prone. > Mostly because of conflicting overrides by different packages! > > Anyways, if you don't like playing with special objects array. Please, > can we think of a scheme which at least > allows us to avoid overrides of a very same method by different packages? > >> Cheers, >> - Andreas >> > >

April 12, 2010

Re: [Pharo-project] browse hierarchyImplementors raise an error

by Mariano Martinez Peck

Yes, sorry it was fixed but I don't remember if I opened a ticket....in case I dind', sorry. But don't worry it will be fixed for the next Pharo image. And if it is not, please let us know. cheers mariano 2010/4/12 Cyrille Delaunay <cy.delaunay(a)gmail.com> > Hello, > > In a Pharo-1.0-10515-rc3 image, > > In the standard class browser, when you click on the green arrow at the left of a method, to > browse hierarchyImplementor, an error occur. > > > I opened an issue: http://code.google.com/p/pharo/issues/detail?id=2305 > > > _______________________________________________ > 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] Open Pharo debugger from a Seaside wallback

by Facundo Vozzi

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 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

April 12, 2010

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

by Igor Stasenko

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? 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. By keeping things intact, we're having a bottleneck which doesn't allows developers to use a special objects array in their plugins for own purposes (i guess you're not assuming that FFI and Alien are the only exceptional plugins which having an ultimate right to touch a special objects array). > 2) The recreation of the > splObjs implies specific knowledge about which values should be added and > which values should be removed. > Sure, each part of a system knows wery well which objects should be there and at what place. But there is no need to recreate an array (unless it needs to grow) , and it could be done automatically, by copying old objects into a new, bigger array, while revoking the #recreateSpecialObjects from system completely. For replacing an object(s) in array there is a simple as #at:put: Ensuring an array size doesn't means automatically that it should be rebuilt from scratch, in same way as OrderedCollection doesn't forcing you to add all items from scratch into it, once it needs to grow. > In any case, there are only two packages that have ever made mods to the > splObjs array (FFI and Alien) for *very* specialized reasons. We should just > add these definitions manually and remove the patch from the Alien package. > I think you are mixing the cause and consequence here. As to me, the reason, why there's only two plugins who extending a special objects array is because its very tedious and error prone. Mostly because of conflicting overrides by different packages! Anyways, if you don't like playing with special objects array. Please, can we think of a scheme which at least allows us to avoid overrides of a very same method by different packages? > Cheers, > Â - Andreas > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

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

by Henrik Johansen

On Apr 12, 2010, at 5:54 59PM, Marcus Denker 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 It can still be slow in 1.1, depending on where the log is written to. F.ex. I opened an image on Windows under Parallells, which decided it wanted to write to somewhere in the mounted OSX home directory, took a few good seconds for the debugger to open. Cheers, Henry

April 12, 2010