- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Working Directory Changes

by Esteban Lorenzano

in general, this core-core functions is better to implement them as primitives. and you put a fallback using UFFI (in case the primitive is not there). of course, your solution worksâ¦ but it adds dependency with FFI-Kernel, which is also not good to have it in the bootstrap IMO. take a look at OSEnvironment>>getEnv implementation. we can go that direction and I think it will be better. Esteban > On 11 Oct 2017, at 10:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > I'd like to push a really core change in file management: the working directory. This is really needed for command line apps, when you have your app deployed in some directory and you're launching it from another one. The current implementation, where workingDirectory = imageDirectory, forces to have absolute paths or extra handling all over the place to manage this complexity. > > Rajula proposed a couple of months ago a solution for this based on the getcwd functions. You can read in his blogpost why using getcwd is better than $PWD in general here: > > https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/ <https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/> > > Now, since accessing the working directory is a core part of Pharo but based on UFFI, his implementation was breaking the build process. We cannot and we will not integrate UFFI in the bootstrap because it depends mainly on the compiler which is a big beast. Instead, I propose that only for this core-core-core feature, we use directly FFI. > > In other words, the bootstrap will include just a couple of classes to manage the basics of FFI. And the working directory will be fetched by using this low level API. Such a call looks like this: > > (ExternalLibraryFunction > name: 'getcwd' > module: 'libc.dylib' > callType: 1 > returnType: ExternalType char asPointerType > argumentTypes: { > ExternalType char asPointerType. > ExternalType long }) > invokeWith: buffer with: bufferSize. > > We reviewed it with Pablo two days ago. The build process works with this implementation and tests are still running. The pull request is in here: > > https://github.com/pharo-project/pharo/pull/92 <https://github.com/pharo-project/pharo/pull/92> > > > Thanks, > Guille, Pablo and Rajula > > -- > > 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. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Torsten Bergmann

For "safe" environments it would not make sense to offer already in a minimal base support for "unsafe" foreign calls and an (U)FFI. Out of curiosity: why not moving this to the VM itself to provide as a service to the image? Thanks T. Am 11.10.2017 um 10:27 schrieb Guillermo Polito: > Hi all, > > I'd like to push a really core change in file management: the working > directory. This is really needed for command line apps, when you have > your app deployed in some directory and you're launching it from > another one. The current implementation, where workingDirectory = > imageDirectory, forces to have absolute paths or extra handling all > over the place to manage this complexity. > > Rajula proposed a couple of months ago a solution for this based on > the getcwd functions. You can read in his blogpost why using getcwd is > better than $PWD in general here: > > https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/ > > Now, since accessing the working directory is a core part of Pharo but > based on UFFI, his implementation was breaking the build process. We > cannot and we will not integrate UFFI in the bootstrap because it > depends mainly on the compiler which is a big beast. Instead, I > propose that only for this core-core-core feature, we use directly FFI. > > In other words, the bootstrap will include just a couple of classes to > manage the basics of FFI. And the working directory will be fetched by > using this low level API. Such a call looks like this: > > (ExternalLibraryFunction > Â Â name: 'getcwd' > Â Â module: 'libc.dylib' > Â Â callType: 1 > Â Â returnType: ExternalType char asPointerType > Â Â argumentTypes: { > Â Â Â Â ExternalType char asPointerType. > Â Â Â Â ExternalType long }) > Â Â Â Â Â Â invokeWith: buffer with: bufferSize. > > We reviewed it with Pablo two days ago. The build process works with > this implementation and tests are still running. The pull request is > in here: > > https://github.com/pharo-project/pharo/pull/92 > > > Thanks, > Guille, Pablo and Rajula > > -- > > > > 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. 11, 2017

Re: [Pharo-dev] Working Directory Changes

by Pavel Krivanek

>From my experiments to execute FFI calls without FFI packages in the image I know that we can do it without it on even lower level but then we will anyway need to somehow handle library paths and so on. So to add these small packages into the bootstrapped kernel is totally reasonable and will open a lot of next possibilities. So definitely yes! Cheers, -- Pavel 2017-10-11 10:27 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > Hi all, > > I'd like to push a really core change in file management: the working > directory. This is really needed for command line apps, when you have your > app deployed in some directory and you're launching it from another one. > The current implementation, where workingDirectory = imageDirectory, forces > to have absolute paths or extra handling all over the place to manage this > complexity. > > Rajula proposed a couple of months ago a solution for this based on the > getcwd functions. You can read in his blogpost why using getcwd is better > than $PWD in general here: > > https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/ > > Now, since accessing the working directory is a core part of Pharo but > based on UFFI, his implementation was breaking the build process. We cannot > and we will not integrate UFFI in the bootstrap because it depends mainly > on the compiler which is a big beast. Instead, I propose that only for this > core-core-core feature, we use directly FFI. > > In other words, the bootstrap will include just a couple of classes to > manage the basics of FFI. And the working directory will be fetched by > using this low level API. Such a call looks like this: > > (ExternalLibraryFunction > name: 'getcwd' > module: 'libc.dylib' > callType: 1 > returnType: ExternalType char asPointerType > argumentTypes: { > ExternalType char asPointerType. > ExternalType long }) > invokeWith: buffer with: bufferSize. > > We reviewed it with Pablo two days ago. The build process works with this > implementation and tests are still running. The pull request is in here: > > https://github.com/pharo-project/pharo/pull/92 > > > Thanks, > Guille, Pablo and Rajula > > -- > > > > 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 <+33%206%2052%2070%2066%2013> >

Oct. 11, 2017

Working Directory Changes

by Guillermo Polito

Hi all, I'd like to push a really core change in file management: the working directory. This is really needed for command line apps, when you have your app deployed in some directory and you're launching it from another one. The current implementation, where workingDirectory = imageDirectory, forces to have absolute paths or extra handling all over the place to manage this complexity. Rajula proposed a couple of months ago a solution for this based on the getcwd functions. You can read in his blogpost why using getcwd is better than $PWD in general here: https://vineetreddy.wordpress.com/2017/05/17/pwd-vs-getcwd/ Now, since accessing the working directory is a core part of Pharo but based on UFFI, his implementation was breaking the build process. We cannot and we will not integrate UFFI in the bootstrap because it depends mainly on the compiler which is a big beast. Instead, I propose that only for this core-core-core feature, we use directly FFI. In other words, the bootstrap will include just a couple of classes to manage the basics of FFI. And the working directory will be fetched by using this low level API. Such a call looks like this: (ExternalLibraryFunction name: 'getcwd' module: 'libc.dylib' callType: 1 returnType: ExternalType char asPointerType argumentTypes: { ExternalType char asPointerType. ExternalType long }) invokeWith: buffer with: bufferSize. We reviewed it with Pablo two days ago. The build process works with this implementation and tests are still running. The pull request is in here: https://github.com/pharo-project/pharo/pull/92 Thanks, Guille, Pablo and Rajula -- 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. 11, 2017

DelaySpinScheduler and DelayExperimentalSpinScheduler

by Torsten Bergmann

Two questions from https://pharo.fogbugz.com/f/cases/20510 1. DelaySpinScheduler needs a good comment. Anyone? 2. DelayExperimentalSpinScheduler is not used, can we remove it?

Oct. 11, 2017

Re: [Pharo-dev] [Pharo 7.0-dev] Build #176: 20505-The-special-objects-array-needs-to-be-recreated-during-bootstrap

by Guillermo Polito

On Tue, Oct 10, 2017 at 2:46 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > Hi Guille, > > For "First": > I looked into this problem with Pavel this morning. The special object > array being incorrectly created leads to problems when a large object > (bigger that growthHeadroom) is created, as it does not go through the > handleFailingBasicNew methods. Typically, Pavel could not load Seaside into > the minimal image because of that. The problem lies with the initialization > of error codes. > Yes we were discussing this with Pavel yesterday too. I pointed him to look for your blogpost on sunday when he would not load seaside :). We I meant is that this should have been in a comment at least in the pull request. Otherwise your private discussion gets lost... > > For "Second": > I don't mind what you do as long as it solves the problem of large > allocations on minimal images. In any case the problems lies with the error > code symbols, so that the code in basicNew: > ec == #'insufficient object memory' ifTrue: > [^self handleFailingBasicNew: sizeRequested]. > takes the correct branch. Before Pavel's change, the condition was false > during bootstrap leading to large allocation crashing the VM, ec was equal > to 9 instead of #'insufficient object memory', since the error codes in > the special object array were incorrectly initialized somehow. > Yes, I understand the error. Now, I was crunching it a bit yesterday, and this looks too error prone. This has a super hidden dependency with the special objects array. I ask myself: do we want this to fail when the special object's array changes? What if somebody suddenly tries to "fix a typo" in the error message and forgots to update the special object's array? Moreover, Why not doing ec == ((Smalltalk specialObjectsArray at: 53) at: 9) ifTrue: [^self handleFailingBasicNew: sizeRequested]. And why not adding also a guard in case ec == 9? ec == 9 ifTrue: [^self handleFailingBasicNew: sizeRequested]. ec == ((Smalltalk specialObjectsArray at: 53) at: 9) ifTrue: [^self handleFailingBasicNew: sizeRequested]. Like that the fallback code could be a bit more robust. What do you think? > > PS: Who is nobody ? > > Cheers > > > On Tue, Oct 10, 2017 at 2:04 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> Hi Pavel, >> >> I don't like this change. >> >> First, there is no comment nor explanation why that is needed. This >> change is obscure, if we forget in a couple of months why that line of code >> is there we may >> - delete it unintentionally >> - or leave it forever and fear to clean it up because we do not >> understand it :( >> >> Second, It looks that recreating the special objects array there, like >> that, means that it was not correctly created from the beginning. We should >> instead create it correctly from the beginning. >> >> I think we should revert this change. >> >> On Tue, Oct 10, 2017 at 12:24 PM, <ci-pharo-ci-jenkins2(a)inria.fr> wrote: >> >>> There is a new Pharo build available! >>> >>> The status of the build #176 was: SUCCESS. >>> >>> The Pull Request #336 was integrated: "20505-The-special-objects-arr >>> ay-needs-to-be-recreated-during-bootstrap" >>> Pull request url: https://github.com/pharo-project/pharo/pull/336 >>> >>> Issue Url: https://pharo.fogbugz.com/f/cases/20505 >>> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20p >>> ull%20request%20and%20branch%20Pipeline/job/development/176/ >>> >> >> >> >> -- >> >> >> >> 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 <+33%206%2052%2070%2066%2013> >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > -- 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. 11, 2017

Re: [Pharo-dev] State of files.pharo.org

by stephan

On 06-10-17 16:00, Ben Coman wrote: > Without know what actions they may have tries, I'd generally say it seems > that it can't be solved with local testing since that is a different > environment. Ideally your DevOps guys could get on a machine in a remote > corner of the world exhibiting the problem, to help them "see" the > problem. That could be easily and cheaply done by using some of the vps providers that let you work with a machine in a datacenter of your choosing. Anyway, what might help the Inria team is a traceroute from the slow connection Stephan

Oct. 11, 2017

Re: [Pharo-dev] Videos ESUG17 Day1 online

by Tudor Girba

Thanks, Marcus! Doru > On Oct 11, 2017, at 9:50 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The videos of the first day are online: > > https://www.youtube.com/playlist?list=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv > > > More coming soon. > > Marcus > > -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

Oct. 11, 2017

[Pharo 7.0-dev] Build #177: 14443 unify transcript packages

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

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

Oct. 11, 2017

Videos ESUG17 Day1 online

by Marcus Denker

Hi, The videos of the first day are online: https://www.youtube.com/playlist?list=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv <https://www.youtube.com/playlist?list=PLJ5nSnWzQXi_THfKwhzxFwbXy00YTi0uv> More coming soon. Marcus

Oct. 11, 2017