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

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by StÃ©phane Ducasse

+ 1 for that. Stef On Apr 12, 2010, at 4:42 PM, Henrik Johansen wrote: > On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote: > >> Hello, >> >> i attempted to load Alien-Core package into trunk image, and it failed. >> >> One of the problem is override of recreateSpecialObjectsArray method.. >> >> I wonder, maybe we should design a nicer API for extending/reserving >> slots in special objects array, >> so it won't require overriding this method by every package which >> needs to extend special objects, like FFI or Alien. >> >> Another aspect of replacing this method is , that it makes problematic >> to unload such package, in case one wants to unload it. >> >> So, my proposal is to add a simple API to SmalltalkImage class, and in >> order to install additional special objects one should do like: >> >> MyClass class>>initialize >> >> Smalltalk registerSpecialObject: myObject at: 55. >> Smalltalk registerSpecialObject: myObject at: 56. >> ... >> >> or: >> >> Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. >> >> upon package unload, a reverse scheme should be supported: >> >> >> MyClass class>>unload >> >> Smalltalk unregisterSpecialObjectAt: 55. >> Smalltalk unregisterSpecialObjectAt: 56. >> ... >> >> or: >> >> Smalltalk unregisterSpecialObjects: 3 startingAt: 56. >> >> >> what you think? >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > +1 for the overall idea. > Implementation-wise, I'd also vote for raising errors in registerSpecialObject:at: if something other than myObject is already registered, changing to unregisterSpecialObject: at: in order to not unintentionally unregistering something else, and disallow unregisterSpecialObjects:startingAt: ;) > > Cheers, > Henry > > > _______________________________________________ > 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 Fernando olivero

On Apr 12, 2010, at 5:16 PM, Igor Stasenko wrote: > On 12 April 2010 17:43, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: >> Good idea! I had a similar idea when initially worked on Alien loader. >> >> I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the assumed special object array size. >> >> >> For example: >> Smalltalk registerSpecialObject: myObject with: aName >> >> And later you reference that special object by aName instead of an index to the array. >> >> >> So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes. >> > Yeah, that would be nice. > But this will require VM changes.. and therefore is doomed :) > Also, this could impact the VM speed significantly, because its using > special object quite frequently. > Imagine replacing a simple index-based lookup with name(string) based. > Hi Igor, i wasn't speaking of an on-image API change. For example if you introduced the API you mentioned we could replace Utilities>> initializeClosures "Eliminate the prototype BlockContext from the specialObjectsArray. The VM doesn't use it. This paves the way for removing BlockCOntext altogether and merging ContextPart and MethodContext into e.g. Context." (Smalltalk specialObjectsArray at: 38) class == BlockContext ifTrue:[Smalltalk specialObjectsArray at: 38 put: nil]. With Utilities>> initializeClosures ...... (Smalltalk hasSpecialObjectNamed: #BlockContext) ifTrue:[ Smalltalk unregisterSpecialObjectNamed: #BlockContext ]. ....

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Igor Stasenko

On 12 April 2010 17:43, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Good idea! I had a similar idea when initially worked on Alien loader. > > I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the Â assumed special object array size. > > > For example: > Â Â Â Â Smalltalk registerSpecialObject: myObject with: aName > > Â Â Â Â And later you reference that special object by aName instead of an index to the array. > > > So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes. > Yeah, that would be nice. But this will require VM changes.. and therefore is doomed :) Also, this could impact the VM speed significantly, because its using special object quite frequently. Imagine replacing a simple index-based lookup with name(string) based. > > Fernando > > On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote: > >> Hello, >> >> i attempted to load Alien-Core package into trunk image, and it failed. >> >> One of the problem is override of recreateSpecialObjectsArray method.. >> >> I wonder, maybe we should design a nicer API for extending/reserving >> slots in special objects array, >> so it won't require overriding this method by every package which >> needs to extend special objects, like FFI or Alien. >> >> Another aspect of replacing this method is , that it makes problematic >> to unload such package, in case one wants to unload it. >> >> So, my proposal is to add a simple API to SmalltalkImage class, and in >> order to install additional special objects one should do like: >> >> MyClass class>>initialize >> >> Smalltalk registerSpecialObject: myObject at: 55. >> Smalltalk registerSpecialObject: myObject at: 56. >> ... >> >> or: >> >> Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. >> >> upon package unload, a reverse scheme should be supported: >> >> >> MyClass class>>unload >> >> Smalltalk unregisterSpecialObjectAt: 55. >> Smalltalk unregisterSpecialObjectAt: 56. >> ... >> >> or: >> >> Smalltalk unregisterSpecialObjects: 3 startingAt: 56. >> >> >> what you think? >> >> -- >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Fernando olivero

Good idea! I had a similar idea when initially worked on Alien loader. I think that what is needed also is remove the dependency with the array, i mean explicitly calling the indexes make the image crash if you didn't had the assumed special object array size. For example: Smalltalk registerSpecialObject: myObject with: aName And later you reference that special object by aName instead of an index to the array. So it would be easier to load/unload the packages that extend the special objects array, because there would be no explicit dependency to indexes. Fernando On Apr 12, 2010, at 4:17 PM, Igor Stasenko wrote: > Hello, > > i attempted to load Alien-Core package into trunk image, and it failed. > > One of the problem is override of recreateSpecialObjectsArray method.. > > I wonder, maybe we should design a nicer API for extending/reserving > slots in special objects array, > so it won't require overriding this method by every package which > needs to extend special objects, like FFI or Alien. > > Another aspect of replacing this method is , that it makes problematic > to unload such package, in case one wants to unload it. > > So, my proposal is to add a simple API to SmalltalkImage class, and in > order to install additional special objects one should do like: > > MyClass class>>initialize > > Smalltalk registerSpecialObject: myObject at: 55. > Smalltalk registerSpecialObject: myObject at: 56. > ... > > or: > > Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. > > upon package unload, a reverse scheme should be supported: > > > MyClass class>>unload > > Smalltalk unregisterSpecialObjectAt: 55. > Smalltalk unregisterSpecialObjectAt: 56. > ... > > or: > > Smalltalk unregisterSpecialObjects: 3 startingAt: 56. > > > what you think? > > -- > 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

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Henrik Johansen

On Apr 12, 2010, at 4:17 11PM, Igor Stasenko wrote: > Hello, > > i attempted to load Alien-Core package into trunk image, and it failed. > > One of the problem is override of recreateSpecialObjectsArray method.. > > I wonder, maybe we should design a nicer API for extending/reserving > slots in special objects array, > so it won't require overriding this method by every package which > needs to extend special objects, like FFI or Alien. > > Another aspect of replacing this method is , that it makes problematic > to unload such package, in case one wants to unload it. > > So, my proposal is to add a simple API to SmalltalkImage class, and in > order to install additional special objects one should do like: > > MyClass class>>initialize > > Smalltalk registerSpecialObject: myObject at: 55. > Smalltalk registerSpecialObject: myObject at: 56. > ... > > or: > > Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. > > upon package unload, a reverse scheme should be supported: > > > MyClass class>>unload > > Smalltalk unregisterSpecialObjectAt: 55. > Smalltalk unregisterSpecialObjectAt: 56. > ... > > or: > > Smalltalk unregisterSpecialObjects: 3 startingAt: 56. > > > what you think? > > -- > Best regards, > Igor Stasenko AKA sig. > +1 for the overall idea. Implementation-wise, I'd also vote for raising errors in registerSpecialObject:at: if something other than myObject is already registered, changing to unregisterSpecialObject: at: in order to not unintentionally unregistering something else, and disallow unregisterSpecialObjects:startingAt: ;) Cheers, Henry

April 12, 2010

[Pharo-project] pharo on sparc solaris

by Tudor Girba

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). Can anyone help me with this issue? 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."

April 12, 2010

[Pharo-project] #recreateSpecialObjectsArray woes

by Igor Stasenko

Hello, i attempted to load Alien-Core package into trunk image, and it failed. One of the problem is override of recreateSpecialObjectsArray method.. I wonder, maybe we should design a nicer API for extending/reserving slots in special objects array, so it won't require overriding this method by every package which needs to extend special objects, like FFI or Alien. Another aspect of replacing this method is , that it makes problematic to unload such package, in case one wants to unload it. So, my proposal is to add a simple API to SmalltalkImage class, and in order to install additional special objects one should do like: MyClass class>>initialize Smalltalk registerSpecialObject: myObject at: 55. Smalltalk registerSpecialObject: myObject at: 56. ... or: Smalltalk registerSpecialObjects: #( x y z) startingAt: 56. upon package unload, a reverse scheme should be supported: MyClass class>>unload Smalltalk unregisterSpecialObjectAt: 55. Smalltalk unregisterSpecialObjectAt: 56. ... or: Smalltalk unregisterSpecialObjects: 3 startingAt: 56. what you think? -- Best regards, Igor Stasenko AKA sig.

April 12, 2010

Re: [Pharo-project] BrowserEnvironment>>forPackages: aCollection

by Lukas Renggli

Sure, that seems to be a good idea: Name: Refactoring-Core-lr.123 Author: lr Time: 12 April 2010, 3:28:11 pm UUID: e30a9d78-bd6e-4da0-9d85-ba99270925a4 Ancestors: Refactoring-Core-lr.122 - made packages a set On 12 April 2010 15:15, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > Lukas, i've noticed that PackageEnvironment instance variable packages is an ordered collection. > > Could we make it a Set, so when iterating we reduce iterating the same packages twice, > > Of course just in case a duplicated package was passed as an argument ( which was my case!!!!) > Which leads to iterate possibly multiple times through the classes of packages, which significantly increases time to run when using the whole system. > > Fernando > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

April 12, 2010

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

by Lukas Renggli

This problem has been fixed a while ago. Lukas 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 > -- Lukas Renggli www.lukas-renggli.ch

April 12, 2010

[Pharo-project] BrowserEnvironment>>forPackages: aCollection

by Fernando olivero

Lukas, i've noticed that PackageEnvironment instance variable packages is an ordered collection. Could we make it a Set, so when iterating we reduce iterating the same packages twice, Of course just in case a duplicated package was passed as an argument ( which was my case!!!!) Which leads to iterate possibly multiple times through the classes of packages, which significantly increases time to run when using the whole system. Fernando

April 12, 2010