January 2019 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Lazy File Opening in FileHandle

by Guillermo Polito

> > On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <martin(a)hand2mouse.com> > wrote: > >> >> > >> >> Lazy opening is rather odd conceptually, and doesn't seem to meet the >> principle of least surprise, so I'd think deprecating it would be >> reasonable. >> > > Agreed. > Personally I think FileHandle needs some cleanup, to me it looks strange > that it acquires a vm file handle, and then it operates on it through > primitives, when the File class already does that properly. > And even just change the code to do it in a non-lazy way. I don't think the lazy opening is exposed through any of FileSystem's API.

Jan. 4, 2019

Re: [Pharo-dev] Lazy File Opening in FileHandle

by Guillermo Polito

Hi all, On Fri, Jan 4, 2019 at 12:26 AM Martin McClure <martin(a)hand2mouse.com> wrote: > Hi Reg, > > It looks to me like the lazy opening functionality is unused in Pharo 7, > and is not reachable when using the documented "new" API. And I think it never was... or I least I don't remember it being used. Actually the only way to get a file handle is on an (in theory) already open file. See for example that the only place where file handles are instantiated are in open: aResolvable writable: aBoolean "Resolve aResolvable into an absolute path, then ask the store to open the file at that path using the specified access mode." | path | path := self resolve: aResolvable. ^ store handleClass open: (FileReference fileSystem: self path: path) writable: aBoolean > (Somewhat > oddly, one of the more complete documentations of what's recommended > seems to be the class comment of the deprecated class FileStream.) > Well, this thing grew a bit organically. I bet Pavel put that comment there :) > > Lazy opening is rather odd conceptually, and doesn't seem to meet the > principle of least surprise, so I'd think deprecating it would be > reasonable. > Agreed. Personally I think FileHandle needs some cleanup, to me it looks strange that it acquires a vm file handle, and then it operates on it through primitives, when the File class already does that properly. > Regards, > > -Martin > > On 1/2/19 9:15 AM, Reg Krock wrote: > > Guille, > > > > In FileHandle there is a concept of a lazy file opening in > > > > FileHandle>>#at:read:startingAt:count > > FileHandle>>#at:write:startingAt:count > > > > where the method FileHandle>>#assureOpen is called. > > > > Based on out previous conversations I believe that this concept is to be > deprecated. > > > > Can you please confirm. > > > > Regards, > > > > Reg > > > -- 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

Jan. 4, 2019

libssh2 1.7.0 & 1.8.0

by Alistair Grant

Hi Esteban, The VM is currently being built with libssh2 1.7.0, but this doesn't build on ARM v6 (Raspberry Pi) due to changes in openssl. libssh2 1.8.0, which was released in October 2016, builds and appears to function correctly (the VM crashes when attempting to commit from within Iceberg, but I think this is an unrelated problem). I've built and done some ad-hoc testing of libssh2 1.8.0 on linux 64 bit (Ubuntu 16.04) and haven't had any issues. What do you think of upgrading from libssh2 1.7.0 to 1.8.0? I don't know how close Pharo 7.0 is to release, but I expect this can wait until Pharo 8.0 if you prefer. For convenience: https://www.libssh2.org/ Thanks, Alistair

Jan. 4, 2019

Re: [Pharo-dev] Lazy File Opening in FileHandle

by Martin McClure

Hi Reg, It looks to me like the lazy opening functionality is unused in Pharo 7, and is not reachable when using theÂ documented "new" API. (Somewhat oddly, one of the more complete documentations of what's recommended seems to be the class comment of the deprecated class FileStream.) Lazy opening is rather odd conceptually, and doesn't seem to meet the principle of least surprise, so I'd think deprecating it would be reasonable. Regards, -Martin On 1/2/19 9:15 AM, Reg Krock wrote: > Guille, > > In FileHandle there is a concept of a lazy file opening in > > FileHandle>>#at:read:startingAt:count > FileHandle>>#at:write:startingAt:count > > where the method FileHandle>>#assureOpen is called. > > Based on out previous conversations I believe that this concept is to be deprecated. > > Can you please confirm. > > Regards, > > Reg

Jan. 3, 2019

[Pharo 7.0] Build #97: 22862-RubScrolledTextMorph-should-be-able-to-manage-a-ghost-text

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

There is a new Pharo build available! The status of the build #97 was: SUCCESS. The Pull Request #2166 was integrated: "22862-RubScrolledTextMorph-should-be-able-to-manage-a-ghost-text" Pull request url: https://github.com/pharo-project/pharo/pull/2166 Issue Url: https://pharo.fogbugz.com/f/cases/22862 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 3, 2019

Re: [Pharo-dev] Happy new year!

by Arturo Zambrano

Besides wishing you guys a great 2019, it is good opportunity to THANK you a lot for efforts. All the best. Arturo On Wed, Jan 2, 2019 at 8:43 AM Torsten Bergmann <astares(a)gmx.de> wrote: > Happy new year - I'm sure 2019 will be another good year for Pharo > >

Jan. 3, 2019

[Pharo 7.0] Build #96: 21876 Re-evaluating of class definition with slots cleans the class instance variables

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

There is a new Pharo build available! The status of the build #96 was: SUCCESS. The Pull Request #2161 was integrated: "21876 Re-evaluating of class definition with slots cleans the class instance variables " Pull request url: https://github.com/pharo-project/pharo/pull/2161 Issue Url: https://pharo.fogbugz.com/f/cases/21876 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 3, 2019

Re: [Pharo-dev] ZeroConf trouble (curl/64bit)

by Torsten Bergmann

Subbu wrote: >>Does curl -L help? Yes - the documented curl https://get.pharo.org/64 | bash as mentioned on https://get.pharo.org/64/ FAILS while curl -L https://get.pharo.org/64 | bash as well as curl get.pharo.org/64 | bash work. Anyone able to change the template/docu on https://get.pharo.org/64 ? Thx T.

Jan. 2, 2019

Re: [Pharo-dev] ZeroConf trouble (curl/64bit)

by Sven Van Caekenberghe

Last login: Sat Dec 29 19:43:53 on ttys003 prometheus:2018-12-17 sven$ cd /tmp prometheus:tmp sven$ curl get.pharo.org/64/70+vm | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3054 100 3054 0 0 23470 0 --:--:-- --:--:-- --:--:-- 23492 Downloading the latest 70 Image: http://files.pharo.org/get-files/70/pharo64.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/get-files/70/pharo64-mac-stable.zip pharo-vm/Pharo.app/Contents/MacOS/Pharo Creating starter scripts pharo and pharo-ui prometheus:tmp sven$ ./pharo Pharo.image printVersion [version] 'Pharo7.0.0' 'Pharo-7.0.0+rc1.build.95.sha.e5eda48cff58fbdbe71ad02dbc9540d8d3e94875 (64 Bit)' And indeed prometheus:tmp sven$ curl -L get.pharo.org/64 | bash % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 232 100 232 0 0 3406 0 --:--:-- --:--:-- --:--:-- 3411 100 11324 100 11324 0 0 115k 0 --:--:-- --:--:-- --:--:-- 115k Downloading the latest 61 Image: http://files.pharo.org/get-files/61/pharo64.zip Pharo.image Downloading the latest pharoVM: http://files.pharo.org/get-files/61/pharo64-mac-stable.zip pharo-vm/Pharo.app/Contents/MacOS/Pharo Downloading PharoV61.sources: http://files.pharo.org/get-files/61/sources.zip Creating starter scripts pharo and pharo-ui prometheus:tmp sven$ ./pharo Pharo.image printVersion [version] 6.0 #60546 > On 2 Jan 2019, at 12:46, Torsten Bergmann <astares(a)gmx.de> wrote: > > Using ZeroConf on a fresh Ubuntu machine: > > wget -O- https://get.pharo.org/64 | bash > > works but > > curl https://get.pharo.org/64 | bash > > as mentioned on https://get.pharo.org/64/ gives an error: > > > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 237 100 237 0 0 556 0 --:--:-- --:--:-- --:--:-- 555 > bash: line 1: syntax error near unexpected token `newline' > bash: line 1: `<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">' > > > The 32 bit curl works >

Jan. 2, 2019

Re: [Pharo-dev] ZeroConf trouble (curl/64bit)

by K K Subbu

On 02/01/19 5:16 PM, Torsten Bergmann wrote: > Using ZeroConf on a fresh Ubuntu machine: > > wget -O- https://get.pharo.org/64 | bash > > works but > > curl https://get.pharo.org/64 | bash Does curl -L help? HTH .. Subbu

Jan. 2, 2019