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

Some bugs I'm experiencing in latest 50

by stepharo

- I got nautilus blocked and irresponsive (but I could close it). - When I saved my image the vm crashed but the image was fully saved. Stef Image ----- /Users/ducasse/Library/Application Support/Pharo/images/OPAX/OPAX.image Pharo5.0 Latest update: #50636 Unnamed Virtual Machine --------------- /Applications/Pharo/SpurPharo.app/Contents/MacOS/Pharo CoInterpreter VMMaker.oscog-eem.1664 uuid: 9e676eea-f638-4da0-bd70-920a096bda28 Jan 23 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1664 uuid: 9e676eea-f638-4da0-bd70-920a096bda28 Jan 23 2016 https://github.com/estebanlm/pharo-vm.git Commit: 8872c82ba7e8a56d06a95fb473501bde1b6ec807 Date: 2016-01-23 03:23:40 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #533 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString https://github.com/estebanlm/pharo-vm.git Commit: 8872c82ba7e8a56d06a95fb473501bde1b6ec807 Date: 2016-01-23 03:23:40 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #533 CoInterpreter VMMaker.oscog-eem.1664 uuid: 9e676eea-f638-4da0-bd70-920a096bda28 Jan 23 2016 StackToRegisterMappingCogit VMMaker.oscog-eem.1664 uuid: 9e676eea-f638-4da0-bd70-920a096bda28 Jan 23 2016

March 13, 2016

Re: [Pharo-dev] feedback from yet another student presentation

by Stephan Eggermont

On 11-03-16 09:22, philippe.back(a)highoctane.be wrote: > > And that woukd be a nice thing to hack on during PharoDays > I'm not sure that is good timing, at least not if you want to implement changes there. PharoDays is not at INRIA, and it is likely that improvements need changes at the system level. I'm not aware of a test environment for smalltalkhub. And I'd expect a more than average load on smalltalkhub during the event. I'd welcome an upgrade to current Amber and changes that allow me to look at Smalltalkhub from an iOS device. Stephan

March 13, 2016

Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations

by Ben Coman

On Sun, Mar 13, 2016 at 9:27 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> > wrote: > >> Hi >> >> At some point I got a feeling that actual Delay time is longer than >> expected. It is especially visible on small delays less than 100ms >> (otherwise difference is < 1%). >> >> [image: Inline image 1] >> Documentation says that *Delay waits approximately* for specified amount >> of time. However, according to experimental data an actual difference is >> always positive with the value around 1.5-2 seconds. It is actually strange >> where such a constant difference, independent from delay length, comes from. >> [image: Inline image 2] >> To conclude, if you want to wait more precisely you need to create delays >> with duration 1.5 seconds less than expected. Also it would be interesting >> to test on different hardwares to make sure that difference stays constant >> (around 1.5-2s) >> >> I used the following script to gather data and save in .csv file >> http://ws.stfx.eu/DSCLG2ON0VBI >> >> Tested on: >> Pharo: #50636 >> Spur-VM: #463 >> OS: Mac OS Yosemite >> CPU: Intel Core i7 2.39 GHz >> > > > Nice analysis. I've previously wondered about such an effect from > resumptionTime being calculated by the high priority thread in > #handleTimerEvent: and thus delayed by switching threads, rather than being > calculated as-soon-as-possible by the low priority process when #schedule: > is called. I can't remember my line of reasoning, but doing it the low > priority process seemed to open the potential for nasty race conditions, so > I left it as I found it. Perhaps we should take a time snapshot in the > #schedule: and pass that through to #handleTimerEvent: similar to > scheduledDelay. Would you like to try that? > > btw, I have some cleanup of DelayScheduler almost complete that I had > meant to get into Pharo 5 earlier, but now I think best to wait for early > Pharo 6. > > cheers -ben > P.S. I'm curious how you came to notice this. I have a long term interest in Pharo as a soft-real time industrial control system, motion control system and robotics. One option is using a protocol like EtherCAT which at the hardware level does microsecond time synchronisation of all nodes on the network, and every measurement is microsecond timestamped in the node before it is sent to the control system. So your motion control algorithms can work with an extremely accurate timestamp of *exactly* when a measurement was taken, rather than when the measurement arrived at the control program which is dependent on the delay and jitter vagaries of communications hardware and CPU scheduling of the network stack and control programs.

March 13, 2016

Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations

by Ben Coman

On Sun, Mar 13, 2016 at 1:47 AM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > Hi > > At some point I got a feeling that actual Delay time is longer than > expected. It is especially visible on small delays less than 100ms > (otherwise difference is < 1%). > > [image: Inline image 1] > Documentation says that *Delay waits approximately* for specified amount > of time. However, according to experimental data an actual difference is > always positive with the value around 1.5-2 seconds. It is actually strange > where such a constant difference, independent from delay length, comes from. > [image: Inline image 2] > To conclude, if you want to wait more precisely you need to create delays > with duration 1.5 seconds less than expected. Also it would be interesting > to test on different hardwares to make sure that difference stays constant > (around 1.5-2s) > > I used the following script to gather data and save in .csv file > http://ws.stfx.eu/DSCLG2ON0VBI > > Tested on: > Pharo: #50636 > Spur-VM: #463 > OS: Mac OS Yosemite > CPU: Intel Core i7 2.39 GHz > Nice analysis. I've previously wondered about such an effect from resumptionTime being calculated by the high priority thread in #handleTimerEvent: and thus delayed by switching threads, rather than being calculated as-soon-as-possible by the low priority process when #schedule: is called. I can't remember my line of reasoning, but doing it the low priority process seemed to open the potential for nasty race conditions, so I left it as I found it. Perhaps we should take a time snapshot in the #schedule: and pass that through to #handleTimerEvent: similar to scheduledDelay. Would you like to try that? btw, I have some cleanup of DelayScheduler almost complete that I had meant to get into Pharo 5 earlier, but now I think best to wait for early Pharo 6. cheers -ben

March 13, 2016

Re: [Pharo-dev] Adding a serialize menu item?

by Mariano Martinez Peck

On Sat, Mar 12, 2016 at 5:27 PM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > Hi guys, > > Frequently I need to serialize contents from an inspector/explorer for > later work or because image cannot work with big data sets. > Do you find yourself doing this from an inspector? > > FLSerializer serialize: self toFileNamed: 'MyBigArrayOrString.FL' > > Is there a reason for not having a "Serialize" menu entry in the Raw > palette? > On the other side, from the File Browser a "Materialize" could be added > for .FL files. > > What do you think? > > Sure. And as you said, I would serialize the contents (the object being inspected) instead of the inspector. Because the inspector may reach UI elements and lots of stuff. Or... serialize the inspector, but be sure to use Fuel provided hooks to cut the graph to be traversed that you know that it may bring lot of unneeded stuff. -- Mariano http://marianopeck.wordpress.com

March 13, 2016

Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations

by serge.stinckwich＠gmail.com

Sent from my iPhone On 12 mars 2016, at 21:01, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> I get a BoxedFloat64(61.5) > > Very strange... > > For some unexpected reason you get integers in delay test. But all values should be floats. I double checked the script.. > > There is a difference in arithmetic behaviour between mac and windows! > If I remember correctly there is some differences in float operations between mac and windows. This is a problem for SciSmalltalk. > Cheers, > Alex > >> On Sat, Mar 12, 2016 at 8:48 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >> Le 12/03/2016 20:44, Aliaksei Syrel a Ã©crit : >> > I think we just found a serious bug! >> > >> > Cyrill, could you perform a division in the same image you used for >> > delay test and post result here? >> > >> > 123 / 2.0 >> > >> >> I get a BoxedFloat64(61.5) >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 165 Avenue Bretagne >> Lille 59000 France >

March 12, 2016

Re: [Pharo-dev] Adding a serialize menu item?

by Sven Van Caekenberghe

> On 12 Mar 2016, at 21:27, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > Hi guys, > > Frequently I need to serialize contents from an inspector/explorer for later work or because image cannot work with big data sets. > Do you find yourself doing this from an inspector? > > FLSerializer serialize: self toFileNamed: 'MyBigArrayOrString.FL' > > Is there a reason for not having a "Serialize" menu entry in the Raw palette? Good idea. > On the other side, from the File Browser a "Materialize" could be added for .FL files. I think this already exists, but the extension should be .fuel (just .FL is to simple). > What do you think? > > Cheers, > > HernÃ¡n >

March 12, 2016

Re: [Pharo-dev] problems with the default font

by Esteban Lorenzano

> On 12 Mar 2016, at 21:22, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I meant to ask if you confirm that the rendering looks like the DejaVu font :). I know it was not intentional. > > Indeed, I confirm that just saving fixed the problem. > > I checked the issue tracker and I did not find a bug. Is there such a report or should I create one? wellâ¦ I closed last one (I submitted a fix), but I think I need to open a new one :) Esteban > > Cheers, > Doru > > >> On Mar 12, 2016, at 2:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> no, I do not confirm (that the defaults are DejaVu): it is a bug. >> what actually happens is an effect of the infamous âfont bugâ that is around. >> >> in fact, if you have that effect with a latest image you should not need to reload fonts, just saving image will fix it. >> >>> On 12 Mar 2016, at 14:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> Hi, >>> >>> It looks to me as if in the latest Pharo, the default font is rendered with the DejaVu bitmap font instead of Source Sans Pro. >>> >>> Here is how the font looks like in Nautilus (look at the fonts in the top part): >>> <Screen Shot 2016-03-12 at 1.58.46 PM.png> >>> When I look in Settings, it says that it uses Source Sans Pro. >>> >>> However, if I reload the fonts and set it again to Source Sans Pro, I get this picture with the correct rendering (look at the category name âannouncing"): >>> >>> <Screen Shot 2016-03-12 at 2.18.09 PM.png> >>> >>> Interestingly, the code font looks the same in both situations. Can you confirm this effect? >>> >>> Cheers, >>> Doru >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> www.feenk.com >>> >>> "From an abstract enough point of view, any two things are similar." >>> >>> >>> >>> >> > > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > >

March 12, 2016

Adding a serialize menu item?

by HernÃ¡n Morales Durand

Hi guys, Frequently I need to serialize contents from an inspector/explorer for later work or because image cannot work with big data sets. Do you find yourself doing this from an inspector? FLSerializer serialize: self toFileNamed: 'MyBigArrayOrString.FL' Is there a reason for not having a "Serialize" menu entry in the Raw palette? On the other side, from the File Browser a "Materialize" could be added for .FL files. What do you think? Cheers, HernÃ¡n

March 12, 2016

Re: [Pharo-dev] problems with the default font

by Tudor Girba

Hi, I meant to ask if you confirm that the rendering looks like the DejaVu font :). I know it was not intentional. Indeed, I confirm that just saving fixed the problem. I checked the issue tracker and I did not find a bug. Is there such a report or should I create one? Cheers, Doru > On Mar 12, 2016, at 2:59 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > no, I do not confirm (that the defaults are DejaVu): it is a bug. > what actually happens is an effect of the infamous âfont bugâ that is around. > > in fact, if you have that effect with a latest image you should not need to reload fonts, just saving image will fix it. > >> On 12 Mar 2016, at 14:19, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> It looks to me as if in the latest Pharo, the default font is rendered with the DejaVu bitmap font instead of Source Sans Pro. >> >> Here is how the font looks like in Nautilus (look at the fonts in the top part): >> <Screen Shot 2016-03-12 at 1.58.46 PM.png> >> When I look in Settings, it says that it uses Source Sans Pro. >> >> However, if I reload the fonts and set it again to Source Sans Pro, I get this picture with the correct rendering (look at the category name âannouncing"): >> >> <Screen Shot 2016-03-12 at 2.18.09 PM.png> >> >> Interestingly, the code font looks the same in both situations. Can you confirm this effect? >> >> Cheers, >> Doru >> >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "From an abstract enough point of view, any two things are similar." >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Next time you see your life passing by, say 'hi' and get to know her."

March 12, 2016