- Pharo-dev - lists.pharo.org

Re: [Pharo-project] O2 in 1.1

by StÃ©phane Ducasse

On May 18, 2010, at 10:00 PM, Geert Claes wrote: > > Just loaded O2 in 1.1 and when I start it I get the warning "The method > Collection asSortedArray has been deprecated. Use asArray sort" > > How do I actually change my default system browser back? Look at ToolSet you can also click on the window right icons and get the menu and select choose new default browser. Would be good then to fix the deprecated use. Stef > -- > View this message in context: http://forum.world.st/O2-in-1-1-tp2221821p2221821.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] [Vm-dev] Re: how to change the default size of the Pharo host windows?

by Igor Stasenko

On 18 May 2010 22:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, May 18, 2010 at 11:52 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> cool we could turn them into nice query methods with semantics revealing names :) > > I would just use a SHaredPool with class variables appropriately named, e.g. > SharedPool subclass: #VMParameterNames > instanceVariableNames: '' > classVariableNames: '... ImageFormatVersion ...' > VMParameterNames class methods for initialization > initialize > ... > ImageFormatVersion := 41 > ... > then a client would use things like > Smalltalk image vmParameterAt:Â ImageFormatVersion > These are for very special uses and I don't really like the idea of making access to them too easy. > With such excuse, were ending up with a hacky shell scripts - an ultimately afwul way to access these attributes. It should be easier :) Its been always easy to make a mess: Array setFormat: 88888. Array new. bye-bye vm & image. Just give developers freedom, and then it is their own responsibility to not make mess out of it, not yours. -- Best regards, Igor Stasenko AKA sig.

May 18, 2010

[Pharo-project] O2 in 1.1

by Geert Claes

Just loaded O2 in 1.1 and when I start it I get the warning "The method Collection asSortedArray has been deprecated. Use asArray sort" How do I actually change my default system browser back? -- View this message in context: http://forum.world.st/O2-in-1-1-tp2221821p2221821.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Eliot Miranda

On Tue, May 18, 2010 at 11:52 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > cool we could turn them into nice query methods with semantics revealing > names :) > I would just use a SHaredPool with class variables appropriately named, e.g. SharedPool subclass: #VMParameterNames instanceVariableNames: '' classVariableNames: '... ImageFormatVersion ...' VMParameterNames class methods for initialization initialize ... ImageFormatVersion := 41 ... then a client would use things like Smalltalk image vmParameterAt: ImageFormatVersion These are for very special uses and I don't really like the idea of making access to them too easy. > On May 18, 2010, at 7:21 PM, Eliot Miranda wrote: > > > > > > > On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > 2010/5/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > > > > On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse > > > <stephane.ducasse(a)inria.fr> wrote: > > >> > > >> On Ma > > >> > > > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog > also > > >> > uses bits 1 through 4 > > >> > bit 0: 1 => open full screen, 0 => open using width & > > >> > height > > >> > bit 1: 1 => image floats are in little-endian format, > 0=> > > >> > image floats are in big-endian format > > >> > bit 2: 1 => Process's 4th inst var (after myList) is > > >> > threadId to be used by the VM for overlapped calls > > >> > > > >> > bit 3: 1 => set the flag bit on methods that the VM > will > > >> > only interpret (because they're considered too big to JIT) > > >> > bit 4: 1 => preempting a process does not put it to > the > > >> > back of its run queue > > >> > > >> > > >> I was not clear how to read > > >> bit 3: 1 > > >> this information is not in the compiledMethods? > > > > > > For the Cog JIT I want to measure which methods get interpreted to > determine > > > the threshold at which to decide to JIT methods. It makes little sense > to > > > JIT methods that are large and only executed once, typically class > > > initialization methods. A simple criterion is to set a limit on the > number > > > of literals in a method. But I still need to know whether my threshold > is > > > affecting frequently used methods. So I added the option of setting > the > > > flag bit in any method which the JIT refuses to compile because it has > too > > > many literals. Since I need to see which methods are interpreted on > > > start-up putting a flag in the image header was convenient. The effect > is > > > that the JIT will set the flag bit on any method it refuses to JIT. I > can > > > then browse these in the image and decide whether any are important and > > > adjust the threshold accordingly. Arguably this should be a command > line > > > argument, not an image header flag. > > > > Eliot, i beg you, instead of using an obscure flags in image header, > > just add (or reserve unused) splObject indice and read/write whatever > > you want from there. > > > > SOme times it isn't appropriate to put flags in the special objects > array. Further, changing the specialObjectsArray isn't only a VM change, > its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all > the flags which can be set in the header I provide access through > vmParameterAt:[put:]. > > > > > > I guess that Cog having substantial changes all around places, so > > adding a convenient API for VM flags > > and removing a bit fiddling from image header, would make things > > transparent and easy to use from language side. > > > > Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's > different in vmParameterAt:put: at Teleplace: > > VM parameters are numbered as follows: > > ... > > 4 allocationCount (read-only; nil in Cog VMs) > > 5 allocations between GCs (read-write; nil in Cog > VMs) > > ... > > 41 imageFormatVersion for the VM > > 42 number of stack pages in use (Cog Stack VM only, > otherwise nil) > > 43 desired number of stack pages (stored in image file > header, max 65535; Cog VMs only, otherwise nil) > > 44 size of eden, in bytes (Cog VMs only, otherwise > nil) > > 45 desired size of eden, in bytes (stored in image > file header; Cog VMs only, otherwise nil) > > 46 size of machine code zone, in bytes (stored in > image file header; Cog JIT VM only, otherwise nil) > > 47 desired size of machine code zone, in bytes > (applies at startup only, stored in image file header; Cog JIT VM only) > > 48 various properties of the Cog VM as an integer > encoding an array of bit flags. > > Bit 0: implies the image's Process class has > threadId as its 3rd inst var (zero relative) > > Bit 1: if set, methods that are interpreted will > have the flag bit set in their header > > Bit 2: if set, implies preempting a process does > not put it to the back of its run queue > > 49-55 reserved for VM parameters that persist in the image > (such as eden above) > > 56 number of process switches since startup > (read-only) > > 57 number of ioProcessEvents calls since startup > (read-only) > > 58 number of ForceInterruptCheck (Cog VMs) or > quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) > > 59 number of check event calls since startup > (read-only) > > 60 number of stack page overflows since startup > (read-only; Cog VMs only) > > 61 number of stack page divorces since startup > (read-only; Cog VMs only) > > 62 compiled code compactions since startup (read-only; > Cog only; otherwise nil) > > 63 total milliseconds in compiled code compactions > since startup (read-only; Cog only; otherwise nil) > > > > > > > > > > > > >> > > >> Stef > > >> > > >> > > >> _______________________________________________ > > >> 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. > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by StÃ©phane Ducasse

cool we could turn them into nice query methods with semantics revealing names :) On May 18, 2010, at 7:21 PM, Eliot Miranda wrote: > > > On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> On Ma > >> > > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also > >> > uses bits 1 through 4 > >> > bit 0: 1 => open full screen, 0 => open using width & > >> > height > >> > bit 1: 1 => image floats are in little-endian format, 0=> > >> > image floats are in big-endian format > >> > bit 2: 1 => Process's 4th inst var (after myList) is > >> > threadId to be used by the VM for overlapped calls > >> > > >> > bit 3: 1 => set the flag bit on methods that the VM will > >> > only interpret (because they're considered too big to JIT) > >> > bit 4: 1 => preempting a process does not put it to the > >> > back of its run queue > >> > >> > >> I was not clear how to read > >> bit 3: 1 > >> this information is not in the compiledMethods? > > > > For the Cog JIT I want to measure which methods get interpreted to determine > > the threshold at which to decide to JIT methods. It makes little sense to > > JIT methods that are large and only executed once, typically class > > initialization methods. A simple criterion is to set a limit on the number > > of literals in a method. But I still need to know whether my threshold is > > affecting frequently used methods. So I added the option of setting the > > flag bit in any method which the JIT refuses to compile because it has too > > many literals. Since I need to see which methods are interpreted on > > start-up putting a flag in the image header was convenient. The effect is > > that the JIT will set the flag bit on any method it refuses to JIT. I can > > then browse these in the image and decide whether any are important and > > adjust the threshold accordingly. Arguably this should be a command line > > argument, not an image header flag. > > Eliot, i beg you, instead of using an obscure flags in image header, > just add (or reserve unused) splObject indice and read/write whatever > you want from there. > > SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:]. > > > I guess that Cog having substantial changes all around places, so > adding a convenient API for VM flags > and removing a bit fiddling from image header, would make things > transparent and easy to use from language side. > > Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: > VM parameters are numbered as follows: > ... > 4 allocationCount (read-only; nil in Cog VMs) > 5 allocations between GCs (read-write; nil in Cog VMs) > ... > 41 imageFormatVersion for the VM > 42 number of stack pages in use (Cog Stack VM only, otherwise nil) > 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil) > 44 size of eden, in bytes (Cog VMs only, otherwise nil) > 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil) > 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil) > 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only) > 48 various properties of the Cog VM as an integer encoding an array of bit flags. > Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) > Bit 1: if set, methods that are interpreted will have the flag bit set in their header > Bit 2: if set, implies preempting a process does not put it to the back of its run queue > 49-55 reserved for VM parameters that persist in the image (such as eden above) > 56 number of process switches since startup (read-only) > 57 number of ioProcessEvents calls since startup (read-only) > 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) > 59 number of check event calls since startup (read-only) > 60 number of stack page overflows since startup (read-only; Cog VMs only) > 61 number of stack page divorces since startup (read-only; Cog VMs only) > 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) > 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil) > > > > > > >> > >> Stef > >> > >> > >> _______________________________________________ > >> 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. > > _______________________________________________ > 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

May 18, 2010

Re: [Pharo-project] how to change the default size of the Pharo host windows?

by Eliot Miranda

On Mon, May 17, 2010 at 9:04 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/17 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > > > On Mon, May 17, 2010 at 11:30 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> On Ma > >> > > >> > bytes 28 to 31: image flags, conventional VMs use only bit 0, Cog also > >> > uses bits 1 through 4 > >> > bit 0: 1 => open full screen, 0 => open using width & > >> > height > >> > bit 1: 1 => image floats are in little-endian format, > 0=> > >> > image floats are in big-endian format > >> > bit 2: 1 => Process's 4th inst var (after myList) is > >> > threadId to be used by the VM for overlapped calls > >> > > >> > bit 3: 1 => set the flag bit on methods that the VM will > >> > only interpret (because they're considered too big to JIT) > >> > bit 4: 1 => preempting a process does not put it to the > >> > back of its run queue > >> > >> > >> I was not clear how to read > >> bit 3: 1 > >> this information is not in the compiledMethods? > > > > For the Cog JIT I want to measure which methods get interpreted to > determine > > the threshold at which to decide to JIT methods. It makes little sense > to > > JIT methods that are large and only executed once, typically class > > initialization methods. A simple criterion is to set a limit on the > number > > of literals in a method. But I still need to know whether my threshold > is > > affecting frequently used methods. So I added the option of setting the > > flag bit in any method which the JIT refuses to compile because it has > too > > many literals. Since I need to see which methods are interpreted on > > start-up putting a flag in the image header was convenient. The effect > is > > that the JIT will set the flag bit on any method it refuses to JIT. I > can > > then browse these in the image and decide whether any are important and > > adjust the threshold accordingly. Arguably this should be a command line > > argument, not an image header flag. > > Eliot, i beg you, instead of using an obscure flags in image header, > just add (or reserve unused) splObject indice and read/write whatever > you want from there. > SOme times it isn't appropriate to put flags in the special objects array. Further, changing the specialObjectsArray isn't only a VM change, its also a change to SystemDictionary>>recreateSpecialObjectsArray. For all the flags which can be set in the header I provide access through vmParameterAt:[put:]. > I guess that Cog having substantial changes all around places, so > adding a convenient API for VM flags > and removing a bit fiddling from image header, would make things > transparent and easy to use from language side. > Ah, ok. That exists in vmParameterAt:[put:]. i.e. here's what's different in vmParameterAt:put: at Teleplace: VM parameters are numbered as follows: ... 4 allocationCount (read-only; nil in Cog VMs) 5 allocations between GCs (read-write; nil in Cog VMs) ... 41 imageFormatVersion for the VM 42 number of stack pages in use (Cog Stack VM only, otherwise nil) 43 desired number of stack pages (stored in image file header, max 65535; Cog VMs only, otherwise nil) 44 size of eden, in bytes (Cog VMs only, otherwise nil) 45 desired size of eden, in bytes (stored in image file header; Cog VMs only, otherwise nil) 46 size of machine code zone, in bytes (stored in image file header; Cog JIT VM only, otherwise nil) 47 desired size of machine code zone, in bytes (applies at startup only, stored in image file header; Cog JIT VM only) 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: if set, methods that are interpreted will have the flag bit set in their header Bit 2: if set, implies preempting a process does not put it to the back of its run queue 49-55 reserved for VM parameters that persist in the image (such as eden above) 56 number of process switches since startup (read-only) 57 number of ioProcessEvents calls since startup (read-only) 58 number of ForceInterruptCheck (Cog VMs) or quickCheckInterruptCalls (non-Cog VMs) calls since startup (read-only) 59 number of check event calls since startup (read-only) 60 number of stack page overflows since startup (read-only; Cog VMs only) 61 number of stack page divorces since startup (read-only; Cog VMs only) 62 compiled code compactions since startup (read-only; Cog only; otherwise nil) 63 total milliseconds in compiled code compactions since startup (read-only; Cog only; otherwise nil) > >> > >> Stef > >> > >> > >> _______________________________________________ > >> 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. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 18, 2010

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by StÃ©phane Ducasse

Right now SystemOrganization is a global stored in SystemDictionary. And it would be nice to have a new instance named organizer held by SystemDictionary that points to the organizer associated with the SystemDictionary. Similarly it would be good not to point to the global but use this new methods. I imagine that it requires some care. Now if you have a class comments please send it we will integrate it: add it to the bug tracker. I'm a bit worry to introduce a "singleton" Stef > > > StÃ©phane Ducasse wrote: >> >> Now can we do it better :) what I would love it if we can have >> SystemOrganization be an instance variable of the SystemDictionary and >> may be returned by the categorizer message sent to Smalltalk globals. >> This way each instance of SystemDictionary would have its own >> SystemOrganizer instance. >> > > Sounds good. I might be able to do that if I had more detail. > > Also, until that refactoring is done, it would be helpful to make > SystemOrganizer easier to use - if not the method, maybe at least the class > comment? > > > StÃ©phane Ducasse wrote: >> >> This will make sure that people >> can experiment with alternate semantics and that we do not have one >> monolitic system :) >> > Sounds interesting (even though I'm not sure exactly what that means, lol). > Maybe I'll do a little digging here... > > Sean > -- > View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 18, 2010

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Lukas Renggli

> Sounds good. Â I might be able to do that if I had more detail. > > Also, until that refactoring is done, it would be helpful to make > SystemOrganizer easier to use - if not the method, maybe at least the class > comment? Currently it is impossible to instantiate a new namespace and open a browser on it, because the organization is global. If the organization would be a variable of the namespace (SystemDictionary) and not a global, there would be no such problem: Smalltalk globals organization Lukas -- Lukas Renggli www.lukas-renggli.ch

May 18, 2010

[Pharo-project] [update 1.1] #11366

by StÃ©phane Ducasse

11366 ----- - merged the changes for Issue 1884 (NetNameResolver doesnt work in PharoCore) Next condense changes and clean stuff reported by torsten Stef

May 18, 2010

Re: [Pharo-project] Feature: SystemOrganizer class>>default returns SystemOrganization

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > Now can we do it better :) what I would love it if we can have > SystemOrganization be an instance variable of the SystemDictionary and > may be returned by the categorizer message sent to Smalltalk globals. > This way each instance of SystemDictionary would have its own > SystemOrganizer instance. > Sounds good. I might be able to do that if I had more detail. Also, until that refactoring is done, it would be helpful to make SystemOrganizer easier to use - if not the method, maybe at least the class comment? StÃ©phane Ducasse wrote: > > This will make sure that people > can experiment with alternate semantics and that we do not have one > monolitic system :) > Sounds interesting (even though I'm not sure exactly what that means, lol). Maybe I'll do a little digging here... Sean -- View this message in context: http://forum.world.st/Feature-SystemOrganizer-class-default-returns-SystemO… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 18, 2010