- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Alistair Grant

Hi Sven & Guille, On Tue, 25 Sep 2018 at 10:49, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Mon, Sep 24, 2018 at 11:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >> > On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> > >> > Hi Guille, Sven, Esteban and Everyone, >> > >> > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is >> > considered part of the pharo "core" image? >> >> Yes, for me anyway, it is (or should be) part of core. > > > Yes, they are part of the Core image. Simply because an image without any I/O is an image you cannot interact with, so it's kind of useless :) > And an image doing I/O without managing encoding is pretty useless too... Thanks for the confirmation. I suspected this was the case, but didn't want to be wrong later on. > Also, keep in mind that we try to maintain Zn packages in sync with Sven's repository, and we try to keep them loadable/compatible with other pharo versions. > Usually Zn encoders should be stable enough in terms of API and features, but in case you need to extend them in some way we should keep Sven in the loop so we can sync both repositories ^^. Sure, at the moment I can't envisage any required changes. Thanks again, Alistair

Sept. 25, 2018

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Guillermo Polito

On Mon, Sep 24, 2018 at 11:23 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Guille, Sven, Esteban and Everyone, > > > > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is > > considered part of the pharo "core" image? > > Yes, for me anyway, it is (or should be) part of core. > Yes, they are part of the Core image. Simply because an image without any I/O is an image you cannot interact with, so it's kind of useless :) And an image doing I/O without managing encoding is pretty useless too... Also, keep in mind that we try to maintain Zn packages in sync with Sven's repository, and we try to keep them loadable/compatible with other pharo versions. Usually Zn encoders should be stable enough in terms of API and features, but in case you need to extend them in some way we should keep Sven in the loop so we can sync both repositories ^^. Guille

Sept. 25, 2018

Re: [Pharo-dev] update linux info page again, please [CentOS/RHEL]

by Marcus Denker

Hello, I have added it. https://pharo.org/gnu-linux-installation-64 > On 23 Sep 2018, at 18:32, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: update linux info page again, please [CentOS/RHEL] > Date: 23 September 2018 at 18:32:00 CEST > To: pharo-dev(a)lists.pharo.org > > > Hello, > > please, edit CentOS7 installation page: > https://pharo.org/gnu-linux-installation-64 > > and add workaround for CentOS7 section, wihout this symlink, iceberg is broken: > > (do as root) > cd /usr/lib64 > ln -s libcurl.so.4 libcurl-gnutls.so.4 > > Best solution is to put this in the RPM post installation step (I mean RPM from official Pharo CentOS repository) - but we will wait for this fix for months, maybe years, so, workaround info on that page is necessary and easy to manage. > > More details here: > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-July/272624… > > Thanks! pf > > >

Sept. 25, 2018

[ANN] Pharo Consortium New Bronze Member: Spesenfuchs

by Marcus Denker

The Pharo Consortium is very happy to announce that Spesenfuchs has joined the Consortium as a Bronze Member. About - Spesenfuchs: http://spesenfuchs.de - Pharo Consortium: http://consortium.pharo.org The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association: - http://association.pharo.org

Sept. 25, 2018

Re: [Pharo-dev] Files-Core and Zinc-Character-Encoding-Core package load sequence

by Sven Van Caekenberghe

> On 24 Sep 2018, at 21:55, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Guille, Sven, Esteban and Everyone, > > Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is > considered part of the pharo "core" image? Yes, for me anyway, it is (or should be) part of core. > The reason I ask is that I'd like to know whether the File class (which > is part of the Files-Core package) can count on ZnUTF8Encoder (which is > part of the Zinc-Character-Encoding-Core package) being present in the > image. > > If File can count on ZnUTF8Encoder being present then for FileAttributes > I will make UTF8 encoding / decoding available from File, and thus UTF8 > file names will be supported. If it can't count on ZnUTF8Encoder being > present then File will only be able to handle ascii file names (unless > the names are somehow already UTF8 encoded) and support for UTF8 file > names will effectively be restricted to FileSystem. > > > Thanks, > Alistair >

Sept. 24, 2018

Files-Core and Zinc-Character-Encoding-Core package load sequence

by Alistair Grant

Hi Guille, Sven, Esteban and Everyone, Can someone (dis)confirm that the Zinc-Character-Encoding-Core package is considered part of the pharo "core" image? The reason I ask is that I'd like to know whether the File class (which is part of the Files-Core package) can count on ZnUTF8Encoder (which is part of the Zinc-Character-Encoding-Core package) being present in the image. If File can count on ZnUTF8Encoder being present then for FileAttributes I will make UTF8 encoding / decoding available from File, and thus UTF8 file names will be supported. If it can't count on ZnUTF8Encoder being present then File will only be able to handle ascii file names (unless the names are somehow already UTF8 encoded) and support for UTF8 file names will effectively be restricted to FileSystem. Thanks, Alistair

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Eliot Miranda

Hi Petr, along with Estebanâs request for the error code from allocateExecutablePage can you also see whether use of iceberg is successful the second time you launch Pharo? So start up your virtualbox, try and interact with iceberg, quit if it fails, relaunch and try again? Also in your steps what do you do to prepare? eg do you boot in virtualbox, return from sleep, or...? FYI, allocateExecutablePage uses valloc (IIRC) to get a page from the OS and then uses mprotect to add executable permission to the page before answering the pageâs address as the result of the primitive. The callback machinery then uses the page to provide the executable blue code used in implementing callbacks. The address of a code sequence in the page is what is actually handed out to C code as a fu croon pointer. When external code calls this function pointer the code in the sequence invokes a callback into the vm before returning back to C. Consequently it is key that allocateExecutablePage works correctly. If it doesnât then no callbacks. _,,,^..^,,,_ (phone) > On Sep 24, 2018, at 11:11 AM, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > <mime-attachment>

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Petr Fischer

Thanks for your assistance, but sources of this weird behavior is probably in the virtualization layer: http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-September/2… pf > That means > > primAllocateExecutablePage > > failed. > There should be an errorCode value there, that can help us understand better the problem. > > Can you check at it? > > Thanks! > > Esteban > > > On 24 Sep 2018, at 17:49, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > > >

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - solved (probably virtualization problem)

by Petr Fischer

Something very weird happens - my steps: 1) ok, lets run UFFI Tests in Test Runnner 2) 5 tests fails (RED) 3) saved the test output to file (button in test runner) 4) quit from Pharo 5) I forgot to click on the 5 failed tests and generate some PharoDebug.log, so... start Pharo again... 6) lets run UFFI Tests again... 7) bang! all tests OK (GREEN)! WTF? run test again -> all green again (!) Bang! Iceberg clone repo works now... I simply can't explain this. Whole thing (CentOS7 + Pharo) is inside VirtualBox - most probably the virtual image is somehow crippled... Pharo+UFFI+Iceberg is OK, sorry for this mess... pf > This looks like an FFI error... > > Can you try running uFFI tests in your system and sen us the results? > > Tx, > Guille > > On Sun, Sep 23, 2018 at 9:54 PM Petr Fischer via Pharo-dev < > pharo-dev(a)lists.pharo.org> wrote: > > > Ohh sorry - better screenshot link: > > > > > > > > https://app.box.com/s/isd7tdyv8lgr8aj5449xqkrxt4y4uxqy > > > > > > > > pf > > > > > > > Hi Petr, > > > > > > On Sun, 23 Sep 2018 at 19:52, Petr Fischer via Pharo-dev > > > <pharo-dev(a)lists.pharo.org> wrote: > > > > > > > > Hello, I want to propose some small fixes to Pharo, it took me hours > > just to run Pharo with Iceberg on CentOS 7 (I don't care about Ubuntu)... > > > > > > > > Now I am stuck with this Iceberg error: > > > > https://app.box.com/file/321243070589 > > > > > > I was presented with a login box when I tried to view this. > > > > > > > > > > I am using 64bit Pharo VM + latest Pharo7 image from zeroconf (and > > latest CentOS7) - is Iceberg OK on 64bits? > > > > > > Yes, I use it all the time (on Ubuntu 16.04 64 bit). > > > > > > Cheers, > > > 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

Sept. 24, 2018

Re: [Pharo-dev] iceberg PrimitiveFailed allocateExecutablePage - PharoDebug.log

by Esteban Lorenzano

That means primAllocateExecutablePage failed. There should be an errorCode value there, that can help us understand better the problem. Can you check at it? Thanks! Esteban > On 24 Sep 2018, at 17:49, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > >

Sept. 24, 2018