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

glamorous toolkit alpha.2

by Tudor Girba

Hi, Glamorous Toolkit has evolved quite a bit over the past months, and we now would like to announce that we reached alpha.2 version. It runs on top of Pharo 7: feenk.com/gt There quite a number of new things. Some highlights are: - We added extensive documentation for GT, Bloc and Brick. By running "GtWorld openTourâ you essentially transform the image into an elaborate wiki. - We worked on Coder, a new set of tools that are dedicated for affecting code. For example, in the picture below we see an editor on embedded examples that can be edited and run independently. And this one shows how we can visualize and edit the result of querying. Just a note: To make Coder work the way we want, we extended Brick with several widgets, and enhanced significantly the linear and grid layouts. - We added the first version of xdoc in order to serialize the Playground every time you evaluate something. As always, we are looking forward to your feedback. Have fun, The feenk team -- www.feenk.com -- www.feenk.com "Every thing should have the right to be different."

Oct. 31, 2018

Re: [Pharo-dev] [ANN] The STON Specification

by David T. Lewis

This is very clear and well written. Dave > Hi, > > Since there can never be enough documentation I finally took some time to > write a more formal description of STON as a data format. > > https://github.com/svenvc/ston/blob/master/ston-spec.md > > The idea is to let this stabilise a bit and to then update the two other > documents describing STON, where necessary: > > https://github.com/svenvc/ston/blob/master/ston-paper.md > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… > > Also, the latest changes in STON have to make their way to the Pharo image > as well. > > https://github.com/svenvc/ston > > All feedback is welcome. > > Sven > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

Oct. 31, 2018

[ANN] The STON Specification

by Sven Van Caekenberghe

Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

Oct. 31, 2018

Re: [Pharo-dev] ClyMethodGroup>>#fileOut dead code ?

by Denis Kudriashov

Hi Sven. It is not dead. It is here to file out any method group including normal protocols. It was copied from SystemOrganizer>>fileOutCategory:. Now it needs to be fixed in Pharo 7 and it would be nice to have it in better form ÑÑ, 31 Ð¾ÐºÑ. 2018 Ð³. Ð² 15:39, Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > ClyMethodGroup>>#fileOut seems like dead code (it sends #trailer to a > WriteStream which DNUs). It also uses the deprecated FileStream. > > Can it be removed ? > > Sven >

Oct. 31, 2018

Source/changes file suffixes constants

by Sven Van Caekenberghe

Hi, Current FileStream holds (in the protocol 'file reader services') some constants regarding source/changes file suffixes. Where should we move these to (as FileStream is deprecated) ? There is a class SourceFile, there is PharoFilesOpener, neither seems to fit that well. Suggestions ? Sven

Oct. 31, 2018

Re: [Pharo-dev] About #zipped / #unzipped

by Sven Van Caekenberghe

https://github.com/pharo-project/pharo/pull/1947 > On 26 Oct 2018, at 22:28, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > +1 > > On Tue, Oct 23, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >>> On 18 Oct 2018, at 20:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>> Hi, >>> >>> Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. >>> >>> (note also that there are no real users of these methods) >>> >>> Right now it seems cool that the following is an identity. >>> >>> 'foobar' zipped unzipped. >>> >>> However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. >>> >>> Of course, the current methods are broken, as can be seen from a more complex (wide) string. >>> >>> 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> >>> >>> The error results from some implicit/wrong character encoding being used. >>> >>> The right way to do this is to explicitly encode/decode the string. >>> >>> (GZipReadStream on: (ByteArray streamContents: [ :out | >>> (GZipWriteStream on: out) >>> nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; >>> close ])) upToEnd utf8Decoded. >>> >>> From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. >>> >>> 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. >>> >>> This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded >>> >>> What do you think ? >>> >> >> Yes, to me this sounds interestingâ¦ I think compression is indeed better done on the level of bytes then on Strings. >> >> >> Marcus >> >> >

Oct. 31, 2018

ClyMethodGroup>>#fileOut dead code ?

by Sven Van Caekenberghe

Hi, ClyMethodGroup>>#fileOut seems like dead code (it sends #trailer to a WriteStream which DNUs). It also uses the deprecated FileStream. Can it be removed ? Sven

Oct. 31, 2018

[Pharo 7.0-dev] Build #1358: 22608-Deprecate-FileDialog-methods-that-open-streams

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

There is a new Pharo build available! The status of the build #1358 was: FAILURE. The Pull Request #1941 was integrated: "22608-Deprecate-FileDialog-methods-that-open-streams" Pull request url: https://github.com/pharo-project/pharo/pull/1941 Issue Url: https://pharo.fogbugz.com/f/cases/22608 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 31, 2018

[Pharo 7.0-dev] Build #1357: Added a guard in LinkedList>>sort: that directly returns self if the â¦

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

There is a new Pharo build available! The status of the build #1357 was: SUCCESS. The Pull Request #1921 was integrated: "Added a guard in LinkedList>>sort: that directly returns self if the â¦" Pull request url: https://github.com/pharo-project/pharo/pull/1921 Issue Url: https://pharo.fogbugz.com/f/cases/22587 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 31, 2018

[Pharo 7.0-dev] Build #1356: Adding class OCCompilerDynamicASTPlugin (and its test class), allowiâ¦

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

There is a new Pharo build available! The status of the build #1356 was: FAILURE. The Pull Request #1920 was integrated: " Adding class OCCompilerDynamicASTPlugin (and its test class), allowiâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/1920 Issue Url: https://pharo.fogbugz.com/f/cases/DynamicCompilerPlugins Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 31, 2018

[Pharo 7.0-dev] Build #1355: 22466-Add-readWriteStream-and-readWriteStreamDo-in-FileSystem

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

There is a new Pharo build available! The status of the build #1355 was: FAILURE. The Pull Request #1924 was integrated: "22466-Add-readWriteStream-and-readWriteStreamDo-in-FileSystem" Pull request url: https://github.com/pharo-project/pharo/pull/1924 Issue Url: https://pharo.fogbugz.com/f/cases/22466 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 31, 2018

[Pharo 7.0-dev] Build #1354: 22617-MemoryFileWriteStreamclose-doesnt-flush

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

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

Oct. 31, 2018

[Pharo 7.0-dev] Build #1353: REVERT-22239-DataAndTimeTesttestAsDateAndTime-is-meaningful

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

There is a new Pharo build available! The status of the build #1353 was: FAILURE. The Pull Request #1945 was integrated: "REVERT-22239-DataAndTimeTesttestAsDateAndTime-is-meaningful" Pull request url: https://github.com/pharo-project/pharo/pull/1945 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. 30, 2018

[Pharo 7.0-dev] Build #1352: 21667-Dropping-a-mcz-on-image-raises-an-error

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

There is a new Pharo build available! The status of the build #1352 was: FAILURE. The Pull Request #1939 was integrated: "21667-Dropping-a-mcz-on-image-raises-an-error" Pull request url: https://github.com/pharo-project/pharo/pull/1939 Issue Url: https://pharo.fogbugz.com/f/cases/21667 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 30, 2018

[Pharo 7.0-dev] Build #1351: 22615-Random-Core-can-be-removed-form-the-manual-dependencies-list-of-Collections-String

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

There is a new Pharo build available! The status of the build #1351 was: FAILURE. The Pull Request #1944 was integrated: "22615-Random-Core-can-be-removed-form-the-manual-dependencies-list-of-Collections-String" Pull request url: https://github.com/pharo-project/pharo/pull/1944 Issue Url: https://pharo.fogbugz.com/f/cases/22615 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 29, 2018

[Pharo 7.0-dev] Build #1350: 22499-modifying-a-method-in-a-trait-that-is-aliased-in-a-class-is-not-propagated-correctly-

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

There is a new Pharo build available! The status of the build #1350 was: FAILURE. The Pull Request #1938 was integrated: "22499-modifying-a-method-in-a-trait-that-is-aliased-in-a-class-is-not-propagated-correctly-" Pull request url: https://github.com/pharo-project/pharo/pull/1938 Issue Url: https://pharo.fogbugz.com/f/cases/22499 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 29, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Guillermo Polito

Well, there are still variants - chooseFile* - fileOpen* - fileSave* - chooseFileName* - chooseFullFileName* I prefered rather to be explicit and to avoid confusion with the old API (which I deprecated, not removed!) On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > What about different names? > > UIManager default > chooseFileIn: aFileReference > withExtensions: #() > title: 'title' > > UIManager default > chooseFileForSaveIn: aFileReference > withExtensions: #() > title: 'title' > > We can just expect file references because it is what is exposed to users > in pharo file system. Not neccessery to put it in method name. > > Ð¿Ñ, 26 Ð¾ÐºÑ. 2018 Ð³., 16:32 Guillermo Polito <guillermopolito(a)gmail.com>: > >> Hi all, >> >> I've proposed a PR with some cleanups in this respect >> >> https://github.com/pharo-project/pharo/pull/1941 >> >> This is the proposed replacement API that returns file references instead >> of streams or file names. >> >> "Get existing file reference" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: nil >> path: FileSystem workingDirectory. >> >> "Get existing file reference filtering by extensions" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: #('log') >> path: FileSystem workingDirectory. >> >> "Get existing file reference to file" >> UIManager default >> chooseExistingFileReference: 'title' >> extensions: nil >> path: FileSystem workingDirectory / 'PharoDebug.log'. >> >> "Get file reference for save (not necessarily existing)" >> UIManager default >> chooseForSaveFileReference: 'title' >> extensions: #('log') >> path: 'PharoDebuasdg.log'. >> >> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Ok, so can we agree on deprecating the non compatible methods and >>> redirect the user to the new ones? >>> >>> To me, the problem with returning a stream is that from a user >>> perspective you don't know: >>> - is the file encoded or binary >>> - if it is encoded, in which encoding? >>> - if i receive an open file stream, and I want to delete that file I >>> have to close it, retrieve the file, delete it? >>> - IMHO, what is the worst: whose responsibility is it to close the file? >>> >>> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>> >>>> > It should return a FileReference, not an open stream. I believe >>>> there are methods that do that. >>>> >>>> There are different APIs for that. >>>> >>>> fileOpen*, as the name implies, _opens the file_ and returns the >>>> stream. (I think this should be the case for fileSave*) >>>> >>>> If you want file reference, then you can use e.g. >>>> >>>> UIManager default chooseFileMatching: #() label: nil >>>> >>>> or `chooseFileMatching:label:`, >>>> `chooseFileName:extensions:path:preview:`, >>>> `chooseFullFileName:extensions:path:preview:`, >>>> `chooseFullFileNameMatching:label:`. >>>> Also some methods for selecting directories >>>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >>>> >>>> iirc some of them actually return String (file path) instead of >>>> FileReference. ( >>>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >>>> ) >>>> >>>> So it can be confusing, but the API is already available. >>>> >>>> Also iirc UIManager should be preferred over UITheme builder. >>>> >>>> Peter >>>> >>>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>>> wrote: >>>> >>>>> >>>>> >>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> > >>>>> > Hi, >>>>> > >>>>> > A question to those who worked on the new streams for Pharo 7: >>>>> > >>>>> > >>>>> > In PHARO 6 I used the following expression to open a file dialog and >>>>> let the user choose >>>>> > a binary file: >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: >>>>> #('exe'). >>>>> > >>>>> > This returned >>>>> > - either nil (when file dialog was canceled) >>>>> > - a "MultiByteFileStream" instance when a file was selected >>>>> > >>>>> > The MultiByteFileStream instance already had the name of the file (= >>>>> full path) and I was >>>>> > able to query it for further use: >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>> > s name inspect >>>>> > >>>>> > (for instance to display which file is processed in a window by >>>>> showing the full path) >>>>> > >>>>> > >>>>> > >>>>> > Now in PHARO 7 same expression returns an instance of >>>>> ZnCharacterReadStream (as MultiByteFileStream >>>>> > is deprecated): >>>>> > >>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>> > >>>>> > and ZnCharacterReadStream does not understand #name - and in fact >>>>> the info about the name is >>>>> > totally lost/not available. To me this looks missing/broken. >>>>> > >>>>> > So what is the recommended way in Pharo 7 to open a file dialog, let >>>>> the use choose a file >>>>> > and get a file stream but also the name? IMHO this is either broken >>>>> or missing... >>>>> > >>>>> > Thanks >>>>> > T. >>>>> >>>>> It should return a FileReference, not an open stream. I believe there >>>>> are methods that do that. >>>>> >>>>> But that is an incompatible API change (same selector, different >>>>> return type). So hard to decide. >>>>> >>>>> >>>>> >>> >>> -- >>> >>> >>> >>> Guille Polito >>> >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> >>> CRIStAL - UMR 9189 >>> >>> French National Center for Scientific Research - *http://www.cnrs.fr >>> <http://www.cnrs.fr>* >>> >>> >>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>> >>> *Phone: *+33 06 52 70 66 13 >>> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 29, 2018

Esteban's ChangeLog week of 22 October 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 22 October 2018 to 28 October 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=22/10/2018&to=28/10/2018 ChangeLog ========= 22 October 2018: ---------------- * I (finally) finnished couple of PRs for Calypso! * [Issue 304](https://github.com/pharo-ide/Calypso/pull/346) * [Issue 335](https://github.com/pharo-ide/Calypso/pull/348) This two are the content of my work of last week. It was complicated to understand the model behind calypso and that took more time than preview. A bit of an explanation: 1. First one eliminates the extension that takes +Traits+ as if they would be superclasses of somekind. While I understand what Denis tried to do here, the premise he took is wrong: traits are not a multiple inheritance mechanism (even if they can be used to simulate it), traits are a *composition* strategy (and there is a trait composition arithmetic that is somekind complex that needs to be taken into account). As a result, the price of simulating a multiple-inheritance scenario where there is not was complexifying the model at levels way higher than desired. Also it was not working properly and patching it to make it work was resulting on re-writing all the trait arithmetic at UI level. So the right approach here is just to remove. And to be clear: I'm not oposed to the existence of a plugin that hides methods comming from traits (even if I think is incorrect because once a trait is applied, those methods actually 'belong' to the class). But in case you want something like this, it can be implemented in a much simpler way by not mixing what a superclass and a trait is. 2. Second PR also eliminates something :) This time I eliminate the inclusion of metaclasses in the extension list while displaying a package. Again, I understand what Denis tried to do: to easy the view of which classes are extended in the class side and the ones that are extended in instance side. Problem with thid is that it was breaking completely the cognitive model the system browser offers, which is already complex enough to add also an exceptional behaviour. Anyway, this list now works as before: if there are extensions classes are shown and to see the class side extensions you need to click in class side option. cheers! Esteban

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by John M McIntosh

Although xCode makes much of that process easier it is just a GUI front end for a bunch of command line tools. You can re-sign and submit an app from the command line for enterprise usage, no doubt the same for the store. Apple at one time had a utility app to submit apps to the store for people needed to sub 100âs of apps at a time. .... John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk On Sun, Oct 28, 2018 at 21:04, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > I'm more about wanting an iOS VM and to do that you need to build and sign through Apple's tool set as far as I know. > > And the debugging experience is much more pleasant - especially when making FFI calls into Apple's system libraries. > > CMake can build an Xcode project from a CMake build system I believe. At least there is a cross platform marine navigation project called OpenCPN (written in C++ and which relies on wxWidgets) that does this. > > So I'm not arguing to have the official builds in Xcode, but if you want to build an app and ship it on iPhone or Mac, Xcode is the build system you are going to need to submit it to the App store. > >> On Oct 28, 2018, at 12:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Todd, >> >> On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: >> >>> Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? >> >> First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). >> >> Second, my reasons for not using Xcode projects for building the Mac VMs are that >> - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable >> - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools >> >> However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. >> >> _,,,^..^,,,_ >> best, Eliot

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Todd Blanchard

I'm more about wanting an iOS VM and to do that you need to build and sign through Apple's tool set as far as I know. And the debugging experience is much more pleasant - especially when making FFI calls into Apple's system libraries. CMake can build an Xcode project from a CMake build system I believe. At least there is a cross platform marine navigation project called OpenCPN (written in C++ and which relies on wxWidgets) that does this. So I'm not arguing to have the official builds in Xcode, but if you want to build an app and ship it on iPhone or Mac, Xcode is the build system you are going to need to submit it to the App store. > On Oct 28, 2018, at 12:27 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Todd, > > On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: > Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? > > First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). > > Second, my reasons for not using Xcode projects for building the Mac VMs are that > - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable > - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools > > However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. > > _,,,^..^,,,_ > best, Eliot

Oct. 29, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Eliot Miranda

Hi Todd, On Fri, Oct 26, 2018 at 10:00 AM Todd Blanchard via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Does anyone have Xcode projects for building the VM on iOS or Mac? Can > they share them or give me some tips for setting one up? > First I'd like to know your use case. I presume it;'s for debugging, but it may be more for browsing. Can you say? (Personally I find raw lldb adequate for debugging). Second, my reasons for not using Xcode projects for building the Mac VMs are that - Xcode projects, being a serialization of an object graph, are difficult to edit, and they offer no parameterisation, so whereas there is one small set of makefiles (8 in all) for all of the 32-bit and 64-bit builds on Mac, there had to be a separate Xcode project for each build. When adding Spur this was simply unsupportable - clearly Xcode is not necessary for building, browsing, or debugging; people are able to accomplish all three tasks using other tools However, I do appreciate that Xcode is a more pleasant and higher-level GUI interface than the shell, make, lldb and one's favorite editor. What I would support is a tool that created an Xcode project from Makefiles; such tools used to exist. I'd love to see such a tool. What I will fight against until my dying breath is any attempt to replace the Makefile based build system with Xcode. I hope the reasons above justify why. _,,,^..^,,,_ best, Eliot

Oct. 28, 2018

Re: [Pharo-dev] [squeak-dev] Open Croquet will ahve issues in next version of Mac OS X

by Nikolay Suslov

Hello Lawson, Thanks for raising that question about 64 bit future of Open Croquet and Mac OS X support. I have tested the possibility of running Open Croquet on recent 64 bit version of Squeak 5.2. And it seems to be working, on Windows at least. Due to the B3DAccelerator and Croquet plugins, which are available in recent Squeak 64 bit VMs (there are still some issues with B3DAccelerator plugin on macOS). Here is preloaded image for Squeak: https://www.krestianstvo.org/sdk/croquet/Squeak5.2-18225-64bit-Croquet-Imag… Yes, you are right, that replication from participant running Croquet 64 bit image onto participant with 32 bit image or vice versa will not work properly by default. What is about supporting of 3D graphics in future versions of macOS, may be the time is coming to think about Metal FFI bindings. And yes, potentially this integration should work on Pharo too. Best regards, Nikolai On Mon, Oct 22, 2018 at 11:24 PM LawsonEnglish <LEnglish5(a)cox.net> wrote: > https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ > > > This sounds really cool, but thereâs an issue coming up: > > Apple is doing away with ANY support for 32-bit apps and plugins and of > course, Croquet is built for 32-bits and uses 32-bit plugins all over the > place. > > > > Croquet could STILL be the killer-app for Smalltalk even though it never > realized its potential in the past, and it wonât be able to if something > isnât done about the looming 32-bit vs 64-bit issue. > > Need I point out that it should work on Pharo just the same way it does on > Squeak? > > L > >

Oct. 28, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Denis Kudriashov

What about different names? UIManager default chooseFileIn: aFileReference withExtensions: #() title: 'title' UIManager default chooseFileForSaveIn: aFileReference withExtensions: #() title: 'title' We can just expect file references because it is what is exposed to users in pharo file system. Not neccessery to put it in method name. Ð¿Ñ, 26 Ð¾ÐºÑ. 2018 Ð³., 16:32 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi all, > > I've proposed a PR with some cleanups in this respect > > https://github.com/pharo-project/pharo/pull/1941 > > This is the proposed replacement API that returns file references instead > of streams or file names. > > "Get existing file reference" > UIManager default > chooseExistingFileReference: 'title' > extensions: nil > path: FileSystem workingDirectory. > > "Get existing file reference filtering by extensions" > UIManager default > chooseExistingFileReference: 'title' > extensions: #('log') > path: FileSystem workingDirectory. > > "Get existing file reference to file" > UIManager default > chooseExistingFileReference: 'title' > extensions: nil > path: FileSystem workingDirectory / 'PharoDebug.log'. > > "Get file reference for save (not necessarily existing)" > UIManager default > chooseForSaveFileReference: 'title' > extensions: #('log') > path: 'PharoDebuasdg.log'. > > On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Ok, so can we agree on deprecating the non compatible methods and >> redirect the user to the new ones? >> >> To me, the problem with returning a stream is that from a user >> perspective you don't know: >> - is the file encoded or binary >> - if it is encoded, in which encoding? >> - if i receive an open file stream, and I want to delete that file I >> have to close it, retrieve the file, delete it? >> - IMHO, what is the worst: whose responsibility is it to close the file? >> >> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >>> > It should return a FileReference, not an open stream. I believe there >>> are methods that do that. >>> >>> There are different APIs for that. >>> >>> fileOpen*, as the name implies, _opens the file_ and returns the stream. >>> (I think this should be the case for fileSave*) >>> >>> If you want file reference, then you can use e.g. >>> >>> UIManager default chooseFileMatching: #() label: nil >>> >>> or `chooseFileMatching:label:`, >>> `chooseFileName:extensions:path:preview:`, >>> `chooseFullFileName:extensions:path:preview:`, >>> `chooseFullFileNameMatching:label:`. >>> Also some methods for selecting directories >>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >>> >>> iirc some of them actually return String (file path) instead of >>> FileReference. ( >>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >>> ) >>> >>> So it can be confusing, but the API is already available. >>> >>> Also iirc UIManager should be preferred over UITheme builder. >>> >>> Peter >>> >>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> >>>> >>>> >>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>>> > >>>> > Hi, >>>> > >>>> > A question to those who worked on the new streams for Pharo 7: >>>> > >>>> > >>>> > In PHARO 6 I used the following expression to open a file dialog and >>>> let the user choose >>>> > a binary file: >>>> > >>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: >>>> #('exe'). >>>> > >>>> > This returned >>>> > - either nil (when file dialog was canceled) >>>> > - a "MultiByteFileStream" instance when a file was selected >>>> > >>>> > The MultiByteFileStream instance already had the name of the file (= >>>> full path) and I was >>>> > able to query it for further use: >>>> > >>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>> > s name inspect >>>> > >>>> > (for instance to display which file is processed in a window by >>>> showing the full path) >>>> > >>>> > >>>> > >>>> > Now in PHARO 7 same expression returns an instance of >>>> ZnCharacterReadStream (as MultiByteFileStream >>>> > is deprecated): >>>> > >>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>> > >>>> > and ZnCharacterReadStream does not understand #name - and in fact >>>> the info about the name is >>>> > totally lost/not available. To me this looks missing/broken. >>>> > >>>> > So what is the recommended way in Pharo 7 to open a file dialog, let >>>> the use choose a file >>>> > and get a file stream but also the name? IMHO this is either broken >>>> or missing... >>>> > >>>> > Thanks >>>> > T. >>>> >>>> It should return a FileReference, not an open stream. I believe there >>>> are methods that do that. >>>> >>>> But that is an incompatible API change (same selector, different return >>>> type). So hard to decide. >>>> >>>> >>>> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - *http://www.cnrs.fr >> <http://www.cnrs.fr>* >> >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io> >> >> *Phone: *+33 06 52 70 66 13 >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Oct. 27, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Esteban Lorenzano

Iâm sorry I forget to answer your mail :( Anyway, my response was not something you wanted to hear: I maintained the iOS version of the VM and up to three years ago (before spur) it was working, but I didnât try it since a lot of time and most of the work I did (who was based in CMakeMaker) is now not used anymore so I do not think they will work âout of the boxâ if needed. I find sad that we have to depend on otherâs Xcode projects to being able to do something, but wellâ¦ is better than nothing :) Esteban > On 26 Oct 2018, at 19:55, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Todd Blanchard <tblanchard(a)mac.com> > Subject: Re: [Pharo-dev] Xcode projects for VM on iOS or Mac? > Date: 26 October 2018 at 19:55:24 CEST > To: John M McIntosh <johnmci(a)smalltalkconsulting.com>, Pharo Development List <pharo-dev(a)lists.pharo.org> > > > That would be super awesome! Please let me know if/when you do. > > Thanks, > -Todd Blanchard > >> On Oct 26, 2018, at 9:43 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com <mailto:johnmci@smalltalkconsulting.com>> wrote: >> >> I have one. I should see about adding it to a branch. >> >> .... >> John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk> >> >> >> >> >> On Fri, Oct 26, 2018 at 09:39, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: >>> Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? >>> >>> Thanks, >>> -Todd > > >

Oct. 27, 2018

Re: [Pharo-dev] About #zipped / #unzipped

by Stephane Ducasse

+1 On Tue, Oct 23, 2018 at 10:50 AM Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > > On 18 Oct 2018, at 20:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. > > > > (note also that there are no real users of these methods) > > > > Right now it seems cool that the following is an identity. > > > > 'foobar' zipped unzipped. > > > > However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. > > > > Of course, the current methods are broken, as can be seen from a more complex (wide) string. > > > > 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> > > > > The error results from some implicit/wrong character encoding being used. > > > > The right way to do this is to explicitly encode/decode the string. > > > > (GZipReadStream on: (ByteArray streamContents: [ :out | > > (GZipWriteStream on: out) > > nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; > > close ])) upToEnd utf8Decoded. > > > > From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. > > > > 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. > > > > This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded > > > > What do you think ? > > > > Yes, to me this sounds interestingâ¦ I think compression is indeed better done on the level of bytes then on Strings. > > > Marcus > >

Oct. 26, 2018

Re: [Pharo-dev] Where to discuss strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Stephane Ducasse

Hi Bernhard we are interested in that topics. This is why I wrote the botsinc book in the past and more recently learning OOP with TDD in Pharo book. Now I do not have much resources for the topic. Stef On Fri, Oct 26, 2018 at 2:16 PM Bernhard HÃ¶fner <bernhard.hoefner(a)gmx.de> wrote: > > > Hello Group. I like to discuss about the subject and have also some ideas. But I want to ask first for the proper list within the forum. I heard that there is a discussion ongoing and want to participate. > > > > I will send this question to Squeak and Pharo usegroup and to the Phratch-developer. I assume that there is a common discussion about the subject. Hopefully there is no need to open on each platform an individual thread. > > > > Regards, Bernhard >

Oct. 26, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Stephane Ducasse

go go go! FileReference! On Fri, Oct 26, 2018 at 3:12 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, so can we agree on deprecating the non compatible methods and redirect > the user to the new ones? > > To me, the problem with returning a stream is that from a user perspective > you don't know: > - is the file encoded or binary > - if it is encoded, in which encoding? > - if i receive an open file stream, and I want to delete that file I have > to close it, retrieve the file, delete it? > - IMHO, what is the worst: whose responsibility is it to close the file? > > On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > It should return a FileReference, not an open stream. I believe there >> are methods that do that. >> >> There are different APIs for that. >> >> fileOpen*, as the name implies, _opens the file_ and returns the stream. >> (I think this should be the case for fileSave*) >> >> If you want file reference, then you can use e.g. >> >> UIManager default chooseFileMatching: #() label: nil >> >> or `chooseFileMatching:label:`, >> `chooseFileName:extensions:path:preview:`, >> `chooseFullFileName:extensions:path:preview:`, >> `chooseFullFileNameMatching:label:`. >> Also some methods for selecting directories >> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >> >> iirc some of them actually return String (file path) instead of >> FileReference. ( >> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >> ) >> >> So it can be confusing, but the API is already available. >> >> Also iirc UIManager should be preferred over UITheme builder. >> >> Peter >> >> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> >>> >>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>> > >>> > Hi, >>> > >>> > A question to those who worked on the new streams for Pharo 7: >>> > >>> > >>> > In PHARO 6 I used the following expression to open a file dialog and >>> let the user choose >>> > a binary file: >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > >>> > This returned >>> > - either nil (when file dialog was canceled) >>> > - a "MultiByteFileStream" instance when a file was selected >>> > >>> > The MultiByteFileStream instance already had the name of the file (= >>> full path) and I was >>> > able to query it for further use: >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > s name inspect >>> > >>> > (for instance to display which file is processed in a window by >>> showing the full path) >>> > >>> > >>> > >>> > Now in PHARO 7 same expression returns an instance of >>> ZnCharacterReadStream (as MultiByteFileStream >>> > is deprecated): >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > >>> > and ZnCharacterReadStream does not understand #name - and in fact >>> the info about the name is >>> > totally lost/not available. To me this looks missing/broken. >>> > >>> > So what is the recommended way in Pharo 7 to open a file dialog, let >>> the use choose a file >>> > and get a file stream but also the name? IMHO this is either broken or >>> missing... >>> > >>> > Thanks >>> > T. >>> >>> It should return a FileReference, not an open stream. I believe there >>> are methods that do that. >>> >>> But that is an incompatible API change (same selector, different return >>> type). So hard to decide. >>> >>> >>> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 >

Oct. 26, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by Todd Blanchard

That would be super awesome! Please let me know if/when you do. Thanks, -Todd Blanchard > On Oct 26, 2018, at 9:43 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com> wrote: > > I have one. I should see about adding it to a branch. > > .... > John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk <https://www.linkedin.com/in/smalltalk> > > > > > On Fri, Oct 26, 2018 at 09:39, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> wrote: >> Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? >> >> Thanks, >> -Todd

Oct. 26, 2018

Re: [Pharo-dev] Xcode projects for VM on iOS or Mac?

by John M McIntosh

I have one. I should see about adding it to a branch. .... John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk On Fri, Oct 26, 2018 at 09:39, Todd Blanchard via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? > > Thanks, > -Todd

Oct. 26, 2018

Xcode projects for VM on iOS or Mac?

by Todd Blanchard

Does anyone have Xcode projects for building the VM on iOS or Mac? Can they share them or give me some tips for setting one up? Thanks, -Todd

Oct. 26, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Sven Van Caekenberghe

Looks fine. > On 26 Oct 2018, at 17:31, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > I've proposed a PR with some cleanups in this respect > > https://github.com/pharo-project/pharo/pull/1941 > > This is the proposed replacement API that returns file references instead of streams or file names. > > "Get existing file reference" > UIManager default > chooseExistingFileReference: 'title' > extensions: nil > path: FileSystem workingDirectory. > > "Get existing file reference filtering by extensions" > UIManager default > chooseExistingFileReference: 'title' > extensions: #('log') > path: FileSystem workingDirectory. > > "Get existing file reference to file" > UIManager default > chooseExistingFileReference: 'title' > extensions: nil > path: FileSystem workingDirectory / 'PharoDebug.log'. > > "Get file reference for save (not necessarily existing)" > UIManager default > chooseForSaveFileReference: 'title' > extensions: #('log') > path: 'PharoDebuasdg.log'. > > On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, so can we agree on deprecating the non compatible methods and redirect the user to the new ones? > > To me, the problem with returning a stream is that from a user perspective you don't know: > - is the file encoded or binary > - if it is encoded, in which encoding? > - if i receive an open file stream, and I want to delete that file I have to close it, retrieve the file, delete it? > - IMHO, what is the worst: whose responsibility is it to close the file? > > On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > It should return a FileReference, not an open stream. I believe there are methods that do that. > > There are different APIs for that. > > fileOpen*, as the name implies, _opens the file_ and returns the stream. (I think this should be the case for fileSave*) > > If you want file reference, then you can use e.g. > > UIManager default chooseFileMatching: #() label: nil > > or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`, `chooseFullFileName:extensions:path:preview:`, `chooseFullFileNameMatching:label:`. > Also some methods for selecting directories (`chooseDirectory:path:`, chooseDirectory:from:`, ...) > > iirc some of them actually return String (file path) instead of FileReference. ( https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… ) > > So it can be confusing, but the API is already available. > > Also iirc UIManager should be preferred over UITheme builder. > > Peter > > On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > A question to those who worked on the new streams for Pharo 7: > > > > > > In PHARO 6 I used the following expression to open a file dialog and let the user choose > > a binary file: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > This returned > > - either nil (when file dialog was canceled) > > - a "MultiByteFileStream" instance when a file was selected > > > > The MultiByteFileStream instance already had the name of the file (= full path) and I was > > able to query it for further use: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > s name inspect > > > > (for instance to display which file is processed in a window by showing the full path) > > > > > > > > Now in PHARO 7 same expression returns an instance of ZnCharacterReadStream (as MultiByteFileStream > > is deprecated): > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > and ZnCharacterReadStream does not understand #name - and in fact the info about the name is > > totally lost/not available. To me this looks missing/broken. > > > > So what is the recommended way in Pharo 7 to open a file dialog, let the use choose a file > > and get a file stream but also the name? IMHO this is either broken or missing... > > > > Thanks > > T. > > It should return a FileReference, not an open stream. I believe there are methods that do that. > > But that is an incompatible API change (same selector, different return type). So hard to decide. > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13 > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Oct. 26, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Guillermo Polito

Hi all, I've proposed a PR with some cleanups in this respect https://github.com/pharo-project/pharo/pull/1941 This is the proposed replacement API that returns file references instead of streams or file names. "Get existing file reference" UIManager default chooseExistingFileReference: 'title' extensions: nil path: FileSystem workingDirectory. "Get existing file reference filtering by extensions" UIManager default chooseExistingFileReference: 'title' extensions: #('log') path: FileSystem workingDirectory. "Get existing file reference to file" UIManager default chooseExistingFileReference: 'title' extensions: nil path: FileSystem workingDirectory / 'PharoDebug.log'. "Get file reference for save (not necessarily existing)" UIManager default chooseForSaveFileReference: 'title' extensions: #('log') path: 'PharoDebuasdg.log'. On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Ok, so can we agree on deprecating the non compatible methods and redirect > the user to the new ones? > > To me, the problem with returning a stream is that from a user perspective > you don't know: > - is the file encoded or binary > - if it is encoded, in which encoding? > - if i receive an open file stream, and I want to delete that file I have > to close it, retrieve the file, delete it? > - IMHO, what is the worst: whose responsibility is it to close the file? > > On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > It should return a FileReference, not an open stream. I believe there >> are methods that do that. >> >> There are different APIs for that. >> >> fileOpen*, as the name implies, _opens the file_ and returns the stream. >> (I think this should be the case for fileSave*) >> >> If you want file reference, then you can use e.g. >> >> UIManager default chooseFileMatching: #() label: nil >> >> or `chooseFileMatching:label:`, >> `chooseFileName:extensions:path:preview:`, >> `chooseFullFileName:extensions:path:preview:`, >> `chooseFullFileNameMatching:label:`. >> Also some methods for selecting directories >> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >> >> iirc some of them actually return String (file path) instead of >> FileReference. ( >> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >> ) >> >> So it can be confusing, but the API is already available. >> >> Also iirc UIManager should be preferred over UITheme builder. >> >> Peter >> >> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> >>> >>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>> > >>> > Hi, >>> > >>> > A question to those who worked on the new streams for Pharo 7: >>> > >>> > >>> > In PHARO 6 I used the following expression to open a file dialog and >>> let the user choose >>> > a binary file: >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > >>> > This returned >>> > - either nil (when file dialog was canceled) >>> > - a "MultiByteFileStream" instance when a file was selected >>> > >>> > The MultiByteFileStream instance already had the name of the file (= >>> full path) and I was >>> > able to query it for further use: >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > s name inspect >>> > >>> > (for instance to display which file is processed in a window by >>> showing the full path) >>> > >>> > >>> > >>> > Now in PHARO 7 same expression returns an instance of >>> ZnCharacterReadStream (as MultiByteFileStream >>> > is deprecated): >>> > >>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>> > >>> > and ZnCharacterReadStream does not understand #name - and in fact >>> the info about the name is >>> > totally lost/not available. To me this looks missing/broken. >>> > >>> > So what is the recommended way in Pharo 7 to open a file dialog, let >>> the use choose a file >>> > and get a file stream but also the name? IMHO this is either broken or >>> missing... >>> > >>> > Thanks >>> > T. >>> >>> It should return a FileReference, not an open stream. I believe there >>> are methods that do that. >>> >>> But that is an incompatible API change (same selector, different return >>> type). So hard to decide. >>> >>> >>> > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 26, 2018

Effect Handlers

by Eliot Miranda

Hi All, I found this write up instructive and well-written: https://www.quora.com/What-are-some-features-youd-want-a-new-programming-la… _,,,^..^,,,_ (phone)

Oct. 26, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Sven Van Caekenberghe

> On 26 Oct 2018, at 15:11, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Ok, so can we agree on deprecating the non compatible methods and redirect the user to the new ones? > > To me, the problem with returning a stream is that from a user perspective you don't know: > - is the file encoded or binary > - if it is encoded, in which encoding? > - if i receive an open file stream, and I want to delete that file I have to close it, retrieve the file, delete it? > - IMHO, what is the worst: whose responsibility is it to close the file? Well said, agreed on all points. Using a FileReference is soo much better. > On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > It should return a FileReference, not an open stream. I believe there are methods that do that. > > There are different APIs for that. > > fileOpen*, as the name implies, _opens the file_ and returns the stream. (I think this should be the case for fileSave*) > > If you want file reference, then you can use e.g. > > UIManager default chooseFileMatching: #() label: nil > > or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`, `chooseFullFileName:extensions:path:preview:`, `chooseFullFileNameMatching:label:`. > Also some methods for selecting directories (`chooseDirectory:path:`, chooseDirectory:from:`, ...) > > iirc some of them actually return String (file path) instead of FileReference. ( https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… ) > > So it can be confusing, but the API is already available. > > Also iirc UIManager should be preferred over UITheme builder. > > Peter > > On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi, > > > > A question to those who worked on the new streams for Pharo 7: > > > > > > In PHARO 6 I used the following expression to open a file dialog and let the user choose > > a binary file: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > This returned > > - either nil (when file dialog was canceled) > > - a "MultiByteFileStream" instance when a file was selected > > > > The MultiByteFileStream instance already had the name of the file (= full path) and I was > > able to query it for further use: > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > s name inspect > > > > (for instance to display which file is processed in a window by showing the full path) > > > > > > > > Now in PHARO 7 same expression returns an instance of ZnCharacterReadStream (as MultiByteFileStream > > is deprecated): > > > > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). > > > > and ZnCharacterReadStream does not understand #name - and in fact the info about the name is > > totally lost/not available. To me this looks missing/broken. > > > > So what is the recommended way in Pharo 7 to open a file dialog, let the use choose a file > > and get a file stream but also the name? IMHO this is either broken or missing... > > > > Thanks > > T. > > It should return a FileReference, not an open stream. I believe there are methods that do that. > > But that is an incompatible API change (same selector, different return type). So hard to decide. > > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Oct. 26, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Guillermo Polito

Ok, so can we agree on deprecating the non compatible methods and redirect the user to the new ones? To me, the problem with returning a stream is that from a user perspective you don't know: - is the file encoded or binary - if it is encoded, in which encoding? - if i receive an open file stream, and I want to delete that file I have to close it, retrieve the file, delete it? - IMHO, what is the worst: whose responsibility is it to close the file? On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > It should return a FileReference, not an open stream. I believe there > are methods that do that. > > There are different APIs for that. > > fileOpen*, as the name implies, _opens the file_ and returns the stream. > (I think this should be the case for fileSave*) > > If you want file reference, then you can use e.g. > > UIManager default chooseFileMatching: #() label: nil > > or `chooseFileMatching:label:`, `chooseFileName:extensions:path:preview:`, > `chooseFullFileName:extensions:path:preview:`, > `chooseFullFileNameMatching:label:`. > Also some methods for selecting directories > (`chooseDirectory:path:`, chooseDirectory:from:`, ...) > > iirc some of them actually return String (file path) instead of > FileReference. ( > https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… > ) > > So it can be confusing, but the API is already available. > > Also iirc UIManager should be preferred over UITheme builder. > > Peter > > On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> >> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >> > >> > Hi, >> > >> > A question to those who worked on the new streams for Pharo 7: >> > >> > >> > In PHARO 6 I used the following expression to open a file dialog and >> let the user choose >> > a binary file: >> > >> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >> > >> > This returned >> > - either nil (when file dialog was canceled) >> > - a "MultiByteFileStream" instance when a file was selected >> > >> > The MultiByteFileStream instance already had the name of the file (= >> full path) and I was >> > able to query it for further use: >> > >> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >> > s name inspect >> > >> > (for instance to display which file is processed in a window by showing >> the full path) >> > >> > >> > >> > Now in PHARO 7 same expression returns an instance of >> ZnCharacterReadStream (as MultiByteFileStream >> > is deprecated): >> > >> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >> > >> > and ZnCharacterReadStream does not understand #name - and in fact the >> info about the name is >> > totally lost/not available. To me this looks missing/broken. >> > >> > So what is the recommended way in Pharo 7 to open a file dialog, let >> the use choose a file >> > and get a file stream but also the name? IMHO this is either broken or >> missing... >> > >> > Thanks >> > T. >> >> It should return a FileReference, not an open stream. I believe there are >> methods that do that. >> >> But that is an incompatible API change (same selector, different return >> type). So hard to decide. >> >> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 26, 2018

Where to discuss strategies and tools for a comeback of Smalltalk using Scratch as entrance

by Bernhard HÃ¶fner

> Hello Group. I like to discuss about the subject and have also some ideas. But I want to ask first for the proper list within the forum. I heard that there is a discussion ongoing and want to participate. > > I will send this question to Squeak and Pharo usegroup and to the Phratch-developer. I assume that there is a common discussion about the subject. Hopefully there is no need to open on each platform an individual thread. > > Regards, Bernhard

Oct. 26, 2018

[Pharo 7.0-dev] Build #1349: 22602-Add-spec-demos-to-help-menu

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

There is a new Pharo build available! The status of the build #1349 was: SUCCESS. The Pull Request #1936 was integrated: "22602-Add-spec-demos-to-help-menu" Pull request url: https://github.com/pharo-project/pharo/pull/1936 Issue Url: https://pharo.fogbugz.com/f/cases/22602 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 26, 2018

[Pharo 7.0-dev] Build #1348: 22512-Test-runner-browse-method-does-not-work

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

There is a new Pharo build available! The status of the build #1348 was: SUCCESS. The Pull Request #1937 was integrated: "22512-Test-runner-browse-method-does-not-work" Pull request url: https://github.com/pharo-project/pharo/pull/1937 Issue Url: https://pharo.fogbugz.com/f/cases/22512 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 26, 2018

[Pharo 7.0-dev] Build #1347: 22567 - Moved back Array2D and its test into collection packages.

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

There is a new Pharo build available! The status of the build #1347 was: SUCCESS. The Pull Request #1919 was integrated: "22567 - Moved back Array2D and its test into collection packages." Pull request url: https://github.com/pharo-project/pharo/pull/1919 Issue Url: https://pharo.fogbugz.com/f/cases/22567 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

Re: [Pharo-dev] STON updates/improvements

by Sven Van Caekenberghe

Hi Henrik, I implemented some of your suggestions and did some cleanups: === Name: STON-Core-SvenVanCaekenberghe.97 Author: SvenVanCaekenberghe Time: 23 October 2018, 3:32:00.595497 pm UUID: a627a421-4735-0d00-8c11-99b80be56389 Ancestors: STON-Core-SvenVanCaekenberghe.96 make #stonName a Symbol everywhere and add comments to STONReader>>#lookupClass: add an #asString conversion in STONReader>>#parseNamedInstVarsFor: to ease porting fix STONCStyleCommentsSkipStream>>#readInto:startingAt:count: and add #testBlockReading change the implementation of STONReaderError>>#messageText to ease porting === Name: STON-Tests-SvenVanCaekenberghe.90 Author: SvenVanCaekenberghe Time: 23 October 2018, 3:32:18.123909 pm UUID: 309faf22-4735-0d00-8c12-16b60be56389 Ancestors: STON-Tests-SvenVanCaekenberghe.89 make #stonName a Symbol everywhere and add comments to STONReader>>#lookupClass: add an #asString conversion in STONReader>>#parseNamedInstVarsFor: to ease porting fix STONCStyleCommentsSkipStream>>#readInto:startingAt:count: and add #testBlockReading change the implementation of STONReaderError>>#messageText to ease porting === Or https://github.com/svenvc/ston/commit/90a96aeb7042822f370e6f4cda6f1aed78457… I still do not clearly understand the problems with ScaledDecial. If the implementation is different on the other platform, the writing and reading might need different implementations, but the general syntax, <nominator>/<denominator>[s<scale>] can remain the same, no ? Sven > On 18 Oct 2018, at 11:03, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> 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. 23, 2018

[Pharo 7.0-dev] Build #1346: 22585 Tag ManifestSystemSupport and related classes in System-Support

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

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

Oct. 23, 2018

[Pharo 7.0-dev] Build #1345: 22598 Tag ManifestManifestTests and other classes in Manifest-Tests

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

There is a new Pharo build available! The status of the build #1345 was: FAILURE. The Pull Request #1934 was integrated: "22598 Tag ManifestManifestTests and other classes in Manifest-Tests" Pull request url: https://github.com/pharo-project/pharo/pull/1934 Issue Url: https://pharo.fogbugz.com/f/cases/22598 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

Re: [Pharo-dev] About #zipped / #unzipped

by Marcus Denker

> On 18 Oct 2018, at 20:59, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. > > (note also that there are no real users of these methods) > > Right now it seems cool that the following is an identity. > > 'foobar' zipped unzipped. > > However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. > > Of course, the current methods are broken, as can be seen from a more complex (wide) string. > > 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> > > The error results from some implicit/wrong character encoding being used. > > The right way to do this is to explicitly encode/decode the string. > > (GZipReadStream on: (ByteArray streamContents: [ :out | > (GZipWriteStream on: out) > nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; > close ])) upToEnd utf8Decoded. > > From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. > > 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. > > This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded > > What do you think ? > Yes, to me this sounds interestingâ¦ I think compression is indeed better done on the level of bytes then on Strings. Marcus

Oct. 23, 2018

[Pharo 7.0-dev] Build #1344: 22599 Tag ManifestPharoBootstrapInitialization and related classes

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

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

Oct. 23, 2018

[Pharo 7.0-dev] Build #1343: 22593-GZipReadStream-enhancement-Pharo-7-streams-and-tests

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

There is a new Pharo build available! The status of the build #1343 was: SUCCESS. The Pull Request #1929 was integrated: "22593-GZipReadStream-enhancement-Pharo-7-streams-and-tests" Pull request url: https://github.com/pharo-project/pharo/pull/1929 Issue Url: https://pharo.fogbugz.com/f/cases/22593 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

[Pharo 7.0-dev] Build #1342: 22223 Categorize classes in System-Changes

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

There is a new Pharo build available! The status of the build #1342 was: FAILURE. The Pull Request #1930 was integrated: "22223 Categorize classes in System-Changes" Pull request url: https://github.com/pharo-project/pharo/pull/1930 Issue Url: https://pharo.fogbugz.com/f/cases/22223 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Oct. 23, 2018

Open Croquet will ahve issues in next version of Mac OS X

by LawsonEnglish

https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/ <https://blog.krestianstvo.org/en/open-croquet-for-squeak-6/> This sounds really cool, but thereâs an issue coming up: Apple is doing away with ANY support for 32-bit apps and plugins and of course, Croquet is built for 32-bits and uses 32-bit plugins all over the place. Croquet could STILL be the killer-app for Smalltalk even though it never realized its potential in the past, and it wonât be able to if something isnât done about the looming 32-bit vs 64-bit issue. Need I point out that it should work on Pharo just the same way it does on Squeak? L

Oct. 22, 2018

[Pharo 7.0-dev] Build #1341: 22591-MoticellowarnAboutLosingChangesTo-is-dead-code

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

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

Oct. 22, 2018

[ANN] Next Pharo Sprint: Oct 26

by Marcus Denker

We will organize a Pharo sprint / Moose dojo Oct 26, starting at 10:00am. (Local Time Paris). Goals of this sprint: â¢ Pharo 7 issues Remote Sprint: Remotely, you can join us on Discord. During the sprint, we synchronize local and remote Pharo sprinters: http://pharo.org/contribute-events Known Local Sprint meetings Lille/France: It will be at the Inria Lille, Building B, third floor (RMoD offices). As the building is not open to the public, please contact us before if you plan to come https://association.pharo.org/event-2973622

Oct. 22, 2018

About #zipped / #unzipped

by Sven Van Caekenberghe

Hi, Given https://pharo.fogbugz.com/f/cases/21858/Cleanup-remaining-DeprecatedFileSys… [where we need more help !!] I found String>>#zipped to be one of the users of the deprecated RWBinaryOrTextStream. Although this usage is easy enough to fix, I think the current #zipped / #unzipped on String is broken. (note also that there are no real users of these methods) Right now it seems cool that the following is an identity. 'foobar' zipped unzipped. However, the result of zipping something is actual something binary (a collection of opaque bytes). Thinking of it, the input is actually also bytes, not unencoded characters. Of course, the current methods are broken, as can be seen from a more complex (wide) string. 'Ã©lÃ¨ves FranÃ§aises @ 10 â¬' zipped unzipped. >>> <something very weird> The error results from some implicit/wrong character encoding being used. The right way to do this is to explicitly encode/decode the string. (GZipReadStream on: (ByteArray streamContents: [ :out | (GZipWriteStream on: out) nextPutAll: 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded; close ])) upToEnd utf8Decoded. >From this it would follow that #zipped / #unzipped would make more sense on ByteArray. So that the above identity would become. 'Ã©lÃ¨ves FranÃ§aises Ã 10 â¬' utf8Encoded zipped unzipped utf8Decoded. This change of signature would be comparable to what we recently did with #base64Encoded / #base64Decoded What do you think ? Sven

Oct. 18, 2018