- Pharo-dev - lists.pharo.org

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