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

[pharo-project/pharo-core] 228585: 60439

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 2285859f8218c1d33ca591886f51bb6c98a097eb https://github.com/pharo-project/pharo-core/commit/2285859f8218c1d33ca59188… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-13 (Mon, 13 Mar 2017) Changed paths: M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/baseline_.st M BaselineOfIDE.package/BaselineOfIDE.class/instance/baseline/groups_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60438.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60439.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60438.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60439.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A ScriptingExtensions-Tests.package/extension/StringTest/instance/testAsClass.st A ScriptingExtensions-Tests.package/extension/StringTest/instance/testAsClassIfAbsent.st A ScriptingExtensions-Tests.package/extension/StringTest/instance/testAsClassIfPresent.st A ScriptingExtensions-Tests.package/extension/SymbolTest/instance/testAsClass.st A ScriptingExtensions-Tests.package/extension/SymbolTest/instance/testAsClassIfAbsent.st A ScriptingExtensions-Tests.package/extension/SymbolTest/instance/testAsClassIfPresent.st R ScriptingExtensions.package/extension/StringTest/instance/testAsClass.st R ScriptingExtensions.package/extension/StringTest/instance/testAsClassIfAbsent.st R ScriptingExtensions.package/extension/StringTest/instance/testAsClassIfPresent.st R ScriptingExtensions.package/extension/SymbolTest/instance/testAsClass.st R ScriptingExtensions.package/extension/SymbolTest/instance/testAsClassIfAbsent.st R ScriptingExtensions.package/extension/SymbolTest/instance/testAsClassIfPresent.st Log Message: ----------- 60439 19822 ScriptingExtensions tests must be standalone https://pharo.fogbugz.com/f/cases/19822 19809 Failing test: WeakAnnouncerTest>>#testNoDeadWeakSubscriptions https://pharo.fogbugz.com/f/cases/19809 http://files.pharo.org/image/60/60439.zip

March 13, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60439 Home: https://github.com/pharo-project/pharo-core

March 13, 2017

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

by Igor Stasenko

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/ > 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 :) > > > 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] Esteban's ChangeLog week of 6 March 2017

by Thierry Goubier

Hi Esteban, regarding the threaded versus itimer vm, I guess OSProcess would be affected as well? And also, how to get the threaded vm with zero-conf or files.pharo.org? Regards, Thierry 2017-03-13 8:00 GMT+01:00 <estebanlm(a)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 > > 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 > ---- > > 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

[Help Wanted] moderators for pharo mailing lists

by Marcus Denker

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 olivier auverlot

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_FTDI_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] debugger feature I would pay for

by Ben Coman

On Mon, Mar 13, 2017 at 12:53 AM, stepharong <stepharong(a)free.fr> wrote: > Hi doru > > You have some features and I would love to use it for real. > > Here is my scenario: I have a test failing in pillar dev but not in my > previous image. :( > > I want to run a test in an image (green test). > - get the test execution stack > > In another image (dev), I would like to load the green test stack and > say to the debugger > - execute the test in the local image up to there is a change > by comparison with the other. > > I would pay for this feature. > > Stef > > Hi Stef, I hadn't put pen-to-paper** yet in response to your call for debugger features, but your scenario is related, so here it is... Sometimes it would be extremely useful to synchronously step two debuggers. That is, you only push one <StepXxx> button, and both debuggers make that step. My original idea was doing this just within one Image, but having one of those debuggers being remote would be super cool. cheers -ben ** is that still a valid saying, eh-hem, maybe now fingers-to-keyboard??

March 13, 2017

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

by Ben Coman

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_FTDI_Drivers_Inst… 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

Esteban's ChangeLog week of 6 March 2017

by 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 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 ---- 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] Debugger: is there a way to skip a message?

by Max Leske

Oops. Didn't see all those answers :) > On 13 Mar 2017, at 07:16, Max Leske <maxleske(a)gmail.com> wrote: > > What do you mean by "skip"? Not execute? Then not that I'm aware of. But you can: > > 1. step into > 2. return value from method (right click on the current frame) > > With a return value of nil that will have the same effect. > > HTH, > Max > >> On 10 Mar 2017, at 21:20, stepharong <stepharong(a)free.fr> wrote: >> >> Hi >> >> I need to skip message while debugging and I thought that it was possible. >> May be I do not see it. >> >> Stef >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >

March 13, 2017