- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by stepharo

To me this is pre optimisation I do not see why we cannot do BlElement>>drawOnAthensCanvas: aCanvas self shape drawOnAthensCanvas: aCanvas with: self so far only localBounds from BlElement are used. And to me this is really strange to have an object responsible for the drawing not doing it. It blurs the responsibility. Stef Le 25/2/16 10:39, Tudor Girba a Ã©crit : > Hi, > > Good question. > > The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. > > Cheers, > Doru > > >> On Feb 25, 2016, at 9:56 AM, stepharo <stepharo(a)free.fr> wrote: >> >> Hi Blockers >> >> I do not really understand why drawOnAthensCanvas: is not defined on BlShape >> (especially when we see how many self space are defined in this method. >> And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). >> >> >> drawOnAthensCanvas: aCanvas >> "Actually render receiver on aCanvas in local bounds. >> Override to customize. >> aCanvas is an instance of AthensCanvas >> aCanvas must not be nil" >> >> | pathTransform | >> pathTransform := aCanvas pathTransform. >> "First we fill" >> pathTransform >> restoreAfter: >> [ | path fillExtent fillTranslation | >> "We fill inside natural element's bounds" >> fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: fillExtent. >> "Translate fill if needed" >> fillTranslation := self shape path >> fillTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: fillTranslation. >> aCanvas >> setPaint: self shape fillPaint; >> drawShape: path ]. >> pathTransform >> restoreAfter: >> [ | path strokeExtent strokeTranslation | >> "We stroke inside natural element's bounds" >> strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. >> path := self shape path pathOn: aCanvas forExtent: strokeExtent. >> "Translate stroke if needed" >> strokeTranslation := self shape path >> strokeTranslationFor: self shape >> inBounds: self localBounds. >> pathTransform translateBy: strokeTranslation. >> aCanvas >> setPaint: self shape strokePaint; >> drawShape: path ] >> > -- > www.tudorgirba.com > www.feenk.com > > "Sometimes the best solution is not the best solution." > > >

Feb. 25, 2016

Is there a plan to have refreshing values in debugger?

by stepharo

Hi Is there a plan to have refreshed values (instance variables) in debugger and inspector? This is super annoying to have to refresh the complete list in the debugger to see new values of instance variables. Why we cannot put back the old pulling behavior and in the future use reflectivity? Stef

Feb. 25, 2016

Re: [Pharo-dev] [Moose-dev] Call for action for Roassal

by Tudor Girba

This is very cool. We will all benefit from this documentation. One thing that I would still like to see fixed before the release is the edge building (this problem of not being able to properly specify random objects to be taken into account when building edges). Could we work on that? Cheers, Doru > On Feb 24, 2016, at 9:51 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Dear community, > > As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: > > What are the 3 aspects you would like to see improved in Roassal? > > You can answer publicly or by sending private messages. > > Kind regards, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Feb. 25, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by Alain Plantec

> 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 :( >> >> > >

Feb. 25, 2016

debugger versus primitive 19 "simulation guard"

by Ben Coman

Trying to debug step two times into... [ 'a' ] newProcess ...hangs the image. It works okay with... Pharo5.0 update: #50495 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.21 uuid: 4d9b9bdf-2dfa-4c0b-99eb-5b110dadc697 Apr 2 2015 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #14904 Unix built on Apr 2 2015 00:51:53 Compiler: 4.6.3 but not with... Pharo5.0 update: #50496 CoInterpreter VMMaker.oscog-eem.1630 uuid: 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 14 2016 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 Unix built on Jan 14 2016 11:50:34 Compiler: 4.6.3 btw, the same case on Squeak-4.6-All-In-one and Squeak-5-All-In-One both produce "Code simulation error." Is it maybe related to... "another endless debugger loop" https://pharo.fogbugz.com/default.asp?16877 cheers -ben

Feb. 25, 2016

Re: [Pharo-dev] [bloc] why redefining new is not enough?

by Esteban Lorenzano

this is badâ¦ redefining basicNew should not be done, never, never, never. thatâs why we have new and basicNew :) 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 :( > >

Feb. 25, 2016

Re: [Pharo-dev] Spotter - shortcut display on categories

by Ben Coman

okay, that makes sense. cheers -ben On Thu, Feb 25, 2016 at 6:11 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > We added it intentionally at the beginning so that you can continue typing without being disturbed. The idea is that you can do something like: > - GT > - Cmd+b > - In > > ==> #Classes GTIn > > For this scenario, it feels more natural to have the cursor at the end. On the other hand, the whole text shifts. Both options have pros and cons I think. > > Cheers, > Doru > > >> On Feb 25, 2016, at 6:05 AM, Ben Coman <btc(a)openInWorld.com> wrote: >> >> 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 >> > > -- > www.tudorgirba.com > www.feenk.com > > "One cannot do more than one can do." > > > > >

Feb. 25, 2016

Re: [Pharo-dev] Spotter - shortcut display on categories

by Tudor Girba

Hi, We added it intentionally at the beginning so that you can continue typing without being disturbed. The idea is that you can do something like: - GT - Cmd+b - In ==> #Classes GTIn For this scenario, it feels more natural to have the cursor at the end. On the other hand, the whole text shifts. Both options have pros and cons I think. Cheers, Doru > On Feb 25, 2016, at 6:05 AM, Ben Coman <btc(a)openInWorld.com> wrote: > > 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 > -- www.tudorgirba.com www.feenk.com "One cannot do more than one can do."

Feb. 25, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by Alain Plantec

Hello, very good remark. This is one of the main consequence of the design review we made recently. In the first design, this was the case, the drawing was delegated. For now, it is a known issue of the current design. Cheers Alain > On 25 fÃ©vr. 2016, at 09:56, stepharo <stepharo(a)free.fr> wrote: > > Hi Blockers > > I do not really understand why drawOnAthensCanvas: is not defined on BlShape > (especially when we see how many self space are defined in this method. > And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). > > > drawOnAthensCanvas: aCanvas > "Actually render receiver on aCanvas in local bounds. > Override to customize. > aCanvas is an instance of AthensCanvas > aCanvas must not be nil" > > | pathTransform | > pathTransform := aCanvas pathTransform. > "First we fill" > pathTransform > restoreAfter: > [ | path fillExtent fillTranslation | > "We fill inside natural element's bounds" > fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. > path := self shape path pathOn: aCanvas forExtent: fillExtent. > "Translate fill if needed" > fillTranslation := self shape path > fillTranslationFor: self shape > inBounds: self localBounds. > pathTransform translateBy: fillTranslation. > aCanvas > setPaint: self shape fillPaint; > drawShape: path ]. > pathTransform > restoreAfter: > [ | path strokeExtent strokeTranslation | > "We stroke inside natural element's bounds" > strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. > path := self shape path pathOn: aCanvas forExtent: strokeExtent. > "Translate stroke if needed" > strokeTranslation := self shape path > strokeTranslationFor: self shape > inBounds: self localBounds. > pathTransform translateBy: strokeTranslation. > aCanvas > setPaint: self shape strokePaint; > drawShape: path ] >

Feb. 25, 2016

Re: [Pharo-dev] [bloc] feature envy -> move method close to data?

by Tudor Girba

Hi, Good question. The reason we want to have the morph be responsible because subclasses might decide to draw in a different way regardless of the shape being used. This gives us the maximum freedom for more specific blocs. Still, this is something to experiment with once we have more complicated examples built with Bloc. Cheers, Doru > On Feb 25, 2016, at 9:56 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi Blockers > > I do not really understand why drawOnAthensCanvas: is not defined on BlShape > (especially when we see how many self space are defined in this method. > And this is one of the few things I thought I understood from bloc (grouping the rendering in a separate object). > > > drawOnAthensCanvas: aCanvas > "Actually render receiver on aCanvas in local bounds. > Override to customize. > aCanvas is an instance of AthensCanvas > aCanvas must not be nil" > > | pathTransform | > pathTransform := aCanvas pathTransform. > "First we fill" > pathTransform > restoreAfter: > [ | path fillExtent fillTranslation | > "We fill inside natural element's bounds" > fillExtent := self shape path fillExtentFor: self shape inBounds: self localBounds. > path := self shape path pathOn: aCanvas forExtent: fillExtent. > "Translate fill if needed" > fillTranslation := self shape path > fillTranslationFor: self shape > inBounds: self localBounds. > pathTransform translateBy: fillTranslation. > aCanvas > setPaint: self shape fillPaint; > drawShape: path ]. > pathTransform > restoreAfter: > [ | path strokeExtent strokeTranslation | > "We stroke inside natural element's bounds" > strokeExtent := self shape path strokeExtentFor: self shape inBounds: self localBounds. > path := self shape path pathOn: aCanvas forExtent: strokeExtent. > "Translate stroke if needed" > strokeTranslation := self shape path > strokeTranslationFor: self shape > inBounds: self localBounds. > pathTransform translateBy: strokeTranslation. > aCanvas > setPaint: self shape strokePaint; > drawShape: path ] > -- www.tudorgirba.com www.feenk.com "Sometimes the best solution is not the best solution."

Feb. 25, 2016