- Pharo-dev - lists.pharo.org

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

by Marcus Denker

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.

April 12, 2010

Re: [Pharo-project] #recreateSpecialObjectsArray woes

by Igor Stasenko

On 12 April 2010 18:30, Fernando olivero <oliverof(a)lu.unisi.ch> wrote: > > > > 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 ]. > Â Â Â Â .... > Ah you mean associating indexes with corresponding names, so code can use a nice-looking names instead of bare indexes? But then who is responsible for providing these associations? Somewhere you have to put things like: BlockContextIndex := 38. so, then later you can do nice: Smalltalk unregisterSpecialObjectNamed: #BlockContextIndex The problem is, that we don't know these names beforehead. So, should a newly loaded package also define a new index names then? Like Smalltalk registerSpecialObjectIndex: 55 named: #MyName. and then to register an object, it should do: Smalltalk specialObjectAt: #MyName put: MySpecialObject. ? > _______________________________________________ > 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] About getting HashedCollection (another dream happening)

by Levente Uzonyi

On Mon, 12 Apr 2010, Peter Hugosson-Miller wrote: <snip> > > Sig, I agree with you! My example was of some code that would not survive > the transition: using a asSet as a cheap way to get rid of the *possible* > nils in a collection. (ab)using asSet this way is bad practive (if it works at all in VA). #(1 2 3 4 nil 6 7 nil) reject: #isNil and #(1 2 3 4 nil 6 7 nil) select: #notNil (or the corresponding versions with block arguments) are the way to do it. Levente > > In fact, I think I'm going to take a look at our code and do something about > it now, just in case... Thanks for the heads-up > > -- > Cheers, > Peter >

April 12, 2010

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

by Facundo Vozzi

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? Thanks for your attention. Facundo On Sun, Apr 11, 2010 at 6:35 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > I don't have windows, so I cannot help. It would be cool if some > Windows/Firefox user could figure out a permanent solution for our > side, as this problem keeps on reappearing. > > Luas > > 2010/4/11 Facundo Vozzi <facundov79(a)gmail.com>: > > Yes, it's seems to be that issue but its solution didn't repair my > problem. > > I > > think that the problem is relationated with a network configuration issue > so > > i will > > continue trying in that way. > > Thank you Lukas. > > Facundo > > On Sun, Apr 11, 2010 at 5:24 PM, Lukas Renggli <renggli(a)gmail.com> > wrote: > >> > >> This seems to be a known problem: > >> > >> > >> > http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.seaside/20959 > >> > >> Lukas > >> > >> 2010/4/11 Facundo Vozzi <facundov79(a)gmail.com>: > >> > Hi people, > >> > I'm using Pharo RC2 with Seaside 2.8.4 version and it's very slow when > >> > I trying to debugging a seaside application. In other words, I press > the > >> > debug link on the seaside application walback and it take to Pharo > over > >> > 40 > >> > seconds to open de imagen debugger. I tried with Seaside 3 developer > >> > image > >> > and it was the same situation. > >> > I'm using pharo on 32 bits Windows 7 in a Core 2 Duo and 2 GB ram > >> > memory. > >> > Has anybody experimented the same problem or behavior? > >> > Tranks, > >> > Facundo > >> > ps: Please, excuse my poor english. > >> > > >> > _______________________________________________ > >> > 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 > >> > >> _______________________________________________ > >> 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 > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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] About getting HashedCollection (another dream happening)

by StÃ©phane Ducasse

igor peter snippets was just a dull example. Peter mentioned that some people fix consequences instead of causes.... Stef

April 12, 2010

Re: [Pharo-project] [ANN] Pharo Windows VM 4.0.2

by Levente Uzonyi

On Mon, 12 Apr 2010, Torsten Bergmann wrote: > There is a new 4.0.2 Pharo VM for Windows available (see [1]) based > on the same Squeak VM release. If you want to build it yourself just use [2]. > > There was no official announcement from Andreas on 4.0.2 on vm-dev list > but according to the logs ([3]) sound recording should work again with > this release. > > Note that the 4.0x VM's redirect the window close event to the image > (see discussion in [4]) > > Therefore this 4.0.2 VM is mainly useful for people who base their work on > Pharo 1.1. Core Alpha (as of today image nr #11312) > since the Pharo 1.1 image already includes the support to handle > the window close event directly from within the image. > > When you want to use Pharo core 1.0 (currently image #10517) with > this VM you have to use SHIFT+ALT+F4 to close the image. Or just hold shift while you're clicking the X. Levente > Therefor it is better to use 3.11.8 VM (see 5) with the 1.0 images. > > Bye > T. > > > [1] https://gforge.inria.fr/frs/download.php/26814/PharoVM-Win32-4.0.2-bin.zip > [2] https://gforge.inria.fr/frs/download.php/26815/PharoVM-Win32-4.0.2-src.zip > [3] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-April/148560.ht… > [4] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-April/024677.html > [5] https://gforge.inria.fr/frs/download.php/26654/PharoVM-Win32-3.11.8.zip > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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 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