November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Would it be possible to also launch templates in PharoLauncher?

by Mariano Martinez Peck

On Sun, Nov 26, 2017 at 11:08 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi guys, > > Thank you Christophe for continue pushing this useful tool! > > One small request which might be easy to do... Quite frequently I want to > do something and re-save an image I have previosuly saved as a custom > template (under Local root tree). Right now what I have to do so: > > 1) Make a new image from that template > 2) remove template > Weird....I was needing to do this yet another time but now I cannot even find a way to remove a template (I was sure I could the other day...) > 2) do the thing and save the opened image. > 3) go back to laucher and save that image as a new template (with the same > name of the one I deleted) > 4) delete the created image > > All that would be simplified if I could also launch my local templates. Is > there any reason why is that not allowed? (at least for Local tree). > > Thanks in advance, > > > -- > Mariano > http://marianopeck.wordpress.com > -- Mariano http://marianopeck.wordpress.com

Nov. 28, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by David T. Lewis

On Mon, Nov 27, 2017 at 12:11:13PM -0800, Eliot Miranda wrote: > Hi Cl??ment, > > On Wed, Nov 22, 2017 at 5:35 AM, Cl??ment Bera <bera.clement(a)gmail.com> > wrote: > > > Hi All, > > > > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the > > instVarAt: / instVarAt:put: primitive is not doing what it says it does. > > When I look at Object>>#instVarAt: I see: > > > > "[...]Answer a fixed variable in an object. The numbering of the variables > > corresponds to the named instance variables, followed by the indexed > > instance > > variables. Fail if the index is not an Integer or is not the index of a > > fixed variable[...]" > > > > Now in Pharo 7 when one does: > > > > #(iv1) instVarAt: 1, one gets #iv1. > > > > But the failure code should indeed answer #iv1. > > > > So the comment is wrong. > > > > The reason for this is that instVarAt: / instVarAt:put: should be > > primitive 73/74, while they are in Pharo 173/174 (primitive > > slotAt:/slotAt:put:). > > > > Why do you say "should"? The 173/174 primitives work well and avoid > unnecessary primitive failures (which is why they're there). > > > > The slot primitive access pointer slots of objects, whichever inst var or > > variable fields. A good example would be: > > > > | t | > > t := #temp. > > [ t ] instVarAt: 4, one gets #temp > > > > So I have two solutions for this problem: > > 1) We change the instVarAt: / instVarAt:put: primitives comments to match > > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / > > instVarAt:put: means in factslotAt: / slotAt:put: . > > > > This is the performant solution, because... > > > > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 > > and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we > > ask everyone to fix their code relying on instVarAt: / instVarAt:put: > > acting as slotAt: / slotAt:put: > > > > Early in Squeak Spur testing Chris Muller noticed a slow down in his code > He was accessing an Array using instVarAt:, which was failing because he > was using it to access an indexed field in an Array. Now in Spur the VM > must scan the object graph of a primitive's receiver and arguments to some > depth on primitive failure to follow forwarders. Because a) at that time > the VM computed a depth > 0 for instVarAt:[put:] it scanned the whole array > on each access, and b) the Array was large, this meant that the failures > were very expensive. So I added the slot primitives, since the old 73/74 > primitive pair were only used in the instVarAt:[put:] methods that accessed > indexable slots on failure. So the new 173/174 pair subsumed the 73/74 > pair. > > I eventually added an accessorDepth: pragma rot specify the accessor depth > manually when the automatically computed depth is too deep. It is for > at:[put:] because the String version of the at: 60 primitive appears to > access the innards of non-immediate Characters (it doesn't do this in Spur, > but the depth inferencer isn't clever enough to notice). So primitiveAt > looks like: > > primitiveAt > <accessorDepth: 0> > self commonAt: false > > So we could go back to using 73/74 for instVarAt:[put:] provided that their > accessorDepth ends up being 0, which likely means they will require the > pragma. But I think the simplest thing is to keep using 173/174. Here's > the Squeak code: > > Object>>instVarAt: index > "Primitive. Answer a fixed variable in an object. The numbering of the > variables > corresponds to the named instance variables, followed by the indexed > instance > variables. Fail if the index is not an Integer or is not the index of a > fixed or > indexed variable. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 173 error: ec> > self primitiveFailed > > Object>>instVarAt: index put: anObject > "Primitive. Store a value into a fixed variable in an object. The numbering > of the > variables corresponds to the named instance variables, followed by the > indexed > instance variables. Fail if the index is not an Integer or is not the index > of a fixed > or indexed variable. Essential. See Object documentation whatIsAPrimitive." > > <primitive: 174 error: ec> > self primitiveFailed > > I've attached these methods. > > > What do you think ? > > > > I think for Spur it makes sense to use 173/174. > +1 The 73/74 primitives (primitiveInstVarAt and primitiveInstVarAtPut) are semantically different from the 173/174 primitives (primitiveSlotAt and primitiveSlotAtPut). The 173/174 primitives are preferred for Spur images, and the 73/74 primitives are used for V3 images. The VM can support both, and the image should call the primitive that it needs or wants to use. In any case, the primitive table numbering should not be confused between them. Squeak has the correct implementation for calling the primitives from a Spur image. See Cuis has an implementation of the image calling the appropriate primitive for whatever image format it happens to be using. Dave

Nov. 28, 2017

QA rule suggestion - assignment symbol slips

by Ben Coman

A quick suggestion for anyone working on QA rules... Just now I am playing with FFI a bit and switching back a forth from Pharo to C and sometimes I end up doing... location = Libclang clang_getRangeStart__range: range. thus QA reported a. "Temporaries read before written" and b. "Temporary variables not read or not written" but these weren't helpful since I was stuck staring at it saying to myself "Well range is assigned before its used, and location is assigned, so bah! the rules seem broken" and for about 30 seconds I remained blind to the truth I'd left the colon off the assignment operator. I'd expect newcomers from other languages might slip in the same way, so a higher priority rule extending [b.] that identifies such variable followed by equal-sign would provide pertinent feedback. cheers -ben

Nov. 28, 2017

[Pharo 7.0-dev] Build #343: 20772 - Unused temps in MBConfigurationInfo, MethodDictionaryTest, ...

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #343 was: FAILURE. The Pull Request #557 was integrated: "20772 - Unused temps in MBConfigurationInfo, MethodDictionaryTest,..." Pull request url: https://github.com/pharo-project/pharo/pull/557 Issue Url: https://pharo.fogbugz.com/f/cases/20772 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by Reg Krock

Marcus, I agree with keeping it as Slot. The existing literature (non-Smalltalk) uses Slot in a fairly consistent manner so what would the advantage be of changing it? Reg Sent from my iPhone > On Nov 24, 2017, at 4:44 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > In the VM primitiveSlotAt: / at:Put: mean access to any field (pointer or non pointer, sorry for the confusion Marcus earlier on) of an object. The primitive in the image can be named fieldAt:/fieldAt:put: if it makes more sense for Pharo. > > #[0] slotAt: 1 => 0 > #(#a) slotAt: 1 => #a > 0@2 slotAt: 1 => 0 > With Pharo 6 blocks: > | t | t := #tmp. {[ t ] slotAt: 3 . [ t ] slotAt: 4} => { 0 "numArgs". #tmp } > > Right now you can do that with instVarAt: on the contrary to what instVarAt: comment states, and this is wrong. > >> On Fri, Nov 24, 2017 at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 24 Nov 2017, at 00:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> >>> >>> On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> Did you talk with marcus? >>> >>> I don't understand the connection between slots and this problem with primitives. >>>> >> >> There is no connection, just the same name. >> >> For Slots aka First Class Instance variables: >> >> I sometimes think that Slot for the first class instance variables might not be a good name, but then, >> the only alternative would be âinstance variableâ, but that is not that nice either, as these Slots include >> virtual variables (that are computed) or variables that are combine stored in a hidden base slot (e.g. >> used for BooleanSlot or PropertySlot). >> >> So for now I will keep the Slot termâ¦ >> >> >> Marcus > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 27, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in Metacello classes

by Torsten Bergmann

Yes - I submitted a PR to Metacello too: https://github.com/Metacello/metacello/pull/473 Who is able to merge it there? > Gesendet: Montag, 27. November 2017 um 09:16 Uhr > Von: "Marcus Denker" <marcus.denker(a)inria.fr> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [Pharo 7.0-dev] Build #332: 20759 Unused temps in Metacello classes > > This fix has been submitted upstream, too. > > > On 27 Nov 2017, at 09:09, ci-pharo-ci-jenkins2(a)inria.fr wrote: > > > > There is a new Pharo build available! > > > > The status of the build #332 was: SUCCESS. > > > > The Pull Request #546 was integrated: "20759 Unused temps in Metacello classes" > > Pull request url: https://github.com/pharo-project/pharo/pull/546 > > > > Issue Url: https://pharo.fogbugz.com/f/cases/20759 > > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > >

Nov. 27, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by Eliot Miranda

Hi ClÃ©ment, On Wed, Nov 22, 2017 at 5:35 AM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi All, > > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the > instVarAt: / instVarAt:put: primitive is not doing what it says it does. > When I look at Object>>#instVarAt: I see: > > "[...]Answer a fixed variable in an object. The numbering of the variables > corresponds to the named instance variables, followed by the indexed > instance > variables. Fail if the index is not an Integer or is not the index of a > fixed variable[...]" > > Now in Pharo 7 when one does: > > #(iv1) instVarAt: 1, one gets #iv1. > But the failure code should indeed answer #iv1. > So the comment is wrong. > > The reason for this is that instVarAt: / instVarAt:put: should be > primitive 73/74, while they are in Pharo 173/174 (primitive > slotAt:/slotAt:put:). > Why do you say "should"? The 173/174 primitives work well and avoid unnecessary primitive failures (which is why they're there). > The slot primitive access pointer slots of objects, whichever inst var or > variable fields. A good example would be: > > | t | > t := #temp. > [ t ] instVarAt: 4, one gets #temp > > So I have two solutions for this problem: > 1) We change the instVarAt: / instVarAt:put: primitives comments to match > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / > instVarAt:put: means in factslotAt: / slotAt:put: . > This is the performant solution, because... > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 > and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we > ask everyone to fix their code relying on instVarAt: / instVarAt:put: > acting as slotAt: / slotAt:put: > Early in Squeak Spur testing Chris Muller noticed a slow down in his code He was accessing an Array using instVarAt:, which was failing because he was using it to access an indexed field in an Array. Now in Spur the VM must scan the object graph of a primitive's receiver and arguments to some depth on primitive failure to follow forwarders. Because a) at that time the VM computed a depth > 0 for instVarAt:[put:] it scanned the whole array on each access, and b) the Array was large, this meant that the failures were very expensive. So I added the slot primitives, since the old 73/74 primitive pair were only used in the instVarAt:[put:] methods that accessed indexable slots on failure. So the new 173/174 pair subsumed the 73/74 pair. I eventually added an accessorDepth: pragma rot specify the accessor depth manually when the automatically computed depth is too deep. It is for at:[put:] because the String version of the at: 60 primitive appears to access the innards of non-immediate Characters (it doesn't do this in Spur, but the depth inferencer isn't clever enough to notice). So primitiveAt looks like: primitiveAt <accessorDepth: 0> self commonAt: false So we could go back to using 73/74 for instVarAt:[put:] provided that their accessorDepth ends up being 0, which likely means they will require the pragma. But I think the simplest thing is to keep using 173/174. Here's the Squeak code: Object>>instVarAt: index "Primitive. Answer a fixed variable in an object. The numbering of the variables corresponds to the named instance variables, followed by the indexed instance variables. Fail if the index is not an Integer or is not the index of a fixed or indexed variable. Essential. See Object documentation whatIsAPrimitive." <primitive: 173 error: ec> self primitiveFailed Object>>instVarAt: index put: anObject "Primitive. Store a value into a fixed variable in an object. The numbering of the variables corresponds to the named instance variables, followed by the indexed instance variables. Fail if the index is not an Integer or is not the index of a fixed or indexed variable. Essential. See Object documentation whatIsAPrimitive." <primitive: 174 error: ec> self primitiveFailed I've attached these methods. What do you think ? > I think for Spur it makes sense to use 173/174. > > Best, > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > -- _,,,^..^,,,_ best, Eliot

Nov. 27, 2017

[Pharo 7.0-dev] Build #342: 20745-cleanup-unused-methods-OCOptimizedBlockScope

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #342 was: SUCCESS. The Pull Request #556 was integrated: "20745-cleanup-unused-methods-OCOptimizedBlockScope" Pull request url: https://github.com/pharo-project/pharo/pull/556 Issue Url: https://pharo.fogbugz.com/f/cases/20745 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2017

[Pharo 7.0-dev] Build #341: 20700-translateToUTC-does-not-work-on-Month-and-Year

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #341 was: SUCCESS. The Pull Request #545 was integrated: "20700-translateToUTC-does-not-work-on-Month-and-Year" Pull request url: https://github.com/pharo-project/pharo/pull/545 Issue Url: https://pharo.fogbugz.com/f/cases/20700 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2017

[Pharo 7.0-dev] Build #340: 20770-Open-WelcomeHelp-window-at-startup

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #340 was: SUCCESS. The Pull Request #555 was integrated: "20770-Open-WelcomeHelp-window-at-startup" Pull request url: https://github.com/pharo-project/pharo/pull/555 Issue Url: https://pharo.fogbugz.com/f/cases/20770 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 27, 2017