- Pharo-dev - lists.pharo.org

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