- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Debugger: is there a way to skip a message?

by Max Leske

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

Re: [Pharo-dev] Growing large images: the case of Moose models

by ClÃ©ment Bera

Hi again, I summarised my experiment with Moose and 2 other experiments in a "Tuning the Pharo garbage collector" blog post here: https://clementbera.wordpress.com/2017/03/12/tuning-the-pharo-garbage-colle… I may integrate some new methods in the VirtualMachine class in Pharo in the next few months to make VM tuning easier to deal with. I will update the scripts in the blog post accordingly if I do so. Best, On Sat, Mar 4, 2017 at 12:49 AM, stepharong <stepharong(a)free.fr> wrote: > tx clement > > this is indeed really important > > On Fri, 03 Mar 2017 11:56:05 +0100, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > Hello everyone, > > This morning I investigated with Vincent Blondeau a problem reported by > the Moose community a while ago: loading Moose model is slower in Spur > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem > was present for anyone growing images to a significant size. > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb > image, growing the image to 450Mb. Loading such a model takes 2 minutes in > Spur and 1m30s in pre-Spur VMs. > > Using the stable Pharo VM, the analysis results were the following: > - total time spent to load the Model: 2 minutes > - time spent in full GC: 1 minute (4 fullGCs) > - time spent in scavenges[1]: 15 seconds > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% > in scavenges, 37.5% executing code. > > We then used the latest VM that features the new compactor (VM from > beginning of March 2017 and over). The full GC execution time went down > from 1 minute to 2 seconds. > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent > in scavenges decreased from 15 seconds to 5 seconds. > > Overall, loading the model is now taking ~50 seconds instead of 2 minutes. > > To increase Eden size, one needs to run a script similar to: > > | currentEdenSize desiredEdenSize | > currentEdenSize := Smalltalk vm parameterAt: 44. > desiredEdenSize := currentEdenSize * 4. > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > *And then restart the image.* > > I hope this report can be useful for some of you. I will try to make a > blog post out of it, detailing other GC settings one can change from the > image to improve performance. > > Best, > > Clement > > [1] A scavenge is basically the garbage collection of only young objects > [2] Eden is basically the space where objects are initially allocated. > [3] All numbers in the report are order of magnitudes and not precise > numbers > > > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ >

March 12, 2017

Re: [Pharo-dev] perform:withArguments: and collection

by Eliot Miranda

On Sun, Mar 12, 2017 at 3:16 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi, > > Apparently sending #perform:withArguments: and using OrderedCollection > leads to PrimitiveFailed. > > I can recast it, but maybe we can just add > > (argArray isArray) > ifFalse: [ ^ self error: 'Arguments must be instance of Array' ] > +1. The alternative is having the primitive failure code test for the argument being sequence able and doing it for you: perform: selector withArguments: argArray inSuperclass: lookupClass "NOTE: This is just like perform:withArguments:, except that the message lookup process begins, not with the receivers's class, but with the supplied superclass instead. It will fail if lookupClass cannot be found among the receiver's superclasses. Primitive. Essential. See Object documentation whatIsAPrimitive." <primitive: 100> argArray isArray ifFalse: [(argArray isCollection and: [argArray isSequenceable]) ifTrue: [^self perform: selector withArguments: argArray asArray inSuperclass: lookupClass]. ^self error: 'argArray argument must be an Array']. selector isSymbol ifFalse: [^self error: 'selector argument must be a Symbol']. selector numArgs = argArray size ifFalse: [^self error: 'incorrect number of arguments']. (self class == lookupClass or: [self class inheritsFrom: lookupClass]) ifFalse: [^self error: 'lookupClass is not in my inheritance chain']. (self class lookupMethodFor: selector ifAbsent: nil) ifNotNil: [:method| | overflowArgs | (method numArgs = argArray size and: [argArray size >= 15]) ifTrue: [overflowArgs := argArray copyFrom: 1 to: 15. overflowArgs at: 15 put: (argArray copyFrom: 15 to: overflowArgs size). ^self perform: selector withArguments: overflowArgs inSuperclass: lookupClass]]. self primitiveFailed > > to make the error less cryptic. > > (or allow OrderedCollection, but since the operation is done in VM it > might be needlessly more work.) > Right. IMO, it's a bad idea putting knowledge of OrderedCollection's representation in the VM. > Peter > > -- _,,,^..^,,,_ best, Eliot

March 12, 2017