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

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