April 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] (non)prefixes of Spec classes

by Stephane Ducasse

I agree with you now it can make the name long. But we could have SpecWindowModel. To me it would help. At least with Spec all the models should terminate with model. On Sat, Apr 1, 2017 at 5:50 PM, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > I suppose this applies to other tools/frameworks as well, but is it > beneficial to have non-prefixed classes in the system? > > e.g. in Spec we have WindowModel, AbstractAdapter, TreeModel, ... > > I am not asking because I want these generic terms free, but rather to be > more explicit about the classes being from Spec. > > Is there any "official" view or preferred view on this? > > Thanks, > Peter > >

April 1, 2017

(non)prefixes of Spec classes

by Peter Uhnak

I suppose this applies to other tools/frameworks as well, but is it beneficial to have non-prefixed classes in the system? e.g. in Spec we have WindowModel, AbstractAdapter, TreeModel, ... I am not asking because I want these generic terms free, but rather to be more explicit about the classes being from Spec. Is there any "official" view or preferred view on this? Thanks, Peter

April 1, 2017

File I/O performance (Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure)

by David T. Lewis

On Sat, Apr 01, 2017 at 10:06:34AM +0200, Nicolas Cellier wrote: > AFAIR, flushing after each write was a workaround against some linux > problem. This was specifically for the case of writing a chunk to e.g. the changes file. The extra flush for that case is protecting for two processes writing to the same stream. This would not affect overall read/write performance though. > I think that flush is not exagerately expensive on linux, because there's a > difference between flush (transfer data from user space buffers to kernel > space buffers) and sync (transfer data to the disc). The Windows VM uses a different FilePlugin. The I/O calls are made at the HANDLE level, not at the (FILE *) level as in the Unix plugin. A HANDLE on Windows would be loosely equivalent to a file descriptor number on Unix. If #primitiveFileFlush is intended to mean "flush everything from the VM out to the operating system", and #primitiveFileSync is intended to mean "tell the operating system to flush it all way to disk", then flush would be a no-op on Windows, and you would call the sync primitive only in cases where you really need to guarantee a flush to disk. An interesting project would be to adapt the Unix plugin to run on Windows (maybe it already just works, I never tried), or conversely to write a Unix plugin that reads and writes to the file descriptor level as in done with the Windows plugin. My guess is that both approaches are valid, and they probably will have differing performance advantages based on the I/O workload. But someone would have to try it to find out :-) Dave > > In Win32 VM, the fileFlush and fileSync primitives do the same call to > FlushFileBuffers. > The msdn tells it's a bad thing to repeatedly call FlushFileBuffers > https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).… > I don't see such thing as a "cheap" flush on windows. > > But do we really need to flush? > Couldn't we rather implement a linuxWorkaroundFlush: aFile method that > would flush on linux and do nothing anywhere else? > > 2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > > > Hi all. I rarely use Windows but this night entered again to repeat the > > load test in Pharo. > > > > Cyril: I uninstalled the antivirus and excluded .changes and .images files > > in the "Windows Defender" (didn't know it exists). I may note some speed up > > but not much, so it wasn't THE solution. > > > > Peter: I didn't check firewall but "Compiling methods..." is what stays on > > screen so it shouldn't be the network. > > > > Eliot: this time I profiled it and can highlight from report that Leaves > > shows 91% in StandardFileStream>>primFlush:. I guess it isn't too > > surprising since file writing is expensive but it's a lot. However I didn't > > compare it yet with the respective report in linux. For the record, I > > attach the report. > > > > Code evaluated: > > AndreasSystemProfiler spyOn: [ > > Gofer new > > url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; > > package: 'ConfigurationOfRoassal2'; > > load. > > #ConfigurationOfRoassal2 asClass load.] > > > > Regards > > Mart??n > > > > > > On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < > > cyril.ferlicot(a)gmail.com> wrote: > > > >> Le 16/03/2017 ?? 05:11, Martin Dias a ??crit : > >> > And it takes >30 minutes to load Roassal2, while takes <1 minyte in > >> > Linux (same notebook). Script: > >> > > >> > >> Do you have an anti-virus? If yes did you excluded the .changes and ombu > >> files from the files to check? If not the anti-virus might analyze your > >> file at each compilation. > >> > >> -- > >> Cyril Ferlicot > >> > >> http://www.synectique.eu > >> > >> 2 rue Jacques Pr??vert 01, > >> 59650 Villeneuve d'ascq France > >> > >> > >

April 1, 2017

Re: [Pharo-dev] [gsoc] Advances in Code Quality

by Guillermo Polito

Yes! Actually offering fixes and transformations from renraku based on the selected ast node could be really cool! On Fri, Mar 31, 2017 at 7:21 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > This is a super topic. > What would be good is to check the smart suggestions because they need > more love. > > Stef > > On Fri, Mar 31, 2017 at 3:14 PM, Myroslava Romaniuk <romaniuk(a)ucu.edu.ua> > wrote: > >> Hello, >> >> I'm Myroslava and I'm studying Computer Science at the Ukrainian Catholic >> University in Lviv. As part of my Google Summer of Code project I'm going >> to work on the quality of code in Pharo. This >> <https://docs.google.com/document/d/1cX7VJ2QZejq_Cu6Ur28UCiUwzSD-Bu8GgSDqECi…> >> is my proposal draft, and I would really appreciate some feedback, >> comments, suggestions and so on. >> >> Thanks! >> > >

April 1, 2017

Re: [Pharo-dev] [Gsoc] [FastTable improvements] [Features request]

by Guillermo Polito

I understand that the data source we have right now is too low level. I'd prefer to call it "Cell data source" rather than view as it is more specific to the table, unless we want to reuse it in other scenarios.... Now, maybe part of GSOC could be to provide a higher-level provider able to nicely map domain objects to cells, wether it is text, icons, pictures, morphs, widgets. On Fri, Mar 31, 2017 at 7:24 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > I read and could not understand. Now what I see is that there are view in > the class name. > So at least dataSource should be called dataSourceViewProvider. > > On Fri, Mar 31, 2017 at 9:56 AM, Stephan Eggermont <stephan(a)stack.nl> > wrote: > >> On 31/03/17 08:14, Stephane Ducasse wrote: >> >>> To me a datasource should deliver data and not UI elements. >>> >> >> AFAIK it is an old established designation for this. >> It is the data source of the table view, not of the persistency >> layer. It provides a single point of access to the data in a form that >> the table view can understand, which is cells. >> >> https://developer.apple.com/reference/uikit/uitableviewdatasource >> https://developer.apple.com/reference/uikit/uitableviewdelegate >> >> Stephan >> >> >> >

April 1, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Nicolas Cellier

In squeak, that would be: Frank Shearar uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-fbs.513.mcz ==================== Summary ==================== Name: Collections-fbs.513 Author: fbs Time: 26 April 2013, 11:13:00.656 am UUID: dba4f808-6844-414c-a5bf-5cda0cf4e342 Ancestors: Collections-bf.512 This fixes the recent report of an Ubuntu 13.04 machine not being able to save a class comment. https://bugzilla.redhat.com/show_bug.cgi?id=956376 I presume that the workaround in Pharo appeared more or less simultaneously since Pavel was active in the bug report. Now we re-discover that such workaround can have side effects... 2017-04-01 10:06 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > AFAIR, flushing after each write was a workaround against some linux > problem. > I think that flush is not exagerately expensive on linux, because there's > a difference between flush (transfer data from user space buffers to kernel > space buffers) and sync (transfer data to the disc). > > In Win32 VM, the fileFlush and fileSync primitives do the same call to > FlushFileBuffers. > The msdn tells it's a bad thing to repeatedly call FlushFileBuffers > https://msdn.microsoft.com/en-us/library/windows/desktop/ > aa364439(v=vs.85).aspx > I don't see such thing as a "cheap" flush on windows. > > But do we really need to flush? > Couldn't we rather implement a linuxWorkaroundFlush: aFile method that > would flush on linux and do nothing anywhere else? > > 2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > >> Hi all. I rarely use Windows but this night entered again to repeat the >> load test in Pharo. >> >> Cyril: I uninstalled the antivirus and excluded .changes and .images >> files in the "Windows Defender" (didn't know it exists). I may note some >> speed up but not much, so it wasn't THE solution. >> >> Peter: I didn't check firewall but "Compiling methods..." is what stays >> on screen so it shouldn't be the network. >> >> Eliot: this time I profiled it and can highlight from report that Leaves >> shows 91% in StandardFileStream>>primFlush:. I guess it isn't too >> surprising since file writing is expensive but it's a lot. However I didn't >> compare it yet with the respective report in linux. For the record, I >> attach the report. >> >> Code evaluated: >> AndreasSystemProfiler spyOn: [ >> Gofer new >> url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main' >> ; >> package: 'ConfigurationOfRoassal2'; >> load. >> #ConfigurationOfRoassal2 asClass load.] >> >> Regards >> MartÃn >> >> >> On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < >> cyril.ferlicot(a)gmail.com> wrote: >> >>> Le 16/03/2017 Ã 05:11, Martin Dias a Ã©crit : >>> > And it takes >30 minutes to load Roassal2, while takes <1 minyte in >>> > Linux (same notebook). Script: >>> > >>> >>> Do you have an anti-virus? If yes did you excluded the .changes and ombu >>> files from the files to check? If not the anti-virus might analyze your >>> file at each compilation. >>> >>> -- >>> Cyril Ferlicot >>> >>> http://www.synectique.eu >>> >>> 2 rue Jacques PrÃ©vert 01, >>> 59650 Villeneuve d'ascq France >>> >>> >> >

April 1, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Nicolas Cellier

AFAIR, flushing after each write was a workaround against some linux problem. I think that flush is not exagerately expensive on linux, because there's a difference between flush (transfer data from user space buffers to kernel space buffers) and sync (transfer data to the disc). In Win32 VM, the fileFlush and fileSync primitives do the same call to FlushFileBuffers. The msdn tells it's a bad thing to repeatedly call FlushFileBuffers https://msdn.microsoft.com/en-us/library/windows/desktop/aa364439(v=vs.85).… I don't see such thing as a "cheap" flush on windows. But do we really need to flush? Couldn't we rather implement a linuxWorkaroundFlush: aFile method that would flush on linux and do nothing anywhere else? 2017-04-01 6:40 GMT+02:00 Martin Dias <tinchodias(a)gmail.com>: > Hi all. I rarely use Windows but this night entered again to repeat the > load test in Pharo. > > Cyril: I uninstalled the antivirus and excluded .changes and .images files > in the "Windows Defender" (didn't know it exists). I may note some speed up > but not much, so it wasn't THE solution. > > Peter: I didn't check firewall but "Compiling methods..." is what stays on > screen so it shouldn't be the network. > > Eliot: this time I profiled it and can highlight from report that Leaves > shows 91% in StandardFileStream>>primFlush:. I guess it isn't too > surprising since file writing is expensive but it's a lot. However I didn't > compare it yet with the respective report in linux. For the record, I > attach the report. > > Code evaluated: > AndreasSystemProfiler spyOn: [ > Gofer new > url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; > package: 'ConfigurationOfRoassal2'; > load. > #ConfigurationOfRoassal2 asClass load.] > > Regards > MartÃn > > > On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> Le 16/03/2017 Ã 05:11, Martin Dias a Ã©crit : >> > And it takes >30 minutes to load Roassal2, while takes <1 minyte in >> > Linux (same notebook). Script: >> > >> >> Do you have an anti-virus? If yes did you excluded the .changes and ombu >> files from the files to check? If not the anti-virus might analyze your >> file at each compilation. >> >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >> >

April 1, 2017

Re: [Pharo-dev] [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

by Martin Dias

Hi all. I rarely use Windows but this night entered again to repeat the load test in Pharo. Cyril: I uninstalled the antivirus and excluded .changes and .images files in the "Windows Defender" (didn't know it exists). I may note some speed up but not much, so it wasn't THE solution. Peter: I didn't check firewall but "Compiling methods..." is what stays on screen so it shouldn't be the network. Eliot: this time I profiled it and can highlight from report that Leaves shows 91% in StandardFileStream>>primFlush:. I guess it isn't too surprising since file writing is expensive but it's a lot. However I didn't compare it yet with the respective report in linux. For the record, I attach the report. Code evaluated: AndreasSystemProfiler spyOn: [ Gofer new url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main'; package: 'ConfigurationOfRoassal2'; load. #ConfigurationOfRoassal2 asClass load.] Regards MartÃn On Thu, Mar 16, 2017 at 8:03 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com > wrote: > Le 16/03/2017 Ã 05:11, Martin Dias a Ã©crit : > > And it takes >30 minutes to load Roassal2, while takes <1 minyte in > > Linux (same notebook). Script: > > > > Do you have an anti-virus? If yes did you excluded the .changes and ombu > files from the files to check? If not the anti-virus might analyze your > file at each compilation. > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

April 1, 2017