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

Re: [Pharo-dev] Array inspector Items view Selection broken

by Tudor Girba

Indeed. The issue comes from this commit: https://github.com/pharo-project/pharo/pull/1889 Cheers, Doru > On Oct 10, 2018, at 9:24 PM, Julien <julien.delplanque(a)inria.fr> wrote: > > I can relate. > > I encountered this bug today and days before as well. > > I was going to ask about it as well. > > Cheers, > > Julien > > --- > Julien Delplanque > Doctorant Ã lâUniversitÃ© de Lille > http://juliendelplanque.be/phd.html > Equipe Rmod, Inria > BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq > NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > >> Le 10 oct. 2018 Ã 21:20, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : >> >> When you inspect an array, like #(1 2 3), using the Items view in the GT Inspector, a selection of an item/element results in a sub GT tab with another array containing that item/element, not the item/element itself as it should be. >> >> Anyone else seeing this ? >> >> Sven > -- www.feenk.com "You can inspect and adapt only what is explicit."

Oct. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Pierce Ng

On Wed, Oct 10, 2018 at 08:42:13AM -0300, Esteban Maringolo wrote: > PR approved! We're listed at https://github.com/topics/pharo Great! I've tagged all my projects. Pierce

Oct. 11, 2018

Re: [Pharo-dev] What you think about visibility of trait method in browser?

by Gabriel Cotelli

I think that by default methods coming for traits should be visible in the browser, but needs to be somehow identified. Pharo traits was conceived in a way that from the class point of view you see no difference if it was flattened or not, and Self traits are not exactly the same because they use the delegation scheme in the method lookup. I think that a feature to hide trait methods is unneeded, but the possiblity to easily filter methods coming from a trait it a good one. Just my two cents. And by the way, we really need to name traits with a T in the name? I always found this ugly, it makes the trait support look like a hack. On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > In next Calypso version the option to enable or disable trait method > visibility will not be available anymore (not my choice). > All trait methods installed to the class will be just a class methods like > it was in Nautilus. No way to hide them. > I want to ask you what you think about it. > - do you prefer to see trait methods by default? > - do you want feature to hide trait methods? > > Current Calypso support for traits follows simple principle which I found > important for me. But I can be the only guy who think this way. Maybe > because I meet traits in Self. So: > I simply want to see in the browser what class is actually implements. If > class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see > its methods by default. When I open such class in the browser I want to see > only code which class explicitly implements For me this logic is same as > for superclass methods. > It was my original intention for trait support in Calypso. And I would > like to hear if people share it or not. > (there are missing trait feature in the current approach but it is not a > subject of my question. Think that everything is supported correctly) > > Best regards, > Denis > >

Oct. 10, 2018

What you think about visibility of trait method in browser?

by Denis Kudriashov

Hello. In next Calypso version the option to enable or disable trait method visibility will not be available anymore (not my choice). All trait methods installed to the class will be just a class methods like it was in Nautilus. No way to hide them. I want to ask you what you think about it. - do you prefer to see trait methods by default? - do you want feature to hide trait methods? Current Calypso support for traits follows simple principle which I found important for me. But I can be the only guy who think this way. Maybe because I meet traits in Self. So: I simply want to see in the browser what class is actually implements. If class uses TEmpty trait (with ifEmpty, isEmpty methods) I don't want to see its methods by default. When I open such class in the browser I want to see only code which class explicitly implements For me this logic is same as for superclass methods. It was my original intention for trait support in Calypso. And I would like to hear if people share it or not. (there are missing trait feature in the current approach but it is not a subject of my question. Think that everything is supported correctly) Best regards, Denis

Oct. 10, 2018

Re: [Pharo-dev] Array inspector Items view Selection broken

by Julien

I can relate. I encountered this bug today and days before as well. I was going to ask about it as well. Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 10 oct. 2018 Ã 21:20, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > When you inspect an array, like #(1 2 3), using the Items view in the GT Inspector, a selection of an item/element results in a sub GT tab with another array containing that item/element, not the item/element itself as it should be. > > Anyone else seeing this ? > > Sven

Oct. 10, 2018

Array inspector Items view Selection broken

by Sven Van Caekenberghe

When you inspect an array, like #(1 2 3), using the Items view in the GT Inspector, a selection of an item/element results in a sub GT tab with another array containing that item/element, not the item/element itself as it should be. Anyone else seeing this ? Sven

Oct. 10, 2018

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Peter Uhnak

> > Same same > Tag is a git concept that marks a specific commit. Release is a hosting platform (GitHub/GitLab/...) concept that wraps a tag with some fancy stuff (release page, downloads, whatnot). However each release is tied to a git tag. >From pharo/metacello dependency perspective, only git tags are relevant. Peter > > Norbert > > > >> Norbert > >> > >> > >>> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >>> > >>> Hi, > >>> > >>> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. > >>> So far I did the following: > >>> > >>> https://github.com/svenvc/NeoJSON > >>> https://github.com/svenvc/NeoCSV > >>> https://github.com/svenvc/ztimestamp > >>> https://github.com/svenvc/P3 > >>> https://github.com/svenvc/stamp > >>> https://github.com/svenvc/SimpleRedisClient > >>> https://github.com/svenvc/NeoConsole > >>> > >>> More will follow, in particular Zinc/Zodiac and STON, both of which > are more complex. > >>> > >>> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. > >>> By loading the latest Metacello and Tonel, the code is also loadable > in Pharo 6 or 5. > >>> > >>> After a while I will switch the Catalog entries and declare these repo > the main ones. > >>> > >>> Sven > >>> > >>> -- > >>> Sven Van Caekenberghe > >>> Proudly supporting Pharo > >>> http://pharo.org > >>> http://association.pharo.org > >>> http://consortium.pharo.org > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > >

Oct. 10, 2018

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Norbert Hartl

> Am 10.10.2018 um 15:58 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 10 Oct 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Very cool. Thank you very much, >> >> Can you make releases for your repos? In my repos I did a release of a version saying it is the same as the last on smalltalkhub. So people can pinpoint to a specific release. I think this is a good way of doing it. > > OK, I am still learning ;-) > > What is the technical/practical differences between a tag and a release then ? None :) On Github you press the button âCreate a new releaseâ on git commandline you create a tag. Same same Norbert > >> Norbert >> >> >>> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Hi, >>> >>> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. >>> So far I did the following: >>> >>> https://github.com/svenvc/NeoJSON >>> https://github.com/svenvc/NeoCSV >>> https://github.com/svenvc/ztimestamp >>> https://github.com/svenvc/P3 >>> https://github.com/svenvc/stamp >>> https://github.com/svenvc/SimpleRedisClient >>> https://github.com/svenvc/NeoConsole >>> >>> More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. >>> >>> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. >>> By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. >>> >>> After a while I will switch the Catalog entries and declare these repo the main ones. >>> >>> Sven >>> >>> -- >>> Sven Van Caekenberghe >>> Proudly supporting Pharo >>> http://pharo.org >>> http://association.pharo.org >>> http://consortium.pharo.org >>> >>> >>> >>> >>> >> >> > >

Oct. 10, 2018

[Pharo 7.0-dev] Build #1325: 16196-Move-Zinc-Examples-to-a-different-package

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

There is a new Pharo build available! The status of the build #1325 was: SUCCESS. The Pull Request #1841 was integrated: "16196-Move-Zinc-Examples-to-a-different-package" Pull request url: https://github.com/pharo-project/pharo/pull/1841 Issue Url: https://pharo.fogbugz.com/f/cases/16196 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 10, 2018

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Sven Van Caekenberghe

> On 10 Oct 2018, at 11:15, Norbert Hartl <norbert(a)hartl.name> wrote: > > Very cool. Thank you very much, > > Can you make releases for your repos? In my repos I did a release of a version saying it is the same as the last on smalltalkhub. So people can pinpoint to a specific release. I think this is a good way of doing it. OK, I am still learning ;-) What is the technical/practical differences between a tag and a release then ? > Norbert > > >> Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> Hi, >> >> I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. >> So far I did the following: >> >> https://github.com/svenvc/NeoJSON >> https://github.com/svenvc/NeoCSV >> https://github.com/svenvc/ztimestamp >> https://github.com/svenvc/P3 >> https://github.com/svenvc/stamp >> https://github.com/svenvc/SimpleRedisClient >> https://github.com/svenvc/NeoConsole >> >> More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. >> >> The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. >> By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. >> >> After a while I will switch the Catalog entries and declare these repo the main ones. >> >> Sven >> >> -- >> Sven Van Caekenberghe >> Proudly supporting Pharo >> http://pharo.org >> http://association.pharo.org >> http://consortium.pharo.org >> >> >> >> >> > >

Oct. 10, 2018

Re: [Pharo-dev] GitHub Topics

by Sven Van Caekenberghe

Super, thank you ! > On 10 Oct 2018, at 13:42, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > PR approved! We're listed at https://github.com/topics/pharo > > <image.png> > > > > Esteban A. Maringolo > > Esteban A. Maringolo > > > El mar., 9 oct. 2018 a las 22:31, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > El mar., 9 oct. 2018 a las 18:30, Peter Uhnak (<i.uhnak(a)gmail.com>) escribiÃ³: > > > >> Maybe there is a minimum threshold required to enable such edits. > > issue a pull request to this repo https://github.com/github/explore > > Done! > > https://github.com/github/explore/pull/409 > > Esteban A. Maringolo

Oct. 10, 2018

Re: [Pharo-dev] GitHub Topics

by Esteban Maringolo

PR approved! We're listed at https://github.com/topics/pharo [image: image.png] Esteban A. Maringolo Esteban A. Maringolo El mar., 9 oct. 2018 a las 22:31, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > El mar., 9 oct. 2018 a las 18:30, Peter Uhnak (<i.uhnak(a)gmail.com>) > escribiÃ³: > > > >> Maybe there is a minimum threshold required to enable such edits. > > issue a pull request to this repo https://github.com/github/explore > > Done! > > https://github.com/github/explore/pull/409 > > Esteban A. Maringolo >

Oct. 10, 2018

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Julien

Sorry, I forgot to answer. This change is indeed really nice. Thank you for it! Cheers, Julien --- Julien Delplanque Doctorant Ã lâUniversitÃ© de Lille http://juliendelplanque.be/phd.html Equipe Rmod, Inria BÃ¢timent B 40, Avenue Halley 59650 Villeneuve d'Ascq NumÃ©ro de tÃ©lÃ©phone: +333 59 35 86 40 > Le 9 oct. 2018 Ã 21:22, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > I decided to add it for real: > > https://github.com/svenvc/ston/commit/9c83e3cc2f00cab83e57f2e10a139d6ecef3c… > > add support for Fraction and ScaledDecimal as direct numeric literals (in STON mode, not in JSON mode) with units tests > >> On 25 Sep 2018, at 14:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 18 Sep 2018, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Of course, we could also extend the basic number parser and allow the native (stored) notation >>> >>> 1/3 >>> 3/2s2 >>> >>> Note how that last one should use the more exact #storeOn: notation, not the #printOn: >>> >>> I'll have to think about this a bit more, as I can really not choose right now. >> >> I am still not sure if we should do this or not, but here is a POC implementation of the above. >> >> It implements the following syntax extension (see the class comment of STON for the rest). >> >> number >> int >> int denominator >> int denominator scale >> int frac >> int exp >> int frac exp >> >> denominator >> / digits >> >> scale >> s digits >> >> >> STONWriter>>#writeFraction: fraction >> jsonMode >> ifTrue: [ self writeFloat: fraction asFloat ] >> ifFalse: [ >> writeStream >> print: fraction numerator; >> nextPut: $/; >> print: fraction denominator ] >> >> STONWriter>>#writeScaledDecimal: scaledDecimal >> jsonMode >> ifTrue: [ self writeFloat: scaledDecimal asFloat ] >> ifFalse: [ >> writeStream >> print: scaledDecimal numerator; >> nextPut: $/; >> print: scaledDecimal denominator; >> nextPut: $s; >> print: scaledDecimal scale ] >> >> Fraction>>#stonOn: stonWriter >> stonWriter writeFraction: self >> >> ScaledDecimal>>#stonOn: stonWriter >> stonWriter writeScaledDecimal: self >> >> STONReader>>parseNumber >> | negated number | >> negated := readStream peekFor: $-. >> number := self parseNumberInteger. >> (readStream peekFor: $/) >> ifTrue: [ >> number := Fraction numerator: number denominator: self parseNumberInteger. >> (readStream peekFor: $s) >> ifTrue: [ number := ScaledDecimal newFromNumber: number scale: self parseNumberInteger ] ] >> ifFalse: [ >> (readStream peekFor: $.) >> ifTrue: [ number := number + self parseNumberFraction ]. >> ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) >> ifTrue: [ number := number * self parseNumberExponent ] ]. >> negated >> ifTrue: [ number := number negated ]. >> self consumeWhitespace. >> ^ number >> >> Sven >> > >

Oct. 10, 2018

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Norbert Hartl

Very cool. Thank you very much, Can you make releases for your repos? In my repos I did a release of a version saying it is the same as the last on smalltalkhub. So people can pinpoint to a specific release. I think this is a good way of doing it. Norbert > Am 05.10.2018 um 14:05 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. > So far I did the following: > > https://github.com/svenvc/NeoJSON > https://github.com/svenvc/NeoCSV > https://github.com/svenvc/ztimestamp > https://github.com/svenvc/P3 > https://github.com/svenvc/stamp > https://github.com/svenvc/SimpleRedisClient > https://github.com/svenvc/NeoConsole > > More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. > > The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. > By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. > > After a while I will switch the Catalog entries and declare these repo the main ones. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

Oct. 10, 2018

Re: [Pharo-dev] GitHub Topics

by Esteban Maringolo

El mar., 9 oct. 2018 a las 18:30, Peter Uhnak (<i.uhnak(a)gmail.com>) escribiÃ³: > >> Maybe there is a minimum threshold required to enable such edits. > issue a pull request to this repo https://github.com/github/explore Done! https://github.com/github/explore/pull/409 Esteban A. Maringolo

Oct. 10, 2018

Re: [Pharo-dev] GitHub Topics

by Peter Uhnak

> So at least 'Pharo' (capitalised) should be there. all topics are forcibly lowercased > I will check because I did not see that we could tag our project. > Personally I will use Pharo because of reasons that you know. For repositories that you control you can see a "button" at the top [image: image.png] Maybe there is a minimum threshold required to enable such edits. > issue a pull request to this repo https://github.com/github/explore Peter

Oct. 9, 2018

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Stephane Ducasse

This is cool because indeed scaledDecimal are nice objects :) On Tue, Oct 9, 2018 at 9:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I decided to add it for real: > > https://github.com/svenvc/ston/commit/9c83e3cc2f00cab83e57f2e10a139d6ecef3c… > > add support for Fraction and ScaledDecimal as direct numeric literals (in STON mode, not in JSON mode) with units tests > > > On 25 Sep 2018, at 14:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > > >> On 18 Sep 2018, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Of course, we could also extend the basic number parser and allow the native (stored) notation > >> > >> 1/3 > >> 3/2s2 > >> > >> Note how that last one should use the more exact #storeOn: notation, not the #printOn: > >> > >> I'll have to think about this a bit more, as I can really not choose right now. > > > > I am still not sure if we should do this or not, but here is a POC implementation of the above. > > > > It implements the following syntax extension (see the class comment of STON for the rest). > > > > number > > int > > int denominator > > int denominator scale > > int frac > > int exp > > int frac exp > > > > denominator > > / digits > > > > scale > > s digits > > > > > > STONWriter>>#writeFraction: fraction > > jsonMode > > ifTrue: [ self writeFloat: fraction asFloat ] > > ifFalse: [ > > writeStream > > print: fraction numerator; > > nextPut: $/; > > print: fraction denominator ] > > > > STONWriter>>#writeScaledDecimal: scaledDecimal > > jsonMode > > ifTrue: [ self writeFloat: scaledDecimal asFloat ] > > ifFalse: [ > > writeStream > > print: scaledDecimal numerator; > > nextPut: $/; > > print: scaledDecimal denominator; > > nextPut: $s; > > print: scaledDecimal scale ] > > > > Fraction>>#stonOn: stonWriter > > stonWriter writeFraction: self > > > > ScaledDecimal>>#stonOn: stonWriter > > stonWriter writeScaledDecimal: self > > > > STONReader>>parseNumber > > | negated number | > > negated := readStream peekFor: $-. > > number := self parseNumberInteger. > > (readStream peekFor: $/) > > ifTrue: [ > > number := Fraction numerator: number denominator: self parseNumberInteger. > > (readStream peekFor: $s) > > ifTrue: [ number := ScaledDecimal newFromNumber: number scale: self parseNumberInteger ] ] > > ifFalse: [ > > (readStream peekFor: $.) > > ifTrue: [ number := number + self parseNumberFraction ]. > > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > > ifTrue: [ number := number * self parseNumberExponent ] ]. > > negated > > ifTrue: [ number := number negated ]. > > self consumeWhitespace. > > ^ number > > > > Sven > > > >

Oct. 9, 2018

Re: [Pharo-dev] GitHub Topics

by Esteban Maringolo

What I don't know is how to suggest edits to the Pharo topic, so we can also add a logo to it, reference to pharo.org, etc. Maybe there is a minimum threshold required to enable such edits. Esteban A. Maringolo El mar., 9 oct. 2018 a las 16:57, Stephane Ducasse (<stepharo.self(a)gmail.com>) escribiÃ³: > > Hi sven > > I will check because I did not see that we could tag our project. > Personally I will use Pharo because of reasons that you know. > > Stef > On Mon, Oct 8, 2018 at 11:32 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > One of the goals of moving to GitHub.com is to gain visibility. > > > > There is https://github.com/topics > > > > I think we should standardise how we tag our projects. > > > > So at least 'Pharo' (capitalised) should be there. > > > > Do we also add 'Smalltalk' by default ? > > > > Any other suggestions, ideas ? > > > > Sven > > >

Oct. 9, 2018

Re: [Pharo-dev] GitHub Topics

by Stephane Ducasse

Hi sven I will check because I did not see that we could tag our project. Personally I will use Pharo because of reasons that you know. Stef On Mon, Oct 8, 2018 at 11:32 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > One of the goals of moving to GitHub.com is to gain visibility. > > There is https://github.com/topics > > I think we should standardise how we tag our projects. > > So at least 'Pharo' (capitalised) should be there. > > Do we also add 'Smalltalk' by default ? > > Any other suggestions, ideas ? > > Sven >

Oct. 9, 2018

Re: [Pharo-dev] Fraction and ScaledDecimal should be not be serialized as Float in STON format

by Sven Van Caekenberghe

I decided to add it for real: https://github.com/svenvc/ston/commit/9c83e3cc2f00cab83e57f2e10a139d6ecef3c… add support for Fraction and ScaledDecimal as direct numeric literals (in STON mode, not in JSON mode) with units tests > On 25 Sep 2018, at 14:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 18 Sep 2018, at 16:45, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Of course, we could also extend the basic number parser and allow the native (stored) notation >> >> 1/3 >> 3/2s2 >> >> Note how that last one should use the more exact #storeOn: notation, not the #printOn: >> >> I'll have to think about this a bit more, as I can really not choose right now. > > I am still not sure if we should do this or not, but here is a POC implementation of the above. > > It implements the following syntax extension (see the class comment of STON for the rest). > > number > int > int denominator > int denominator scale > int frac > int exp > int frac exp > > denominator > / digits > > scale > s digits > > > STONWriter>>#writeFraction: fraction > jsonMode > ifTrue: [ self writeFloat: fraction asFloat ] > ifFalse: [ > writeStream > print: fraction numerator; > nextPut: $/; > print: fraction denominator ] > > STONWriter>>#writeScaledDecimal: scaledDecimal > jsonMode > ifTrue: [ self writeFloat: scaledDecimal asFloat ] > ifFalse: [ > writeStream > print: scaledDecimal numerator; > nextPut: $/; > print: scaledDecimal denominator; > nextPut: $s; > print: scaledDecimal scale ] > > Fraction>>#stonOn: stonWriter > stonWriter writeFraction: self > > ScaledDecimal>>#stonOn: stonWriter > stonWriter writeScaledDecimal: self > > STONReader>>parseNumber > | negated number | > negated := readStream peekFor: $-. > number := self parseNumberInteger. > (readStream peekFor: $/) > ifTrue: [ > number := Fraction numerator: number denominator: self parseNumberInteger. > (readStream peekFor: $s) > ifTrue: [ number := ScaledDecimal newFromNumber: number scale: self parseNumberInteger ] ] > ifFalse: [ > (readStream peekFor: $.) > ifTrue: [ number := number + self parseNumberFraction ]. > ((readStream peekFor: $e) or: [ readStream peekFor: $E ]) > ifTrue: [ number := number * self parseNumberExponent ] ]. > negated > ifTrue: [ number := number negated ]. > self consumeWhitespace. > ^ number > > Sven >

Oct. 9, 2018

[Pharo 7.0-dev] Build #1324: 22563-GTInspector-can-loop-on-WindowPresenter

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

There is a new Pharo build available! The status of the build #1324 was: SUCCESS. The Pull Request #1898 was integrated: "22563-GTInspector-can-loop-on-WindowPresenter" Pull request url: https://github.com/pharo-project/pharo/pull/1898 Issue Url: https://pharo.fogbugz.com/f/cases/22563 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2018

[Pharo 7.0-dev] Build #1323: 22534-split-Refactoring2-package-to-extract-Tests

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

There is a new Pharo build available! The status of the build #1323 was: SUCCESS. The Pull Request #1871 was integrated: "22534-split-Refactoring2-package-to-extract-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1871 Issue Url: https://pharo.fogbugz.com/f/cases/22534 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2018

[Pharo 7.0-dev] Build #1322: 22548-Typo-in-FractionTestclassst

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

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

Oct. 9, 2018

[Pharo 7.0-dev] Build #1321: 22554-GlamourPresentationModel-has-a-name-out-of-synch-with-the-current-spec

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

There is a new Pharo build available! The status of the build #1321 was: SUCCESS. The Pull Request #1891 was integrated: "22554-GlamourPresentationModel-has-a-name-out-of-synch-with-the-current-spec" Pull request url: https://github.com/pharo-project/pharo/pull/1891 Issue Url: https://pharo.fogbugz.com/f/cases/22554 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2018

[Pharo 7.0-dev] Build #1320: 22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector

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

There is a new Pharo build available! The status of the build #1320 was: FAILURE. The Pull Request #1889 was integrated: "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/1889 Issue Url: https://pharo.fogbugz.com/f/cases/22553 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2018

[Pharo 7.0-dev] Build #1319: 22556-Reverting-slots-to-return-the-set-of-installed-slots-in-the-class-

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

There is a new Pharo build available! The status of the build #1319 was: FAILURE. The Pull Request #1892 was integrated: "22556-Reverting-slots-to-return-the-set-of-installed-slots-in-the-class-" Pull request url: https://github.com/pharo-project/pharo/pull/1892 Issue Url: https://pharo.fogbugz.com/f/cases/22556 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 9, 2018

[Pharo 7.0-dev] Build #1318: 22492-Self-Hosted Gitlab support

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

There is a new Pharo build available! The status of the build #1318 was: SUCCESS. The Pull Request #1828 was integrated: "22492-Self-Hosted Gitlab support" Pull request url: https://github.com/pharo-project/pharo/pull/1828 Issue Url: https://pharo.fogbugz.com/f/cases/self_hosted_gitlab Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 8, 2018

Re: [Pharo-dev] GitHub Topics

by Cyril Ferlicot

On Mon, Oct 8, 2018 at 11:32 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > One of the goals of moving to GitHub.com is to gain visibility. > > There is https://github.com/topics > > I think we should standardise how we tag our projects. > > So at least 'Pharo' (capitalised) should be there. > > Do we also add 'Smalltalk' by default ? > > Any other suggestions, ideas ? > Hi Sven, I think topics are case insensitive. Personally I tagged all my projects with "pharo" and "smalltalk", then I add tags depending on the subject of the project. > Sven > -- Cyril Ferlicot https://ferlicot.fr

Oct. 8, 2018

GitHub Topics

by Sven Van Caekenberghe

One of the goals of moving to GitHub.com is to gain visibility. There is https://github.com/topics I think we should standardise how we tag our projects. So at least 'Pharo' (capitalised) should be there. Do we also add 'Smalltalk' by default ? Any other suggestions, ideas ? Sven

Oct. 8, 2018

[Pharo 7.0-dev] Build #1317: 22545-The-64-bit-image-does-not-have-the-correct-display-size-again

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

There is a new Pharo build available! The status of the build #1317 was: SUCCESS. The Pull Request #1884 was integrated: "22545-The-64-bit-image-does-not-have-the-correct-display-size-again" Pull request url: https://github.com/pharo-project/pharo/pull/1884 Issue Url: https://pharo.fogbugz.com/f/cases/22545 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 8, 2018

[Pharo 7.0-dev] Build #1316: 22541 Tag and comment ManifestGTSpotter

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

There is a new Pharo build available! The status of the build #1316 was: SUCCESS. The Pull Request #1879 was integrated: "22541 Tag and comment ManifestGTSpotter" Pull request url: https://github.com/pharo-project/pharo/pull/1879 Issue Url: https://pharo.fogbugz.com/f/cases/22541 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 8, 2018

Esteban's ChangeLog week of 1 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 1 October 2018 to 7 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=1/10/2018&to=7/10/2018 ChangeLog ========= 5 October 2018: --------------- * I made a couple of backports to Pharo 6.1 * [case: 22517](https://pharo.fogbugz.com/f/cases/22517) : Update ProfStef and fix spelling mistakes * [case: 22535](https://pharo.fogbugz.com/f/cases/22535) : Backport Tonel v1.0.9 to Pharo 6.1 * I finished a "simple" [PR for Calypso](https://github.com/pharo-ide/Calypso/pull/330): It was about better exposing the usage of certain command when using the +cmd+/+ Calypso-Spotter help. Now, this was not obvious because this correspons to a command nobody is using it yet, but it will become important as we enhance discoverability of it :) 2 October 2018: --------------- * Well... I spent the full day debugging on smalltalkCI to send a [new fix](https://github.com/hpi-swa/smalltalkCI/pull/399) to allow the load of projects with packages already installed in the image. This is very useful for us, developing Pharo and their components. * Spec * Calypso * Iceberg * Zinc * etc. And maybe it will be useful for others in the future. cheers! Esteban

Oct. 8, 2018

Re: [Pharo-dev] [squeak-dev] DelayIdleScheduler experiment

by Ben Coman

Hi Tim, Thanks for your feedback On Mon, 8 Oct 2018 at 01:27, tim Rowledge <tim(a)rowledge.org> wrote: > I may be out of date on this but I think that the Cog setup makes it > possible to have a timer check every 2mS by default. The > relinquishProcessor stuff was a definite hack to try to reduce cpu usage on > laptoppy things and I don't think anyone ever expected it to be used for > more than 1mS sleeps. It was one of those "I wonder if this will improve > anything?" ideas that got left in place. > > Surely the ideal would be to > a) as you point out, add this delay to the main delay list > Its not a separate delay. The "activeDelay" is split into separate pieces relinquished around asynchronous I/O like mouse, etc. b) find a way to provide an outside timer to trigger the delay at the top > of the list rather than relying on the vm eventually checking the tick etc. > The key thing is to inform the VM that there are no runnable processes and pause the main-native-thread and heartbeat-thread until the next image-scheduled wakeup time. One alternative may be to adapt #primSignal:atUTCMicroseconds: to be #primSignal:atUTCMicroseconds:idle: > > Interestingly, we have the threaded ticker for many systems as part of the > Cog vm. I don't know if it works on all systems; I do know it would be > 'interesting' to implement on RISC OS, but that's life. A quick look at > unix/sqUnixHeartbeat.c suggests to me that it might be plausible to use > variable length beats Q: does the main-native-thread stop running if the heatbeat stops? > and tie the time to any sooner-than-2mS event wanted. We'd (probably) change Delay handling to behave as if there were always a 1 > or 2mS (fake)delay even if the nearest actual Delay were far beyond that. > I can't follow where you are going with that. If your on a cloud server, you may want to idle for minutes or hours without processing delays, and restarting delays when I/O comes in. cheers -ben > > > On 2018-10-07, at 1:11 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > Cross posting since at this level systems are still very similar. > > > > I've sometimes wondered about how the idle process > > relinquishing the CPU interacted with delay scheduling, > > since they operate at the extreme opposite ends of process priorities. > > > > Historically there was... > > ProcessorScheduler class >> idleProcess > > [ "A default background process which is invisible." > > [true] whileTrue: > > [self relinquishProcessorForMicroseconds: 1000] > > > > which had the following performance this for later comparison... > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==> "#(2 5 4 2 4 4 2 4 4 3)" > > > > To improve battery life yield time Pharo changed this to 50000 in... > > * > https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-… > > * https://github.com/pharo-project/pharo/commit/0b0d12dc > > but had a negative impact on delays... > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==> "#(36 51 50 51 50 51 51 30 50 50)" > > as reported... > https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly > > > > The problem seems to be that #relinquishProcessorForMicroseconds: > suspends the main VM thread for a fixed amount during which expired delays > cannot be dealt with. I'm not sure of the exact mechanism in the VM but > this looks related... > > Win: > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/wi… > > Mac: > https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/un… > > I'm not sure about Linux > > > > One idea was to have a setting, but another path is to mix the > idle-relinquish > > into the delay-scheduling to dynamically relinquish up to exactly when > the activeDelay expires. > > > > After loading... > > https://github.com/pharo-project/pharo/pull/1887 > > you can do... > > DelayIdleTicker installExperiment. > > (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] > timeToRun asMilliSeconds]. > > ==>"#(1 1 2 2 2 2 2 2 2 2)" which btw is half the latency of the original > > DelayIdleTicker debug: true. "CPU usage goes way up" > > DelayIdleTicker uninstall. > > > > I'm now seeking: > > * comment on how this might interact with parts of the VM I'm not > familiar with. > > * help to discover and stress test corner cases. > > * help to determine if there actually is a benefit and characterize what > that is, > > especially anyone familiar with headless images with reduced UI and I/O > events. > > I was surprised to see the existing system already often showed 0% CPU > usage (in Windows). > > > > cheers -ben > > > > > tim > -- > tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim > Bayard(n): a person armed with the self-confidence of ignorance > > >

Oct. 7, 2018

[Pharo 7.0-dev] Build #1315: 22539 Tag ManifestRPackageCore and related classes in RPackage-Core

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

There is a new Pharo build available! The status of the build #1315 was: SUCCESS. The Pull Request #1877 was integrated: "22539 Tag ManifestRPackageCore and related classes in RPackage-Core" Pull request url: https://github.com/pharo-project/pharo/pull/1877 Issue Url: https://pharo.fogbugz.com/f/cases/22539 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2018

[Pharo 7.0-dev] Build #1314: 20344-DualChangeSorter-shows-debug-context-menu

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

There is a new Pharo build available! The status of the build #1314 was: SUCCESS. The Pull Request #1881 was integrated: "20344-DualChangeSorter-shows-debug-context-menu" Pull request url: https://github.com/pharo-project/pharo/pull/1881 Issue Url: https://pharo.fogbugz.com/f/cases/20344 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2018

[Pharo 7.0-dev] Build #1313: 22546 Tag classes in FuzzyMatcher-Tests

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

There is a new Pharo build available! The status of the build #1313 was: SUCCESS. The Pull Request #1885 was integrated: "22546 Tag classes in FuzzyMatcher-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1885 Issue Url: https://pharo.fogbugz.com/f/cases/22546 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2018

[Pharo 7.0-dev] Build #1312: 22544 Comment File package

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

There is a new Pharo build available! The status of the build #1312 was: FAILURE. The Pull Request #1883 was integrated: "22544 Comment File package" Pull request url: https://github.com/pharo-project/pharo/pull/1883 Issue Url: https://pharo.fogbugz.com/f/cases/22544 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 7, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Esteban Lorenzano

Hi, > On 5 Oct 2018, at 19:03, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi monty > > I ****really**** think that we should move to github. > I mean really. Let us use a pro VCS - I do not like much git but > Iceberg improves the > feeling. It is not just that is a modern vcs tool. I already talked a lot about the technical advantages of using git. But let me put the accent now in some ânon technicalâ reasons: - Imagine if we migrate to github all the projects at sthub, ss, ss3, etcâ¦ There are thousands of projects there (yes, many od them are dead code, but is the same about most of the projects on GitHub too): we will be making something to help re-place Smalltalk in the map (is not of course ensured, but is a small contribution to gain a visibility we do not have now. - you know a lot of companies look at the GitHub profiles of applicants these days, to see how they work on open source projects, etc. Which means having GitHub exposure will also help people willing to start with Pharo (or Smalltalk in general) and do not do it because that will not help them to get a job. One important reason why we selected GitHub and not another provider (personally I prefer GitLab, for example) is precisely that: increase visibility and lower the artificial barriers to adopt Pharo.And of course, this is just a small thing among the huge amount of things to do, but that does not means is not an important one. Esteban > > Stef > On Wed, Oct 3, 2018 at 8:28 AM monty <monty2(a)programmer.net> wrote: >> >> It would also prefer an SS3-based STHub, at least as an alternative to GitHub. >> ___ >> montyos.wordpress.com >> >> >>> Sent: Saturday, September 29, 2018 at 6:43 AM >>> From: "Stephane Ducasse" <stepharo.self(a)gmail.com> >>> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> >>> Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ >>> >>> Hi Sven >>> >>> SmalltalkHub is dying. And we will turn it readonly by January. >>> Esteban has something else to do that to take care of it. It is a legacy. >>> We are about to announce that we cannot create account and projects anymore. >>> We are waiting to do that after the mooc. >>> Now you want to use Squeaksource or SS3 I do not want. >>> I want to use github and I guess that I do not have to explain why for real. >>> >>> Stef >>> >>> On Sat, Sep 29, 2018 at 11:27 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> I think that would be monty, email addresses (CC-ed) >>>> >>>> monty2(a)programmer.net >>>> >>>> I should note that he has been very good at maintaining the XML packages (the specs of which are super complex), and as far as I know, the code works under Pharo 7 ... >>>> >>>> What does not work for you ? >>>> >>>> Sven >>>> >>>>> On 29 Sep 2018, at 10:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>>> >>>>> Hi >>>>> >>>>> I contacted the maintainer (but I'm not sure in fact who it is :) ) >>>>> about the XML related packages in Pharo extras. >>>>> >>>>> XMLParser >>>>> XMLParserHTML >>>>> XMLParserStAX >>>>> XMLSupport >>>>> XMLWriter >>>>> XPath >>>>> >>>>> I did not get any answer so may be I sent a mail to the wrong email address. >>>>> Probably. >>>>> Now the question still remains: who is planning to migrate the XML packages. >>>>> I was planning to do it but I will not consider history because I do >>>>> not know how to do it and I do not have the time to do it (sorry). And >>>>> yes I work the weekends and this is bad and this is not even on Pharo. >>>>> >>>>> I was planning to spend some time on the baseline and making sure that >>>>> we can load everything and run the tests. >>>>> So let me know. >>>>> >>>>> Stef >>>>> >>>> >>>> >>> >>> >> >

Oct. 7, 2018

DelayIdleScheduler experiment

by Ben Coman

Cross posting since at this level systems are still very similar. I've sometimes wondered about how the idle process relinquishing the CPU interacted with delay scheduling, since they operate at the extreme opposite ends of process priorities. Historically there was... ProcessorScheduler class >> idleProcess [ "A default background process which is invisible." [true] whileTrue: [self relinquishProcessorForMicroseconds: 1000] which had the following performance this for later comparison... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(2 5 4 2 4 4 2 4 4 3)" To improve battery life yield time Pharo changed this to 50000 in... * https://pharo.fogbugz.com/f/cases/20425/Yield-longer-in-ProcessorScheduler-… * https://github.com/pharo-project/pharo/commit/0b0d12dc but had a negative impact on delays... (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==> "#(36 51 50 51 50 51 51 30 50 50)" as reported... https://pharo.fogbugz.com/f/cases/22400/Delays-are-not-working-properly The problem seems to be that #relinquishProcessorForMicroseconds: suspends the main VM thread for a fixed amount during which expired delays cannot be dealt with. I'm not sure of the exact mechanism in the VM but this looks related... Win: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/e2fa2d1/platforms/wi… Mac: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/a8a1dc1/platforms/un… I'm not sure about Linux One idea was to have a setting, but another path is to mix the idle-relinquish into the delay-scheduling to dynamically relinquish up to exactly when the activeDelay expires. After loading... https://github.com/pharo-project/pharo/pull/1887 you can do... DelayIdleTicker installExperiment. (1 to: 10) collect: [:i | [ (Delay forMilliseconds: 1) wait ] timeToRun asMilliSeconds]. ==>"#(1 1 2 2 2 2 2 2 2 2)" which btw is half the latency of the original DelayIdleTicker debug: true. "CPU usage goes way up" DelayIdleTicker uninstall. I'm now seeking: * comment on how this might interact with parts of the VM I'm not familiar with. * help to discover and stress test corner cases. * help to determine if there actually is a benefit and characterize what that is, especially anyone familiar with headless images with reduced UI and I/O events. I was surprised to see the existing system already often showed 0% CPU usage (in Windows). cheers -ben

Oct. 7, 2018

[Pharo 7.0-dev] Build #1311: 22542 Tag and comment ManifestGTDebugger

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

There is a new Pharo build available! The status of the build #1311 was: SUCCESS. The Pull Request #1880 was integrated: "22542 Tag and comment ManifestGTDebugger" Pull request url: https://github.com/pharo-project/pharo/pull/1880 Issue Url: https://pharo.fogbugz.com/f/cases/22542 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 6, 2018

Re: [Pharo-dev] Conversion of my Libraries/Frameworks to GitHub/Tonel/TravisCI, Part 1

by Stephane Ducasse

Excellent! Tx Sven. I love Tonel :). I'm super happy because I dreamt about bootstrap in 2001 and Tonel also and now we get them. On Fri, Oct 5, 2018 at 2:06 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I started converting my Libraries/Frameworks to GitHub/Tonel/TravisCI. > So far I did the following: > > https://github.com/svenvc/NeoJSON > https://github.com/svenvc/NeoCSV > https://github.com/svenvc/ztimestamp > https://github.com/svenvc/P3 > https://github.com/svenvc/stamp > https://github.com/svenvc/SimpleRedisClient > https://github.com/svenvc/NeoConsole > > More will follow, in particular Zinc/Zodiac and STON, both of which are more complex. > > The TravisCI builds now run for Pharo 7 (32 & 64 bits) and Pharo 6.1. > By loading the latest Metacello and Tonel, the code is also loadable in Pharo 6 or 5. > > After a while I will switch the Catalog entries and declare these repo the main ones. > > Sven > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

Oct. 6, 2018

Re: [Pharo-dev] Slowness when loading code in Pharo 7?

by Alexandre Bergel

Shouldnât the Metacello>>load be updated to disable EpMonitor? It seems to be an easy fix no? Alexandre > On Oct 2, 2018, at 11:31 PM, Juraj Kubelka via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Juraj Kubelka <juraj.kubelka(a)icloud.com> > Subject: Re: [Pharo-dev] Slowness when loading code in Pharo 7? > Date: October 2, 2018 at 11:31:59 PM GMT-3 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hi Martin, > > By disabling EpMonitor, the slowdown disappears. > > EpMonitor current disable. > [ Metacello new > baseline: 'GToolkit'; > repository: 'github://feenkcom/gtoolkit/src'; > load. > ] timeToRun "0:00:08:03.504â > > > Cheers, > Juraj > >> On Oct 2, 2018, at 18:14, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Hi Andrei. You can evaluate "EpMonitor current disable" before loading >> to compare times. >> El mar., 2 de oct. de 2018 a la(s) 11:18, Andrei Chis >> (chisvasileandrei(a)gmail.com) escribiÃ³: >>> >>> Hi, >>> >>> Are there any know slowdowns when loading code in Pharo 7? Usually on my machine (Mac - HighSierra) loading GToolkit in a Pharo 6.1 images takes around 9 minutes. In the latest Pharo 7 it takes 20 minutes. On two other newer laptops running Mac results are similar (15 minutes on Pharo 7 64it, and 7 minutes on Pharo 6.1 64bit). >>> >>> We have the impression that most of the times, the regression happens because of reading sources file. And the sources files are read because of checking Epicea method changes. We have not done a deep research on it, just whenever we do CMD+. it stops in that stage. >>> >>> Cheers, >>> Andrei >> > > > >

Oct. 5, 2018

Re: [Pharo-dev] Slowness when loading code in Pharo 7?

by Andrei Chis

Hi, In my case I get: pharo 61 * disabled: 0:00:09:39.43 * enabled: 0:00:10:25.173" pharo 70 * disabled: 0:00:12:44.701 * enabled: 0:00:21:21.285 Each time in a clean folder with a new image. All tests are with the current stable vm on High Sierra. Cheers, Andrei On Thu, Oct 4, 2018 at 8:23 AM <tinchodias(a)gmail.com> wrote: > On Wed, 2018-10-03 at 20:08 +0200, Peter Uhnak wrote: > > > > > > On Wed, Oct 3, 2018 at 7:31 PM Juraj Kubelka via Pharo-dev <pharo-dev > > @lists.pharo.org> wrote: > > > Hi! > > > > > > I did the same measurement for Pharo 6.1. To summarize it I have > > > those results: > > > > > > By executing: > > > > > > -=-=-=- > > > EpMonitor current disable. > > > [ Metacello new > > > baseline: 'GToolkit'; > > > repository: 'github://feenkcom/gtoolkit/src'; > > > load. > > > ] timeToRun > > > -=-=-=- > > > > > > Pharo 6.1 64bit macOS: 6 minutes > > > Pharo 7.0 64bit macOS: 8 minutes > > > > > > With EpMonitor current enabled it is: > > > > > > Pharo 6.1 64bit macOS: 7 minutes > > > Pharo 7.0 64bit macOS: 15 minutes > > > > > > > So nice... I was just trying to install GToolkit in P6.1 on Windows > > (but with updated Iceberg)... it took over 1.5 hours (SmaCC was > > probably 30 minutes by itself), and then the image crashed... really > > looking forward to pre-made images :) > > > > Peter > > I ran the attached script on my debian 64 bits (disk: slow HDD w/ext4, > cpu: i5 ram: 12gb). Here, the slowdown from 61 to 70 is not as evident > as in your cases. > > It's only me? It can help if others can run the script and report your > results in other computers and OSs. > > Two output examples: > --- > > pharo 61 > * disabled: > 0:00:07:30.783 > * enabled: > 0:00:08:27.931 > > pharo 70 > * disabled: > 0:00:08:24.403 > * enabled: > 0:00:09:12.858 > > --- > > pharo 61 > * disabled: > 0:00:08:16.036 > * enabled: > 0:00:09:21.368 > > pharo 70 > * disabled: > 0:00:08:06.57 > * enabled: > 0:00:10:05.194 > > --- > > pharo 61 > * disabled: > 0:00:07:39.538 > * enabled: > 0:00:08:33.778 > > pharo 70 > * disabled: > 0:00:07:23.528 > * enabled: > 0:00:09:11.453 > > --- > Note: the script removes pharo-local/ before loading the code to > download again everything (and I don't have configured a central repo > in personal settings or something like that). It should be more fair to > compare to have locally cached as much as possible. I tried once and it > was reducing a couple of minutes, but the conclusion was the same. > > Additionally: In both 61 and 70, I browsed the resulting ombu file > (>110 mb), it was not thaat bad... > ~5 seconds when I clicked on the file, and then almost no delay on > scroll and when clicking on a particular change. > > But: The problem was when I clicked on a filter and it started to parse > each change... I waited like 10 minutes and then closed it. No visual > feedback, and looks too inefficient. > > > MartÃn

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by tesonep＠gmail.com

Thanks a lot, I will check it in this days. On Fri, 5 Oct 2018, 20:28 Andrei Chis, <chisvasileandrei(a)gmail.com> wrote: > Done: > https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-ne… > > Cheers, > Andrei > > On Fri, Oct 5, 2018 at 8:15 PM tesonep(a)gmail.com <tesonep(a)gmail.com> > wrote: > >> Hi Andrei, would you mind opening an issue for this, making a comment in >> a merged PR does not help to see it. >> >> Thanks >> >> On Fri, 5 Oct 2018, 20:09 Andrei Chis, <chisvasileandrei(a)gmail.com> >> wrote: >> >>> Now I found the comment from >>> https://github.com/pharo-project/pharo/pull/1618. >>> Will add a comment there. >>> >>> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis <chisvasileandrei(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> Executed in the latest Pharo 7 image >>>> (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 >>>> (64 Bit)) the code below blocks the image (both with latest and stable vm >>>> on MacOs HighSierra). The vm does not crash but gets into a "Not >>>> Responding" state and does not get out: >>>> >>>> Class new >>>> superclass: GLMTransmission; >>>> setFormat: GLMTransmission format; >>>> classLayout: GLMTransmission classLayout copy; >>>> yourself >>>> >>>> Code like this is used in Moose in some tests and in SmaCC in the >>>> rewrite engine: >>>> >>>> Class new >>>> superclass: SmaCCRewriteMatchContext; >>>> setFormat: SmaCCRewriteMatchContext format; >>>> classLayout: SmaCCRewriteMatchContext classLayout copy; >>>> yourself. >>>> >>>> This worked in Pharo 6. Bug or here should be a different way to do >>>> this? >>>> >>>> Cheers, >>>> Andrei >>>> >>>

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

Done: https://pharo.fogbugz.com/f/cases/22547/Creating-a-new-class-using-Class-ne… Cheers, Andrei On Fri, Oct 5, 2018 at 8:15 PM tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi Andrei, would you mind opening an issue for this, making a comment in a > merged PR does not help to see it. > > Thanks > > On Fri, 5 Oct 2018, 20:09 Andrei Chis, <chisvasileandrei(a)gmail.com> wrote: > >> Now I found the comment from >> https://github.com/pharo-project/pharo/pull/1618. >> Will add a comment there. >> >> On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis <chisvasileandrei(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> Executed in the latest Pharo 7 image >>> (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 >>> (64 Bit)) the code below blocks the image (both with latest and stable vm >>> on MacOs HighSierra). The vm does not crash but gets into a "Not >>> Responding" state and does not get out: >>> >>> Class new >>> superclass: GLMTransmission; >>> setFormat: GLMTransmission format; >>> classLayout: GLMTransmission classLayout copy; >>> yourself >>> >>> Code like this is used in Moose in some tests and in SmaCC in the >>> rewrite engine: >>> >>> Class new >>> superclass: SmaCCRewriteMatchContext; >>> setFormat: SmaCCRewriteMatchContext format; >>> classLayout: SmaCCRewriteMatchContext classLayout copy; >>> yourself. >>> >>> This worked in Pharo 6. Bug or here should be a different way to do this? >>> >>> Cheers, >>> Andrei >>> >>

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by tesonep＠gmail.com

Hi Andrei, would you mind opening an issue for this, making a comment in a merged PR does not help to see it. Thanks On Fri, 5 Oct 2018, 20:09 Andrei Chis, <chisvasileandrei(a)gmail.com> wrote: > Now I found the comment from > https://github.com/pharo-project/pharo/pull/1618. > Will add a comment there. > > On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> Hi, >> >> Executed in the latest Pharo 7 image >> (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 >> (64 Bit)) the code below blocks the image (both with latest and stable vm >> on MacOs HighSierra). The vm does not crash but gets into a "Not >> Responding" state and does not get out: >> >> Class new >> superclass: GLMTransmission; >> setFormat: GLMTransmission format; >> classLayout: GLMTransmission classLayout copy; >> yourself >> >> Code like this is used in Moose in some tests and in SmaCC in the rewrite >> engine: >> >> Class new >> superclass: SmaCCRewriteMatchContext; >> setFormat: SmaCCRewriteMatchContext format; >> classLayout: SmaCCRewriteMatchContext classLayout copy; >> yourself. >> >> This worked in Pharo 6. Bug or here should be a different way to do this? >> >> Cheers, >> Andrei >> >

Oct. 5, 2018

Re: [Pharo-dev] Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

Now I found the comment from https://github.com/pharo-project/pharo/pull/1618. Will add a comment there. On Fri, Oct 5, 2018 at 7:48 PM Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > Hi, > > Executed in the latest Pharo 7 image > (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 > (64 Bit)) the code below blocks the image (both with latest and stable vm > on MacOs HighSierra). The vm does not crash but gets into a "Not > Responding" state and does not get out: > > Class new > superclass: GLMTransmission; > setFormat: GLMTransmission format; > classLayout: GLMTransmission classLayout copy; > yourself > > Code like this is used in Moose in some tests and in SmaCC in the rewrite > engine: > > Class new > superclass: SmaCCRewriteMatchContext; > setFormat: SmaCCRewriteMatchContext format; > classLayout: SmaCCRewriteMatchContext classLayout copy; > yourself. > > This worked in Pharo 6. Bug or here should be a different way to do this? > > Cheers, > Andrei >

Oct. 5, 2018

[Pharo 7.0-dev] Build #1310: 22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest

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

There is a new Pharo build available! The status of the build #1310 was: SUCCESS. The Pull Request #1875 was integrated: "22537 Tag ManifestMultilingualEncodings and related classes in Multilingual-Encodings-Manifest" Pull request url: https://github.com/pharo-project/pharo/pull/1875 Issue Url: https://pharo.fogbugz.com/f/cases/22537 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 5, 2018

Creating a new class using `Class new superclass:` blocks the image in Pharo 7

by Andrei Chis

Hi, Executed in the latest Pharo 7 image (Pharo-7.0.0+alpha.build.1310.sha.a454977bb3d55bc4fcca3a57ac2fafcf137c0f30 (64 Bit)) the code below blocks the image (both with latest and stable vm on MacOs HighSierra). The vm does not crash but gets into a "Not Responding" state and does not get out: Class new superclass: GLMTransmission; setFormat: GLMTransmission format; classLayout: GLMTransmission classLayout copy; yourself Code like this is used in Moose in some tests and in SmaCC in the rewrite engine: Class new superclass: SmaCCRewriteMatchContext; setFormat: SmaCCRewriteMatchContext format; classLayout: SmaCCRewriteMatchContext classLayout copy; yourself. This worked in Pharo 6. Bug or here should be a different way to do this? Cheers, Andrei

Oct. 5, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Stephane Ducasse

Hi monty I ****really**** think that we should move to github. I mean really. Let us use a pro VCS - I do not like much git but Iceberg improves the feeling. Stef On Wed, Oct 3, 2018 at 8:28 AM monty <monty2(a)programmer.net> wrote: > > It would also prefer an SS3-based STHub, at least as an alternative to GitHub. > ___ > montyos.wordpress.com > > > > Sent: Saturday, September 29, 2018 at 6:43 AM > > From: "Stephane Ducasse" <stepharo.self(a)gmail.com> > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > Subject: Re: [Pharo-dev] Migrating XML support to github/PharoContributions/ > > > > Hi Sven > > > > SmalltalkHub is dying. And we will turn it readonly by January. > > Esteban has something else to do that to take care of it. It is a legacy. > > We are about to announce that we cannot create account and projects anymore. > > We are waiting to do that after the mooc. > > Now you want to use Squeaksource or SS3 I do not want. > > I want to use github and I guess that I do not have to explain why for real. > > > > Stef > > > > On Sat, Sep 29, 2018 at 11:27 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > I think that would be monty, email addresses (CC-ed) > > > > > > monty2(a)programmer.net > > > > > > I should note that he has been very good at maintaining the XML packages (the specs of which are super complex), and as far as I know, the code works under Pharo 7 ... > > > > > > What does not work for you ? > > > > > > Sven > > > > > > > On 29 Sep 2018, at 10:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > > > > > Hi > > > > > > > > I contacted the maintainer (but I'm not sure in fact who it is :) ) > > > > about the XML related packages in Pharo extras. > > > > > > > > XMLParser > > > > XMLParserHTML > > > > XMLParserStAX > > > > XMLSupport > > > > XMLWriter > > > > XPath > > > > > > > > I did not get any answer so may be I sent a mail to the wrong email address. > > > > Probably. > > > > Now the question still remains: who is planning to migrate the XML packages. > > > > I was planning to do it but I will not consider history because I do > > > > not know how to do it and I do not have the time to do it (sorry). And > > > > yes I work the weekends and this is bad and this is not even on Pharo. > > > > > > > > I was planning to spend some time on the baseline and making sure that > > > > we can load everything and run the tests. > > > > So let me know. > > > > > > > > Stef > > > > > > > > > > > > > > >

Oct. 5, 2018