- Pharo-dev - lists.pharo.org

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

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

by StÃ©phane Ducasse

Yes we have to kick our asses more often... but squeak is that for that :) Stef On Apr 12, 2010, at 5:54 PM, 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 > > > > -- > 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

April 12, 2010

[Pharo-project] [ANN 1.1] pre-built core image #11312

by Marcus Denker

https://gforge.inria.fr/frs/download.php/26817/PharoCore-1.1-11312-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 12, 2010

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

by Marcus Denker

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.

April 12, 2010

Re: [Pharo-project] About getting HashedCollection (another dream happening)

by Henrik Johansen

On Apr 12, 2010, at 5:33 42PM, StÃ©phane Ducasse wrote: > igor > > peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes.... > > > Stef Or their application may have different expectations for what methods are ok to return collections with duplicated/nils in them. In which case (in VW) mySourcesWithoutNilsOrDuplicates |myColl| myColl := List new. myColl addAll: self aSourceWithNils. myColl addAll self aSourceWithDuplicates. ^myColl asSet might have been an entirely legit use, which is sure to cause headaches if ported to a dialect which allows nils. Not that that's a common occurrence, or something we should account for, just sayin' Cheers, Henry

April 12, 2010