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

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Aliaksei Syrel

There is also <return: BlElement or: nil> to indicate explicitly that user must check for nil. There are only a few methods in element (#owner and some collection related methods like "find element such that") that may return nil. Ideally syntax checker should take into account that method can return nil and indicate it somehow to user. Annotating return values is very common nowadays in popular dynamically typed languages to help static analysis of IDE. Annotating return values allows to instantly browse its class. Small script can remove those annotations and asserts from code during build for production on CI server. I don't understand why only symbols are allowed. In any console string parameter without spaces can be used directly without quotes. So for pragmas should work (and it works in latest pharo) <return: Point> <return: nil> <return: #Point> <return: 'Point'> <return: #'Point of view'> <return: 'Point of view'> I had the following pragma: <return: MyMagicClass> After renaming of MyMagicClass in nautilus it was also renamed in pragma. On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I saw that something <return: #Point> or <return: Point> > I do not know why but I have the impression that <return: #Point> is > better. > Because we may have code not present and still want to load the code. > Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot

Feb. 25, 2016

[pharo-project/pharo-core]

by GitHub

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

Feb. 25, 2016

[pharo-project/pharo-core] c2b19a: 50611

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c2b19a15475f784e06cbcf617d7e304632e16de4 https://github.com/pharo-project/pharo-core/commit/c2b19a15475f784e06cbcf61… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-02-25 (Thu, 25 Feb 2016) Changed paths: M AST-Tests-Core.package/NumberParserTest.class/instance/tests - Float/testIntegerWithNegExponentIsAFloat.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/baselines/baseline22_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/development_.st M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version28_.st A Kernel-Rules.package/FloatReferencesRule.class/README.md A Kernel-Rules.package/FloatReferencesRule.class/definition.st A Kernel-Rules.package/FloatReferencesRule.class/instance/accessing/group.st A Kernel-Rules.package/FloatReferencesRule.class/instance/accessing/name.st A Kernel-Rules.package/FloatReferencesRule.class/instance/accessing/rationale.st A Kernel-Rules.package/FloatReferencesRule.class/instance/running/basicCheck_.st A Kernel-Rules.package/FloatReferencesRule.class/instance/running/check_forCriticsDo_ifNone_.st A Kernel-Rules.package/FloatReferencesRule.class/instance/running/systemClassNames.st M NECompletion-Tests.package/NECContextTest.class/instance/tests/testReceiverConstant.st A Rubric-Rules.package/RbScriptingSetBeforeModel.class/README.md A Rubric-Rules.package/RbScriptingSetBeforeModel.class/definition.st A Rubric-Rules.package/RbScriptingSetBeforeModel.class/instance/accessing/group.st A Rubric-Rules.package/RbScriptingSetBeforeModel.class/instance/accessing/name.st A Rubric-Rules.package/RbScriptingSetBeforeModel.class/instance/running/basicCheck_.st A Rubric-Rules.package/RbScriptingSetBeforeModel.class/instance/running/check_forCriticsDo_ifNone_.st R Rubric.package/RubBasicSelectionDecorator.class/README.md R Rubric.package/RubBasicSelectionDecorator.class/class/querying/key.st R Rubric.package/RubBasicSelectionDecorator.class/definition.st R Rubric.package/RubBasicSelectionDecorator.class/instance/drawing/draw.st R Rubric.package/RubBasicSelectionDecorator.class/instance/drawing/drawOnAthensCanvas.st R Rubric.package/RubBasicSelectionDecorator.class/instance/drawing/handleDrawingOnAthensCanvas_bounds_.st R Rubric.package/RubBasicSelectionDecorator.class/instance/drawing/handleDrawingOn_using_at_.st M Rubric.package/RubCurrentLineBarDecorator.class/definition.st A Rubric.package/RubCurrentLineBarDecorator.class/instance/drawing/drawOnAthensCanvas_.st A Rubric.package/RubCurrentLineBarDecorator.class/instance/drawing/drawOn_.st M Rubric.package/RubExtraSelectionDecorator.class/definition.st M Rubric.package/RubExtraSelectionDecorator.class/instance/accessing/findRegex.st M Rubric.package/RubExtraSelectionDecorator.class/instance/accessing/primarySelectionInterval.st A Rubric.package/RubExtraSelectionDecorator.class/instance/computation/cleanUpText.st A Rubric.package/RubExtraSelectionDecorator.class/instance/computation/computeFindReplaceShapesFrom_to_.st R Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/cleanUpText.st R Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/computeFindReplaceShapesFrom_to_.st M Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/computeSecondarySelectionShapesFrom_to_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/computeSelectionShapesFor_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawAllSelectionShapesOnAthensCanvas_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawAllSelectionShapesOn_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawOnAthensCanvas_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawOn_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawSelectionShape_onAthensCanvas_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/drawing/drawSelectionShape_on_.st A Rubric.package/RubExtraSelectionDecorator.class/instance/testing/hasValidSelection.st A Rubric.package/RubOpeningClosingDelimiterDecorator.class/instance/drawing/drawOnAthensCanvas_.st A Rubric.package/RubOpeningClosingDelimiterDecorator.class/instance/drawing/drawOn_.st A Rubric.package/RubOpeningClosingDelimiterDecorator.class/instance/drawing/positionOfOppositeDelimiter_startingAt_in_.st M Rubric.package/RubParagraphDecorator.class/definition.st A Rubric.package/RubParagraphDecorator.class/instance/drawing/canDrawDecoratorsOn_.st A Rubric.package/RubParagraphDecorator.class/instance/drawing/drawOnAthensCanvas_.st M Rubric.package/RubParagraphDecorator.class/instance/drawing/drawOnAthensCanvas_bounds_color_.st A Rubric.package/RubParagraphDecorator.class/instance/drawing/drawOn_.st M Rubric.package/RubParagraphDecorator.class/instance/drawing/drawOn_using_at_.st A Rubric.package/RubParagraphDecorator.class/instance/instead of DNU/paragraph.st A Rubric.package/RubParagraphDecorator.class/instance/instead of DNU/text.st A Rubric.package/RubSmalltalkCodeMode.class/instance/formatting/maxFormatterLineLength.st M Rubric.package/RubSmalltalkCodeMode.class/instance/initialize-release/formatMethodCode.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50610.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50611.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50610.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50611.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools-Test.package/MessageTallyTest.class/instance/tallying/testTallySends.st Log Message: ----------- 50611 17686 Add rules about Rubric method precedence https://pharo.fogbugz.com/f/cases/17686 17689 BoxedFloat Fix remaining Tests https://pharo.fogbugz.com/f/cases/17689 17685 Add rules to check if Float system classes are referenced https://pharo.fogbugz.com/f/cases/17685 http://files.pharo.org/image/50/50611.zip

Feb. 25, 2016

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

by Aliaksei Syrel

An we need NullSpace to be default value. On Feb 25, 2016 2:06 PM, "Aliaksei Syrel" <alex.syrel(a)gmail.com> wrote: > 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

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