- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Who are the experts?

by stepharo

Le 27/1/15 13:21, Roberto Minelli a Ã©crit : > ### NautilusRefactoring > - How does it work? Why there are different methods to remove a class, for example? e.g., NautilusRefactoring>>#removeClasses: vs. AbstractTool>>#removeClasses: I looked at it and clean it a bit. Now AbstractTool is common to all the tools. NautilusRefactoring introduces refactoring at the level of nautilus hence redefines the methods. > - Why #removeClasses: is triggered before the actual removal (i.e., confirmation dialogue)? where? because this is not what I see. I renamed private... by classRemoval..... removeClasses: aCollection "Execute the refactoring of the receiver." | refactoring | refactoring := self classRemovalRefactoringObjectFor: aCollection. refactoring model environment: self model browsedEnvironment. self performRefactoring: refactoring. ^ true

Jan. 31, 2015

Re: [Pharo-dev] Who are the experts?

by Sven Van Caekenberghe

It would be really good to pick a date, that way we can make this into a little celebration each year ! > On 31 Jan 2015, at 18:15, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 31 Jan 2015, at 18:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >>> On 31 Jan 2015, at 17:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :) > > This date makes a good birthday. Because without Moose there would have not been the same pressure and commitmentâ¦ it changed the game > to another level. > > If Moose would be today on VW, a lot of things would be differentâ¦ > > Marcus > >

Jan. 31, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Ben Coman

On Sat, Jan 31, 2015 at 11:50 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Ben Coman wrote > > This is all in SLICE-Issue-12970-16-steps-to-get-through-halt-BenComan.4. > > Great, I'll take another look. Did you consider Elliot's suggestion? > > > Sorry I didn't. At first glance I didn't fathom the "inlining" concept and I already had a sniff that this other solution having potential to solve all woes, so I didn't stop to dig into it. Reviewing it again now, I understand the "inlining", but trying it as given (in a fresh image) fails to bring up a debugger at all, for the following... a := 1. Halt enableHaltOnce. self haltOnce. b := 2. I think the following gives the same intent... haltOnce "Halt unless we have already done it once." Halt isHaltOnceEnabled ifTrue: [Halt disableHaltOnce. Halt signal] but the debugger opens on the "Halt signal". This is due to Halt>>signalerContext's special handling ONLY of #halt, which is the essence of the different behaviour between #halt and #haltOnce. Changing "Halt signal" to "self halt" has no effect, with the debugger opening on the same line. As well, I think it would only solve the behaviour for the initial opening of the debugger, but not subsequent encounters of a halt while stepping - which was the problem I was attacking. Indeed, solving that #haltOnce problem was an afterthought - the one line change from the .2 slice to the .3 slice Now for your critical review, in particular consider the pragma name "<debuggerCompleteToSender>". I'm not sure its the best. Also, did I miss tagging any halt-like methods ? cheers -ben

Jan. 31, 2015

Re: [Pharo-dev] Who are the experts?

by Marcus Denker

> On 31 Jan 2015, at 18:11, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 31 Jan 2015, at 17:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :) This date makes a good birthday. Because without Moose there would have not been the same pressure and commitmentâ¦ it changed the game to another level. If Moose would be today on VW, a lot of things would be differentâ¦ Marcus

Jan. 31, 2015

Re: [Pharo-dev] Who are the experts?

by Marcus Denker

> On 31 Jan 2015, at 17:36, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :) > Yes, I defended my thesis end of May, finished writing 1st Aprilâ¦ The first project of what became 2Denker we did in June (holidays well spend ;-), after postdoc in Bern with a stay in Brussels in the fall. The 2Denker company was founded Jan 2009, Pharo1.0 was released shortly after, I left Switzerland, stayed in Germany a month, then I was in Chile until something like November, official start at Inria mid December. Marcus

Jan. 31, 2015

Re: [Pharo-dev] Who are the experts?

by Tudor Girba

We started to move Moose from VW to Pharo on April 24, 2008 (right after a decisive meeting with Cincom). This was a very early Pharo (pre 1.0) that was hardly distinguishable from Squeak :) Cheers, Doru On Sat, Jan 31, 2015 at 3:08 PM, stepharo <stepharo(a)free.fr> wrote: > ;) > you remember better than me. > > Stef > > > * Related to the Pharo-users thread about when Pharo was publicly > announced, timestamp in 1.0 shows that change committed 25/2/2009. I > remember first hearing about Pharo from Steph announcing a new dialect at > an ESUG, which means even though it's not an official post of the program > of ESUG Amsterdam 2008, at least by the end of that, it was public. > > > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 31, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Sean P. DeNigris

Ben Coman wrote > This is all in SLICE-Issue-12970-16-steps-to-get-through-halt-BenComan.4. Great, I'll take another look. Did you consider Elliot's suggestion? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-12970-16-steps-to-get-through-halt-PROPOSED-FIX… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 31, 2015

Re: [Pharo-dev] Issue 12970 - 16 steps to get through #halt - PROPOSED FIX

by Ben Coman

On Sat, Jan 31, 2015 at 8:44 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Jan 30, 2015 at 2:54 PM, Sean P. DeNigris <sean(a)clipperadams.com> > wrote: > >> Ben Coman wrote >> > @Sean, In what way will it make halts more annoying? >> >> Clearly seems to make things better in your use case, but IIRC the purpose >> of that test is that you don't want to open the debugger within the >> halting >> system. And indeed, when you remove it, you end up in #halt. But where you >> want to be is in UndefinedObject>>DoIt. So, it seems like a hack that, >> while >> better in this case, may have implications in other cases. The solution >> we're looking for is: "debuggers-opened-due-to-halts always open on the >> first context totally outside the halt machinery" and we're not quite >> there >> yet. >> > Okay I agree. So I threw away that solution you commented on and came at it another way. In summary... * The following four statements now all operate identically * self halt. * self haltOnce. * Halt now. * Halt once. * The first time the debugger opens - the halt statement is highlighted in the method that contains it. (In addition, the several other conditional and counting halt methods in the Halt class protocol 'halting' and Object protocol '*Kernel-Exceptions-debugging' "should" also work identically - but I haven't tested them pending confirmation I'm on the right track) * Upon <Restart>, all the above statements are properly ignored by <Step Over> Consider the following now opens a debugger on line 2 and gets to line 5 in just three <Step Over>s. a := 1. self halt. b := 2. self halt. c := 3. > > Nobody responded to my suggestion of inlining the code for haltOnce so > that the Halt signal happens in haltOnce itself, just as it does inside > halt. This may make the system respond to haltOnce the same as it does to > halt. i.e. the debugger can look to the sender of the signalling context. > As it is now, the sender of the signalling context of a haltOnce is halt, > not the sender of haltOnce as desired. > > > Let me reiterate, I expect > > haltOnce > "Halt unless we have already done it once." > (Smalltalk at: #HaltOnce ifAbsent: [false]) ifTrue: > [Smalltalk at: #HaltOnce put: false. > Halt signal] > > will behave similarly to > > halt > Halt signal > > > I believe I have been successful in this. The following now opens a debugger on line 3 instead of inside the #haltOnce.... a := 1. Halt enableHaltOnce. self haltOnce. b := 2. This is all in SLICE-Issue-12970-16-steps-to-get-through-halt-BenComan.4. Now maybe its not the best implementation, but I believe it satisfies all functional requirements and please can it be reviewed for integration asap. For me this adds that much more joy to using our great debugger. cheers -ben

Jan. 31, 2015

Re: [Pharo-dev] Who are the experts?

by stepharo

;) you remember better than me. Stef * Related to the Pharo-users thread about when Pharo was publicly announced, timestamp in 1.0 shows that change committed 25/2/2009. I remember first hearing about Pharo from Steph announcing a new dialect at an ESUG, which means even though it's not an official post of the program of ESUG Amsterdam 2008, at least by the end of that, it was public.

Jan. 31, 2015

Re: [Pharo-dev] Fwd: 14827 ProtoObject>>pointersTo failing circular references

by stepharo

So you found a bug :) Le 30/1/15 15:32, Ben Coman a Ã©crit : > Yes. I just got back to looking at it and noticed the culprit was > printString. Now #printString --> #printStringLimitedTo: --> > #streamContents:limitedTo: which uses LimitedWriteStream that should > protect against such recursion. > > However Array>>printOn: is... > > self shouldBePrintedAsLiteral ifTrue: [self printAsLiteralFormOn: > aStream. ^ self]. > self isSelfEvaluating ifTrue: [self printAsSelfEvaluatingFormOn: > aStream. ^ self]. > super printOn: aStream > > where #shouldBePrintedAsLiteral and #isSelfEvaluating recursively > call themselves - bypassing the protection of LimitedWriteStream. > > As an aside, Array>>shouldBePrintedAsLiteral seems identical to > Array>>isLiteral -- so is it redundant and the former be deprecated? > > Now I don't quite follow the semantics of #isLiteral and > #isSelfEvaluating for Arrays. > > a := #( 1 2 { 3 . 4 } 5). > a isLiteral. "true" > a isSelfEvaluating. "true" > > b := { 1 . 2 . #( 3 4 ) . 5 }. > b isLiteral. "true" > b isSelfEvaluating. "true" > > So can someone provide an example for an Array where #isLiteral or > #isSelfEvaluating are false ? Otherwise it seems it will always > take the first condition of Array>>printOn: . > > cheers -ben > > On Fri, Jan 30, 2015 at 9:23 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > Quick and Dirty, > replace Array>>#printOn: > with > > printOn: aStream > self class = Array ifTrue: [self printAsSelfEvaluatingFormOn: > aStream. ^ self]. > super printOn: aStream > > testObject := 'TEST'. > ref1 := { testObject. nil }. > ref2 := { ref1 }. > ref3 := { ref2 }. > ref1 at: 2 put: ref3. "note the reference loop this creates" > testObject pointersTo asString > > works > > > 2015-01-30 14:15 GMT+01:00 Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>>: > > Hi Ben, > > i don't know exactly what is happening here, but (size vs. > inpsect) > > testObject := 'TEST'. > ref1 := { testObject. nil }. > ref2 := { ref1 }. > ref3 := { ref2 }. > ref1 at: 2 put: ref3. "note the reference loop this creates" > testObject pointersTo size > -> 5 > > > > works. So, the problem is not in #pointersTo but inspecting > the result array has one or more recursive self calls > to its elements. > > > > > 2015-01-30 3:59 GMT+01:00 Ben Coman <btc(a)openinworld.com > <mailto:btc@openinworld.com>>: > > > I am revisiting my PointerDetective tool, which relies > heavily on ProtoObject>>pointersTo. > > The example I recorded at the repository home page is > currently locking & crashing the image due to #pointersTo > being unable to handle the circular reference. This > "must" have been working on Windows at least around August > 2014, but I've been unable to reproduce a working case > since my Windows laptop died and I've since moved to OSX. > > On OSX, in a fresh image 40467 and latest vm 402, the > following crashes the image... > > testObject := 'TEST'. > ref1 := { testObject. nil }. > ref2 := { ref1 }. > ref3 := { ref2 }. > ref1 at: 2 put: ref3. "note the reference loop this creates" > testObject pointersTo inspect. > > OSX Memory Monitor shows memory usage shoot from 50MB to > >500MB in a few seconds, then usually the image crashes, > but sometimes just hangs. > > I've logged... > https://pharo.fogbugz.com/default.asp?14827 > > cheers -ben > > > >

Jan. 31, 2015