- Pharo-users - lists.pharo.org

pharo looses font settings on linux with retina screen

by Martin BÃ¤hr

hi, i am running pharo 40614 on linux on a mac with a retina screen. i have not tested this on a normal laptop yet, so i don't know if the retina resolution is the problem or the pharo version i am using. probably a bit of both. the worst issue is that when i restart an image, the font settings are partially lost and reverted to the original size, which is to small to read on such a screen. and restoring the font size requires me to reopen all the affected windows. there are also issues with some widgets not resizing to the full size of the font, making the text only partially readable. and then there are widgets that have the correct size, but the font remains small. and all that is not consistent, sometimes all sizes are correct, sometimes it is a complete mess. pretty much every time i restart after resetting the font size i get different results. it makes pharo practically unusable on this machine, because i am spending to much time fixing fonts, and am not getting any work done. is there some other setting to adjust to the resolution besides selecting a huge font? greetings, martin. -- eKita - the online platform for your entire academic life -- chief engineer eKita.co pike programmer pike.lysator.liu.se caudium.net societyserver.org secretary beijinglug.org mentor fossasia.org foresight developer foresightlinux.org realss.com unix sysadmin Martin BÃ¤hr working in china http://societyserver.org/mbaehr/

July 1, 2015

Re: [Pharo-users] does anybody use the AST navigation?

by Marcus Denker

> On 30 Jun 2015, at 19:21, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > does any of you use the AST code navigation? > Because we could remove it. I think we never enabled it because we could not use good key combinationsâ¦ the idea was to use ctrl-arrow keys for itâ¦ I still think that AST based navigation is a very good idea, removing it now without having ever used it for real is not good. Marcus

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

I tried commenting primFlush: fileID in StandardFileStream>>#flush on my desktop PC and the "store" benchmark's speed improved significantly. Original result on Windows 7: 11 per sec Result without flushing on Windows 7: 9 430 per sec Original result on Linux Mint 17: 26 590 per sec Result without flushing on Linux Mint 17: 34 879 per sec Mentioned Linux Mint is in VirtualBox on the same PC. Also loading of Roassal2 now takes 58 seconds insted of 386. Jan Nicolai Hess wrote > 2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko < > bliznjan@.cvut > >: > >> Sounds good, could I try it and run all those benchmarks etc. on it on my >> PCs? >> >> Jan >> > > With this: > http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… > It seems this all comes down to calling FlushFileBuffers. > > You can check what would happen if we just disabling the explicit flushing > (comment out > self primFlush: fileID > in StandardFileStream>>#flush) > and run the benchmarks. > > > (Of course, I don't know what side effects this have, *I* think WriteFile > calls flush on > its own, and of course *if* this solves the problem, we can not just > disable call to flush in the > image, but have to change the windows file plugin). > > > > > > >> >> >> Nicolai Hess wrote >> > Yes, the vm primitives, like I already told some messages above. >> > FilePrimitives ARE slow on windows. >> > >> > We may get better performance, if we disable windows file >> cache/buffering >> > and use slightly different ways to do the CreateFile and WriteFile >> > calls, and do the buffering on our own, but this is not easy. >> > >> > Luckily (?), this may be alread work if we use the std file api (?) >> > >> > A small dirty test: >> > >> > store bench >> > latest vm -> '22.098 per second' >> > modified vm -> '31,027 per second' >> > >> > (in the modified vm I replaced all file operation from >> > sqWin32FilePrims.c >> > with the code from >> > sqFilePluginBasicPrims.c) >> > >> > The result may seem strange, because both implementation will actually >> use >> > win32s CreateFile/WriteFile methods, but >> > maybe the second one uses better caching/buffering. >> > >> > nicolai >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Nicolai Hess

2015-07-01 7:46 GMT+02:00 Jan BlizniÄenko <bliznjan(a)fit.cvut.cz>: > Sounds good, could I try it and run all those benchmarks etc. on it on my > PCs? > > Jan > With this: http://stackoverflow.com/questions/14290337/is-fwrite-faster-than-writefile… It seems this all comes down to calling FlushFileBuffers. You can check what would happen if we just disabling the explicit flushing (comment out self primFlush: fileID in StandardFileStream>>#flush) and run the benchmarks. (Of course, I don't know what side effects this have, *I* think WriteFile calls flush on its own, and of course *if* this solves the problem, we can not just disable call to flush in the image, but have to change the windows file plugin). > > > Nicolai Hess wrote > > Yes, the vm primitives, like I already told some messages above. > > FilePrimitives ARE slow on windows. > > > > We may get better performance, if we disable windows file cache/buffering > > and use slightly different ways to do the CreateFile and WriteFile > > calls, and do the buffering on our own, but this is not easy. > > > > Luckily (?), this may be alread work if we use the std file api (?) > > > > A small dirty test: > > > > store bench > > latest vm -> '22.098 per second' > > modified vm -> '31,027 per second' > > > > (in the modified vm I replaced all file operation from > > sqWin32FilePrims.c > > with the code from > > sqFilePluginBasicPrims.c) > > > > The result may seem strange, because both implementation will actually > use > > win32s CreateFile/WriteFile methods, but > > maybe the second one uses better caching/buffering. > > > > nicolai > > > > > > -- > View this message in context: > http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 1, 2015

Re: [Pharo-users] Pharo image processing library

by Luc Fabresse

2015-06-30 9:34 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > On Tue, Jun 30, 2015 at 8:39 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > > > 2015-06-25 18:41 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> > >> Hi, > >> > >> is there any image (as in picture) processing library in the likes of > >> Python's PIL(http://effbot.org/imagingbook/image.htm), > >> > >> or even (highly unlikely) something like OpenCV (http://opencv.org/)? > > > > > > Not that I know of. > > I was interested at one time with the same topic. > > > Juan Vuletich had a nice PhotoSqueak project (squeak 1 or 2?) > > > http://www.jvuletich.org/Squeak/PhotoSqueak/PhotoSqueakGallery/PhotoSqueakG… > > I ask Juan about this one, but apparently this is not open-source. > > > There is Smagick > > http://smalltalkhub.com/#!/~StefanReichhart/Smagick/ > > > > (not a library on its own, but an interface to imagemagick) > > > > I think there was another squeak/imagemagic project but I don't remember. > > > > It would be great to have something like imagemagick, but implemented > > entirely in smalltalk. > > There was some experiments done by Luc : > http://smalltalkhub.com/#!/~LucFabresse/OpenCV this repo only contains some highly experimental code that do not work anymore :-( Luc > > > There is also some basic image processing in VirtualGPU : > http://smalltalkhub.com/#!/~ronsaldo/VirtualGPU > > Regards, > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

Sounds good, could I try it and run all those benchmarks etc. on it on my PCs? Jan Nicolai Hess wrote > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. > > We may get better performance, if we disable windows file cache/buffering > and use slightly different ways to do the CreateFile and WriteFile > calls, and do the buffering on our own, but this is not easy. > > Luckily (?), this may be alread work if we use the std file api (?) > > A small dirty test: > > store bench > latest vm -> '22.098 per second' > modified vm -> '31,027 per second' > > (in the modified vm I replaced all file operation from > sqWin32FilePrims.c > with the code from > sqFilePluginBasicPrims.c) > > The result may seem strange, because both implementation will actually use > win32s CreateFile/WriteFile methods, but > maybe the second one uses better caching/buffering. > > nicolai -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by David T. Lewis

On Wed, Jul 01, 2015 at 01:39:25AM +0200, Nicolai Hess wrote: > 2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > Then the only thing I can think of is a vm primitive that is implemented > > differently in linux/mac than windows vm... > > > > Yes, the vm primitives, like I already told some messages above. > FilePrimitives ARE slow on windows. Is that actually true? I have not done any work on Windows in a while, but I recall that file primitives on Windows were quite efficient. They work differently because they operate at the level of direct file handles rather than stdio streams, but this may be faster in many cases. So unless you have measurable evidence that the Windows IO is slower, don't assume it to be true. Dave

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Nicolai Hess

2015-07-01 0:39 GMT+02:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Then the only thing I can think of is a vm primitive that is implemented > differently in linux/mac than windows vm... > Yes, the vm primitives, like I already told some messages above. FilePrimitives ARE slow on windows. We may get better performance, if we disable windows file cache/buffering and use slightly different ways to do the CreateFile and WriteFile calls, and do the buffering on our own, but this is not easy. Luckily (?), this may be alread work if we use the std file api (?) A small dirty test: store bench latest vm -> '22.098 per second' modified vm -> '31,027 per second' (in the modified vm I replaced all file operation from sqWin32FilePrims.c with the code from sqFilePluginBasicPrims.c) The result may seem strange, because both implementation will actually use win32s CreateFile/WriteFile methods, but maybe the second one uses better caching/buffering. nicolai > > On Tue, Jun 30, 2015 at 7:07 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> > wrote: > >> I'm gonna try to reply to all of you and try your ideas >> >> >> Stephan Eggermont wrote >> > On 30-06-15 14:37, Jan BlizniÄenko wrote: >> >> Unfortunately no - all benchmarks I made with antivirus disabled. >> > >> > Including the Microsoft stuff itself? (Security Essentials/Windows >> > Defender) Does your desktop have a drive > 2TB? >> >> Yes, all such things I have disabled / removed. >> >> >> >> Mariano Martinez Peck wrote >> > Can you think of any other window process that could be detecting >> changes >> > all the time in .changes and therefore have an impact in the >> performance? >> > Do you have such pharo image in dropbox or similar service? >> >> I don't think so. I tried even running Windows in diagnostic startup (safe >> mode / running with only core processes and services) and it had no >> effect. >> >> >> >> Mariano Martinez Peck wrote >> > I would check the processes running and CPU of Windows while loading the >> > code... >> >> I was looking at it some time ago and it didn't seem like processor is too >> much busy, but as I think about it, it is suspiciously almost not busy at >> all ... ~1 % of processor usage. On laptop it fluctuates between 5 and 10 >> %. >> I'm talking about usage when benchmarking the "store" code. >> >> >> >> philippeback wrote >> > Silly question: do you have a couple of Nautilus windows open? >> > >> > Loading stuff generates annoucements and Nautilus updates are killing >> > performance. >> >> No, only open thing is Playground from which I run the benchmarking codes. >> >> >> >> Sven Van Caekenberghe-2 wrote >> >> On 30 Jun 2015, at 18:36, Peter UhnÃ¡k < >> >> > i.uhnak@ >> >> > > wrote: >> >> >> >> I think we've safely established that the bottleneck is disk >> operations. >> > >> > Let's take it one level down then, >> > >> > [ 'foo.txt' asFileReference in: [ :file | >> > file writeStreamDo: [ :out | >> > 3 timesRepeat: [ out << String loremIpsum ] ]. >> > file ensureDelete ] ] bench >> > >> > => "'512.595 per second'" >> > >> > We could experiment with variants, calling #flush, writing by character, >> > adding buffering, etc, but this is a start. At least this takes the >> source >> > code stuff out of the equations. >> >> "654.738 per second" on desktop >> "1,271 per second" on laptop >> >> >> Thank you all for ideas. >> Jan >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Mariano Martinez Peck

Then the only thing I can think of is a vm primitive that is implemented differently in linux/mac than windows vm... On Tue, Jun 30, 2015 at 7:07 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > I'm gonna try to reply to all of you and try your ideas > > > Stephan Eggermont wrote > > On 30-06-15 14:37, Jan BlizniÄenko wrote: > >> Unfortunately no - all benchmarks I made with antivirus disabled. > > > > Including the Microsoft stuff itself? (Security Essentials/Windows > > Defender) Does your desktop have a drive > 2TB? > > Yes, all such things I have disabled / removed. > > > > Mariano Martinez Peck wrote > > Can you think of any other window process that could be detecting changes > > all the time in .changes and therefore have an impact in the performance? > > Do you have such pharo image in dropbox or similar service? > > I don't think so. I tried even running Windows in diagnostic startup (safe > mode / running with only core processes and services) and it had no effect. > > > > Mariano Martinez Peck wrote > > I would check the processes running and CPU of Windows while loading the > > code... > > I was looking at it some time ago and it didn't seem like processor is too > much busy, but as I think about it, it is suspiciously almost not busy at > all ... ~1 % of processor usage. On laptop it fluctuates between 5 and 10 > %. > I'm talking about usage when benchmarking the "store" code. > > > > philippeback wrote > > Silly question: do you have a couple of Nautilus windows open? > > > > Loading stuff generates annoucements and Nautilus updates are killing > > performance. > > No, only open thing is Playground from which I run the benchmarking codes. > > > > Sven Van Caekenberghe-2 wrote > >> On 30 Jun 2015, at 18:36, Peter UhnÃ¡k < > > > i.uhnak@ > > > > wrote: > >> > >> I think we've safely established that the bottleneck is disk operations. > > > > Let's take it one level down then, > > > > [ 'foo.txt' asFileReference in: [ :file | > > file writeStreamDo: [ :out | > > 3 timesRepeat: [ out << String loremIpsum ] ]. > > file ensureDelete ] ] bench > > > > => "'512.595 per second'" > > > > We could experiment with variants, calling #flush, writing by character, > > adding buffering, etc, but this is a start. At least this takes the > source > > code stuff out of the equations. > > "654.738 per second" on desktop > "1,271 per second" on laptop > > > Thank you all for ideas. > Jan > > > > -- > View this message in context: > http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

July 1, 2015

Re: [Pharo-users] Slow compilation on one of my Windows PCs

by Jan BlizniÄenko

I tried Time profiler on |code method| code := 'a'. method := Object compiler source: code; requestor: nil; failBlock: [ ^nil ]; compile. method putSource: code inFile: 2 withPreamble: [:f | f cr; nextPut: $!; nextChunkPut: 'Behavior method'; cr]. desktop: 37.0% {38ms} MultiByteFileStream(WriteStream)>>nextChunkPut: 34.0% {35ms} MultiByteFileStream(WriteStream)>>cr 29.0% {30ms} InMidstOfFileinNotification class(Exception class)>>signal laptop: 60.0% {4ms} MultiByteFileStream(WriteStream)>>cr 40.0% {2ms} InMidstOfFileinNotification class(Exception class)>>signal Jan Sven Van Caekenberghe-2 wrote >> On 30 Jun 2015, at 19:42, Peter UhnÃ¡k < > i.uhnak@ > > wrote: >> >> Debian (host) "'4,855 per second'" >> >> Ubuntu (vbox) "'4,709 per second'" >> >> Win XP (vbox) "'504.099 per second'" >> >> The difference here is just one order of magnitude and not two... so >> maybe I should take apart CompileMethod>>putSource:inFile:withPreambule >> statement by statement. >> >> Is there some more convenient way to do it than wrap each statement in a >> block? Some way to profile a method or something. > > Open the Time Profiler and write your expression there is how you do > analysis on the whole tree. It is not perfect but should help you find the > bottleneck. > >> Peter -- View this message in context: http://forum.world.st/Slow-compilation-on-one-of-my-Windows-PCs-tp4834668p4… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 1, 2015