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

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Alistair Grant

On 9 March 2018 at 16:56, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 2018-03-09 16:47 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >> Hi Pavel, >> >> On 9 March 2018 at 16:12, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> 2018-03-09 16:02 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >>>> Hi Pavel, >>>> >>>> I tried to get this working on Ubuntu 16.04 and found the following: >>>> >>>> - The compilation failed unless I added the '-fPIC' flag (as suggested by gcc). >>> >>> is it on 64-bit system and VM? >> >> Yep. > > I will check that, I guess some package is missing in this Ubuntu > environment because I think I checked it on the same system without > this issue. > >> >> >>>> - The example code in the TerminalEmulator class comment references >>>> ProcessEndpoint, but the class doesn't exist. >>> >>> Thanks, this class was renamed >> >> To PseudoTTYEndpoint, it looks like. >> >> Cool! The interactive terminal is up and running. >> >> Is it possible to have a cursor? > > the original implementation had it, I need to only fix it ;-) >> >> How does one pass more than one argument, for example, if I want to >> execute "ls -l -h", what should be the format be (ignore that the two >> arguments can be combined in this case, it's just as a simple >> example)? >> >> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h') >> >> produces: >> >> ls: invalid option -- ' ' >> Try 'ls --help' for more information. >> >> >> PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h') >> >> ignores the second argument. > > In this prototype implementation, only one argument is allowed because > to pass variable arguments list with FFI is not trivial. It will be > fixed soon. Great, thanks! Cheers, Alistair

March 9, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Pavel Krivanek

2018-03-09 16:47 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Pavel, > > On 9 March 2018 at 16:12, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> 2018-03-09 16:02 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >>> Hi Pavel, >>> >>> I tried to get this working on Ubuntu 16.04 and found the following: >>> >>> - The compilation failed unless I added the '-fPIC' flag (as suggested by gcc). >> >> is it on 64-bit system and VM? > > Yep. I will check that, I guess some package is missing in this Ubuntu environment because I think I checked it on the same system without this issue. > > >>> - The example code in the TerminalEmulator class comment references >>> ProcessEndpoint, but the class doesn't exist. >> >> Thanks, this class was renamed > > To PseudoTTYEndpoint, it looks like. > > Cool! The interactive terminal is up and running. > > Is it possible to have a cursor? the original implementation had it, I need to only fix it ;-) > > How does one pass more than one argument, for example, if I want to > execute "ls -l -h", what should be the format be (ignore that the two > arguments can be combined in this case, it's just as a simple > example)? > > PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h') > > produces: > > ls: invalid option -- ' ' > Try 'ls --help' for more information. > > > PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h') > > ignores the second argument. In this prototype implementation, only one argument is allowed because to pass variable arguments list with FFI is not trivial. It will be fixed soon. > > Thanks! > Alistair > > >> Cheers, >> -- Pavel >> >>> >>> Pharo 7.0 >>> Build information: >>> Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807 >>> (64 Bit) >>> >>> >>> Cheers, >>> Alistair >>> >>> >>> >>> >>> >>> >>> On 5 March 2018 at 10:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Guille is working on the Iceberg improvements and he wanted to be able to >>>> open a terminal window on top of the repository and interact with it via the >>>> command line. So we looked at this issue because I already in December made >>>> some experiments with the terminal emulation in Pharo. >>>> >>>> In past, the Squeak had a working terminal emulation that used >>>> PseudoTTYPlugin. The VM is not built with this code for a long time but I >>>> tried to replace it with a small C library and then wrote an FFI interface >>>> to it. Together with that, I ported most of the old code Squeak code to >>>> Pharo. >>>> >>>> With Guille we tried to avoid usage of such external library and wrote an >>>> FFI interface to all the required LibC functions. We were successful but we >>>> realized that there are several issues that are limiting us. >>>> >>>> When you want to execute a separate process for the program that you want to >>>> open in terminal (typically the Bash), you need to redirect the standard IO >>>> files, create a fork of your process, do some additional initialization in >>>> it and call 'exec' on it. In the parent process, you change redirected IO >>>> files back to the original values. >>>> >>>> But the problem is that between the FFI calls from Smalltalk the VM can do a >>>> lot of things including garbage collection etc. On OS X the fork() function >>>> has the following limitation described in man: >>>> >>>> "There are limits to what you can do in the child process. To be totally >>>> safe you should restrict your yourself to only executing async-signal safe >>>> operations until such time as one of the exec functions is called. All >>>> APIs, including global data symbols, in any framework or library should be >>>> assumed to be unsafe after a fork() unless explicitly documented to be safe >>>> or async-signal safe. If you need to use these frameworks in the child >>>> process, you must exec. In this >>>> situation it is reasonable to exec your-self. yourself." >>>> >>>> >>>> As the result in most cases (but not all) the fork() and exec() pair from >>>> the Smalltalk side fails on OS X. Linux does not have this limitation >>>> however even there we found an issue. It is bound to the fact that fork() >>>> makes a fork of all the parent process that uses the same resources. As soon >>>> as Pharo is opened in a window and X11 is involved (the window wants to be >>>> repainted), it can lead to the VM crash. >>>> >>>> So we learned that unfortunately we currently cannot use image-only FFI code >>>> for this task. We need a C library or VM plugin. >>>> >>>> The repository of the terminal emulator is here: >>>> https://github.com/pavel-krivanek/terminal >>>> >>>> and can be loaded using the following code: >>>> >>>> Metacello new >>>> baseline: 'TerminalEmulator'; >>>> repository: 'github://pavel-krivanek/terminal/src'; >>>> load. >>>> >>>> #TerminalEmulator asClass compileLibrary. >>>> >>>> >>>> It compiles and links the small library with only one function using the GCC >>>> so the machine needs to have a proper development environment. >>>> >>>> The terminal emulator is in very early stage and has a lot of issues like >>>> processes cleanup, drawing, keyboard input etc. etc. If you are interested >>>> in it, feel free to contribute. >>>> >>>> Cheers, >>>> -- Pavel >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >

March 9, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Alistair Grant

Hi Pavel, On 9 March 2018 at 16:12, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > 2018-03-09 16:02 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: >> Hi Pavel, >> >> I tried to get this working on Ubuntu 16.04 and found the following: >> >> - The compilation failed unless I added the '-fPIC' flag (as suggested by gcc). > > is it on 64-bit system and VM? Yep. >> - The example code in the TerminalEmulator class comment references >> ProcessEndpoint, but the class doesn't exist. > > Thanks, this class was renamed To PseudoTTYEndpoint, it looks like. Cool! The interactive terminal is up and running. Is it possible to have a cursor? How does one pass more than one argument, for example, if I want to execute "ls -l -h", what should be the format be (ignore that the two arguments can be combined in this case, it's just as a simple example)? PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l -h') produces: ls: invalid option -- ' ' Try 'ls --help' for more information. PseudoTTYEndpoint command: '/bin/ls' arguments: #('-l' '-h') ignores the second argument. Thanks! Alistair > Cheers, > -- Pavel > >> >> Pharo 7.0 >> Build information: >> Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807 >> (64 Bit) >> >> >> Cheers, >> Alistair >> >> >> >> >> >> >> On 5 March 2018 at 10:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> Guille is working on the Iceberg improvements and he wanted to be able to >>> open a terminal window on top of the repository and interact with it via the >>> command line. So we looked at this issue because I already in December made >>> some experiments with the terminal emulation in Pharo. >>> >>> In past, the Squeak had a working terminal emulation that used >>> PseudoTTYPlugin. The VM is not built with this code for a long time but I >>> tried to replace it with a small C library and then wrote an FFI interface >>> to it. Together with that, I ported most of the old code Squeak code to >>> Pharo. >>> >>> With Guille we tried to avoid usage of such external library and wrote an >>> FFI interface to all the required LibC functions. We were successful but we >>> realized that there are several issues that are limiting us. >>> >>> When you want to execute a separate process for the program that you want to >>> open in terminal (typically the Bash), you need to redirect the standard IO >>> files, create a fork of your process, do some additional initialization in >>> it and call 'exec' on it. In the parent process, you change redirected IO >>> files back to the original values. >>> >>> But the problem is that between the FFI calls from Smalltalk the VM can do a >>> lot of things including garbage collection etc. On OS X the fork() function >>> has the following limitation described in man: >>> >>> "There are limits to what you can do in the child process. To be totally >>> safe you should restrict your yourself to only executing async-signal safe >>> operations until such time as one of the exec functions is called. All >>> APIs, including global data symbols, in any framework or library should be >>> assumed to be unsafe after a fork() unless explicitly documented to be safe >>> or async-signal safe. If you need to use these frameworks in the child >>> process, you must exec. In this >>> situation it is reasonable to exec your-self. yourself." >>> >>> >>> As the result in most cases (but not all) the fork() and exec() pair from >>> the Smalltalk side fails on OS X. Linux does not have this limitation >>> however even there we found an issue. It is bound to the fact that fork() >>> makes a fork of all the parent process that uses the same resources. As soon >>> as Pharo is opened in a window and X11 is involved (the window wants to be >>> repainted), it can lead to the VM crash. >>> >>> So we learned that unfortunately we currently cannot use image-only FFI code >>> for this task. We need a C library or VM plugin. >>> >>> The repository of the terminal emulator is here: >>> https://github.com/pavel-krivanek/terminal >>> >>> and can be loaded using the following code: >>> >>> Metacello new >>> baseline: 'TerminalEmulator'; >>> repository: 'github://pavel-krivanek/terminal/src'; >>> load. >>> >>> #TerminalEmulator asClass compileLibrary. >>> >>> >>> It compiles and links the small library with only one function using the GCC >>> so the machine needs to have a proper development environment. >>> >>> The terminal emulator is in very early stage and has a lot of issues like >>> processes cleanup, drawing, keyboard input etc. etc. If you are interested >>> in it, feel free to contribute. >>> >>> Cheers, >>> -- Pavel >>> >>> >>> >>> >>> >>> >>> >> >

March 9, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Pavel Krivanek

2018-03-09 16:02 GMT+01:00 Alistair Grant <akgrant0710(a)gmail.com>: > Hi Pavel, > > I tried to get this working on Ubuntu 16.04 and found the following: > > - The compilation failed unless I added the '-fPIC' flag (as suggested by gcc). is it on 64-bit system and VM? > - The example code in the TerminalEmulator class comment references > ProcessEndpoint, but the class doesn't exist. Thanks, this class was renamed Cheers, -- Pavel > > Pharo 7.0 > Build information: > Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807 > (64 Bit) > > > Cheers, > Alistair > > > > > > > On 5 March 2018 at 10:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> Guille is working on the Iceberg improvements and he wanted to be able to >> open a terminal window on top of the repository and interact with it via the >> command line. So we looked at this issue because I already in December made >> some experiments with the terminal emulation in Pharo. >> >> In past, the Squeak had a working terminal emulation that used >> PseudoTTYPlugin. The VM is not built with this code for a long time but I >> tried to replace it with a small C library and then wrote an FFI interface >> to it. Together with that, I ported most of the old code Squeak code to >> Pharo. >> >> With Guille we tried to avoid usage of such external library and wrote an >> FFI interface to all the required LibC functions. We were successful but we >> realized that there are several issues that are limiting us. >> >> When you want to execute a separate process for the program that you want to >> open in terminal (typically the Bash), you need to redirect the standard IO >> files, create a fork of your process, do some additional initialization in >> it and call 'exec' on it. In the parent process, you change redirected IO >> files back to the original values. >> >> But the problem is that between the FFI calls from Smalltalk the VM can do a >> lot of things including garbage collection etc. On OS X the fork() function >> has the following limitation described in man: >> >> "There are limits to what you can do in the child process. To be totally >> safe you should restrict your yourself to only executing async-signal safe >> operations until such time as one of the exec functions is called. All >> APIs, including global data symbols, in any framework or library should be >> assumed to be unsafe after a fork() unless explicitly documented to be safe >> or async-signal safe. If you need to use these frameworks in the child >> process, you must exec. In this >> situation it is reasonable to exec your-self. yourself." >> >> >> As the result in most cases (but not all) the fork() and exec() pair from >> the Smalltalk side fails on OS X. Linux does not have this limitation >> however even there we found an issue. It is bound to the fact that fork() >> makes a fork of all the parent process that uses the same resources. As soon >> as Pharo is opened in a window and X11 is involved (the window wants to be >> repainted), it can lead to the VM crash. >> >> So we learned that unfortunately we currently cannot use image-only FFI code >> for this task. We need a C library or VM plugin. >> >> The repository of the terminal emulator is here: >> https://github.com/pavel-krivanek/terminal >> >> and can be loaded using the following code: >> >> Metacello new >> baseline: 'TerminalEmulator'; >> repository: 'github://pavel-krivanek/terminal/src'; >> load. >> >> #TerminalEmulator asClass compileLibrary. >> >> >> It compiles and links the small library with only one function using the GCC >> so the machine needs to have a proper development environment. >> >> The terminal emulator is in very early stage and has a lot of issues like >> processes cleanup, drawing, keyboard input etc. etc. If you are interested >> in it, feel free to contribute. >> >> Cheers, >> -- Pavel >> >> >> >> >> >> >> >

March 9, 2018

Re: [Pharo-dev] Pavel's ChangeLog week of 2018-02-26

by Alistair Grant

Hi Pavel, I tried to get this working on Ubuntu 16.04 and found the following: - The compilation failed unless I added the '-fPIC' flag (as suggested by gcc). - The example code in the TerminalEmulator class comment references ProcessEndpoint, but the class doesn't exist. Pharo 7.0 Build information: Pharo-7.0+alpha.build.674.sha.57447e756fa6fcf1877f9d0d1cda235b3b63c807 (64 Bit) Cheers, Alistair On 5 March 2018 at 10:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > Guille is working on the Iceberg improvements and he wanted to be able to > open a terminal window on top of the repository and interact with it via the > command line. So we looked at this issue because I already in December made > some experiments with the terminal emulation in Pharo. > > In past, the Squeak had a working terminal emulation that used > PseudoTTYPlugin. The VM is not built with this code for a long time but I > tried to replace it with a small C library and then wrote an FFI interface > to it. Together with that, I ported most of the old code Squeak code to > Pharo. > > With Guille we tried to avoid usage of such external library and wrote an > FFI interface to all the required LibC functions. We were successful but we > realized that there are several issues that are limiting us. > > When you want to execute a separate process for the program that you want to > open in terminal (typically the Bash), you need to redirect the standard IO > files, create a fork of your process, do some additional initialization in > it and call 'exec' on it. In the parent process, you change redirected IO > files back to the original values. > > But the problem is that between the FFI calls from Smalltalk the VM can do a > lot of things including garbage collection etc. On OS X the fork() function > has the following limitation described in man: > > "There are limits to what you can do in the child process. To be totally > safe you should restrict your yourself to only executing async-signal safe > operations until such time as one of the exec functions is called. All > APIs, including global data symbols, in any framework or library should be > assumed to be unsafe after a fork() unless explicitly documented to be safe > or async-signal safe. If you need to use these frameworks in the child > process, you must exec. In this > situation it is reasonable to exec your-self. yourself." > > > As the result in most cases (but not all) the fork() and exec() pair from > the Smalltalk side fails on OS X. Linux does not have this limitation > however even there we found an issue. It is bound to the fact that fork() > makes a fork of all the parent process that uses the same resources. As soon > as Pharo is opened in a window and X11 is involved (the window wants to be > repainted), it can lead to the VM crash. > > So we learned that unfortunately we currently cannot use image-only FFI code > for this task. We need a C library or VM plugin. > > The repository of the terminal emulator is here: > https://github.com/pavel-krivanek/terminal > > and can be loaded using the following code: > > Metacello new > baseline: 'TerminalEmulator'; > repository: 'github://pavel-krivanek/terminal/src'; > load. > > #TerminalEmulator asClass compileLibrary. > > > It compiles and links the small library with only one function using the GCC > so the machine needs to have a proper development environment. > > The terminal emulator is in very early stage and has a lot of issues like > processes cleanup, drawing, keyboard input etc. etc. If you are interested > in it, feel free to contribute. > > Cheers, > -- Pavel > > > > > > >

March 9, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Marcus Denker

> On 9 Mar 2018, at 14:01, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 9 Mar 2018, at 13:58, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: >> >> On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> Hi, >>> >>> With Christoph we did a version of the download page that points users to >>> the âPharo Launcherâ instead of the zips that just contained one vm and the >>> last image. >>> >>> http://pharo.org/download >>> >>> comments welcomeâ¦ >>> >> Hi! >> I am totally in favour of referencing Pharo Launcher in the Pharo >> download page, but I'm not sure it should totally replace the old >> page. >> In my opinion, it would be good to have both. > > The problem is that things are getting *very* complex, and every new way to download Pharo makes things even more complexâ¦ > > I really do not know how to structure that page if the launcher is added as yet another way. Of course Linux package I kept (they are in the Linux Package section). What do you miss? The .zip files that have vm+sources+image? I think the launcher replaces the âthis is the easiest downloadâ aka the .zip files. For the âsingle downloadsâ (point the the last vm, the last image), maybe adding that section back is neededâ¦ Marcus

March 9, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Marcus Denker

> On 9 Mar 2018, at 13:58, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> Hi, >> >> With Christoph we did a version of the download page that points users to >> the âPharo Launcherâ instead of the zips that just contained one vm and the >> last image. >> >> http://pharo.org/download >> >> comments welcomeâ¦ >> > Hi! > I am totally in favour of referencing Pharo Launcher in the Pharo > download page, but I'm not sure it should totally replace the old > page. > In my opinion, it would be good to have both. The problem is that things are getting *very* complex, and every new way to download Pharo makes things even more complexâ¦ I really do not know how to structure that page if the launcher is added as yet another way. Marcus

March 9, 2018

Re: [Pharo-dev] Experiment: New Download page based on Pharo Launcher

by Cyril Ferlicot

On Fri, Mar 9, 2018 at 1:53 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > With Christoph we did a version of the download page that points users to > the âPharo Launcherâ instead of the zips that just contained one vm and the > last image. > > http://pharo.org/download > > comments welcomeâ¦ > Hi! I am totally in favour of referencing Pharo Launcher in the Pharo download page, but I'm not sure it should totally replace the old page. In my opinion, it would be good to have both. > Marcus -- Cyril Ferlicot https://ferlicot.fr

March 9, 2018

Experiment: New Download page based on Pharo Launcher

by Marcus Denker

Hi, With Christoph we did a version of the download page that points users to the âPharo Launcherâ instead of the zips that just contained one vm and the last image. http://pharo.org/download <http://pharo.org/download> comments welcomeâ¦ Marcus

March 9, 2018

Re: [Pharo-dev] [ANN] Cruiser: A Pharo app packager

by philippe.back＠highoctane.be

Vincent, When it comes to UnifiedFFI what would be your advice to have it working? I am using quite a few such calls. Thx for this cool tool, I'll try it out this week end for sure! Phil On Thu, Mar 8, 2018, 20:30 <Vincent.Blondeau(a)lamresearch.com> wrote: > Hi Pharoers! > > I pleased to announce you the first release of Cruiser: a tool to package > your Pharo applications. The idea is to quickly convert an application from > a development environment to a production one. A production environment > means: > > * No writing on the disk > * No access to the source code (by the shortcuts, debugger,...) > * No error displaying on the interface > * The only thing accessible is the user application > > I let you discover it on: https://github.com/VincentBlondeau/Cruiser > > [cid:image002.png@01D3B6D0.B0BAA0B0] > > Do not hesitate to ask me questions or contribute to improve it! > > Cheers, > > Vincent Blondeau > Software Engineer, Software and Controls | Global Product Group > Desk +1 510.572.7499 > > Lam Research Corporation > 4650 Cushing Pkwy, Fremont, CA 94538 USA | www.lamresearch.com > Connect with Lam Research: Facebook< > https://www.facebook.com/LamResearchCorporation> | Twitter< > https://twitter.com/lamresearch> | LinkedIn< > https://www.linkedin.com/company/lam-research> > > ________________________________ > > NOTICE: This e-mail transmission may contain confidential information. If > you are not the intended recipient, or a person responsible for delivering > it to the intended recipient, you are hereby notified that any disclosure, > copying, distribution or use of any of the information contained in or > attached to this message is STRICTLY PROHIBITED. If you have received this > transmission in error, please immediately notify the sender and destroy the > original transmission and its attachments without reading them or saving > them to disk. Thank you. >

March 9, 2018