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

Google App Engine allows whatever runtime.

by phil＠highoctane.be

And Pharo should of course run there :-) https://techcrunch.com/2017/03/09/new-version-of-google-app-engine-supports… With Google Cloud functions, maybe this will make sense for the initiative of starting lots of VM superfast, Phil

March 13, 2017

[ANN] Fog - Ethereum driver

by Santiago Bragagnolo

Hi all. Im happy to announce a pre release of the Fog ethereum driver that we develop in the space of an Inria project. It still not complete but is already usable for some experiments and simple projects. You can downloadit from https://github.com/sbragagnolo/Fog/ (https://github.com/sbragagnolo/Fog/releases/tag/v0.1.1.1) Dependencies <https://github.com/sbragagnolo/Fog#rhash>RHash sudo apt-get install rhash <https://github.com/sbragagnolo/Fog#solidity>Solidity npm install solc <https://github.com/sbragagnolo/Fog#download-code>Download code <https://github.com/sbragagnolo/Fog#iceberg--baseline>Iceberg / Baseline Metacello new baseline: 'Fog'; repository: 'github://sbragagnolo/Fog:v0.1.1.1/src'; load. <https://github.com/sbragagnolo/Fog#by-hand>By hand You may want to use this version for having access to some scripts and contracts samples. git checkout git@github.com:sbragagnolo/Fog.git git checkout v0.1.1.1 Metacello new baseline: 'Fog'; repository: 'filetree:///path/to/git-repository/Fog/src';; load. It's based on the standar API for javascript ( https://github.com/ethereum/wiki/wiki/JavaScript-API) . It provides interaction with remote contracts, it do as well provides a way for navigating the architecture objects: blocks, transactions, accounts and contracts. I hope you find it useful. Feel free to fill the github issue tracker with anything you find :). I will come to you with some new exciting news about ethereum soon :) Santiago.

March 13, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 6 March 2017

by Esteban Lorenzano

> On 13 Mar 2017, at 10:31, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 13 March 2017 at 09:00, <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Hello! > > This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017 <http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017> > > ChangeLog > ========= > > 10 March 2017: > -------------- > > * === libgit2(ssh) and linux > An update on the libgit2 (and consequently iceberg) problem on linux: SSH will not work on ITIMER VM (which > is the zeroconf default, at least for now). > > Here the reason: > > ITIMER sends an signal to the VM thread using +pthread_kill(tickerThread, TICKER_SIGNAL)+ and that aborts > system calls, which are used by +libssh2+, producing a 'wait for packet' to fail answering a timeout ( > even if that timeout does not happens for real). > > Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ : > > ---- > /* While we use SA_RESTART to ensure system calls are restarted, this is > * not universally effective. In particular, connect calls can abort if > * a system call is made in the signal handler, i.e. the pthread_kill in > * prodHighPriorityThread. So we avoid this if possible by not prodding > * the high-priority thread unless there are high-priority tickees as > * indicated by numAsyncTickees > 0. > */ > ---- > > ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the category of "not universally effective" > (they are connect calls... once disconnected, you cannot connect again 'as is'). > > So, the only workaround possible (at least for now), is to use the threaded version of VM... I improved the > error message it throws when this fails, now looks like this: > > ---- > This VM uses a thread heartbeat who requires a special configuration to work. > You need to allow it to run higher priority threads (real time), to allow clock to work properly > You need to add a conf file to /etc/security/limits.d, executing this: > > sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); > * hard rtprio 2 > * soft rtprio 2 > END > > You need to log out and log back in for the limits to take effect. > For more information read https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > ---- > > which at least shows what's happens and how you can easily fix it. > > Now, I think this is a *sad solution*. Needing to touch system configuration in order to run a VM > does not feels "professional". I would like to have some time to find a fix. > > No, it does feels right, according to common *nix lifestyle :) > No, seriously, it is not an issue for linux to set up configs for installed software , that would require root privileges. > VM is quite a beast, and this is not a surprise, that it requires fine tuning & deep & broader interfacing with OS, comparing to regular software. > Of course, the sad moment is that you need to write down an installation package and put this .conf file there which will install it, > in comparison to usual "download and run" style, this surely looks like a drawback. > But we can do smarter: - add small script to bundle with big letters "RUN ME" , that will do what is should to copy/concat .conf file > for VM binary located at given folder or wherever it does.. and everyone's happy :) hehehâ¦ I was in fact modifying zeroconf to add threaded download and I was adding a file INSTALL with this ;) Esteban > > > > 9 March 2017: > ------------- > > * I spent last two days again fighting with linux dependencies, because what I thought was fixed (the > loading of +libgit2.so+), actually was not working in all conditions. > > Now, I think I finally arrived to a working solution (that involved add an +rpath+ to Pharo, not > to dependent libraries). > > There is a new +vmLatest60+, let's see how it works... > > > 6 March 2017: > ------------- > > * I spent time fixing libgit2 (and dependents) compilation, both for linux and windows. > > As a result, now windows is working again (there was problems after version 0.26)... but linux, who seemed > working last friday, is now again not working properly :( > > > cheers! > Esteban > > > > > -- > Best regards, > Igor Stasenko.

March 13, 2017

Re: [Pharo-dev] [Help Wanted] moderators for pharo mailing lists

by Marcus Denker

I got enough people to help Thanks! > On 13 Mar 2017, at 08:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The two Pharo Mailinglists (pharo-dev and pharo-users) are run using Mailman via a commercial provider. > (Thanks to the Pharo Association, https://association.pharo.org <https://association.pharo.org/>) > > This means that we have nothing to do with regard to technical problems/issues or running the service itself. > but nevertheless, there are 1-2 emails per month that end up in a moderation queue, mostly because they are > very very large. > > It would be nice to have 1-2 people more to help with these (infrequent) moderation calls. > > If you are interested to help â> send a mail to me. > > Marcus

March 13, 2017

Re: [Pharo-dev] How to use the serial port on MacOS X?

by Ben Coman

I don't know how pertinent this is, but to answer my own question... MacOS: what's the difference between /dev/tty.* and /dev/cu.*? http://stackoverflow.com/questions/8632586/macos-whats-the-difference-betwe… /dev/tty.* and /dev/cu.* and AppleUSBFTDI http://www.stm32duino.com/viewtopic.php?t=376 Difference between cu.* and tty.* https://lists.apple.com/archives/usb/2009/Nov/msg00039.html cheers -ben On Mon, Mar 13, 2017 at 8:13 PM, Ben Coman <btc(a)openinworld.com> wrote: > Hi Olivier, > > You'd only mentioned the middle one, which I didn't think was sufficient. > But I agree the other two are strong tests indicating the USB is okay. > Sorry I don't have OSX to test further. > > But a question for me to learn something, what makes these two ports > equivalent test points between your Pharo code and your "more" test. > * /dev/ttyACM0 > * /dev/cu.usbmodel1411 > > To be specific, did ttyACM0 with Perl and the IDE ? > > cheers -ben > > On Mon, Mar 13, 2017 at 3:27 PM, olivier auverlot < > olivier.auverlot(a)gmail.com> wrote: > >> Hi Ben, >> >> I don't think that the problem concerns the USB port or the cable because: >> >> * I have tested with a simple Perl script (with the Device::SerialPort >> module) and all is ok. >> * In a shell, I can activate the rx/tx leds of the Arduino with the >> command "more -f /dev/cu.usbmodel1411". >> * I can use the Arduino IDE to program the card and send my binaries. >> >> If my Pharo code is correct, I suspect a problem in the serial plugin for >> MacOS X. I tried unsuccessful with Pharo 5 and Pharo 6. >> >> Best regards >> Olivier :) >> >> 2017-03-13 8:01 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> Just a few random thoughts... >>> >>> Can you load an echo program into the Arduino to check comms is not >>> getting corrupted? >>> https://www.baldengineer.com/alternatives-to-arduinos-serial >>> -monitor.html >>> >>> >>> Is the problem with a USB3 port? >>> Try using a USB2 port. >>> >>> >>> Are you using an FTDI cable? >>> http://forum.arduino.cc/index.php?topic=373817.0 >>> http://ewen.mcneill.gen.nz/blog/entry/2016-06-26-os-x-el-cap >>> itan-setup/ >>> >>> try disabling Apple's Virtual Com Port and using FTDI's per section 7... >>> http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FT >>> DI_Drivers_Installation_Guide_for_MAC_OSX.pdf >>> >>> or using a non-FTDI serial adpator. >>> >>> cheers -ben >>> >>> >>> On Mon, Mar 13, 2017 at 12:21 AM, olivier auverlot < >>> olivier.auverlot(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I try to use the serial port to communicate with an Arduino. On Linux, >>>> no problemo. I can open the serial port with the following code: >>>> >>>> | serialPort baudRate comPortNumber | >>>> baudRate := 31250. >>>> comPort := '/dev/ttyACM0'. >>>> >>>> serialPort := SerialPort new >>>> baudRate: 31250; >>>> dataBits: 8; >>>> stopBitsType: 1; >>>> parityType: 0; >>>> yourself. >>>> >>>> "the port is closed to ensure that it will be free" >>>> serialPort close. >>>> (serialPort openPort: comPort) isNil >>>> ifTrue: [ ^self error: 'COM port not available' ] >>>> ifFalse: [ serialPort inspect ]. >>>> serialPort close. >>>> >>>> But on MacOS X (10.11.6), the same code used with /dev/cu.usbmodel1411 >>>> doesn't run. The error is "Cannot open '/dev/cu.usbmodel1411'". I'm sure >>>> that is the correct serial port. If I type "more -f /dev/cu.usbmodel1411" >>>> in a terminal, the rx/tx leds of the Arduino are blink. >>>> >>>> Someone has an idea about this problem that is not specific of the >>>> Arduino but concerns the generic usage of the serial port with Pharo? >>>> >>>> Best regards >>>> Olivier >>>> >>>> ps: I can't test on Windows but I'm interested by a feedback. >>>> >>> >>> >> >

March 13, 2017

Re: [Pharo-dev] How to use the serial port on MacOS X?

by Ben Coman

Hi Olivier, You'd only mentioned the middle one, which I didn't think was sufficient. But I agree the other two are strong tests indicating the USB is okay. Sorry I don't have OSX to test further. But a question for me to learn something, what makes these two ports equivalent test points between your Pharo code and your "more" test. * /dev/ttyACM0 * /dev/cu.usbmodel1411 To be specific, did ttyACM0 with Perl and the IDE ? cheers -ben On Mon, Mar 13, 2017 at 3:27 PM, olivier auverlot < olivier.auverlot(a)gmail.com> wrote: > Hi Ben, > > I don't think that the problem concerns the USB port or the cable because: > > * I have tested with a simple Perl script (with the Device::SerialPort > module) and all is ok. > * In a shell, I can activate the rx/tx leds of the Arduino with the > command "more -f /dev/cu.usbmodel1411". > * I can use the Arduino IDE to program the card and send my binaries. > > If my Pharo code is correct, I suspect a problem in the serial plugin for > MacOS X. I tried unsuccessful with Pharo 5 and Pharo 6. > > Best regards > Olivier :) > > 2017-03-13 8:01 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> Just a few random thoughts... >> >> Can you load an echo program into the Arduino to check comms is not >> getting corrupted? >> https://www.baldengineer.com/alternatives-to-arduinos-serial >> -monitor.html >> >> >> Is the problem with a USB3 port? >> Try using a USB2 port. >> >> >> Are you using an FTDI cable? >> http://forum.arduino.cc/index.php?topic=373817.0 >> http://ewen.mcneill.gen.nz/blog/entry/2016-06-26-os-x-el-capitan-setup/ >> >> try disabling Apple's Virtual Com Port and using FTDI's per section 7... >> http://www.ftdichip.com/Support/Documents/AppNotes/AN_134_FT >> DI_Drivers_Installation_Guide_for_MAC_OSX.pdf >> >> or using a non-FTDI serial adpator. >> >> cheers -ben >> >> >> On Mon, Mar 13, 2017 at 12:21 AM, olivier auverlot < >> olivier.auverlot(a)gmail.com> wrote: >> >>> Hi, >>> >>> I try to use the serial port to communicate with an Arduino. On Linux, >>> no problemo. I can open the serial port with the following code: >>> >>> | serialPort baudRate comPortNumber | >>> baudRate := 31250. >>> comPort := '/dev/ttyACM0'. >>> >>> serialPort := SerialPort new >>> baudRate: 31250; >>> dataBits: 8; >>> stopBitsType: 1; >>> parityType: 0; >>> yourself. >>> >>> "the port is closed to ensure that it will be free" >>> serialPort close. >>> (serialPort openPort: comPort) isNil >>> ifTrue: [ ^self error: 'COM port not available' ] >>> ifFalse: [ serialPort inspect ]. >>> serialPort close. >>> >>> But on MacOS X (10.11.6), the same code used with /dev/cu.usbmodel1411 >>> doesn't run. The error is "Cannot open '/dev/cu.usbmodel1411'". I'm sure >>> that is the correct serial port. If I type "more -f /dev/cu.usbmodel1411" >>> in a terminal, the rx/tx leds of the Arduino are blink. >>> >>> Someone has an idea about this problem that is not specific of the >>> Arduino but concerns the generic usage of the serial port with Pharo? >>> >>> Best regards >>> Olivier >>> >>> ps: I can't test on Windows but I'm interested by a feedback. >>> >> >> >

March 13, 2017

Re: [Pharo-dev] How to listen for microsoft os windows messages (WM_MESSAGE's)?

by Mark Bestley

On 28/02/2017 14:05, Dimitris Chloupis wrote: > The first thing is to be very precise in what you want. > I think this is the most important thing to do first. > I thought you wanted a window manager now you mention a full blow GUI API. > You could also look at Dolphin Smalltalk http://object-arts.com/ which is integrated with Windows GUI - albeit 32 bit only > Frankly if you want to ovehaul Pharo GUI API , personally I think hands > down a Pharo QT project will be far more valuable. > > Windows may have an overwhelming market of 90% of OS users but the same > is not true for developers. Developers are far more attracted to other > platforms like MacOS and Linux. MacOS especially has a very loyal and > quite large developer crowd. So a WIN API solution will not be as > attractive as cross platform QT. > > QT not only work on Win, Mac and Linux , it also work inside Web pages , > iOS and Android. If we take into account that mobile is the most > rapidly growing market you can imagine why QT is so much loved by devs. > There are other cross platform APIs e.g. wxWidgets and Gtk There used to be a version of squeak with wx bindings wxSqueak but the code seems not to be on line now. Pharo had some GTK bindings in Mars https://marsonpharo.wordpress.com/ The last two don't work at all now but might help you by giving ideas.

March 13, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 6 March 2017

by Esteban Lorenzano

> On 13 Mar 2017, at 10:10, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Esteban, > > regarding the threaded versus itimer vm, I guess OSProcess would be affected as well? yes > And also, how to get the threaded vm with zero-conf or files.pharo.org <http://files.pharo.org/>? you donât. I have in my todo to add threaded VMs to zeroconf. I will try to handle that today-tomorrow. Esteban > > Regards, > > Thierry > > 2017-03-13 8:00 GMT+01:00 <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > Hello! > > This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. > You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017 <http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017> > > ChangeLog > ========= > > 10 March 2017: > -------------- > > * === libgit2(ssh) and linux > An update on the libgit2 (and consequently iceberg) problem on linux: SSH will not work on ITIMER VM (which > is the zeroconf default, at least for now). > > Here the reason: > > ITIMER sends an signal to the VM thread using +pthread_kill(tickerThread, TICKER_SIGNAL)+ and that aborts > system calls, which are used by +libssh2+, producing a 'wait for packet' to fail answering a timeout ( > even if that timeout does not happens for real). > > Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ : > > ---- > /* While we use SA_RESTART to ensure system calls are restarted, this is > * not universally effective. In particular, connect calls can abort if > * a system call is made in the signal handler, i.e. the pthread_kill in > * prodHighPriorityThread. So we avoid this if possible by not prodding > * the high-priority thread unless there are high-priority tickees as > * indicated by numAsyncTickees > 0. > */ > ---- > > ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the category of "not universally effective" > (they are connect calls... once disconnected, you cannot connect again 'as is'). > > So, the only workaround possible (at least for now), is to use the threaded version of VM... I improved the > error message it throws when this fails, now looks like this: > > ---- > This VM uses a thread heartbeat who requires a special configuration to work. > You need to allow it to run higher priority threads (real time), to allow clock to work properly > You need to add a conf file to /etc/security/limits.d, executing this: > > sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); > * hard rtprio 2 > * soft rtprio 2 > END > > You need to log out and log back in for the limits to take effect. > For more information read https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux <https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux> > ---- > > which at least shows what's happens and how you can easily fix it. > > Now, I think this is a *sad solution*. Needing to touch system configuration in order to run a VM > does not feels "professional". I would like to have some time to find a fix. > > > 9 March 2017: > ------------- > > * I spent last two days again fighting with linux dependencies, because what I thought was fixed (the > loading of +libgit2.so+), actually was not working in all conditions. > > Now, I think I finally arrived to a working solution (that involved add an +rpath+ to Pharo, not > to dependent libraries). > > There is a new +vmLatest60+, let's see how it works... > > > 6 March 2017: > ------------- > > * I spent time fixing libgit2 (and dependents) compilation, both for linux and windows. > > As a result, now windows is working again (there was problems after version 0.26)... but linux, who seemed > working last friday, is now again not working properly :( > > > cheers! > Esteban > >

March 13, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 6 March 2017

by Thierry Goubier

Hi, 2017-03-13 10:42 GMT+01:00 tesonep(a)gmail.com <tesonep(a)gmail.com>: > Hi Igor, > you are right with the idea of having a "setup" script with the > downloadable VM. > > However, I think that the proposed solution, the change in the > configuration is not good. It works, but the solution that we are proposing > alters the permissions for all the users and processes. It creates a > security hole (I don't know how much dangerous it is, but usually the linux > configuration does not allow to change the threads to real time priority). > > We should provide a solution using a specific running user for the VM or > doing something else if we want the VM to run with special privileges. > > I think the professional solution is not to ask to run as root or ask to > lower the security of the whole system. > > Thierry, > I think the VM that you are looking for is in: > http://files.pharo.org/vm/pharo-spur32/linux/latest-threaded.zip > However I won't enter in panic, we have only seen problems with LibSSH > and OSSubProcesses, basically because depends of the system calls used and > if they can be restarted. > Ok, thanks. But I'll test that hypothesis if I see some random lockups over my usual threshold. Thierry > > Cheers. > > On Mon, Mar 13, 2017 at 10:31 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> >> >> On 13 March 2017 at 09:00, <estebanlm(a)gmail.com> wrote: >> >>> Hello! >>> >>> This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. >>> You can see it in a better format by going here: >>> http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017 >>> >>> ChangeLog >>> ========= >>> >>> 10 March 2017: >>> -------------- >>> >>> * === libgit2(ssh) and linux >>> An update on the libgit2 (and consequently iceberg) problem on >>> linux: SSH will not work on ITIMER VM (which >>> is the zeroconf default, at least for now). >>> >>> Here the reason: >>> >>> ITIMER sends an signal to the VM thread using >>> +pthread_kill(tickerThread, TICKER_SIGNAL)+ and that aborts >>> system calls, which are used by +libssh2+, producing a 'wait for >>> packet' to fail answering a timeout ( >>> even if that timeout does not happens for real). >>> >>> Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ >>> : >>> >>> ---- >>> /* While we use SA_RESTART to ensure system calls are restarted, >>> this is >>> * not universally effective. In particular, connect calls can >>> abort if >>> * a system call is made in the signal handler, i.e. the >>> pthread_kill in >>> * prodHighPriorityThread. So we avoid this if possible by not >>> prodding >>> * the high-priority thread unless there are high-priority tickees as >>> * indicated by numAsyncTickees > 0. >>> */ >>> ---- >>> >>> ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the >>> category of "not universally effective" >>> (they are connect calls... once disconnected, you cannot connect >>> again 'as is'). >>> >>> So, the only workaround possible (at least for now), is to use the >>> threaded version of VM... I improved the >>> error message it throws when this fails, now looks like this: >>> >>> ---- >>> This VM uses a thread heartbeat who requires a special configuration >>> to work. >>> You need to allow it to run higher priority threads (real time), to >>> allow clock to work properly >>> You need to add a conf file to /etc/security/limits.d, executing >>> this: >>> >>> sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); >>> * hard rtprio 2 >>> * soft rtprio 2 >>> END >>> >>> You need to log out and log back in for the limits to take effect. >>> For more information read https://github.com/OpenSmallta >>> lk/opensmalltalk-vm/releases/tag/r3732#linux >>> ---- >>> >>> which at least shows what's happens and how you can easily fix it. >>> >>> Now, I think this is a *sad solution*. Needing to touch system >>> configuration in order to run a VM >>> does not feels "professional". I would like to have some time to >>> find a fix. >>> >> >> No, it does feels right, according to common *nix lifestyle :) >> No, seriously, it is not an issue for linux to set up configs for >> installed software , that would require root privileges. >> VM is quite a beast, and this is not a surprise, that it requires fine >> tuning & deep & broader interfacing with OS, comparing to regular software. >> Of course, the sad moment is that you need to write down an installation >> package and put this .conf file there which will install it, >> in comparison to usual "download and run" style, this surely looks like a >> drawback. >> But we can do smarter: - add small script to bundle with big letters "RUN >> ME" , that will do what is should to copy/concat .conf file >> for VM binary located at given folder or wherever it does.. and >> everyone's happy :) >> >> >>> >>> >>> 9 March 2017: >>> ------------- >>> >>> * I spent last two days again fighting with linux dependencies, >>> because what I thought was fixed (the >>> loading of +libgit2.so+), actually was not working in all conditions. >>> >>> Now, I think I finally arrived to a working solution (that involved >>> add an +rpath+ to Pharo, not >>> to dependent libraries). >>> >>> There is a new +vmLatest60+, let's see how it works... >>> >>> >>> 6 March 2017: >>> ------------- >>> >>> * I spent time fixing libgit2 (and dependents) compilation, both for >>> linux and windows. >>> >>> As a result, now windows is working again (there was problems after >>> version 0.26)... but linux, who seemed >>> working last friday, is now again not working properly :( >>> >>> >>> cheers! >>> Esteban >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

March 13, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 6 March 2017

by tesonep＠gmail.com

Hi Igor, you are right with the idea of having a "setup" script with the downloadable VM. However, I think that the proposed solution, the change in the configuration is not good. It works, but the solution that we are proposing alters the permissions for all the users and processes. It creates a security hole (I don't know how much dangerous it is, but usually the linux configuration does not allow to change the threads to real time priority). We should provide a solution using a specific running user for the VM or doing something else if we want the VM to run with special privileges. I think the professional solution is not to ask to run as root or ask to lower the security of the whole system. Thierry, I think the VM that you are looking for is in: http://files.pharo.org/vm/pharo-spur32/linux/latest-threaded.zip However I won't enter in panic, we have only seen problems with LibSSH and OSSubProcesses, basically because depends of the system calls used and if they can be restarted. Cheers. On Mon, Mar 13, 2017 at 10:31 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > On 13 March 2017 at 09:00, <estebanlm(a)gmail.com> wrote: > >> Hello! >> >> This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. >> You can see it in a better format by going here: >> http://log.smallworks.eu/web/search?from=6/3/2017&to=12/3/2017 >> >> ChangeLog >> ========= >> >> 10 March 2017: >> -------------- >> >> * === libgit2(ssh) and linux >> An update on the libgit2 (and consequently iceberg) problem on linux: >> SSH will not work on ITIMER VM (which >> is the zeroconf default, at least for now). >> >> Here the reason: >> >> ITIMER sends an signal to the VM thread using >> +pthread_kill(tickerThread, TICKER_SIGNAL)+ and that aborts >> system calls, which are used by +libssh2+, producing a 'wait for >> packet' to fail answering a timeout ( >> even if that timeout does not happens for real). >> >> Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ : >> >> ---- >> /* While we use SA_RESTART to ensure system calls are restarted, this >> is >> * not universally effective. In particular, connect calls can abort >> if >> * a system call is made in the signal handler, i.e. the pthread_kill >> in >> * prodHighPriorityThread. So we avoid this if possible by not >> prodding >> * the high-priority thread unless there are high-priority tickees as >> * indicated by numAsyncTickees > 0. >> */ >> ---- >> >> ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the >> category of "not universally effective" >> (they are connect calls... once disconnected, you cannot connect >> again 'as is'). >> >> So, the only workaround possible (at least for now), is to use the >> threaded version of VM... I improved the >> error message it throws when this fails, now looks like this: >> >> ---- >> This VM uses a thread heartbeat who requires a special configuration >> to work. >> You need to allow it to run higher priority threads (real time), to >> allow clock to work properly >> You need to add a conf file to /etc/security/limits.d, executing this: >> >> sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); >> * hard rtprio 2 >> * soft rtprio 2 >> END >> >> You need to log out and log back in for the limits to take effect. >> For more information read https://github.com/OpenSmallta >> lk/opensmalltalk-vm/releases/tag/r3732#linux >> ---- >> >> which at least shows what's happens and how you can easily fix it. >> >> Now, I think this is a *sad solution*. Needing to touch system >> configuration in order to run a VM >> does not feels "professional". I would like to have some time to find >> a fix. >> > > No, it does feels right, according to common *nix lifestyle :) > No, seriously, it is not an issue for linux to set up configs for > installed software , that would require root privileges. > VM is quite a beast, and this is not a surprise, that it requires fine > tuning & deep & broader interfacing with OS, comparing to regular software. > Of course, the sad moment is that you need to write down an installation > package and put this .conf file there which will install it, > in comparison to usual "download and run" style, this surely looks like a > drawback. > But we can do smarter: - add small script to bundle with big letters "RUN > ME" , that will do what is should to copy/concat .conf file > for VM binary located at given folder or wherever it does.. and everyone's > happy :) > > >> >> >> 9 March 2017: >> ------------- >> >> * I spent last two days again fighting with linux dependencies, >> because what I thought was fixed (the >> loading of +libgit2.so+), actually was not working in all conditions. >> >> Now, I think I finally arrived to a working solution (that involved >> add an +rpath+ to Pharo, not >> to dependent libraries). >> >> There is a new +vmLatest60+, let's see how it works... >> >> >> 6 March 2017: >> ------------- >> >> * I spent time fixing libgit2 (and dependents) compilation, both for >> linux and windows. >> >> As a result, now windows is working again (there was problems after >> version 0.26)... but linux, who seemed >> working last friday, is now again not working properly :( >> >> >> cheers! >> Esteban >> >> > > > -- > Best regards, > Igor Stasenko. > -- Pablo Tesone. tesonep(a)gmail.com

March 13, 2017