- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Collections-Arithmetic

by stepharo

> I like to use these. > > http://www.squeaksource.com/@G_BxD77Hzwe-SmwI/hUjIUazY > > Now there aren't in PharoExtras. > > Shouldn't we have that there? Yes it would be good. And also adding tests. And a little configuration :) Stef > > Phil

March 13, 2016

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

by stepharo

>> >> 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. Do not dream. We will not do it. We will try to make sure that STHUB is working. I do not understand why amber people do not see that this is a really visible Amber Application and getting it in such state is not a good ad for Amber. I hope we will be able to get rid of amber to simplify the maintenance of STHUB. Stef > > Stephan > > >

March 13, 2016

Collections-Arithmetic

by phil＠highoctane.be

I like to use these. http://www.squeaksource.com/@G_BxD77Hzwe-SmwI/hUjIUazY Now there aren't in PharoExtras. Shouldn't we have that there? Phil

March 13, 2016

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