February 2016 - Pharo-dev - lists.pharo.org

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

by Alain Plantec

> On 25 Feb 2016, at 12:51, stepharo <stepharo(a)free.fr> wrote: > > 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. this was the previous implementation. and nothing prevent a particular BlElement subclass to redefine drawOnAthensCanvas: Alain > > Stef >

Feb. 25, 2016

Re: [Pharo-dev] Is there a plan to have refreshing values in debugger?

by Marcus Denker

> On 25 Feb 2016, at 13:39, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > The support for polling is available since more than 1 year. The problem is that it is too slow to render the tree using MorphTreeMorph. We wanted to wait until Reflectivity would allow us to capture all objects events, but as that will not happen in Pharo 5, we now want to play with FastTable to see if it would be fast enough. > I am really reluctant to change code for every viewâ¦ this needs to be tested like crazy before being ready. And -> How to hook into array change? -> what about methods already on the stack? It is not simpleâ¦ it would need a lot of care. Marcus

Feb. 25, 2016

Re: [Pharo-dev] [Bloc] stroke width and layout measure

by Nicolai Hess

2016-02-25 13:30 GMT+01:00 Aliaksei Syrel <alex.syrel(a)gmail.com>: > I did not finish with shape yet. > > For arbitrary path it is not possible in cairo to render stroke inside > (really inside) of the shape and take stroke into account to render > children. Such behavior to some extent can be simulated but it really > complicates things. So I want to add in contract that it is responsibility > of developer to take border into account. > I don't know if this is currently accessible from athens api, but couldn't this be done with cairo_stroke_extents ? > cheers > On Feb 24, 2016 1:07 PM, "Glenn CavarlÃ©" <glenn(a)cavarle.fr> wrote: > >> 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. >> >>

Feb. 25, 2016

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

by Alain Plantec

> > > 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). ok > >> >>> 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 :) this is how I intended to fix it. > > other possibility is to lazy initialise space with the default universe. maybe, I donât know. thanks Alain > > Esteban > >> Thanks >> Alain >> >>> >>> Esteban >>> >>>> On 25 Feb 2016, at 09:52, stepharo <stepharo(a)free.fr <mailto:stepharo@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] Is there a plan to have refreshing values in debugger?

by Tudor Girba

Hi, The support for polling is available since more than 1 year. The problem is that it is too slow to render the tree using MorphTreeMorph. We wanted to wait until Reflectivity would allow us to capture all objects events, but as that will not happen in Pharo 5, we now want to play with FastTable to see if it would be fast enough. The issue is here: https://pharo.fogbugz.com/f/cases/14569/GTInspector-should-do-live-updates-… Cheers, Doru > On Feb 25, 2016, at 12:47 PM, stepharo <stepharo(a)free.fr> wrote: > > 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 > -- www.tudorgirba.com www.feenk.com "Being happy is a matter of choice."

Feb. 25, 2016

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

by Esteban Lorenzano

> On 25 Feb 2016, at 13:34, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > 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. I just sent the same example ;) > > 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 <mailto:pharo-dev@lists.pharo.org>>: > > > ---------- Message transfÃ©rÃ© ---------- > From: Alain Plantec <alain.plantec(a)yahoo.com <mailto:alain.plantec@yahoo.com>> > To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@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 <mailto:estebanlm@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 <mailto:stepharo@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] [bloc] why redefining new is not enough?

by Esteban Lorenzano

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

Feb. 25, 2016

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

by Aliaksei Syrel

All arbitrary shapes are being drawing in the same way and it is enough to have only one method. Allowing shape to render itself would lead to misunderstanding: bloc user would have to look into two places (element and shape) to find out where drawing actually happens. On Feb 25, 2016 12:56 PM, "stepharo" <stepharo(a)free.fr> wrote: > 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

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

by Tudor Girba

Hi, We discussed this before. Try to draw a hierarchy using classes and inheritance objects (so, without using the class to superclass navigation). Something like this: view := RTMondrian new. view nodes: classes. view edges objects: inheritances; connectFrom: #superclass to: #subclass. view layout tree. view It wonât work. Cheers, Doru > On Feb 25, 2016, at 1:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Do you have an example? I am not sure to understand. > > Alexandre > > >> On Feb 25, 2016, at 12:40 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> 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." >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 "Value is always contextual."

Feb. 25, 2016

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

by ClÃ©ment Bera

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

Feb. 25, 2016