September 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Clarifying and optimizing Integer>>asFloat

by StÃ©phane Ducasse

On Sep 22, 2011, at 6:20 PM, Nicolas Cellier wrote: > 2011/9/22 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Hello nicolas >> >> >> On Sep 22, 2011, at 12:17 AM, Nicolas Cellier wrote: >> >>> It's too long for a mail, but all explained here: >>> http://smallissimo.blogspot.com/2011/09/clarifying-and-optimizing.html >>> >>> Optimizing such kernel message is important - for example when reading >>> a file of floats... >>> Which version do you prefer ? >>> Shall comments be that long ? >> >> YESSSSS :) >> We love good comments! >> And comments should be close to the code else they rot. >> There is no problem having long nd precise comments that empower the reader. >> > > Yes, but if you implement any RFC, you generally put a reference > because that is too much duplicated information... > So there must be a threshold when a link becomes more clever than > inlined comments. > I'm glad if I'm below this threshold. > >> >>> Any other opinion ? >> >> One important question is what is the impact of the hardware dirven solution on bit identical computation >> on different machine. I would do the following: >> use the smalltalk - bit identical idea all the times >> provide one methods for people knowing that they want to get faster but potentially different floats on different platform. >> >> Does it make sense? > > Bit identical computations rely on the rounding mode which is set in > hardware flags. > To my knowledge, all Smalltalk dialects use the default settings and > never change it. > So the case of asFloat is not different from * + - / and other > mathematical functions. > They all rely on this setting. > > I see I introduced a doubt in the blog because I took a perspective of > possible future extensions. > But my intention was to resolve it; case of bad English style ? may be just that we are bad with numbers :) So you are saying that your solutions requires that the platform are IEEE754 so the risks is low then. > Now if some platforms don't adhere to IEEE754, then I think that we > must first try to find a compatibility layer at VM level > It's not difficult to emulate floating point arithmetic in Smalltalk - > see http://smallissimo.blogspot.com/2011/08/arbitraryprecisionfloat.html > (which however does not handle overflow, gradual underflow and NaN). > However it's hard to do it with decent speeds... > > Nicolas > >> >> Stef >> >> >>> >>> Nicolas >>> >> >> >> >

Sept. 22, 2011

Re: [Pharo-project] Smallspaces - Tuple Space for Smalltalk

by Lukas Renggli

I've implemented Tuple Spaces in Helvetia. The implementation is dead simple (50 LOC), slow and practically likely not useful. In fact, I was not interested in Tuple Spaces themselves, but more into supporting call-semantics different to those of Smalltalk. For Tuple Spaces I wrote a Helvetia extensions that allows variables to be passed as reference. This enables a method to write to its arguments and affect the calling context, something that is needed to bind results of a typical Tuple Space query. If you are interested you can have a look at the implementation in the Helvetia One-Click image (http://bit.ly/helvetia-download) The class CULindaSpace implements the tuple space with the basic operations #write:, #take:, #read: and #scan:. Lukas On 22 September 2011 20:18, Dave Mason <dmason(a)mason-rose.ca> wrote: > There is a reference on Wikipedia's page on Tuple Spaces to http://www.fongen.no/?docname=SmallSpaces/ but that is a dead link. > > I was interested in building tuple-space for Smalltalk, but this and a 1988 paper from Matsuoka and Kawai are the only things I turned up. > > If anyone knows more, please let me know. Â Also, I'd be interested to hear if people think this is a particularly good idea before I turn a grad student loose on it. > > Thanks Â ../Dave > -- Lukas Renggli www.lukas-renggli.ch

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Eliot Miranda

On Thu, Sep 22, 2011 at 11:28 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 September 2011 20:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Igor, > > > > On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> > (apologies for the duplicate reply; someone needs to sort out their > >> > threading for the benefit of the community ;) ) > >> > > >> > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker < > marcus.denker(a)inria.fr> > >> > wrote: > >> >> > >> >> Hi, > >> >> > >> >> There are two changesets waiting for integrating in 1.4 that have > >> >> serious > >> >> consequences: > >> >> > >> >> - Ephemerons. The VM level changes are in the Cog VMs build on > Jenkins, > >> >> but have not > >> >> been integrated in the VMMaker codebase. > >> >> > >> >> http://code.google.com/p/pharo/issues/detail?id=4265 > >> > > >> > I would *really* like to back out these changes. The Ephemeron > >> > implementation is very much a prototype, requiring a hack to determine > >> > whether an object is an ephemeron (the presence of a marker class in > >> > the > >> > first inst var) that I'm not at all happy with. There is a neater > >> > implementation available via using an unused instSpec which IMO has > >> > significant advantages (much simpler & faster, instSpec is valid at > all > >> > times, including during compaction, less overhead, doesn't require a > >> > marker > >> > class), and is the route I'm taking with the new > >> > GC/object-representation > >> > I'm working on now. Note that other than determining whether an > object > >> > is > >> > an ephemeron (instSpec/format vs inst var test) the rest of Igor's > code > >> > remains the same. I'd like to avoid too much VM forking. Would you > all > >> > consider putting these changes on hold for now? > >> > If so, I'll make the effort to produce prototype changes (in the area > of > >> > ClassBuilder and class definition; no VM code necessary as yet) to > allow > >> > defining Ephemerons via the int spec route by next week at the latest. > >> > > >> > >> i agree that in my implementation this is a weak point. But its hard > >> to do anything without > >> making changes to object format to identify these special objects. > >> > >> The main story behind this is can we afford to change the internals of > >> VM without being beaten hard > >> by "backwards compatibility" party? :) > > > > I don't think we get stuck in this at all. The instSpec/format field has > an > > unused value (5 i believe) and this can easily be used for Ephemerons. > All > > that is needed is a little image work on these methods: > > Behavior>>typeOfClass > > needs to answer e.g. #ephemeron for ephemeron classes > > ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: > > needs to accept e.g. #ephemeron for type and pass variable: false > > and weak: true for ephemerons to format:variable:words:pointers:weak:. > > ClassBuilder>>format:variable:words:pointers:weak: > > needs to respond to variable: false and weak: true by computing > the > > ephemeron instSpec. > > > > > Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > > > > ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > need siblings, e.g. > > > > > ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category > > > > > superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > Right? This is easy. Then in the VM there are a few places where > pointer > > indexability (formats 3 and 4) need to be firmed up to exclude 5, but > > nothing difficult. We talked about this in email last week. > > > > Do you think this will require boosting an image format version number? > That would make sense. Boosting it so that the new VMs can run older images and newer, ephemeron images, but that ephemeron images won't open on older VMs. Yes, this makes perfect sense. > I think it is, because clearly, an images which expect ephemerons to > function cannot work with older VMs properly without > support of ephemerons. > > And will lead us to numerous reports "cannot open your f*king image" > with my VM :) > Internally, discussing with Marcus and Stef we came to agreement, that > for each Pharo release we should ship > own version of VM (signed appropriately), so then there will be less > confusion. We also thinking that VM versioning > in future should follow the image versioning, again to make things > simpler and to avoid confusion. > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Igor Stasenko

On 22 September 2011 20:06, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Igor, > > On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > (apologies for the duplicate reply; someone needs to sort out their >> > threading for the benefit of the community ;) ) >> > >> > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> >> > wrote: >> >> >> >> Hi, >> >> >> >> There are two changesets waiting for integrating in 1.4 that have >> >> serious >> >> consequences: >> >> >> >> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, >> >> but have not >> >> Â been integrated in the VMMaker codebase. >> >> >> >> Â Â Â Â http://code.google.com/p/pharo/issues/detail?id=4265 >> > >> > I would *really* like to back out these changes. Â The Ephemeron >> > implementation is very much a prototype, requiring a hack to determine >> > whether an object is an ephemeron (the presence of a Â marker class in >> > the >> > first inst var) that I'm not at all happy with. Â There is a neater >> > implementation available via using an unused instSpec which IMO has >> > significant advantages (much simpler & faster, instSpec is valid at all >> > times, including during compaction, less overhead, doesn't require a >> > marker >> > class), and is the route I'm taking with the new >> > GC/object-representation >> > I'm working on now. Â Note that other than determining whether an object >> > is >> > an ephemeron (instSpec/format vs inst var test) the rest of Igor's code >> > remains the same. Â I'd like to avoid too much VM forking. Â Would you all >> > consider putting these changes on hold for now? >> > If so, I'll make the effort to produce prototype changes (in the area of >> > ClassBuilder and class definition; no VM code necessary as yet) to allow >> > defining Ephemerons via the int spec route by next week at the latest. >> > >> >> i agree that in my implementation this is a weak point. But its hard >> to do anything without >> making changes to object format to identify these special objects. >> >> The main story behind this is can we afford to change the internals of >> VM without being beaten hard >> by "backwards compatibility" party? :) > > I don't think we get stuck in this at all. Â The instSpec/format field has an > unused value (5 i believe) and this can easily be used for Ephemerons. All > that is needed is a little image work on these methods: > Â Â Behavior>>typeOfClass > Â Â Â Â needs to answer e.g. #ephemeron for ephemeron classes > Â Â ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: > Â Â Â Â needs to accept e.g. #ephemeron for type and pass variable: false > and weak: true for ephemerons toÂ format:variable:words:pointers:weak:. > Â Â ClassBuilder>>format:variable:words:pointers:weak: > Â Â Â Â needs to respond toÂ variable: false and weak: true by computing the > ephemeron instSpec. > > Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > Â Â Â Â need siblings, e.g. > > ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category > > superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > Right? Â This is easy. Â Then in the VM there are a few places where pointer > indexability (formats 3 and 4) need to be firmed up to exclude 5, but > nothing difficult. Â We talked about this in email last week. > Do you think this will require boosting an image format version number? I think it is, because clearly, an images which expect ephemerons to function cannot work with older VMs properly without support of ephemerons. And will lead us to numerous reports "cannot open your f*king image" with my VM :) Internally, discussing with Marcus and Stef we came to agreement, that for each Pharo release we should ship own version of VM (signed appropriately), so then there will be less confusion. We also thinking that VM versioning in future should follow the image versioning, again to make things simpler and to avoid confusion. -- Best regards, Igor Stasenko.

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Eliot Miranda

On Thu, Sep 22, 2011 at 11:06 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Igor, > > On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com>wrote: > >> On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > (apologies for the duplicate reply; someone needs to sort out their >> > threading for the benefit of the community ;) ) >> > >> > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> >> > wrote: >> >> >> >> Hi, >> >> >> >> There are two changesets waiting for integrating in 1.4 that have >> serious >> >> consequences: >> >> >> >> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, >> >> but have not >> >> been integrated in the VMMaker codebase. >> >> >> >> http://code.google.com/p/pharo/issues/detail?id=4265 >> > >> > I would *really* like to back out these changes. The Ephemeron >> > implementation is very much a prototype, requiring a hack to determine >> > whether an object is an ephemeron (the presence of a marker class in >> the >> > first inst var) that I'm not at all happy with. There is a neater >> > implementation available via using an unused instSpec which IMO has >> > significant advantages (much simpler & faster, instSpec is valid at all >> > times, including during compaction, less overhead, doesn't require a >> marker >> > class), and is the route I'm taking with the new >> GC/object-representation >> > I'm working on now. Note that other than determining whether an object >> is >> > an ephemeron (instSpec/format vs inst var test) the rest of Igor's code >> > remains the same. I'd like to avoid too much VM forking. Would you all >> > consider putting these changes on hold for now? >> > If so, I'll make the effort to produce prototype changes (in the area of >> > ClassBuilder and class definition; no VM code necessary as yet) to allow >> > defining Ephemerons via the int spec route by next week at the latest. >> > >> >> i agree that in my implementation this is a weak point. But its hard >> to do anything without >> making changes to object format to identify these special objects. >> >> The main story behind this is can we afford to change the internals of >> VM without being beaten hard >> by "backwards compatibility" party? :) >> > > I don't think we get stuck in this at all. The instSpec/format field has > an unused value (5 i believe) and this can easily be used for Ephemerons. > All that is needed is a little image work on these methods: > > Behavior>>typeOfClass > needs to answer e.g. #ephemeron for ephemeron classes > > ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: > needs to accept e.g. #ephemeron for type and pass variable: false > and weak: true for ephemerons to format:variable:words:pointers:weak:. > > ClassBuilder>>format:variable:words:pointers:weak: > needs to respond to variable: false and weak: true by computing the > ephemeron instSpec. > > > Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > need siblings, e.g. > > ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category > > superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: > > Right? This is easy. Then in the VM there are a few places where pointer > indexability (formats 3 and 4) need to be firmed up to exclude 5, but > nothing difficult. We talked about this in email last week. > Here's the format field (Behavior>instSpec at the image level) as currently populated: 0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 6 = 32-bit indexable objects (Float, Bitmap ert al) 8 = 8-bit indexable objects (ByteString, ByteArray et al) 12 = CompiledMethod N.B. in the VM the least two bits of the format/instSpec for byte objects (formats 8 and 12) is used to encode the number of odd bytes in the object, so that a 1 character ByteString has a format of 11, = 8 + 3, size = 1 word - 3 bytes. For the future (i.e. the new GC/object representation, /not/ for the first implementation of ephemerons which we can do now, for Pharo 1.4 or 1.5) we need to extend format/instSpec to support 64 bits. I think format needs to be made a 5 bit field with room for 4 bits of odd bytes for 64-bit images. [For VMers, the Size4Bit is a horrible hack). So then 0 = 0 sized objects (UndefinedObject True False et al) 1 = non-indexable objects with inst vars (Point et al) 2 = indexable objects with no inst vars (Array et al) 3 = indexable objects with inst vars (MethodContext AdditionalMethodState et al) 4 = weak indexable objects with inst vars (WeakArray et al) 5 = weak non-indexable objects with inst vars (ephemerons) (Ephemeron) and we need 8 CompiledMethod values, 8 byte values, 4 16-bit values, 2 32-bit values and a 64-bit value, = 23 values, 23 + 5 = 30, so there is room, e.g. 9 (?) 64-bit indexable 10 - 11 32-bit indexable 12 - 15 16-bit indexable 16 - 23 byte indexable 24 - 31 compiled method In 32-bit images only the least significant 2 bits would be used for formats 16 & 24, and the least significant bit for format 12. > >> >> Ephemerons are versatile way to get notifications of objects which are >> about to die, >> and there are certain parts in language which is hard (or even >> impossible) to implement without ephemerons. >> >> I got stuck with it earlier, when realized that we cannot afford to >> have weak subscriptions in announcement framework >> for blocks (which is most convenient and most easy way to define >> subscriptions) without having ephemerons. >> And of course, by having ephemerons we can completely review the weak >> finalization scheme and make it >> much simpler, and faster. >> >> I think we should do something in this regard, even at cost of >> backward compatibility. >> Because as to me it blocks us from moving forward. >> >> I wanted to remind to people, that it took me around a day to >> implement ephemerons in VM. And then few more days >> to actually make a correct implementation and write tests to cover it. >> >> Unfortunately, we yet don't have a well established process, which >> could make VM + language side changes to go in sync, >> when its required, and go much faster and don't fear to >> introduce/change functionality. >> One of the reasons for having a continuous integration setup for VM >> was exactly for that: >> having new VMs every day (comparing to having new VMs every year). >> >> >> >> >> - Finalization code checks for #hasNewFinalization >> >> This is true in the current VMs build in Jenkins, but in older VMs >> this >> >> is not in. >> >> >> >> http://code.google.com/p/pharo/issues/detail?id=4483 >> >> >> >> There are two options: >> >> >> >> a) integrate in >> >> b) not integrate it >> >> >> >> a) means that the image runs on older VMs, too. >> >> b) means we accept that we can never improve anything for real. >> >> >> >> There will be more changes coming... e.g. imagine we have a Vector >> >> Graphics Canvas >> >> as some point next year... what will we do? use it or not use it to >> stay >> >> compatible? >> >> >> >> Marcus >> >> >> >> >> >> -- >> >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> > >> > >> > >> > -- >> > best, >> > Eliot >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> > > > -- > best, > Eliot > > -- best, Eliot

Sept. 22, 2011

[Pharo-project] Smallspaces - Tuple Space for Smalltalk

by Dave Mason

There is a reference on Wikipedia's page on Tuple Spaces to http://www.fongen.no/?docname=SmallSpaces/ but that is a dead link. I was interested in building tuple-space for Smalltalk, but this and a 1988 paper from Matsuoka and Kawai are the only things I turned up. If anyone knows more, please let me know. Also, I'd be interested to hear if people think this is a particularly good idea before I turn a grad student loose on it. Thanks ../Dave

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Eliot Miranda

On Thu, Sep 22, 2011 at 11:04 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Oh, yes. And i forgot to add, if you need any help which could make > VMs with ephemerons to appear sooner, > do not hesitate to ask. > I won't :) > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Eliot Miranda

Hi Igor, On Thu, Sep 22, 2011 at 10:53 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 22 September 2011 19:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > (apologies for the duplicate reply; someone needs to sort out their > > threading for the benefit of the community ;) ) > > > > On Thu, Sep 22, 2011 at 2:36 AM, Marcus Denker <marcus.denker(a)inria.fr> > > wrote: > >> > >> Hi, > >> > >> There are two changesets waiting for integrating in 1.4 that have > serious > >> consequences: > >> > >> - Ephemerons. The VM level changes are in the Cog VMs build on Jenkins, > >> but have not > >> been integrated in the VMMaker codebase. > >> > >> http://code.google.com/p/pharo/issues/detail?id=4265 > > > > I would *really* like to back out these changes. The Ephemeron > > implementation is very much a prototype, requiring a hack to determine > > whether an object is an ephemeron (the presence of a marker class in the > > first inst var) that I'm not at all happy with. There is a neater > > implementation available via using an unused instSpec which IMO has > > significant advantages (much simpler & faster, instSpec is valid at all > > times, including during compaction, less overhead, doesn't require a > marker > > class), and is the route I'm taking with the new GC/object-representation > > I'm working on now. Note that other than determining whether an object > is > > an ephemeron (instSpec/format vs inst var test) the rest of Igor's code > > remains the same. I'd like to avoid too much VM forking. Would you all > > consider putting these changes on hold for now? > > If so, I'll make the effort to produce prototype changes (in the area of > > ClassBuilder and class definition; no VM code necessary as yet) to allow > > defining Ephemerons via the int spec route by next week at the latest. > > > > i agree that in my implementation this is a weak point. But its hard > to do anything without > making changes to object format to identify these special objects. > > The main story behind this is can we afford to change the internals of > VM without being beaten hard > by "backwards compatibility" party? :) > I don't think we get stuck in this at all. The instSpec/format field has an unused value (5 i believe) and this can easily be used for Ephemerons. All that is needed is a little image work on these methods: Behavior>>typeOfClass needs to answer e.g. #ephemeron for ephemeron classes ClassBuilder>>computeFormat:instSize:forSuper:ccIndex: needs to accept e.g. #ephemeron for type and pass variable: false and weak: true for ephemerons to format:variable:words:pointers:weak:. ClassBuilder>>format:variable:words:pointers:weak: needs to respond to variable: false and weak: true by computing the ephemeron instSpec. Class>>weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: ClassBuilder>>superclass:weakSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: need siblings, e.g. ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category superclass:ephemeronSubclass:instanceVariableNames:classVariableNames:poolDictionaries:category: Right? This is easy. Then in the VM there are a few places where pointer indexability (formats 3 and 4) need to be firmed up to exclude 5, but nothing difficult. We talked about this in email last week. > > Ephemerons are versatile way to get notifications of objects which are > about to die, > and there are certain parts in language which is hard (or even > impossible) to implement without ephemerons. > > I got stuck with it earlier, when realized that we cannot afford to > have weak subscriptions in announcement framework > for blocks (which is most convenient and most easy way to define > subscriptions) without having ephemerons. > And of course, by having ephemerons we can completely review the weak > finalization scheme and make it > much simpler, and faster. > > I think we should do something in this regard, even at cost of > backward compatibility. > Because as to me it blocks us from moving forward. > > I wanted to remind to people, that it took me around a day to > implement ephemerons in VM. And then few more days > to actually make a correct implementation and write tests to cover it. > > Unfortunately, we yet don't have a well established process, which > could make VM + language side changes to go in sync, > when its required, and go much faster and don't fear to > introduce/change functionality. > One of the reasons for having a continuous integration setup for VM > was exactly for that: > having new VMs every day (comparing to having new VMs every year). > > >> > >> - Finalization code checks for #hasNewFinalization > >> This is true in the current VMs build in Jenkins, but in older VMs this > >> is not in. > >> > >> http://code.google.com/p/pharo/issues/detail?id=4483 > >> > >> There are two options: > >> > >> a) integrate in > >> b) not integrate it > >> > >> a) means that the image runs on older VMs, too. > >> b) means we accept that we can never improve anything for real. > >> > >> There will be more changes coming... e.g. imagine we have a Vector > >> Graphics Canvas > >> as some point next year... what will we do? use it or not use it to stay > >> compatible? > >> > >> Marcus > >> > >> > >> -- > >> Marcus Denker -- http://marcusdenker.de > >> > >> > > > > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Sept. 22, 2011

Re: [Pharo-project] Integrating Changes in 1.4 that require a new VM

by Igor Stasenko

Oh, yes. And i forgot to add, if you need any help which could make VMs with ephemerons to appear sooner, do not hesitate to ask. -- Best regards, Igor Stasenko.

Sept. 22, 2011

Re: [Pharo-project] [Vm-dev] jenkins cog - slow monticello on osx

by Tudor Girba

Hi, On 22 Sep 2011, at 19:59, Igor Stasenko wrote: > > On 22 September 2011 19:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> I looked a bit into the slowness of the OS X Jenkins Cog VM with Monticello. The problem exists and it is reproducible. >> >> I performed the following experiments using the following script: >> >> Time millisecondsToRun: >> [ 1 to: 100 do: [:x | >> | window | >> window := MCWorkingCopyBrowser new show. >> window delete ] ] >> >> I ran it on the same image using the following vms (on Mac OS X Lion): >> - Jenkins VM from 31.08.2011 >> - Cog VM r2489 >> >> I ran the scenario twice with two different setups: >> >> 1. I placed the image in an empty folder: >> >> Cog VM 2389: 4808 ms >> Jenkins VM: 7345 ms >> >> 2. I places the image in a folder that already had a large package-cache with 7400 mcz files: >> Cog VM: 4867 ms >> Jenkins VM: 50754 ms >> >> >> So: >> - even if there is no package cache, the Jenkins VM seems to perform 1.5 times slower >> - when there is a package-cache, it becomes hardly unusable. >> > Thanks, Tudor for sticking with it :) > > so, your measurements telling that its actually could be related more > to filesystem interaction(s) > rather than to network. This is what I understood as well. > we need to ask an experts (Esteban and John) , what are difference > between cocoa and carbon versions > in file handling, that may cause such big slowdown. > > > >> Cheers, >> Doru >> >> >> On 8 Sep 2011, at 12:10, Tudor Girba wrote: >> >>> Hi, >>> >>> I did not forget about this, but I did not have enough time yet. >>> >>> Cheers, >>> Doru >>> >>> >>> On 26 Aug 2011, at 14:40, Igor Stasenko wrote: >>> >>>> >>>> On 26 August 2011 13:30, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> Hi, >>>>> >>>>> Since a couple of weeks I am working with the Cog VM built on Jenkins: >>>>> https://ci.lille.inria.fr/pharo/view/Cog/job/Cog-Mac-Cocoa/ >>>>> >>>>> Here is a little feedback. It worked quite well, the only problem is that Monticello is really slow in the Moose image. This means that even opening the Monticello Browser takes several seconds. >>>>> >>>>> I thought that this might be induced by something in the Moose image, but if I try with the Elliot's VM (2489), it works blazingly fast. >>>>> >>>> >>>> Thanks for the information, Tudor. >>>> Apparently the difference between Eliot's VM and Cog-Mac-Cocoa that >>>> they are using different frameworks >>>> (Carbon vs Cocoa) >>>> and i don't know too much details about the difference there. >>>> John or Esteban may have better insights how to fix that. >>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "The coherence of a trip is given by the clearness of the goal." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>> >>> -- >>> www.tudorgirba.com >>> >>> "Yesterday is a fact. >>> Tomorrow is a possibility. >>> Today is a challenge." >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "Sometimes the best solution is not the best solution." >> >> > > > > -- > Best regards, > Igor Stasenko. -- www.tudorgirba.com "One cannot do more than one can do."

Sept. 22, 2011