- Pharo-dev - lists.pharo.org

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

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

by Henrik Nergaard

The numbers in that csv from is in float, but with the fraction part is 0. This is most likely caused by the fact that the precision for timing is in milliseconds, not microseconds. Even the #primUTCMicrosecondsClock only updates per millisecond for me. (Windows). ((1 to: 100000) collect: [:n | Time primUTCMicrosecondsClock ] as: Set) asArray sort. âfor me each entry is increased by 1000â Best regards, Henrik From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Aliaksei Syrel Sent: Saturday, March 12, 2016 9:01 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Comparison of actual and expected Delay length on small durations 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! Cheers, Alex On Sat, Mar 12, 2016 at 8:48 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com<mailto:cyril.ferlicot@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] Comparison of actual and expected Delay length on small durations

by Aliaksei Syrel

> > 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! 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] Comparison of actual and expected Delay length on small durations

by Cyril Ferlicot D.

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] Comparison of actual and expected Delay length on small durations

by Aliaksei Syrel

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 On mac I get a float 61.5 Cheers, Alex On Sat, Mar 12, 2016 at 8:33 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 12/03/2016 18:47, Aliaksei Syrel a Ã©crit : > > 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%). > > > > 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. > > 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 > > > > Cheers, > > Alex > > > > If you wish to compare I join a csv. This is my setup: > > Image > ----- > C:\Users\JeCisC\AppData\Roaming\Pharo\images\Common tools-Pharo 5.0 > (beta)-26\Common tools-Pharo 5.0 (beta)-26.image > Pharo5.0 > Latest update: #50636 > Unnamed > > Virtual Machine > --------------- > C:\Users\JeCisC\Desktop\PharoVMSpur\Pharo.exe > CoInterpreter * VMMaker.oscog-rmacnak.1586 uuid: > 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 > StackToRegisterMappingCogit * VMMaker.oscog-rmacnak.1586 uuid: > 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 > https://github.com/estebanlm/pharo-vm.git Commit: > 6dc730123e8f2b0327839b235d16e0604a92288e Date: 2015-12-13 00:23:41 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #456 > > Win32 built on Dec 13 2015 00:58:42 Compiler: 4.6.2 > VMMaker versionString https://github.com/estebanlm/pharo-vm.git Commit: > 6dc730123e8f2b0327839b235d16e0604a92288e Date: 2015-12-13 00:23:41 +0100 > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #456 > CoInterpreter * VMMaker.oscog-rmacnak.1586 uuid: > 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 > StackToRegisterMappingCogit * VMMaker.oscog-rmacnak.1586 uuid: > 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 > > Operating System/Hardware > ------------------------- > Win32 6.1 IX86 > > Operating System Details > ------------------------ > Operating System: Windows 7 Professional N (Build 7601 Service Pack 1) > Registered Owner: JeCisC > Registered Company: > SP major version: 1 > SP minor version: 0 > Suite mask: 100 > Product type: 1 > > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France >

March 12, 2016

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

by Cyril Ferlicot D.

Le 12/03/2016 18:47, Aliaksei Syrel a Ã©crit : > 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%). > > 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. > 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 > > Cheers, > Alex > If you wish to compare I join a csv. This is my setup: Image ----- C:\Users\JeCisC\AppData\Roaming\Pharo\images\Common tools-Pharo 5.0 (beta)-26\Common tools-Pharo 5.0 (beta)-26.image Pharo5.0 Latest update: #50636 Unnamed Virtual Machine --------------- C:\Users\JeCisC\Desktop\PharoVMSpur\Pharo.exe CoInterpreter * VMMaker.oscog-rmacnak.1586 uuid: 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 StackToRegisterMappingCogit * VMMaker.oscog-rmacnak.1586 uuid: 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 https://github.com/estebanlm/pharo-vm.git Commit: 6dc730123e8f2b0327839b235d16e0604a92288e Date: 2015-12-13 00:23:41 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #456 Win32 built on Dec 13 2015 00:58:42 Compiler: 4.6.2 VMMaker versionString https://github.com/estebanlm/pharo-vm.git Commit: 6dc730123e8f2b0327839b235d16e0604a92288e Date: 2015-12-13 00:23:41 +0100 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #456 CoInterpreter * VMMaker.oscog-rmacnak.1586 uuid: 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 StackToRegisterMappingCogit * VMMaker.oscog-rmacnak.1586 uuid: 8e44b2a7-68ee-4fc9-8513-a04520267053 Dec 13 2015 Operating System/Hardware ------------------------- Win32 6.1 IX86 Operating System Details ------------------------ Operating System: Windows 7 Professional N (Build 7601 Service Pack 1) Registered Owner: JeCisC Registered Company: SP major version: 1 SP minor version: 0 Suite mask: 100 Product type: 1 -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

March 12, 2016

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

by Aliaksei Syrel

*Difference is in milliseconds*, sorry :) On Sat, Mar 12, 2016 at 6:47 PM, 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 > > Cheers, > Alex > >

March 12, 2016

Comparison of actual and expected Delay length on small durations

by Aliaksei Syrel

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 Cheers, Alex

March 12, 2016