- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [bloc] why redefining new is not enough?
by Stephan Eggermont Feb. 25, 2016

Feb. 25, 2016

On 25-02-16 14:00, Alain Plantec via Pharo-dev wrote: >interesting. >can you elaborate ? Basically it says I can only be tested when I have a valid space, and you get a really complex one to test with, the one where everything else is running in. Having that space, it tends to be difficult not to depend on that space (and why would you, as it is the space you want). For testing, I mostly don't want the space to be one that can be easily changed behind my back. Basically,the arguments from an old smalltalker [GOOS] Stephan [GOOS] Nat Pryce, Steve Freeman (2009) Growing Object-Oriented Software, Guided By Tests

1 0

[pharo-project/pharo-core]
by GitHub Feb. 25, 2016

Feb. 25, 2016

Branch: refs/tags/50612 Home: https://github.com/pharo-project/pharo-core

1 0

[pharo-project/pharo-core]
by GitHub Feb. 25, 2016

Feb. 25, 2016

Branch: refs/tags/50611 Home: https://github.com/pharo-project/pharo-core

1 0

Re: [Pharo-dev] [bloc] why redefining new is not enough?
by Stephan Eggermont Feb. 25, 2016

Feb. 25, 2016

On 25-02-16 12:31, Alain Plantec via Pharo-dev wrote: >the space may be needed during #initialize. I would strongly advice against that. That makes it untestable Stephan

2 1

[Bloc] stroke width and layout measure
by Glenn CavarlÃ© Feb. 25, 2016

Feb. 25, 2016

Hi, The stroke width of an element's shape is not taken into account when the child elements are measured. In fact, a child element that matches parent extent hides the left and top borders of its parent. Will it mandatory to use a padding to fix that ? Or is it just part of the work that still to be done ? Regards, ----- Glenn CavarlÃ© -- View this message in context: http://forum.world.st/Bloc-stroke-width-and-layout-measure-tp4880292.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

3 3

Re: [Pharo-dev] [bloc] why redefining new is not enough?
by Esteban Lorenzano Feb. 25, 2016

Feb. 25, 2016

> On 25 Feb 2016, at 12:32, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Alain Plantec <alain.plantec(a)yahoo.com> > Subject: Re: [Pharo-dev] [bloc] why redefining new is not enough? > Date: 25 February 2016 at 12:37:59 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > >> On 25 fÃ©vr. 2016, at 11:49, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> this is badâ¦ redefining basicNew should not be done, never, never, never. > why ? wellâ¦ is not forbidden, of courseâ¦ but many frameworks use basicNew as a way of obtain *explicitly* non-initialized objects (voyage does that, for instance). > >> thatâs why we have new and basicNew :) > > the space may be needed during #initialize. > this is why the initialization of the space is done in > basicNew. > But ok, we will fix that. you can define new as: new ^ self basicNew basicSpace: BlUniverse default runningSpace; initialize; yourself thatâs perfectly fine :) other possibility is to lazy initialise space with the default universe. Esteban > Thanks > Alain > >> >> Esteban >> >>> On 25 Feb 2016, at 09:52, stepharo <stepharo(a)free.fr> wrote: >>> >>> BlElement class>>basicNew >>> "Redefined to set the space of the element" >>> >>> ^ super basicNew basicSpace: BlUniverse default runningSpace >>> >>> why redefining new is not enough? >>> >>> Ok now back to the mooc videos :( >>> >>> >> >> > > > >

2 1

Re: [Pharo-dev] [bloc] why redefining new is not enough?
by ClÃ©ment Bera Feb. 25, 2016

Feb. 25, 2016

Hi, when redefining new you don't have to use super: BlElement class>>new ^ self basicNew basicSpace: BlUniverse default runningSpace; initialize; yourself IMO that's a better practice that redefining basicNew. Usually basicNew is only redefined when you cannot instantiate the objects using the normal API because it is not supported by the runtime (SmallInteger, Context, etc.) 2016-02-25 12:33 GMT+01:00 Alain Plantec via Pharo-dev < pharo-dev(a)lists.pharo.org>: > > > ---------- Message transfÃ©rÃ© ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Date: Thu, 25 Feb 2016 12:37:59 +0100 > Subject: Re: [Pharo-dev] [bloc] why redefining new is not enough? > > > On 25 fÃ©vr. 2016, at 11:49, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > this is badâ¦ redefining basicNew should not be done, never, never, never. > why ? > > > thatâs why we have new and basicNew :) > > the space may be needed during #initialize. > this is why the initialization of the space is done in > basicNew. > But ok, we will fix that. > Thanks > Alain > > > > > Esteban > > > >> On 25 Feb 2016, at 09:52, stepharo <stepharo(a)free.fr> wrote: > >> > >> BlElement class>>basicNew > >> "Redefined to set the space of the element" > >> > >> ^ super basicNew basicSpace: BlUniverse default runningSpace > >> > >> why redefining new is not enough? > >> > >> Ok now back to the mooc videos :( > >> > >> > > > > > > > >

2 1

Spotter - shortcut display on categories
by Ben Coman Feb. 25, 2016

Feb. 25, 2016

I see in 50601 that Spotter categories show their shortcut. I like it a lot! Just *maybe* could the "#Implementors" text added to the search field be appended rather than prepended. Then it would feel just like typing. I say *maybe* because I'd like to use-test the idea before I'm sure of myself. Could you point me to where I could make that change to try it out locally? cheers -ben

2 2

GTSpotter displayed shortcut glitch
by stepharo Feb. 25, 2016

Feb. 25, 2016

Hi doru and andrei I saw that you are displaying the shortcuts that can be used and this is good. Now may be I got it wrong but Cmd + M is not for implementors everywhere else it is Cmd + m Same for senders So I checked and Cmd + n is senders but displayed Cmd+N Cmd+N shows references and this is cool. Stef

2 2

fork during debugging to auto spawn new debugger
by Ben Coman Feb. 25, 2016

Feb. 25, 2016

Just a quick random thought before it gets away... It would be *nice* if when debugging and I step over a fork, the new process automatically halts at the start and spawns a new debugger. If its it was spawned at a higher priority, I could immediately move to the new debugger and step through before returning the original debugger. This would help a lot when stepping through unit tests that to test exotic corner cases are sometimes needfully convoluted about which order the processes run. Maybe if somehow a Process new it was being debugged and the new process inherited that state. cheers -ben

3 2