- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2018-03-17 13:15 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >>> So to get all minor fixes from all dependencies the code should be loaded >>> from such floating branch (0.5.x). The main project can be locked to fix >>> current version (only dependencies will be updated). >>> And all released versions (0.5.3 tag) will be completely reproducible. >>> >> >> So your goal for released versions is to be only loadable on a specific >> pharo build? >> >> > On any pharo build. I not understand what you mean Your dependencies will need to be updated to run on newer pharo builds, wonât they? Stephan

March 17, 2018

Adapt ImageReadWriter hierarchy to need only pure binary streams

by Sven Van Caekenberghe

https://pharo.manuscript.com/f/cases/21611 With the new File/Stream changes in Pharo 7, ImageReadWriter and subclasses broke because these classes are not yet capable of working with simple binary streams. I created a new test case (attached) to catch the functional degradation. For each image type (class) there are 2 tests, IO in memory and IO to file. For example: testJpegWriteReadInMemory | form bytes result | form := self pharoLogoFormNonTransparent. bytes := ByteArray streamContents: [ :out | PluginBasedJPEGReadWriter putForm: form onStream: out ]. "Without format detection" result := (JPEGReadWriter on: bytes readStream) nextImage. self assert: form bits size equals: result bits size. "With format detection" result := ImageReadWriter formFromStream: bytes readStream. self assert: form bits size equals: result bits size testJpegWriteReadUsingFiles | form file result | form := self pharoLogoFormNonTransparent. file := (self class name asString , '-pharo-logo.jpeg') asFileReference. file ensureDelete. (PluginBasedJPEGReadWriter on: file binaryWriteStream) nextPutImage: form. "gets closed ?!" "Without format detection" result := file binaryReadStreamDo: [ :in | (JPEGReadWriter on: in) nextImage ]. self assert: form bits size equals: result bits size. "With format detection" result := file binaryReadStreamDo: [ :in | ImageReadWriter formFromStream: in ]. self assert: form bits size equals: result bits size. file delete I have a bunch of changes that make all tests pass. They clean up some strange coding as well. I will make a proper PR later. Sven

March 17, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by CÃ©drick BÃ©ler

Little feedback too. I was surprised by the new download as some students had to install on windowsâ¦ hopefully, I had old win versions but it has disturbed me :) Still handy and straightforward to just put an image on the VM. Butâ¦this being said, I just tried on Mac and this works nicely and this is true that launcher makes the management of image clearer and easier.. I donât know about windows but I have to care about as 98% of students uses Pharo on windows... I was thinking of some adjustments: 1) maybe a default/advanced mode on the launcher to show only, as default, Mooc/PBE5/Official distributions. 2) a proper icon name to display in OSâs task bars. When several image are opened, they should have different icons, at least different name when hovering, and not only Pharo. A more general feedback is about cloud drive OSâs (iCloud Drive, Dropbox, â¦). I have 3 macâs (pro and personal). I put often files in a directory that are synchronized across these devices. - sometimes I get a message that an image are in different states - sync image might be long (+changes) depending on network conditions I think the question is important as the launcher download in the Document folder (OSX) and this directory is synchronized by default. What do you think about such common situation ? What are your common practices ? - lets says on two Macs and works on both - or I use a dropbox folder => cloud drive are cool and my impression is that we could take a better advantage of them for data that could be shared between (personal) images (Play-Cache ? Packages-cache ? â¦ ) ==> would it be possible to have several files for one image (chunked over time so only the last chunk is modified and then less file would be synchronized) - (I donât know at all if possible) ? ==> same for changesâ¦ but this one should be easier I think. => I also find longer to share pharo system the old ways - zipping (or not) via USB - I think git integration produces a large number of files that relies slows down system copy paste (if only image this is ok)â¦ My 2 cents, CÃ©drick PS: my experiments to make students use Pharo are very coolâ¦ I need to adjust my presentations/lecture but already I think I succeeded in getting more attraction (and potential results) than what I tried last year with whatever technologies (Python especially). I still use AppInventor and Arduino.cc <http://arduino.cc/>. PS2: I just like what Sean said (but might be frightening at first for newcomers ^^) Pharo all the way down > >> But just in case we step into the quicksand even further, in this dystopian > >> future you can just copy paste this definition: > >> Pharo is a Pharo app that manages Pharo images, which can be used to make > >> Pharo apps, which can be used to manage Pharo images, [which can be used to > >> make Pharo apps, which can be used to manage Pharo images]* > > > Haha, yes it is so fluid it cannot be described only be experienced through prolonged exposure, it is truly magical. > > Actually, that is not so far from the truth.

March 17, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Denis Kudriashov

2018-03-17 13:15 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > So to get all minor fixes from all dependencies the code should be loaded > > from such floating branch (0.5.x). The main project can be locked to fix > > current version (only dependencies will be updated). > > And all released versions (0.5.3 tag) will be completely reproducible. > > > > So your goal for released versions is to be only loadable on a specific > pharo build? > > On any pharo build. I not understand what you mean > Stephan > > > > > >

March 17, 2018

Re: [Pharo-dev] Released versions in Pharo Bootstrap

by Stephan Eggermont

Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > So to get all minor fixes from all dependencies the code should be loaded > from such floating branch (0.5.x). The main project can be locked to fix > current version (only dependencies will be updated). > And all released versions (0.5.3 tag) will be completely reproducible. > So your goal for released versions is to be only loadable on a specific pharo build? Stephan

March 17, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Alexandre Bergel

Yesterday we also experienced many problem when using Launcher on OSX :-( Is the Launcher still maintained? Alexandre > On Mar 17, 2018, at 8:57 AM, kmo <voxkmp(a)gmail.com> wrote: > > I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at > work. It installs. Runs fine - creates images and vms but when you try to > run them nothing happens. It fails to start the selected image. It just > fails to run the vm at all as far as I can see. > > I tried it on my Windows 10 (32 bit) laptop and got exactly the same result. > > This is not important for me as I use pharo on Linux - but I thought I'd > point it out. If having the launcher as the default download causes more > problems than the traditional vm and image download then perhaps it should > be reconsidered. A pity since I love the launcher. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 17, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by kmo

I tried the default download of Pharo Launcher on my Windows 7 (32 bit) PC at work. It installs. Runs fine - creates images and vms but when you try to run them nothing happens. It fails to start the selected image. It just fails to run the vm at all as far as I can see. I tried it on my Windows 10 (32 bit) laptop and got exactly the same result. This is not important for me as I use pharo on Linux - but I thought I'd point it out. If having the launcher as the default download causes more problems than the traditional vm and image download then perhaps it should be reconsidered. A pity since I love the launcher. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 17, 2018

Re: [Pharo-dev] Executive Summary of the recent FileStream Changes

by monty

The code is in XMLParser: see XMLEncodingDetector. I can port it, if you think the algorithm is appropriate. The YAML algorithm is actually a less restrictive version of this XML one: https://www.w3.org/TR/REC-xml/#sec-guessing The XML one is "Non-Normative" (ie optional), so I chose to implement the more general YAML algorithm instead. > Sent: Friday, March 16, 2018 at 6:44 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Executive Summary of the recent FileStream Changes > > > > > On 16 Mar 2018, at 07:05, monty <monty2(a)programmer.net> wrote: > > > >> Sent: Thursday, March 15, 2018 at 4:01 PM > >> From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > >> To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > >> Subject: [Pharo-dev] Executive Summary of the recent FileStream Changes > >> > >> Executive Summary of the recent FileStream Changes > >> > >> In Pharo 7 Guille Polito recently committed a heroic set of changes that we were planning to do for a long time but were afraid to take on. > >> > >> The idea is to replace a couple of fat, overly complex, multi-functional, do-all classes with a set of simpler single purpose classes that can be combined as needed. > >> > >> The classes that we want to get rid of can be found in the package DeprecatedFileSystem, in particular FileStream, StandardFileStream, MultiByteFileStream, MultiByteBinaryOrTextStream and RWBinaryOrTextStream. > > > > StandardFileStream, at least, should remain for backwards compatibility and cross-platform compatibility with Squeak. It's a no-frills, non-decoding, non-LE normalizing stream that is heavily depended on. > > Hmm, maybe. > > The standard (no pun intended) interface to the file system in Pharo has been FileSystem (FileReference) for quite a while. Many packages dealing with either different Pharo versions or different Smalltalk implementations have constructed their own portability facade (heck, I even did it in ZnFileSystemUtils myself). > > Note however that some aspects (API, behaviour) about the streams themselves changed as well (no longer being bivalent, separating reading/writing, smaller/simpler API, sometimes no positioning). > > >> The replacements are can be found in packages Files and Zinc-Character-Encoding-Core. > >> > >> Encoding and decoding characters to and from bytes is done using classes that you wrap around a more primitive binary stream. The same goes for buffering or translating line endings. > >> > >> For example, > >> > >> '/Users/sven/Desktop/foo.txt' asFileReference binaryReadStream. > >> > >> gives you a ZnBufferedWriteStream wrapping a BinaryWriteStream. > >> > >> While, > >> > >> '/Users/sven/Desktop/foo.txt' asFileReference readStream. > > > > What do you think about this algorithm for encoding detection: http://www.yaml.org/spec/1.2/spec.html#id2771184 > > > > I have an implementation (with tests), if you're interested. (I was waiting to propose it until the FileSystem API switched over to using Zn streams and encoders. The TextConverter API doesn't support UTF-32.) > > I did a primitive one in ZnCharacterEncoding class>>#detectEncoding: but I am not happy with it. I will read your reference and I am certainly interested in seeing your code ! > > >> gives a ZnCharacterReadStream wrapping a ZnBufferedWriteStream wrapping a BinaryWriteStream. > >> > >> To translate line endings, we would wrap a ZnCharacterWriteStream using a ZnCrPortableWriteStream. > >> > >> There are a couple of more specialised streams to cover special cases (like read and writing at the same time). > >> > >> SocketStream remains another fat, overly complex, multi-functional, do-all class, for which usable replacements exist in the form of ZdcSocketStream and ZdcSecureSocketStream, which are simpler, cleaner and binary only. > >> > >> Of course, switching is more than replacing one class with a 100% compatible alternative, that would give us the same complex result. The challenge is to use a simpler API as well, to rethink how the streams are used. You know, KISS. > >> > >> Of course, we are far from done and need more testing, debugging and help from as many people as possible. > >> > >> Sven > >> > >> > >> -- > >> Sven Van Caekenberghe > >> Proudly supporting Pharo > >> http://pharo.org > >> http://association.pharo.org > >> http://consortium.pharo.org > > >

March 17, 2018

[Pharo 7.0-dev] Build #702: Remove extra buffered read stream

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

There is a new Pharo build available! The status of the build #702 was: SUCCESS. The Pull Request #1118 was integrated: "Remove extra buffered read stream" Pull request url: https://github.com/pharo-project/pharo/pull/1118 Issue Url: https://pharo.fogbugz.com/f/cases/21604 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 17, 2018

[Pharo 7.0-dev] Build #701: 21487 Lint clean #testAtWrapPut

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

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

March 16, 2018