- Pharo-dev - lists.pharo.org

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

Special case of pool access lookup crash

by Yuriy Tymchuk

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

Sept. 3, 2014

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

by stepharo

> 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. > + 1 Stef

Sept. 3, 2014

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

by stepharo

Marcus the contract is important and should be explicit because if you do not check the same size then you may have part of the computation done and not the rest. So I would introduce new methods with explicit names telling that fuzzyWith:do: or soemthing like that. On 3/9/14 14:40, Marcus Denker wrote: > with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). > > with: otherCollection do: twoArgBlock > "Evaluate twoArgBlock with corresponding elements from this collection and otherCollection." > otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. > 1 to: self size do: > [:index | > twoArgBlock value: (self at: index) > value: (otherCollection at: index)] > > I think we should not do that: > > 1) it is slow > 2) when the other is larger, is would work and just omit the rest > 3) if it is smaller, you will get an error anyway > > There are just three methods doing such a size check: > > with:do: > with:collect: > reverseWith:do: > (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) > > Is there a reason why this makes sense? > > I added an issue with a slice to clean it up: > > https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-si… > > Marcus > > > > > >

Sept. 3, 2014