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

Re: [Pharo-dev] GitHub Topics

by Norbert Hartl

> Am 13.10.2018 um 11:09 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: > > > >> On sam. 13 oct. 2018 at 10:42, Norbert Hartl <norbert(a)hartl.name> wrote: >> I donât want to kick off another war but shouldnât we add pharo as a language to github. Now it is a topic but the configurations for linguist are still tying it to smalltalk. >> >> Norbert >> >> > > Hi, > > Linguist find the language based on theee things: > - what is written on the .gitattribute file > - the extension of the file > - the source code (it compares it with examples) > > Since multiple Smalltalk shares FileTree format and Tonel format, the extensions and source code will be the same for Pharo and other Smalltalk. > > Introducing a "Pharo" language would force everyone to add a .gitattribute file to their project, and I'm sure not that many people will do it. That is not a problem because the ones that want to distinguish do and the rest does not. But after sending the message I started to think it would only make sense when we switch the file ending to something else then .st Maybe to big a change and not important enough. Norbert > -- > Cyril Ferlicot > https://ferlicot.fr

Oct. 13, 2018

Re: [Pharo-dev] GitHub Topics

by Cyril Ferlicot

On sam. 13 oct. 2018 at 10:42, Norbert Hartl <norbert(a)hartl.name> wrote: > I donât want to kick off another war but shouldnât we add pharo as a > language to github. Now it is a topic but the configurations for linguist > are still tying it to smalltalk. > > Norbert > > > Hi, Linguist find the language based on theee things: - what is written on the .gitattribute file - the extension of the file - the source code (it compares it with examples) Since multiple Smalltalk shares FileTree format and Tonel format, the extensions and source code will be the same for Pharo and other Smalltalk. Introducing a "Pharo" language would force everyone to add a .gitattribute file to their project, and I'm sure not that many people will do it. -- Cyril Ferlicot https://ferlicot.fr

Oct. 13, 2018

Re: [Pharo-dev] GitHub Topics

by Norbert Hartl

I donât want to kick off another war but shouldnât we add pharo as a language to github. Now it is a topic but the configurations for linguist are still tying it to smalltalk. Norbert > Am 11.10.2018 um 16:28 schrieb Sean P. DeNigris <sean(a)clipperadams.com>: > > Stephane Ducasse-3 wrote >> super c00l > > +1. Tagged all mine. Now one can search in "Pharo" topic for subcategories > e.g. "authentication" shows 3 projects. Of course, the ideal is always to > have everything in image, but this is really nice to have: 1) almost for > free, 2) in a place like GH which is highly visible to the outside world and > 3) without needing an image handy (e.g. one could look for a lib on a mobile > device) > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 13, 2018

[Pharo 7.0-dev] Build #1330: Added getter and setter methods to Reflectivity class for the argsAsAâ¦

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

There is a new Pharo build available! The status of the build #1330 was: FAILURE. The Pull Request #1906 was integrated: "Added getter and setter methods to Reflectivity class for the argsAsAâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1906 Issue Url: https://pharo.fogbugz.com/f/cases/Reflectivity Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 13, 2018

[Pharo 7.0-dev] Build #1329: 22569-add-two-more-inspector-views-for-MetaLink-nodes-and-methods

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

There is a new Pharo build available! The status of the build #1329 was: FAILURE. The Pull Request #1905 was integrated: "22569-add-two-more-inspector-views-for-MetaLink-nodes-and-methods" Pull request url: https://github.com/pharo-project/pharo/pull/1905 Issue Url: https://pharo.fogbugz.com/f/cases/22569 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 13, 2018

Re: [Pharo-dev] Is ZipArchive broken?

by Paul DeBruicker

See https://pharo.fogbugz.com/f/cases/21867/cannot-load-save-to-ftp-repository Stephane Ducasse-3 wrote > Hi > > When I drop a MCZ on a Pharo 70 image I get an instance of Character > does not understand bitOr: and I wonder if there is not a regression > in ZipArchive. > I can rename the file and dezip with an external tools and load the code. > It happened to me with multiple mcz files. > > Stef -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2018

Is ZipArchive broken?

by Stephane Ducasse

Hi When I drop a MCZ on a Pharo 70 image I get an instance of Character does not understand bitOr: and I wonder if there is not a regression in ZipArchive. I can rename the file and dezip with an external tools and load the code. It happened to me with multiple mcz files. Stef

Oct. 12, 2018

Re: [Pharo-dev] STON updates/improvements

by phil＠highoctane.be

Sven, You rule. Definitely nice changes and thanks for the consolidation. Best, Phil On Fri, Oct 12, 2018, 11:38 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I have consolidated all repositories where STON code lives so that they > are now all in sync, and in sync with changes from Pharo 7. > > http://ss3.gemtalksystems.com/ss/STON/ > http://smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/ > https://github.com/svenvc/ston > > There are 2 CI builds > > https://travis-ci.org/svenvc/ston > https://ci.inria.fr/pharo-contribution/job/STON/ > > The project's format will remain FileTree (until Tonel is supported on > other Smalltalk implementations). > > > Last week I applied a couple of changes that I wanted to apply for a long > time. > > Traits are no longer used in the implementation (which should help porting > to other Smalltalk implementations). > > More specifically the following are used (again) > > - Class>>#stonOn: > - ClassDescription>>#stonContainsSubObjects > - Metaclass>>#stonName > - Metaclass>>#stonOn: > > instead of > > - TClass>>#stonOn: > - TClassDescription>>#stonContainsSubObjects > - TApplyingOnClassSide>>#stonName > - TApplyingOnClassSide>>#stonOn: > > use #instanceSide instead of #theNonMetaClass in MetaClass>>#stonOn: > > Reorganised the packages with sub tags. > > Add support for Fraction and ScaledDecimal literals (not in JSON mode). > Previously a float conversion meant there was a loss of information. > > Change the representation of Date to include a timezone offset (since the > current Date implementation is sensitive to this). > > 2018-10-11Z > 2018-10-11+00:00 > 2018-10-11+02:00 > > A missing timezone offset is interpreted as being the local timezone > offset. > > Add more special representations for common value style objects. One of > STON's goals is to be a human readable and human editable representation of > an object graph while remaining 100% correct (not losing information). The > following were added for this reason: > > MimeType and URL using ZnMimeType and ZnUrl respectively as simplified > values. > > MimeType['application/json'] > URL['https://pharo.org'] > > Color > > Color[#red] > Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4} > > FileReferences to the DiskFileSystem (effectively normal files) > > FILE['/tmp/foo.txt'] > > Here is an example of how much difference that makes. Given the following > Dictionary > > { > #background->Color red. > #workdir->'/tmp/pharo/work/' asFileReference. > #home->'https://pharo.org/experimental' asUrl. > #datatype->'application/json' asMIMEType } asDictionary > > Which contains real objects as its values. > > was serialised by STON BEFORE the changes as > > { > #datatype : ZnMimeType { > #main : 'application', > #sub : 'json' > }, > #background : Color { > #rgb : 1072693248, > #cachedDepth : 32, > #cachedBitPattern : Bitmap [ > 4294901760 > ], > #alpha : 255 > }, > #home : ZnUrl { > #scheme : #https, > #host : 'pharo.org', > #segments : OrderedCollection [ > 'experimental' > ] > }, > #workdir : FileReference { > #filesystem : FileSystem { > #store : MacStore { > #maxFileNameLength : 255 > } > }, > #path : AbsolutePath [ 'tmp', 'pharo', 'work' ] > } > } > > which is 100% correct, but not very human friendly. > > Now, AFTER the changes, the STON serialisation looks as follows: > > { > #datatype : MimeType [ 'application/json' ], > #background : Color [ #red ], > #home : URL [ 'https://pharo.org/experimental' ], > #workdir : FILE [ '/tmp/pharo/work' ] > } > > which is a huge improvement, IMO. > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > > Sven > > >

Oct. 12, 2018

Re: [Pharo-dev] STON updates/improvements

by Cyril Ferlicot

On ven. 12 oct. 2018 at 11:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I have consolidated all repositories where STON code lives so that they > are now all in sync, and in sync with changes from Pharo 7. > > http://ss3.gemtalksystems.com/ss/STON/ > http://smalltalkhub.com/mc/SvenVanCaekenberghe/STON/main/ > https://github.com/svenvc/ston > > There are 2 CI builds > > https://travis-ci.org/svenvc/ston > https://ci.inria.fr/pharo-contribution/job/STON/ > > The project's format will remain FileTree (until Tonel is supported on > other Smalltalk implementations). > > > Last week I applied a couple of changes that I wanted to apply for a long > time. > > Traits are no longer used in the implementation (which should help porting > to other Smalltalk implementations). > > More specifically the following are used (again) > > - Class>>#stonOn: > - ClassDescription>>#stonContainsSubObjects > - Metaclass>>#stonName > - Metaclass>>#stonOn: > > instead of > > - TClass>>#stonOn: > - TClassDescription>>#stonContainsSubObjects > - TApplyingOnClassSide>>#stonName > - TApplyingOnClassSide>>#stonOn: > > use #instanceSide instead of #theNonMetaClass in MetaClass>>#stonOn: > > Reorganised the packages with sub tags. > > Add support for Fraction and ScaledDecimal literals (not in JSON mode). > Previously a float conversion meant there was a loss of information. > > Change the representation of Date to include a timezone offset (since the > current Date implementation is sensitive to this). > > 2018-10-11Z > 2018-10-11+00:00 > 2018-10-11+02:00 > > A missing timezone offset is interpreted as being the local timezone > offset. > > Add more special representations for common value style objects. One of > STON's goals is to be a human readable and human editable representation of > an object graph while remaining 100% correct (not losing information). The > following were added for this reason: > > MimeType and URL using ZnMimeType and ZnUrl respectively as simplified > values. > > MimeType['application/json'] > URL['https://pharo.org'] > > Color > > Color[#red] > Color{#red:1.0,#green:0.0,#blue:0.0,#alpha:0.4} > > FileReferences to the DiskFileSystem (effectively normal files) > > FILE['/tmp/foo.txt'] > > Here is an example of how much difference that makes. Given the following > Dictionary > > { > #background->Color red. > #workdir->'/tmp/pharo/work/' asFileReference. > #home->'https://pharo.org/experimental' asUrl. > #datatype->'application/json' asMIMEType } asDictionary > > Which contains real objects as its values. > > was serialised by STON BEFORE the changes as > > { > #datatype : ZnMimeType { > #main : 'application', > #sub : 'json' > }, > #background : Color { > #rgb : 1072693248, > #cachedDepth : 32, > #cachedBitPattern : Bitmap [ > 4294901760 > ], > #alpha : 255 > }, > #home : ZnUrl { > #scheme : #https, > #host : 'pharo.org', > #segments : OrderedCollection [ > 'experimental' > ] > }, > #workdir : FileReference { > #filesystem : FileSystem { > #store : MacStore { > #maxFileNameLength : 255 > } > }, > #path : AbsolutePath [ 'tmp', 'pharo', 'work' ] > } > } > > which is 100% correct, but not very human friendly. > > Now, AFTER the changes, the STON serialisation looks as follows: > > { > #datatype : MimeType [ 'application/json' ], > #background : Color [ #red ], > #home : URL [ 'https://pharo.org/experimental' ], > #workdir : FILE [ '/tmp/pharo/work' ] > } > > which is a huge improvement, IMO. > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > This is great thank you! In some projects I had some hacks for the export of FileReferences in a readable way, it is great to know have a readable export by default in ston. > Sven > > > -- Cyril Ferlicot https://ferlicot.fr

Oct. 12, 2018

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

by Jan BlizniÄenko

Hello In my case, I would like to see USED (ie. not removed or replaced) trait methods by default with clearly visible mark that they come from trait (which is how Nautilus presents them). Reason is that quickly seeing whole API brought by this class is more important to me than seeing what the class actually imprements. I would LOVE feature to hide trait methods. I have few classes with like 20 trait methods and 2 own ones and it would be great to temporarily switch to see just the 2 (but when I open the class again later I would like to see all of them again). It seems to me there ought to be multiple opinions on this, so having option in settings (to show trait methods or hide them by default) would be best solution for both groups. Jan Denis Kudriashov 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 -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2018