September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] speed up with:do: by not checking size

by Stephan Eggermont

4) It doesn't work if I modify the collections during the iteration :) The constant time cost in looking up size doesn't look like much of a problem to me. Stephan

Sept. 4, 2014

Re: [Pharo-dev] Special case of pool access lookup crash

by Yuriy Tymchuk

Sure https://pharo.fogbugz.com/f/cases/13952/Pool-access-lookup-crash On 04 Sep 2014, at 09:44, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > No, not yet reported. Can you open an issue? > > > On Wed, Sep 3, 2014 at 8:43 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > when you go to AJx86Registers class, press âShow class variablesâ and select âIPâ, then it crashes with: 'RIP register IP cannot be used only for relative addressingâ. I couldnât find related bug report, should I open one? > > <Screen Shot 2014-09-03 at 20.40.17.png> > > Uko > > > > -- > -- > Marcus Denker -- denker(a)acm.org > http://www.marcusdenker.de

Sept. 4, 2014

Re: [Pharo-dev] speed up with:do: by not checking size

by Marcus Denker

On Wed, Sep 3, 2014 at 8:19 PM, stepharo <stepharo(a)free.fr> wrote: > > Like Thierry I'm not sure that omitting the check brings a >> significant speedup. >> However, not doing this check follows the robustness principle: "Be >> conservative in what you do, be liberal in what you accept from others". >> > > But it violates the "if it ain't broke don't fix it", "it means what it > means", and "Smalltalk is a safe language" principles. That safety check > finds bugs. If one wants a more relaxed contract, implement a new > contract, don't break an existing contract that has stood for years. > > >> I would even be more liberal with a: >> 1 to: (self size min: otherCollection size) do: .... >> :) >> > > But you can write that if that's what you mean. But arbitrarily > changing existing protocol for weak reasons when _it ain't broke_ is a > recipe for chaos. > > Ok, then I will not do it... Marcus

Sept. 4, 2014

Re: [Pharo-dev] Special case of pool access lookup crash

by Marcus Denker

Hi, No, not yet reported. Can you open an issue? On Wed, Sep 3, 2014 at 8:43 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > when you go to AJx86Registers class, press âShow class variablesâ and > select âIPâ, then it crashes with: 'RIP register IP cannot be used only for > relative addressingâ. I couldnât find related bug report, should I open one? > > > Uko > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Sept. 4, 2014

Re: [Pharo-dev] latex exporter in Pillar

by stepharo

Alex did you follow the description? Stef On 3/9/14 21:24, Alexandre Bergel wrote: > Hi! > > I am currently investigating whether Pillar may be used for the AgileVisualization book. > I am interested in exporting to PDF and Latex. I have tried the command: > > ./pillar export âto=latex first.pier > first.tex > > But the generated .tex file is not valid since it contains a line: > -=-=-=-= > \newcommand{\ct}[1]} > -=-=-=-= > > Will this be fixed ? > > Cheers, > Alexandre

Sept. 4, 2014

Re: [Pharo-dev] latex exporter in Pillar

by Damien Cassou

On Wed, Sep 3, 2014 at 9:24 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > -=-=-=-= > \newcommand{\ct}[1]} > -=-=-=-= I know the problem. I think this is a bad interaction between the mustache template and LaTeX use of '}}'. The workaround for you would be to specify your own LaTeX template where all macros are in a dedicated external file (copy/paste what we do for the book from https://github.com/SquareBracketAssociates/PharoForTheEnterprise-english/tr…) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Sept. 4, 2014

Re: [Pharo-dev] latex exporter in Pillar

by Tudor Girba

Hi Alex, Could you describe the steps you took? Cheers, Doru On Wed, Sep 3, 2014 at 9:34 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Have you used the template files ? I used for my own book, took the files > from Update Pharo By Example and it worked like a charm including creation > CI job and even pushing the book to gitbook. Tex files, pdf files and MD > files generated without any issues. Also working with Updated PBE I never > had an issue with bad tex generation. > > > > > On Wed, Sep 3, 2014 at 10:24 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> Hi! >> >> I am currently investigating whether Pillar may be used for the >> AgileVisualization book. >> I am interested in exporting to PDF and Latex. I have tried the command: >> >> ./pillar export âto=latex first.pier > first.tex >> >> But the generated .tex file is not valid since it contains a line: >> -=-=-=-= >> \newcommand{\ct}[1]} >> -=-=-=-= >> >> Will this be fixed ? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 4, 2014

Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix

by stepharo

Clement we should fix the code of the menu :) Stef On 3/9/14 15:25, ClÃ©ment Bera wrote: > Hello, > > Sven you are right, the old compiler was consistent in the sense that > it always iterated over all the elements, including the ones added > with #add: and #addLast: while iterating over the collection. > On the other hand, VW is consistent with the Opal implementation for > #to:do: in the sense that they iterate only on the elements of the > collection excluding the ones added while iterating. > > #add:after: and co do not work well if you edit the collection while > iterating over it for sure :). > > It's too late for "don't modify a collection while iterating it" > because the system does it, for example, to build the world menu. So I > think the solution is in two steps: > - removing code which edit the collection while iterating over it. As > most frameworks work both on Pharo and VW and that the behavior is > different I think there shouldn't be that much, so fixing the Pharo > image may be enough. > - be consistent in our collection protocol, basically by rewriting do: > and reverseDo: like that: > > FROM: > do: aBlock > "Override the superclass for performance reasons." > | index | > index := firstIndex. > [index <= lastIndex] > whileTrue: > [aBlock value: (array at: index). > index := index + 1] > TO: > do: aBlock > "Override the superclass for performance reasons." > firstIndex to: lastIndex do: [ :index | > aBlock value: (array at: index) ] > > > > > > 2014-09-03 14:05 GMT+02:00 Camille Teruel <camille.teruel(a)gmail.com > <mailto:camille.teruel@gmail.com>>: > > > On 3 sept. 2014, at 11:42, ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>> wrote: > > > Hello guys, > > > > I was looking into the OrderedCollection protocols recently to > see how well the sista optimizer perform with it methods, and I > realized that this is completely broken. > > > > For example: > > > > col := #(1 2 3 4 5) asOrderedCollection. > > col do: [ :elem | elem trace . > > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > > > => '12345678' > > > > However: > > > > col := #(1 2 3 4 5) asOrderedCollection. > > col collect: [ :elem | elem trace . > > elem < 4 ifTrue: [ col add: col size + 1 ]]. > > > > => '12345' > > > > This means that #do: and #reverseDo: iterate over all the > elements of the collection,*including* the ones that you are > adding while iterating over the collection, whereas all the other > OrderedCollection protocols, such as #collect:, #select:, iterates > over all the elements of the collection, *excluding* the ones you > are adding while iterating over the collection. > > > > Marcus argued that one should not edit a collection while > iterating over it, however this point is not valid as the World > menu relies on this feature, using #do: to iterate over the > elements of the OrderedCollection including the one it is adding > while iterating over the collection. Changing the implementation > makes the world menu display half of its items. > > > > I don't like this difference because it is inconsistent. For > example, refactoring a #do: into a #collect: can simply not work > because they do not iterate over the same elements if you are > editing the collection while iterating over it. > > > > In VW, the protocols are consistent and iterating over a > collection never iterates over the elements one is adding while > iterating over it. Therefore, I believe most frameworks should > expect this behavior (at least the ones cross smalltalk) which > sounds the most correct. > > > > I think we should fix the world menu implementation and make the > protocols consistent. Alternatively, we can let VW be a much more > consistent Smalltalk environment than Pharo. What do you think ? > > > The thing is to find alternative implementations that are > efficient enough (no copy). Maybe we can get some inspirations > from VW for that (how do they do BTW?). > You should also check with other kinds of collection because they > may act differently than OrderedCollection. > So in the end it depends on the amount of effort needed to make > all collections consistent with this new requirement and on the > resulting overhead. > If it's too much, I think that following the old advice "don't > modify a collection while iterating it" is enough. If one really > needs to do such kind of things he should consider an alternative > design like using a zipper for example. > > Camille > > > > > Clement > > > > >

Sept. 3, 2014

Re: [Pharo-dev] latex exporter in Pillar

by kilon alios

Have you used the template files ? I used for my own book, took the files from Update Pharo By Example and it worked like a charm including creation CI job and even pushing the book to gitbook. Tex files, pdf files and MD files generated without any issues. Also working with Updated PBE I never had an issue with bad tex generation. On Wed, Sep 3, 2014 at 10:24 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > I am currently investigating whether Pillar may be used for the > AgileVisualization book. > I am interested in exporting to PDF and Latex. I have tried the command: > > ./pillar export âto=latex first.pier > first.tex > > But the generated .tex file is not valid since it contains a line: > -=-=-=-= > \newcommand{\ct}[1]} > -=-=-=-= > > Will this be fixed ? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Sept. 3, 2014

latex exporter in Pillar

by Alexandre Bergel

Hi! I am currently investigating whether Pillar may be used for the AgileVisualization book. I am interested in exporting to PDF and Latex. I have tried the command: ./pillar export âto=latex first.pier > first.tex But the generated .tex file is not valid since it contains a line: -=-=-=-= \newcommand{\ct}[1]} -=-=-=-= Will this be fixed ? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 3, 2014