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

Special case of pool access lookup crash

by Yuriy Tymchuk

Hi everyone, when you go to AJx86Registers class, press âShow class variablesâ and select âIPâ, then it crashes with: 'RIP register IP cannot be used only for relative addressingâ. I couldnât find related bug report, should I open one? Uko

Sept. 3, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by stepharo

> Like Thierry I'm not sure that omitting the check brings a > significant speedup. > However, not doing this check follows the robustness principle: > "Be conservative in what you do, be liberal in what you accept > from others". > > > But it violates the "if it ain't broke don't fix it", "it means what > it means", and "Smalltalk is a safe language" principles. That safety > check finds bugs. If one wants a more relaxed contract, implement a > new contract, don't break an existing contract that has stood for years. > > I would even be more liberal with a: > 1 to: (self size min: otherCollection size) do: .... > :) > > > But you can write that if that's what you mean. But arbitrarily > changing existing protocol for weak reasons when _it ain't broke_ is a > recipe for chaos. > + 1 Stef

Sept. 3, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by stepharo

Marcus the contract is important and should be explicit because if you do not check the same size then you may have part of the computation done and not the rest. So I would introduce new methods with explicit names telling that fuzzyWith:do: or soemthing like that. On 3/9/14 14:40, Marcus Denker wrote: > with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). > > with: otherCollection do: twoArgBlock > "Evaluate twoArgBlock with corresponding elements from this collection and otherCollection." > otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. > 1 to: self size do: > [:index | > twoArgBlock value: (self at: index) > value: (otherCollection at: index)] > > I think we should not do that: > > 1) it is slow > 2) when the other is larger, is would work and just omit the rest > 3) if it is smaller, you will get an error anyway > > There are just three methods doing such a size check: > > with:do: > with:collect: > reverseWith:do: > (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) > > Is there a reason why this makes sense? > > I added an issue with a slice to clean it up: > > https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… > > Marcus > > > > > >

Sept. 3, 2014

Re: [Pharo-dev] Why doesn't the OSX vm show the name of the running image?

by Ben Coman

Tim Mackinnon wrote: > Iâm wondering if there is a particular reason why the VM on OSX, just shows the name of the .app file and not the running image? > > Iâve downloaded the recent 3.0 vm, and used it to launch two images (I set it as the default app and double clicked on 2 different images) - and when you do a CMD-Tab, its a bit confusing because all you see are two apps that say âPharo 3.0â - so its hard to distinguish between them. It may be an OSX limitation - but I thought it was worth asking. > > I can create a fogbugz if anyone thinks its worthy. > > Tim > > It would be nice for those icons to show the image name, but all the other applications I have open also don't show the names of their open documents/content. ???

Sept. 3, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by ClÃ©ment Bera

This check is not in a loop so I don't think it is performance critical... I don't know if this change is great. 2014-09-03 16:54 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > > 2014-09-03 14:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > with:do: on SequencableCollection checks that both collections have the >> same size (it raises an Error if not). >> >> with: otherCollection do: twoArgBlock >> "Evaluate twoArgBlock with corresponding elements from this >> collection and otherCollection." >> otherCollection size = self size ifFalse: [self error: >> 'otherCollection must be the same size']. >> 1 to: self size do: >> [:index | >> twoArgBlock value: (self at: index) >> value: (otherCollection at: index)] >> >> I think we should not do that: >> >> 1) it is slow >> > > Are you sure about that one? The check is a constant cost disregarding the > collection length, and, anyway, self size is reused just after that. > > >> 2) when the other is larger, is would work and just omit the rest > > 3) if it is smaller, you will get an error anyway >> > > I have a feeling I'm not in Pharo anymore, but in R instead ;) > > Thierry > > >> >> There are just three methods doing such a size check: >> >> with:do: >> with:collect: >> reverseWith:do: >> (the last one actually raises a SizeMismatch exception, it is the >> sole user of that exception) >> >> Is there a reason why this makes sense? >> >> I added an issue with a slice to clean it up: >> >> >> https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… >> >> Marcus >> >> >> >> >> >> >

Sept. 3, 2014

Why doesn't the OSX vm show the name of the running image?

by Tim Mackinnon

Iâm wondering if there is a particular reason why the VM on OSX, just shows the name of the .app file and not the running image? Iâve downloaded the recent 3.0 vm, and used it to launch two images (I set it as the default app and double clicked on 2 different images) - and when you do a CMD-Tab, its a bit confusing because all you see are two apps that say âPharo 3.0â - so its hard to distinguish between them. It may be an OSX limitation - but I thought it was worth asking. I can create a fogbugz if anyone thinks its worthy. Tim

Sept. 3, 2014

Re: [Pharo-dev] How to see a Pharo job configuration - getting null pointer error?

by Tim Mackinnon

Believe me, I understand the PIA part of CI ;) You are right about the account though. I do have an account - so I tried logging in to ci.inria.fr - and I get a dashboard to navigate down to Pharo-contributions, but clicking the jenkins button for that project gives me the https://ci.inria.fr/pharo-contribution/? link Iâve been used to. I wonder if something is misconfigured (or maybe we just arenât allowed to see how a job is configured?). I wanted to know, because the images that PharoLauncher produces for end users seem different from the ones spit out of the normal jenkins CI. So I think there must be some script run at the very end, which I wanted to understand. Tim On 3 Sep 2014, at 16:33, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I think you need an account to see the real config ... > > Please understand that we are all just users here, maintain/explaining jenkins/hudson is a PIA for all of us ;-) > > On 03 Sep 2014, at 17:26, Tim Mackinnon <tim(a)testit.works> wrote: > >> Hi guys - I am trying to understand how some of the CI jobs work (in particular pharo launcher) - however when I click on the âRead Only Job Configuarionâ link I just get an error screen with : >> java.lang.NullPointerException at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) >> >> Further down the stack it mentions acegisecurity - so Iâm assuming it might be related to some credential thing - but are we not allowed to see what scripts are run to create final images, or is something just misconfigured? >> >> Tim > >

Sept. 3, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by Eliot Miranda

On Wed, Sep 3, 2014 at 8:37 AM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 3 sept. 2014, at 17:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com > > wrote: > >> >> >> >> 2014-09-03 14:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> with:do: on SequencableCollection checks that both collections have the >>> same size (it raises an Error if not). >>> >>> with: otherCollection do: twoArgBlock >>> "Evaluate twoArgBlock with corresponding elements from this >>> collection and otherCollection." >>> otherCollection size = self size ifFalse: [self error: >>> 'otherCollection must be the same size']. >>> 1 to: self size do: >>> [:index | >>> twoArgBlock value: (self at: index) >>> value: (otherCollection at: index)] >>> >>> I think we should not do that: >>> >>> 1) it is slow >>> >> >> Are you sure about that one? The check is a constant cost disregarding >> the collection length, and, anyway, self size is reused just after that. >> >> >>> 2) when the other is larger, is would work and just omit the rest >> >> 3) if it is smaller, you will get an error anyway >>> >> >> I have a feeling I'm not in Pharo anymore, but in R instead ;) >> > > +2. There are clear safety advantages in the check. If you want the > "faster" protocol why not define withSomeOf:do: or some such? > > > Like Thierry I'm not sure that omitting the check brings a significant > speedup. > However, not doing this check follows the robustness principle: "Be > conservative in what you do, be liberal in what you accept from others". > But it violates the "if it ain't broke don't fix it", "it means what it means", and "Smalltalk is a safe language" principles. That safety check finds bugs. If one wants a more relaxed contract, implement a new contract, don't break an existing contract that has stood for years. > I would even be more liberal with a: > 1 to: (self size min: otherCollection size) do: .... > :) > But you can write that if that's what you mean. But arbitrarily changing existing protocol for weak reasons when _it ain't broke_ is a recipe for chaos. Thierry >> >> >>> >>> There are just three methods doing such a size check: >>> >>> with:do: >>> with:collect: >>> reverseWith:do: >>> (the last one actually raises a SizeMismatch exception, it is >>> the sole user of that exception) >>> >>> Is there a reason why this makes sense? >>> >>> I added an issue with a slice to clean it up: >>> >>> >>> https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… >>> >>> Marcus >>> >>> >>> >>> >>> >>> >> > > > -- > best, > Eliot > > > -- best, Eliot

Sept. 3, 2014

Re: [Pharo-dev] Undeclared dictionary

by Yuriy Tymchuk

On 03 Sep 2014, at 17:29, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Uko, > > > On Wed, Sep 3, 2014 at 8:16 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > one more question. How can you find out if method references a thing like that? > > Because if you do: #refersToLiteral: and pass a key from Undeclared you may also match a symbol which is completely ok. Is there a way to check only for variables? > > You check for the binding. e.g. self systemNavigation allCallsOn: (Undeclared bindingOf: #Foo) > > Are you sure refersToLiteral: answers true for a method that directly refers to a binding but not directly to its key? This sounds like a bug to me. Hi My bad. I didnât know that literal in this case is a full binding i.e. association. Thank you. Now Iâve got a bit smarter. Uko > > > Uko > > > On 03 Sep 2014, at 13:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> >> >> On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> Hi, can someone explain me how Undeclared dictionary works? >> >> >> So imagine you want to load code where a variable is not defined (e.g. due to loading old code, >> or because it references a variable that will only be loaded in a second step). >> >> In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), >> it just loads the wrong code and for every undeclared variable, it adds an entry in the >> Undeclared dictionary. >> (the bytecode to read and write is the same as used for Globals and Class variables: >> pushLiteralVariable, which means "push the value of the association", the store bytecode >> for assignment therefore is "store in the value of that association". >> >> So if you actually run code that has Undeclared, it will work: it will be nil by default, >> but when you assign it will store into the Undeclared dictionary. >> >> When you add a new Global to the SystemDictionary, it will check Undeclared and >> move the value over. Same for Class vars. >> (this means that loading a class will automatically fix all Undeclared references to it) >> >> >> Because as I look at it, all the values are nil. Is it possible for them to be not nil? >> >> yes. >> >> Maybe we should have a âglobal variable commentsâ for this situations :) >> >> >> Ideed. >> >> -- >> Marcus Denker -- denker(a)acm.org >> http://www.marcusdenker.de > > > > > -- > best, > Eliot

Sept. 3, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by Camille Teruel

On 3 sept. 2014, at 17:26, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > > 2014-09-03 14:40 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > > with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). > > with: otherCollection do: twoArgBlock > "Evaluate twoArgBlock with corresponding elements from this collection and otherCollection." > otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. > 1 to: self size do: > [:index | > twoArgBlock value: (self at: index) > value: (otherCollection at: index)] > > I think we should not do that: > > 1) it is slow > > Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. > > 2) when the other is larger, is would work and just omit the rest > 3) if it is smaller, you will get an error anyway > > I have a feeling I'm not in Pharo anymore, but in R instead ;) > > +2. There are clear safety advantages in the check. If you want the "faster" protocol why not define withSomeOf:do: or some such? Like Thierry I'm not sure that omitting the check brings a significant speedup. However, not doing this check follows the robustness principle: "Be conservative in what you do, be liberal in what you accept from others". I would even be more liberal with a: 1 to: (self size min: otherCollection size) do: .... :) > > Thierry > > > There are just three methods doing such a size check: > > with:do: > with:collect: > reverseWith:do: > (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) > > Is there a reason why this makes sense? > > I added an issue with a slice to clean it up: > > https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… > > Marcus > > > > > > > > > > -- > best, > Eliot

Sept. 3, 2014