- Pharo-dev - lists.pharo.org

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

by Aliaksei Syrel

Well, it is not *important* for design what method is redefined new or basicNew in order to set space. My question is why do we need at all to set space? It means that element created (not added) while spaceA is running can not be used in or added to spaceB. The only reason that I know is a possibility to add global event listener to space while initializing an element. This must be fixed by having lazy addition of global event listeners. On Feb 25, 2016 9:55 AM, "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

ZTimestamp improvement

by Blondeau Vincent

Hello, I use Ztimestamp to parse a date but the time zone offset is wrongly set: (DateAndTime readTimezoneOffsetFrom: '+0530' readStream) printString gives '0:05:00:00' instead of '0:05:30:00'. See https://pharo.fogbugz.com/f/cases/17693/Time-offset-parsing-is-false for the DateAndTime issue. As the bug is in DateAndTime>>readOptionalSeparatorFrom: and ZTimestamp reuses the same code, I propose to apply the same patch to it. Can I have the commit access to the repo (http://smalltalkhub.com/#!/~SvenVanCaekenberghe/Neo) to submit the patch? Cheers, Vincent ________________________________ Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.

Feb. 25, 2016

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

by Tudor Girba

Oh, I missed this one :). So, now I can refactor the code that is still using the RTEdge class side methods :). Great! Thanks, Doru > On Feb 25, 2016, at 1:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Oh, but this has been in Roassal for many months (I have implemented since right after ESUG). You need to use #source:connectFrom:toAll: > > Here is an example that randomly generate a graph and render it using this facility: > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > nbOfNodes := 40. > nbOfRandomEdges := 40. > > nodes := 1 to: nbOfNodes. > edges := (1 to: nbOfRandomEdges) > collect: [ :notUsed | nodes atRandom -> {nodes atRandom . nodes atRandom} ]. > > b := RTMondrian new. > > b shape circle color: (Color black alpha: 0.5). > b nodes: nodes. > > b shape line color: (Color gray alpha: 0.3). > b edges > source: edges connectFrom: #key toAll: #value. > > b layout force. > b > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > <Screen Shot 2016-02-25 at 1.57.24 PM.png> > > Cheers, > Alexandre > >> On Feb 25, 2016, at 1:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> 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." >> >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > 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 "Next time you see your life passing by, say 'hi' and get to know her."

Feb. 25, 2016

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

by Alexandre Bergel

Oh, but this has been in Roassal for many months (I have implemented since right after ESUG). You need to use #source:connectFrom:toAll: Here is an example that randomly generate a graph and render it using this facility: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= nbOfNodes := 40. nbOfRandomEdges := 40. nodes := 1 to: nbOfNodes. edges := (1 to: nbOfRandomEdges) collect: [ :notUsed | nodes atRandom -> {nodes atRandom . nodes atRandom} ]. b := RTMondrian new. b shape circle color: (Color black alpha: 0.5). b nodes: nodes. b shape line color: (Color gray alpha: 0.3). b edges source: edges connectFrom: #key toAll: #value. b layout force. b -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre > On Feb 25, 2016, at 1:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > 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." > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 25, 2016

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

by Alain Plantec

Hello Stephan, > On 25 Feb 2016, at 13:30, Stephan Eggermont <stephan(a)stack.nl> wrote: > > 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 interesting. can you elaborate ? thanks Alain > > Stephan > >

Feb. 25, 2016

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

by Aliaksei Syrel

no On Feb 25, 2016 1:48 PM, "Nicolai Hess" <nicolaihess(a)gmail.com> wrote: > > > 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] 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