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

[Pharo 7.0-dev] Build #345: 20777-Fix-instVarAt-instVarAt-put-comment

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

There is a new Pharo build available! The status of the build #345 was: FAILURE. The Pull Request #559 was integrated: "20777-Fix-instVarAt-instVarAt-put-comment" Pull request url: https://github.com/pharo-project/pharo/pull/559 Issue Url: https://pharo.fogbugz.com/f/cases/20777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 28, 2017

Iceberg "Create repository" buttons

by Ben Coman

In Iceberg I am finding the "Create repository" button disconcerting for some of the Iceberg repository dialogs. For example, clicking "Add local repository" shows a dialog "Import local repository into Iceberg" with a "Create repository" button and perception of this which I can't shake is "Whoa! I don't want to create a repository. It already exists!" Perhaps this is a narrow view, but for me a git repository exists properly on a remote or under the ".git" folder on the file system. Repositories don't exist inside the Image, only a single checked out working version. So "Create repository" feels like it can only operating on the file system. This is a left-brain/right-brain thing. Technically I can reason its the only button so pushing it can't be wrong, but it "feels" like pushing it will do the wrong thing. wdyt? cheers -ben

Nov. 28, 2017

[Pharo 7.0-dev] Build #344: 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 #344 was: SUCCESS. 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. 28, 2017

Re: [Pharo-dev] QA rule suggestion - assignment symbol slips

by Ben Coman

On 28 November 2017 at 16:25, Marcus Denker <marcus.denker(a)inria.fr> wrote: > as for catching message sends of the kind > > var = 1 + 2. > > (instead of :=), yes, we can add a rule for that. Cool. I added https://pharo.fogbugz.com/f/cases/20780 > >> On 28 Nov 2017, at 09:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> The "Temporaries read before writtenâ rule is implemented very in a way that you get >> *a lot* of false positives. >> >> e.g. it treats *any* block as potentially no exectuted, so any code like >> >> messageSelectorAndArgumentNames >> | t | >> self doSomething: [ t:=1 ]. >> ^t >> >> or >> >> messageSelectorAndArgumentNames >> | t | >> self init: t. >> ^t >> >> triggers the rule. There are many false positives. >> >> I sometimes wonder if this rule makes sense with this strict interpretation. >> >> It leads to bug tracker entries like this: >> >> https://pharo.fogbugz.com/f/cases/18943/PositionableStream-upTo-raised-temp… >> >> Marcus >> >> >>> On 28 Nov 2017, at 02:54, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> 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

Re: [Pharo-dev] clarifying pharo crashing issue(s)

by Nicolas Cellier

2017-11-27 9:20 GMT+01:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > There are recurrent reports that Pharo is crashing often. > > However, at the moment I believe the reasons are not clarified. So, this > mail is not about fixing the issues, but first about clarifying what they > are. > > Namely: > > - I know about the typing problem on MacOS (Sierra or High Sierra). I > encounter this problem daily (literally), and I know that I am not the only > one. For example, this can occur when I type âclasssâ fast and then delete > the last character. It is documented here: > https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 > > - Some people talk about the FreeType problem, but I could not find a > place where this is described. So, while this might be a problem, I am not > sure that this problem is actually causing crashes. > > Hi Tudor, I did not experience directly the FreeType related crash, but here is an analysis of what could potentially happen, a cairo_font_face still pointing on a FreeType FT_Face that has already been freed (dangling pointer...). https://pharo.fogbugz.com/f/cases/20776/Potential-dangling-ref-to-freed-FT_… I started to inquire this after an unrelated libgit crash and reported in the thread "[Pharo-dev] ExternalAddress uniqueness (was Re: Call for help for stability and rewrite of FreeType)" So, first question: > - is Pharo crashing on another system than MacOS Sierra or HighSierra? > - how does the FreeType problem look like? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "Beauty is where we see it." > > > > > >

Nov. 28, 2017

Re: [Pharo-dev] QA rule suggestion - assignment symbol slips

by Marcus Denker

> > or > > messageSelectorAndArgumentNames > | t | > self init: t. > ^t > This one is good to warnâ¦ but we have the âunitialized varâ rule for that already. Marcus

Nov. 28, 2017

Re: [Pharo-dev] QA rule suggestion - assignment symbol slips

by Marcus Denker

as for catching message sends of the kind var = 1 + 2. (instead of :=), yes, we can add a rule for that. > On 28 Nov 2017, at 09:20, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The "Temporaries read before writtenâ rule is implemented very in a way that you get > *a lot* of false positives. > > e.g. it treats *any* block as potentially no exectuted, so any code like > > messageSelectorAndArgumentNames > | t | > self doSomething: [ t:=1 ]. > ^t > > or > > messageSelectorAndArgumentNames > | t | > self init: t. > ^t > > triggers the rule. There are many false positives. > > I sometimes wonder if this rule makes sense with this strict interpretation. > > It leads to bug tracker entries like this: > > https://pharo.fogbugz.com/f/cases/18943/PositionableStream-upTo-raised-temp… > > Marcus > > >> On 28 Nov 2017, at 02:54, Ben Coman <btc(a)openinworld.com> wrote: >> >> 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

Re: [Pharo-dev] QA rule suggestion - assignment symbol slips

by Marcus Denker

Hi, The "Temporaries read before writtenâ rule is implemented very in a way that you get *a lot* of false positives. e.g. it treats *any* block as potentially no exectuted, so any code like messageSelectorAndArgumentNames | t | self doSomething: [ t:=1 ]. ^t or messageSelectorAndArgumentNames | t | self init: t. ^t triggers the rule. There are many false positives. I sometimes wonder if this rule makes sense with this strict interpretation. It leads to bug tracker entries like this: https://pharo.fogbugz.com/f/cases/18943/PositionableStream-upTo-raised-temp… Marcus > On 28 Nov 2017, at 02:54, Ben Coman <btc(a)openinworld.com> wrote: > > 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

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

by Ben Coman

On 27 November 2017 at 10:08, 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 > 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). Maybe you've discounted this already, but on the Image side you could rename it "TemplateBlah" then just use <Copy> to create new images from it. Updating "blahTemplate" is then already supported. cheers -ben

Nov. 28, 2017

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

by ClÃ©ment Bera

Hi, So you're advocating for solution 1: > > 1) We change the instVarAt: / instVarAt:put: primitives comments in Pharo > to match > the slotAt: / slotAt:put: primitives behavior I marked in bold the changes in the Pharo comment (so the comment now reflects the actual behavior): 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 variable *or indexed variable*. Essential. See Object documentation whatIsAPrimitive." <primitive: 173 error: ec> self primitiveFailed I'll make a patch later on. On Tue, Nov 28, 2017 at 2:55 AM, David T. Lewis <lewis(a)mail.msen.com> wrote: > 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 > > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 28, 2017