- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0

by Alistair Grant

On Fri, 4 Jan 2019 at 10:36, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > At the risk of being pedantic, if we were really serious, for mid term, it would be good to not compile ssl, but just link. > > https://www.cvedetails.com/vulnerability-list/vendor_id-217/product_id-383/… We'll need to keep this on the ToDo list for this year: openssl 1.0.2 goes out of support this December 2019. The current version we're using, 1.0.2l, is also out of date, the current release being 1.0.2q. I'll probably have a go at building that version. Cheers, Alistair

Jan. 4, 2019

[Pharo 7.0] Build #98: Fixed issue 22688.

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

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

Jan. 4, 2019

Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0

by Nicolas Cellier

At the risk of being pedantic, if we were really serious, for mid term, it would be good to not compile ssl, but just link. https://www.cvedetails.com/vulnerability-list/vendor_id-217/product_id-383/… Le ven. 4 janv. 2019 Ã 10:13, Alistair Grant <akgrant0710(a)gmail.com> a Ã©crit : > Hi Guille, > > On Fri, 4 Jan 2019 at 09:54, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > Hi Alistair, > > > > On Fri, Jan 4, 2019 at 9:25 AM Alistair Grant <akgrant0710(a)gmail.com> > wrote: > >> > >> 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). > > > > > > May I ask if you mean commit or push? > > I meant commit. I guess that it is doing a comparison of the image to > the git repository to determine what has changed (to present the > dialog saying which methods have changed). It's a call to free() that > actually causes the problem. > > > > Because commiting should not incure into any network activity and thus > the ssl is never used. > > Which is why I thought it is unrelated :-) > > > > I don't know about the satus of libssl and libgit, but it is certain > that libgit uses libssl, so we have to be careful that the versions of > libgit and libssl are compatible. > > I cloned the pharo repository as a basic check that they are working > together (plus the testing on Ubuntu). > > > >> 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 > > > > > > Super close :) > > :-) > > Cheers, > Alistair > > > >> , but I expect this can > >> wait until Pharo 8.0 if you prefer. > > > > > > Or maybe for a 7.1? > > We should be able to have easier and shorter release cycles in the > future. > > > > Thanks Alistair ^^ > > > >> > >> For convenience: https://www.libssh2.org/ > >> > >> Thanks, > >> Alistair > >> > > > > > > -- > > > > > > > > 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 > >

Jan. 4, 2019

Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0

by Alistair Grant

Hi Guille, On Fri, 4 Jan 2019 at 09:54, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Alistair, > > On Fri, Jan 4, 2019 at 9:25 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> 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). > > > May I ask if you mean commit or push? I meant commit. I guess that it is doing a comparison of the image to the git repository to determine what has changed (to present the dialog saying which methods have changed). It's a call to free() that actually causes the problem. > Because commiting should not incure into any network activity and thus the ssl is never used. Which is why I thought it is unrelated :-) > I don't know about the satus of libssl and libgit, but it is certain that libgit uses libssl, so we have to be careful that the versions of libgit and libssl are compatible. I cloned the pharo repository as a basic check that they are working together (plus the testing on Ubuntu). >> 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 > > > Super close :) :-) Cheers, Alistair >> , but I expect this can >> wait until Pharo 8.0 if you prefer. > > > Or maybe for a 7.1? > We should be able to have easier and shorter release cycles in the future. > > Thanks Alistair ^^ > >> >> For convenience: https://www.libssh2.org/ >> >> Thanks, >> Alistair >> > > > -- > > > > 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

Jan. 4, 2019

Re: [Pharo-dev] libssh2 1.7.0 & 1.8.0

by Guillermo Polito

Hi Alistair, On Fri, Jan 4, 2019 at 9:25 AM Alistair Grant <akgrant0710(a)gmail.com> wrote: > 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). > May I ask if you mean commit or push? Because commiting should not incure into any network activity and thus the ssl is never used. I don't know about the satus of libssl and libgit, but it is certain that libgit uses libssl, so we have to be careful that the versions of libgit and libssl are compatible. > 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 Super close :) > , but I expect this can > wait until Pharo 8.0 if you prefer. > Or maybe for a 7.1? We should be able to have easier and shorter release cycles in the future. Thanks Alistair ^^ > For convenience: https://www.libssh2.org/ > > Thanks, > Alistair > > -- 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

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