January 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #464: 21081 Super tearDown need to be called as last message in tearDown of FileSystemHandleTest, FileSystemTest, FileTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #464 was: SUCCESS. The Pull Request #755 was integrated: "21081 Super tearDown need to be called as last message in tearDown of FileSystemHandleTest, FileSystemTest, FileTest" Pull request url: https://github.com/pharo-project/pharo/pull/755 Issue Url: https://pharo.fogbugz.com/f/cases/21081 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 27, 2018

[Pharo 7.0-dev] Build #463: 21168 Use assert:equals: in testRunTarjan

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #463 was: SUCCESS. The Pull Request #758 was integrated: "21168 Use assert:equals: in testRunTarjan" Pull request url: https://github.com/pharo-project/pharo/pull/758 Issue Url: https://pharo.fogbugz.com/f/cases/21168 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 27, 2018

Re: [Pharo-dev] How to get rid of empty XML nodes?

by Stephane Ducasse

Tx Monty! This is a really important addition :) Because a super frequent scenario. Stef On Fri, Jan 26, 2018 at 8:37 AM, monty <monty2(a)programmer.net> wrote: > See #removeAllFormattingNodes and its comment in the latest version. > > And instances of SAXHandler and subclasses are meant to be created with #on: (or another "instance creation" message), _not #new_, otherwise they won't be properly initialized. The class comment is clear about this, but I should have overridden #new to raise an error like Stream does. Your misuse was helpful in bringing this to my attention, and I added a Stream-like #new implementation to SAXHandler. > >> Sent: Friday, December 08, 2017 at 9:21 AM >> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] How to get rid of empty XML nodes? >> >> Hi monty >> >> >> On Fri, Dec 8, 2017 at 9:03 AM, monty <monty2(a)programmer.net> wrote: >> > By "empty XML nodes," do you mean whitespace-only string nodes? >> >> Yes >> >> > Those are included because all in-element whitespace is assumed significant by the spec: https://www.w3.org/TR/xml/#sec-white-space >> >> I know. There was a discussion a while ago. I just lost a couple of >> hours understanding that :( >> >> But this is a super super super annoying practices. >> We had to test each nodes to see if it is a empty nodes so it makes >> everything a lot more complex without real justification >> beside the fact that these standardizers probably never implemented >> some real cases. >> This standard is a really out of reality from that perspective. >> >> > The exception is if the element is declared in the DTD as only having element children ("element content"): https://www.w3.org/TR/xml/#dt-elemcontent >> >> Well the XML files that I had (I did not choose XML because I would >> have prefer JSON :) ), had no DTD :( >> >> So at the end of the day, this wonderful standard puts all the stress >> and burden to people. >> >> > >> > For example, if you declare an element like this: >> > >> > <!ELEMENT one (two,three*,four?)> >> > >> > Any whitespace around a "two," "three," or "four" element child of a "one" element is insignificant and ignored (unless #preservesIgnorableWhitespace: is true). Other parsers, like LibXML2 and Xerces, behave the same way. >> > >> > I'll see if I can come up with some easier way to deal with this, like an optional parser setting, new enumeration methods, or maybe a tree transformation. >> >> It would be A HUGE PLUS!!!!!!!!!!!!!!!!!! >> >> >> Because reality is that people have XML files with just nodes and no >> empty nodes and they are forced to >> Let me know because I could try. >> >> I was showing how to use Pharo to import code to pharo learners and >> this was a big drag. >> >> Stef >> >> >> I tried to set some values in the parser but it did not work. >> BTW I saw that the configuration logic forces to write the following >> >> | parser doc visitor | >> parser := XMLDOMParser new >> on: self xmlContents; >> preservesIgnorableWhitespace: true. >> >> and not >> >> | parser doc visitor | >> parser := XMLDOMParser new >> preservesIgnorableWhitespace: true. >> on: self xmlContents; >> >> >> > >> >> Sent: Tuesday, December 05, 2017 at 8:29 AM >> >> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >> >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >> >> Subject: [Pharo-dev] How to get rid of empty XML nodes? >> >> >> >> )Hi >> >> >> >> we are manipulating an XML document and I would like to get rid of the >> >> spurious empty string. >> >> We saw that the gt panes are doing it. >> >> >> >> (aNodeWithElements isStringNode >> >> and: [aNodeWithElements isEmpty >> >> or: [aNodeWithElements isWhitespace]] >> >> >> >> Is there a way not to produce empty nodes? >> >> Is there a simple way not to have to handle them >> >> >> >> Now each time we are dealing with a node with have to check. >> >> >> >> Stef >> >> >> >> >> > >> >> >

Jan. 26, 2018

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

by Alistair Grant

Hi Subbu & Eliot, Thanks for your replies. They've made me realise that I'm looking in the wrong spot, so I'll take another look before asking any more questions. I'm also travelling tomorrow, so will be without internet for 3 or 4 days. Thanks again, Alistair On 26 January 2018 at 15:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > >> On Jan 26, 2018, at 3:00 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> >> On Ubuntu 16.04, I had to use: >> >> sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev libgl1-mesa-dev libgl1-mesa-glx >> >> to get all dependencies. This was sometime ago and the change should have made it to build.linux64x64/HowToBuild by now. > > Thanks Subbu. Ignore my earlier message. Should have read you response first :-) > >> >> What exactly is your error message? >> >> Regards .. Subbu >> >>> On Friday 26 January 2018 01:24 AM, Alistair Grant wrote: >>> Hi, >>> I'm attempting to build the 64bit VM in a docker container on Ubuntu >>> 16.04 installing the required packages using >>> opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin >>> fails to build because it can't find gl.h. >>> Installing mesa-common-dev (which is the most common answer when >>> searching for missing gl.h on google) changes the error to glRenderer >>> is redefined and has conflicting types. >>> Does anyone know what the correct combination of packages is? >>> Thanks! >>> Alistair >> >> >

Jan. 26, 2018

Re: [Pharo-dev] CI Hickups ...

by Stephane Ducasse

Yes now this is not easy to find the problems. I spent time reviewing your tearDown fixes and this is annoying to get broken tests when normally nothing should be red. On Fri, Jan 26, 2018 at 10:23 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > While our general build from Pharo 7 is (more or less often) green > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > I've noticed more and more that the CI builds for the PR's to Pharo 7 even for trivial changes are > often broken and not green > > https://github.com/pharo-project/pharo/pulls > > which is annoying and one still has the feeling to break the builds. > > As always I think getting a more stable CI is dependent on time, resources and priorities. But does anyone know > if this is a general issue or something that is already worked on? > > Thx > T. >

Jan. 26, 2018

Re: [Pharo-dev] Iceberg Loading issue

by Vincent.Blondeau＠lamresearch.com

Thanks Alistair! I'll try that. But, still, there is an issue somewhere in Iceberg. Cheers, Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alistair Grant Sent: Friday, January 26, 2018 0:57 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Iceberg Loading issue Hi Vincent, Every time I've seen this question asked, the answer has been to checkout the branch that you want and then "Reload All" from the list of packages. Cheers, Alistair On 26 January 2018 at 00:42, <Vincent.Blondeau(a)lamresearch.com> wrote: > Hi, > > I am encountering some problems with Iceberg on the latest version. > > I want to load the commits I just made on a branch on my Pharo fork, let's say "21124". I set the local repo to the current version of my Pharo image, i.e. the development branch (commit 0dbf86). > Thanks to the iceberg interface, I change the current branch to "21124", there are 12 commits that are incoming. > Then, I then do "Pull incoming commit" to load them. > But after a few moment, instead of loading only the delta between the development branch and the "21124" one, iceberg goes further in the commit history and wants to load 174 commits... Including one that does not load. > > By debugging, it seems that there is a problem with LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'" gives not the good commit i.e. the one of the development branch (commit 0dbf86), but instead the one of "I do not what". > > Does this issue is known? And how can I bypass it or solve it? > > Thanks, > > Vincent

Jan. 26, 2018

[Pharo 7.0-dev] Build #462: 20757-Playground-should-be-extensible-as-GT-Inspector

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #462 was: SUCCESS. The Pull Request #745 was integrated: "20757-Playground-should-be-extensible-as-GT-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/745 Issue Url: https://pharo.fogbugz.com/f/cases/20757 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

[Pharo 7.0-dev] Build #461: 21110 Super tearDown need to be called as last message in tearDown ofâ¦

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #461 was: SUCCESS. The Pull Request #722 was integrated: "21110 Super tearDown need to be called as last message in tearDown ofâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/722 Issue Url: https://pharo.fogbugz.com/f/cases/21110 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

[Pharo 7.0-dev] Build #460: 21108 Super tearDown need to be called as last message in tearDown of RGMethodDefinitionTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #460 was: SUCCESS. The Pull Request #723 was integrated: "21108 Super tearDown need to be called as last message in tearDown of RGMethodDefinitionTest" Pull request url: https://github.com/pharo-project/pharo/pull/723 Issue Url: https://pharo.fogbugz.com/f/cases/21108 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

by Eliot Miranda

> On Jan 26, 2018, at 3:00 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > On Ubuntu 16.04, I had to use: > > sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev libgl1-mesa-dev libgl1-mesa-glx > > to get all dependencies. This was sometime ago and the change should have made it to build.linux64x64/HowToBuild by now. Thanks Subbu. Ignore my earlier message. Should have read you response first :-) > > What exactly is your error message? > > Regards .. Subbu > >> On Friday 26 January 2018 01:24 AM, Alistair Grant wrote: >> Hi, >> I'm attempting to build the 64bit VM in a docker container on Ubuntu >> 16.04 installing the required packages using >> opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin >> fails to build because it can't find gl.h. >> Installing mesa-common-dev (which is the most common answer when >> searching for missing gl.h on google) changes the error to glRenderer >> is redefined and has conflicting types. >> Does anyone know what the correct combination of packages is? >> Thanks! >> Alistair > >

Jan. 26, 2018