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

Pharo Memcached client

by Sven Van Caekenberghe

Hi, I copied the (Pharo) Memcached client to https://github.com/svenvc/memcached where is lives in Tonel format with a Baseline and a working Travis CI build against an actual memcached server in the worker. More about memcached - https://en.wikipedia.org/wiki/Memcached - http://memcached.org Acknowledgements The original project can be found at http://www.squeaksource.com/memcached.html As far as I can see it was written by Philippe Marschall and Ramon Leon. I ported the codebase to Pharo. This repository is a recent copy with some cleanups. I intend to maintain this as I need it myself. The codebase should still maintain its original portability (minus the meta info, possibly). Sven

Oct. 18, 2018

[Pharo 7.0-dev] Build #1340: 22575-GZipReadStream-classunzipto-results-in-an-Invalid-utf8-input-detected-error

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

There is a new Pharo build available! The status of the build #1340 was: FAILURE. The Pull Request #1909 was integrated: "22575-GZipReadStream-classunzipto-results-in-an-Invalid-utf8-input-detected-error" Pull request url: https://github.com/pharo-project/pharo/pull/1909 Issue Url: https://pharo.fogbugz.com/f/cases/22575 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 18, 2018

[Pharo 7.0-dev] Build #1339: 22590-Add-support-of-text-input-different-from-keystrokes

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

There is a new Pharo build available! The status of the build #1339 was: SUCCESS. The Pull Request #1923 was integrated: "22590-Add-support-of-text-input-different-from-keystrokes" Pull request url: https://github.com/pharo-project/pharo/pull/1923 Issue Url: https://pharo.fogbugz.com/f/cases/22590 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 18, 2018

M2 research internship

by Jannik Laval GMail

Dear Smalltalkers, We are proposing 3 master internships about message monitoring and IoT. The development will be made in Pharo / Moose. You can find the offers on the lab's website: https://disp-lab.fr/?q=job. Internship position <https://www.disp-lab.fr/?q=content/m2-internship-monitoring-and-evaluation- exchanges-distributed-information-system> M2 Internship: Monitoring and evaluation of exchanges in a distributed information system 21 December 2018 Internship position <https://www.disp-lab.fr/?q=content/m2-internship-monitoring-application-exc hanges-iot-system> M2 Internship: Monitoring of application exchanges with an IoT system 21 December 2018 Internship position <https://www.disp-lab.fr/?q=content/m2-internship-production-dynamic-dashboa rds-monitoring-exchanges-distributed-information> M2 Internship: Production of dynamic dashboards for monitoring the exchanges of a distributed information system Please distribute to students who may be affected. Best regards -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet IUT LumiÃ¨re, UniversitÃ© LumiÃ¨re Lyon 2 laboratoire DISP +33 4 78 77 43 06 <http://www.jannik-laval.eu> http://www.jannik-laval.eu <http://www.phratch.com> http://www.phratch.com <http://www.approchealpes.info> http://www.approchealpes.info

Oct. 18, 2018

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

> On 18 Oct 2018, at 10:59, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > > On Tue, Oct 16, 2018 at 9:28 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 16 Oct 2018, at 19:03, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > > - STONFileReference is a subclass of FileReference, this could/should be > > Object, right? > > Uhh, no, since it acts as a facade that creates FileReferences. > But I can see how that would be hard to port, I guess this has to be implemented differently in your case. > > > I must be missing something, it seemed to me neither FileReference >> #stonOn: nor STONFileReference class >> #fromSton: actually required STONFileReference to be a subclass of FileReference... Yes, you are right, but by making it a subclass, you can infer that it generates something that is compatible with its superclass, that was the idea. Anyway, it is an implementation artefact, so it is not that important. If you handle FILE on a platform that does not have FileReference, then you won't need it. You would then add an #stonName equal to FILE somewhere else. > Cheers, > Henry

Oct. 18, 2018

Re: [Pharo-dev] STON updates/improvements

by Henrik Sperre Johansen

On Tue, Oct 16, 2018 at 9:28 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 16 Oct 2018, at 19:03, Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > > > - STONFileReference is a subclass of FileReference, this could/should be > > Object, right? > > Uhh, no, since it acts as a facade that creates FileReferences. > But I can see how that would be hard to port, I guess this has to be > implemented differently in your case. > > I must be missing something, it seemed to me neither FileReference >> #stonOn: nor STONFileReference class >> #fromSton: actually required STONFileReference to be a subclass of FileReference... Cheers, Henry

Oct. 18, 2018

MemoryFileSystem

by Sven Van Caekenberghe

Hi, In MemoryFileSystem the class MemoryWriteStream seems dead code. Agreed ? In class MemoryFileWriteStream the IV writeStream seems to be used and could be removed. Agreed ? MemoryFileWriteStream>>#close must first do a #flush. Right ? I need these for fixing https://pharo.fogbugz.com/f/cases/22466/Add-readWriteStream-and-readWriteSt… but these are actually a bit independent. Sven

Oct. 17, 2018

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

> On 16 Oct 2018, at 19:03, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Porting the newest version (0.96 from ss3), a few comments: > > - Date in other dialects (and VA specifically) do not contain tz offset - > the roundtrip will thus necessarily be lossy. > I chose to truncate the TZ info on import, and write without any when > storing. > In other words, if unknown, treat the dates as if they are in local tz from > the PoV of STON. If you have a Date without a TZ (or better an implicit one), that would be one strategy: write out without TZ info, drop all TZ info on read. Another option would be to add a Z (for UTC), but that would also not be 100% correct. It feels as if a TZ context is necessary after all. > This will obviously cause some discrepancies if transferring dates from one > dialect to another, but AFAICT, that's already the case when doing Pharo -> > Pharo transfer between systems in different timezones with tz info omitted. These are interesting questions that I have to think more about. The first goal of STON is to be 100% when going from Smalltalk objects to STON and back. Being cross platform or cross version is nice and important, but not a main goal, nor is it solvable I think. > - STONFileReference is a subclass of FileReference, this could/should be > Object, right? Uhh, no, since it acts as a facade that creates FileReferences. But I can see how that would be hard to port, I guess this has to be implemented differently in your case. > - STONFileReference >> #stonName and the other new implentors return a > string, while the existing implentors return a symbol. Not a big deal for > Pharo, but for others, it would be nice if they were consistent. Yes, I'll check and try to make it consistent, you are right about that. > - Is STONCStyleCommentsSkipStream >> #readInto:startingAt:count: in use, but > untested? It contains a reference to self encoder which seems to not be > implemented. A copy/paste error, I am sure. I'll check. > - ScaledDecimals have different internal representations in different > dialects*. > numerator/denominator aren't always implemented in terms of interpretation > as a fraction; explicitly converting to fraction before printing numerator / > denominator in STONWriter >> #writeScaledDecimal: would be of help in > keeping the code cross-platform compatible. > By contrast, implementing newFromNumber:scale: for STONReader is much less > likely to cause clashes with existing functionality. > > - From a cross-dialect perspective, ZnMimeType, ZnUrl, and (to an extent) > FileReference extensions feel like they don't really belong in core, but I > have no better suggestion of how to package them in an easily loadable > manner :/ > The stonName definition split used for STONFileReference seems like a good > thing from this PoV; maybe the same could be done for MimeType and Url? Then > you can load core, ignore the extensions on missing classes, but still have > classes in the image implying you might want to map the custom core STON > tags. Again, if a dialect does not implement certain classes/types, they have to be skipped. In terms of code organisation, separate packages could help. An the other hand, there could be dummy objects that just hold the external representation. I.e. if there is no URL class, just wrap the string/text. This would maintain some compatibility/portability. Thx again for the feedback ! > * ScaledDecimals will thus also experience precision loss (like Dates) when > doing dialect-roundtrips. > For instance, in VAST, it stores an integer with a fixed precision and > scale; 3/7s3 will come back as 429/1000s3 > > Cheers, > Henry > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 16, 2018

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

Hi Henrik, > On 16 Oct 2018, at 15:16, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > Sounds great! > > As for feedback, I've ported a slightly old version to VAST semi-manually > (which was a minimal amount of work, thank you!), from before Traits were in > use. Thx for working on the code base and porting to VAST. > Most fit neatly into a compatibility layer, only a few small things in > STON-Core stood out as things I ended up fixing inline, which could be > suitable for changing in the Pharo canonical version: > > STONReader >> #parseNamedInstVarsFor: > instVarNamed:put: takes a string as arg in VA (at least in VA, strings and > symbols are not interchangeable), so had to add an asString. Pharo code > would continue to work with this in base. Hmm, yes, I will have a look to see how we solved this for NeoJSON with Mariano. > In STONReaderError >> #messageText, format: isn't very portable, and can be > somewhat cumbersome to port. > I ended up replacing it with expandMacrosWithArguments:, which (afaik) works > in multiple dialects (VA, Pharo, and VW,that I know of); > 'At character <1s>: <2s>' expandMacrosWithArguments: #('12' 'Test') OK, I'll note this and have a look later on. Sven > Cheers, > Henry > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Oct. 16, 2018

Re: [Pharo-dev] STON updates/improvements

by Henrik Sperre Johansen

Porting the newest version (0.96 from ss3), a few comments: - Date in other dialects (and VA specifically) do not contain tz offset - the roundtrip will thus necessarily be lossy. I chose to truncate the TZ info on import, and write without any when storing. In other words, if unknown, treat the dates as if they are in local tz from the PoV of STON. This will obviously cause some discrepancies if transferring dates from one dialect to another, but AFAICT, that's already the case when doing Pharo -> Pharo transfer between systems in different timezones with tz info omitted. - STONFileReference is a subclass of FileReference, this could/should be Object, right? - STONFileReference >> #stonName and the other new implentors return a string, while the existing implentors return a symbol. Not a big deal for Pharo, but for others, it would be nice if they were consistent. - Is STONCStyleCommentsSkipStream >> #readInto:startingAt:count: in use, but untested? It contains a reference to self encoder which seems to not be implemented. - ScaledDecimals have different internal representations in different dialects*. numerator/denominator aren't always implemented in terms of interpretation as a fraction; explicitly converting to fraction before printing numerator / denominator in STONWriter >> #writeScaledDecimal: would be of help in keeping the code cross-platform compatible. By contrast, implementing newFromNumber:scale: for STONReader is much less likely to cause clashes with existing functionality. - From a cross-dialect perspective, ZnMimeType, ZnUrl, and (to an extent) FileReference extensions feel like they don't really belong in core, but I have no better suggestion of how to package them in an easily loadable manner :/ The stonName definition split used for STONFileReference seems like a good thing from this PoV; maybe the same could be done for MimeType and Url? Then you can load core, ignore the extensions on missing classes, but still have classes in the image implying you might want to map the custom core STON tags. * ScaledDecimals will thus also experience precision loss (like Dates) when doing dialect-roundtrips. For instance, in VAST, it stores an integer with a fixed precision and scale; 3/7s3 will come back as 429/1000s3 Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 16, 2018

Re: [Pharo-dev] STON updates/improvements

by Henrik Sperre Johansen

Sounds great! As for feedback, I've ported a slightly old version to VAST semi-manually (which was a minimal amount of work, thank you!), from before Traits were in use. Most fit neatly into a compatibility layer, only a few small things in STON-Core stood out as things I ended up fixing inline, which could be suitable for changing in the Pharo canonical version: STONReader >> #parseNamedInstVarsFor: instVarNamed:put: takes a string as arg in VA (at least in VA, strings and symbols are not interchangeable), so had to add an asString. Pharo code would continue to work with this in base. In STONReaderError >> #messageText, format: isn't very portable, and can be somewhat cumbersome to port. I ended up replacing it with expandMacrosWithArguments:, which (afaik) works in multiple dialects (VA, Pharo, and VW,that I know of); 'At character <1s>: <2s>' expandMacrosWithArguments: #('12' 'Test') Cheers, Henry -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 16, 2018

[Pharo 7.0-dev] Build #1338: 22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage

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

There is a new Pharo build available! The status of the build #1338 was: SUCCESS. The Pull Request #1918 was integrated: "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage" Pull request url: https://github.com/pharo-project/pharo/pull/1918 Issue Url: https://pharo.fogbugz.com/f/cases/22564 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 15, 2018

[Pharo 7.0-dev] Build #1337: 22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage

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

There is a new Pharo build available! The status of the build #1337 was: FAILURE. The Pull Request #1918 was integrated: "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage" Pull request url: https://github.com/pharo-project/pharo/pull/1918 Issue Url: https://pharo.fogbugz.com/f/cases/22564 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 15, 2018

[Pharo 7.0-dev] Build #1336: 22583 Tag ManifestCollectionsStreams and related classes in Collections-Streams

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

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

Oct. 15, 2018

[Pharo 7.0-dev] Build #1335: 22582 Tag ManifestSystemFinalization and classes in System-Finalization

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

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

Oct. 15, 2018

[Pharo 7.0-dev] Build #1334: 22570-add-method-reification-

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

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

Oct. 15, 2018

[Pharo 7.0-dev] Build #1333: Revert "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage"

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

There is a new Pharo build available! The status of the build #1333 was: SUCCESS. The Pull Request #1914 was integrated: "Revert "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage"" Pull request url: https://github.com/pharo-project/pharo/pull/1914 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 15, 2018

[Pharo 7.0-dev] Build #1332: 22578 Tag ManifestCollectionsTests

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

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

Oct. 15, 2018

[Pharo 7.0-dev] Build #1331: 22579 Tag and comment ManifestSystemHashing

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

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

Oct. 15, 2018

Esteban's ChangeLog week of 8 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 8 October 2018 to 14 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=8/10/2018&to=14/10/2018 ChangeLog ========= 10 October 2018: ---------------- * I finish an [extension to the GitHub plugin](https://github.com/pharo-vcs/iceberg/issues/1008) to allow users to create branchs from a GitHub issue (same as it works now with pharo fogbugz plugin). This will be used for Pharo 8, but it can also be used by other iceberg users in any project :) cheers! Esteban

Oct. 15, 2018

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

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

> On 12 Oct 2018, at 11:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Thanks Sven :) > > On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. > > Yes, I've suffered the things you explain before :) > > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > > Question: is it a new mechanism or it is based on the existing mapping mechanisms? Can we override it/extend it? This is using the existing mechanism (with specific #stonName's that differ from the class name). Several class already used this mechanism (the Chronology classes for example). In the case of FileReference it is a bit more of a hack: FileReferences to other filesystems than disk are serialised as before. Furthermore I had to use FILE instead of File since that class already exists. On other platforms, other concrete classes might handle the same tags. It wouldn't hurt if others thought a bit about this too. In any case, I intend to work a bit on documentation later on.

Oct. 12, 2018

Re: [Pharo-dev] STON updates/improvements

by Guillermo Polito

Thanks Sven :) On Fri, Oct 12, 2018 at 11:38 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. > Yes, I've suffered the things you explain before :) > > What do you think ? Comments, feedback, remarks ? > Any other suggestions for other object that could use this treatment ? > Question: is it a new mechanism or it is based on the existing mapping mechanisms? Can we override it/extend it?

Oct. 12, 2018

STON updates/improvements

by Sven Van Caekenberghe

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

MacOS instructions do not work on Mojave

by Jan BlizniÄenko

Hello Before starting, note that I am not MacOS user. Most of experiments I have done on MacOS Mojave in VirualBox and with friend with mac with MacOS Mojave. On https://pharo.org/download there are instructions how to run Pharo on MacOS. These steps are however not needed for Pharo Launcher which is now default download - it runs out of a box, you just have to confirm you really want to start it. On the other hand, these instructions do not work for "Pharo standalone"/"platform"/"all in one" package at all and just with these instructions such package cannot be started. Possibility to use this package without Launcher is important to me. Error is: "Pharo6.1-64 is damaged and cannot be opened. You should move it to Trash." and not option to start anyway. There are two options on download page, but none of these work: 1) Right clicking and picking Open does not make any difference at all - same error message is the result. 2) Going through settings - Security & Privacy does not work either because option Anywhere does not appear after clicking on the lockpad and filling my password - it is just not there. Only way to overcome this is to run "sudo spctl --master-disable" in terminal, which is command that is supposed to completely turn off Gatekeeper. After this command is executed, Pharo opens just fine and even the Anywhere option appears in security settings. It means that the Pharo package is not damaged at all (as error message indicates), it is just not properly signed. <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave.png> <http://forum.world.st/file/t369698/Pharo-MacOS_Mojave-2.png> Jan -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 12, 2018

[Call for testers] Pharo Launcher 1.4.5

by Guillermo Polito

Hi all, We have been working these last ~two weeks with Christophe on the stability of the launcher. We have prepared version 1.4.5, and we would like to have some feedback. http://files.pharo.org/pharo-launcher/1.4.5 So, we would really LOVE, if somebody can play with this version and send us feedback. Specially, if your username in your machine has characters that encoded take more than 1 byte, we really would like your feedback. We have tested with japanese characters, and others like Ã®,Ã¼, etc, but the more the better. The main focus was on: - correct management of encodings (in all platforms) - of environment variables - of files and paths - of commands called through OSProcess - better error management in case of edge cases (like when we cannot determine the version of an image) Just FYI: the major limitation of the launcher right now (and it was like that since ever) is that we cannot call external processes with non-ascii characters in windows. This happens because ProcessWrapper uses the ascii version of the windows API to create a process. With what we have learnt this week, we would like to push some of these fixes to Pharo7 too soon: - Correct encoding/decoding of environment variables in linux/osx - Ability to access the encoded version of environment variables in linux/osx to give users control over the encoding they want (or even access binary data) - Correct encoding/decoding of environment variables in windows by using the correct windows API (current primitiveGetenv in windows uses Ascii version too...) In the long term, we also need a solution to enhance or replace ProcessWrapper using the W (wide) version of the windows API. But that is far more work... GC, Guille & Christophe

Oct. 12, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Christophe Demarey

Do you have a pointer to the issue? If you do not use the latest Pharo Launcher, please update it: http://files.pharo.org/pharo-launcher/1.4.5/ Once done, you could also remove the pharo 7 VM from the vm folder and also the private vm folder to ensure the latest VM is downloaded. If you still have an issue, please post it on https://github.com/pharo-project/pharo-launcher/issues Christophe > Le 11 oct. 2018 Ã 20:49, Esteban A. Maringolo <emaringolo(a)gmail.com> a Ã©crit : > > I reported this a week or so ago, same issue. > > On 11/10/2018 03:09, phil(a)highoctane.be wrote: >> Used to work. Then does not anymore. >> >> Phil > > -- > Esteban A. Maringolo >

Oct. 12, 2018

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

by Denis Kudriashov

Hi Guille. ÑÑ, 11 Ð¾ÐºÑ. 2018 Ð³. Ð² 9:24, Guillermo Polito <guillermopolito(a)gmail.com>: > Hi, > > >> On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> Hello. >>> >>> I want to ask you what you think about it. >>> - do you prefer to see trait methods by default? >>> >> > Yes. > > >> - do you want feature to hide trait methods? >>> >> > Not necessarily. But the problem are not the methods "in traits". Read my > explanation below. > > 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. >>> >> > Well, the main problem of this approach is that traits in self are > fundamentally different than traits in self. And the main answer here is > not flattening or not flattening, but the idea of "trait composition". A > class does not just use "some traits". It uses a trait composition, which > includes also other rules like aliases, overrides and removals. With the > new implementation there is also deep aliasing. And moreover, since traits > are stateful, you need to support the same for slots. > > Then, regarding the current implementation, it is duplicating all the > semantics of traits in the UI, and incompletely because it is not covering > at all complex trait compositions. > > The problem with duplication is that then, if there is a bugz, we may have > to fix it several placez. > The problem with duplication is that then, if there is a bug, we may have > to fix it several places. > Duplication just needs to be avoided like in any other cases. I found that system can provide a single method which will allow correctly implement all visibility features but it will not expose to users trait arithmetics. It should just tell how given method is used by given class. aClass howAreYouUsingThisMethod: aMethod It can return different kind of objects like: - method is not used at all - it is an active method in the class - it is overridden method - method is overridden by package (for package overrides scenario) - method is removed (in trait composition) - method is aliased (in trait composition) It is kind of extended version of #isOverridden method. And can be useful in general. Anyway my question was not about implementation details of trait visibility feature. This feature will be removed and I just wanted to know if there are people who will be disappointed by this. But it seems nobody care. > And the other problem is that Traits already provide a good API to > discover all this things automatically without duplicating any of it: > - localMethods > - methods > - allMethods > > And then you can always ask the origin of a method. > > This API is of course perfectible, but I think it's better to enhance it, > than to duplicate it and work it around. > > On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> > wrote: > >> 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. >> > > I don't think so :). It's just a name convention. >

Oct. 11, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Esteban A. Maringolo

I reported this a week or so ago, same issue. On 11/10/2018 03:09, phil(a)highoctane.be wrote: > Used to work. Then does not anymore. > > Phil -- Esteban A. Maringolo

Oct. 11, 2018

Byte ordering in Form (urgent)

by Eliot Miranda

Hi All, in trying to fix a bug in BitBLT to do with accessing a word following a bitmap I have had to understand Form and BitBlt's extensions for handling multiple byte order. In particular, if a Form has a negative depth its byte ordering is reversed w.r.t. a Form with positive depth. But in examining this code I think I have found an inconsistency, and I urgently need to check my understanding. In the Form and BitBlt code, a negative depth is stated to mean a Form whose bits are in little-endian byte order: *Form methods for accessing* *depth* ^ depth < 0 ifTrue:[0-depth] ifFalse:[depth] *nativeDepth* "Return the 'native' depth of the receiver, e.g., including the endianess" ^depth *Form methods for testing* *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 *isLittleEndian* "Return true if the receiver contains little endian pixels, meaning the left-most pixel is stored in the least significant bits of a word." ^depth < 0 and BitBltSimulation (the Smalltalk code for the plugin that implements BitBlt) has two instance variables destMSW and sourceMSW that are true if the destination form or source form has a positive depth: *BitBltSimulation methods for interpreter interface* *loadBitBltDestForm* "Load the dest form for BitBlt. Answer false if anything is wrong, true otherwise." ... destDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: destForm. destMSB := destDepth > 0. destDepth < 0 ifTrue: [destDepth := 0 - destDepth]. ... *loadBitBltSourceForm* "Load the source form for BitBlt. Return false if anything is wrong, true otherwise." ... sourceDepth := interpreterProxy fetchInteger: FormDepthIndex ofObject: sourceForm. sourceMSB := sourceDepth > 0. sourceDepth < 0 ifTrue: [sourceDepth := 0 - sourceDepth]. ... But if I have a look at the actual layout of bytes in a Form I see that the meaning of depth is that if it is positive it is the *native* byte order (little endian on x86, x86-64, ARM, big end on SPARC, PowerPC): Display fill: (0@0 extent: 1@100) rule: Form over fillColor: Color black. (Display bits at: 1) hex '16rFF000001' | bytes | bytes := Display bits copy. ByteArray adoptInstance: bytes. bytes copyFrom: 1 to: 4 #[1 0 0 255] i.e. the first word of the Display after writing the color black into the first 32-bit pixel is 16rFF000001 on Mac OS x86-64, or #[1 0 0 255] , which is little endian. When the Squeak BttF VM was first written it was written on Motorola 68k Macs and PowerPC Macs, which are big-endian. So it is natural that at the time the terms isBigEndian and isLittleEndian and destMSB sourceMSB were as they are now, because the platform was big endian. But subsequently when the code was ported to Windows x86 by Andreas Raab, the meaning seems to me to have changed. Now depth > 0 implies *native* byte order, not big endian byte order, and depth < 0 implies the *opposite of native* byte order, not little endian order. Does anyone disagree? Does anyone have corroborating or contradicting evidence? I ask because to make sense of the code I would at least like to change the variables in BitBltSimulation to be destNativeByteOrder and sourceNativeByteOrder, and I want to either delete Form>>isBigEndian and Form>>isLittleEndian and replace it with Form>>isNativeByteOrder, or redefine isBigEndian and isLittleEndian, eg as *isBigEndian* "Return true if the receiver contains big endian pixels, meaning the left-most pixel is stored in the most significant bits of a word." ^depth > 0 == Smalltalk isBigEndian _,,,^..^,,,_ best, Eliot

Oct. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Sean P. DeNigris

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. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Stephane Ducasse

super c00l I started to tag all my projects too :) On Wed, Oct 10, 2018 at 1:43 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > 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. 11, 2018

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

by Thierry Goubier

Hi Denis, Le jeu. 11 oct. 2018 Ã 10:24, Guillermo Polito <guillermopolito(a)gmail.com> a Ã©crit : > > Hi, > >> >> On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Hello. >>> >>> I want to ask you what you think about it. >>> - do you prefer to see trait methods by default? > > > Yes. > >>> >>> - do you want feature to hide trait methods? > > > Not necessarily. But the problem are not the methods "in traits". Read my explanation below. > >>> 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. > > > Well, the main problem of this approach is that traits in self are fundamentally different than traits in self. And the main answer here is not flattening or not flattening, but the idea of "trait composition". A class does not just use "some traits". It uses a trait composition, which includes also other rules like aliases, overrides and removals. With the new implementation there is also deep aliasing. And moreover, since traits are stateful, you need to support the same for slots. > > Then, regarding the current implementation, it is duplicating all the semantics of traits in the UI, and incompletely because it is not covering at all complex trait compositions. > > The problem with duplication is that then, if there is a bugz, we may have to fix it several placez. > The problem with duplication is that then, if there is a bug, we may have to fix it several places. You're making your point about the danger of duplication very clear :) Thierry > And the other problem is that Traits already provide a good API to discover all this things automatically without duplicating any of it: > - localMethods > - methods > - allMethods > > And then you can always ask the origin of a method. > > This API is of course perfectible, but I think it's better to enhance it, than to duplicate it and work it around. > > On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> 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. > > > I don't think so :). It's just a name convention.

Oct. 11, 2018

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

by Guillermo Polito

Hi, > On Wed, Oct 10, 2018, 19:40 Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> I want to ask you what you think about it. >> - do you prefer to see trait methods by default? >> > Yes. > - do you want feature to hide trait methods? >> > Not necessarily. But the problem are not the methods "in traits". Read my explanation below. 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. >> > Well, the main problem of this approach is that traits in self are fundamentally different than traits in self. And the main answer here is not flattening or not flattening, but the idea of "trait composition". A class does not just use "some traits". It uses a trait composition, which includes also other rules like aliases, overrides and removals. With the new implementation there is also deep aliasing. And moreover, since traits are stateful, you need to support the same for slots. Then, regarding the current implementation, it is duplicating all the semantics of traits in the UI, and incompletely because it is not covering at all complex trait compositions. The problem with duplication is that then, if there is a bugz, we may have to fix it several placez. The problem with duplication is that then, if there is a bug, we may have to fix it several places. And the other problem is that Traits already provide a good API to discover all this things automatically without duplicating any of it: - localMethods - methods - allMethods And then you can always ask the origin of a method. This API is of course perfectible, but I think it's better to enhance it, than to duplicate it and work it around. On Thu, Oct 11, 2018 at 1:00 AM Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > 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. > I don't think so :). It's just a name convention.

Oct. 11, 2018

[Pharo 7.0-dev] Build #1328: Revert "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 #1328 was: FAILURE. The Pull Request #1902 was integrated: "Revert "22553-Instances-are-not-indexable-after-double-clicking-item-in-Collection-Inspector"" Pull request url: https://github.com/pharo-project/pharo/pull/1902 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

[Pharo 7.0-dev] Build #1327: 22566-Add-a-Details-pane-to-Colors-GT-Inspector

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

There is a new Pharo build available! The status of the build #1327 was: FAILURE. The Pull Request #1901 was integrated: "22566-Add-a-Details-pane-to-Colors-GT-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/1901 Issue Url: https://pharo.fogbugz.com/f/cases/22566 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

[Pharo 7.0-dev] Build #1326: 22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage

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

There is a new Pharo build available! The status of the build #1326 was: FAILURE. The Pull Request #1900 was integrated: "22564-Spec-tests-has-a-class-that-need-to-be-moved-to-deprecated-pacakage" Pull request url: https://github.com/pharo-project/pharo/pull/1900 Issue Url: https://pharo.fogbugz.com/f/cases/22564 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 11, 2018

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

by Marcus Denker

> On 11 Oct 2018, at 05:44, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Indeed. > > The issue comes from this commit: > https://github.com/pharo-project/pharo/pull/1889 <https://github.com/pharo-project/pharo/pull/1889> > I made a revert PR https://github.com/pharo-project/pharo/pull/1902 <https://github.com/pharo-project/pharo/pull/1902> and re-opened the issue tracker entry: https://pharo.fogbugz.com/f/cases/22553/Instances-are-not-indexable-after-d… <https://pharo.fogbugz.com/f/cases/22553/Instances-are-not-indexable-after-d…> We need to fix that bugâ¦ we had already multiple issue tracker entries for it. Marcus

Oct. 11, 2018

Re: [Pharo-dev] Laucher cannot start a fresh 7 image

by Christophe Demarey

Hi Phil, It could be a problem due to the introduction of a the use of a new primitive in the image some weeks ago. What is the version of Pharo Launcher you use? Did you try to update the pharo 7 vm? (you could just drop the vm folders in Documents). Christophe > Le 11 oct. 2018 Ã 08:09, phil(a)highoctane.be a Ã©crit : > > Used to work. Then does not anymore. > > Phil > <unknown.png>

Oct. 11, 2018

Re: [Pharo-dev] GitHub Topics

by Norbert Hartl

Mine are tagged, too. And most of them have the gitattributed so is surely discovered as smalltalk > Am 11.10.2018 um 03:48 schrieb Pierce Ng <pierce(a)samadhiweb.com>: > >> 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

Laucher cannot start a fresh 7 image

by phil＠highoctane.be

Used to work. Then does not anymore. Phil

Oct. 11, 2018