- Pharo-users - lists.pharo.org

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

by Jan BlizniÄenko

Well, Peter posted here his results on his Windows XP and it is slow on his PC, too. About those non-latin characters... lots of these benchmarks are made on compilation of ASCII characters as far as I know, without our project ever loaded. I tested whole loading also on Roassal2 package where I don't expect non-ASCII characters (any way to find out for sure?). Sven Van Caekenberghe-2 wrote > Jan, > > I find it rather hard to believe you are the only Windows users for who > #flush is slow. This is such a fundamental operation that it should have > been caught earlier. Remember that the Pharo code itself is cross platform > identical. Anyway, that is how I feel it. > > Just an idea: does your source code contain non-Latin-1 characters (i.e. > WideStrings), even a single one ? Maybe your name itself (the Ä). > > Sven -- 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 3, 2015

Re: [Pharo-users] an elegant way to return a result

by abdelghani ALIDRA

Hi, There is also this book : Clean Code: A Handbook of Agile Software Craftsmanship Some of you probably already knew about it, still it is good to recall :) Abdelghani | Â | | Â | | Â | Â | Â | Â | Â | | Clean Code: A Handbook of Agile Software CraftsmanshipBook by Martin Robert C | | | | Afficher sur www.amazon.fr | AperÃ§u par Yahoo | | | | Â | Date: Thu, 02 Jul 2015 07:37:11 +0200 From: Joachim Tuchel <jtuchel(a)objektfabrik.de> To: stepharo <stepharo(a)free.fr> Cc: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] an elegant way to return a result Message-ID: Â Â Â <mailman.312.1435823336.8793.pharo-users_lists.pharo.org(a)lists.pharo.org> Â Â Â Content-Type: text/plain; charset=utf-8 Just found this on twitter: http://www.cs.wm.edu/~denys/pubs/ICSE%2715-BadSmells-CRC.pdf Am 01.07.2015 23:35 schrieb stepharo <stepharo(a)free.fr>: > > I know :D > > Le 1/7/15 15:19, jtuchel(a)objektfabrik.de a ?crit : > > Stef, > > > > you're shooting the wrong man! ;-) The crime was committed in your > > team ;-)))) > > > > See you in Brescia > > > > Joachim > > > > Am 30.06.15 um 19:19 schrieb stepharo: > >> > >> > >> Le 30/6/15 14:39, jtuchel(a)objektfabrik.de a ?crit : > >>> Ah, Okay, you are mentioning the one and only one case in which this > >>> could make sense.... ;-) > >>> > >>> Something like > >>> > >>> stream next ifNil: [^stream next]. > >> > >> so ugly. > >> Please we should not teach how to do exception with blocks :) > >>> > >>> So there may be cases where the two sends do not return the same > >>> result. But that is, of course, not what the OP suggested. > >>> Nevertheless, I was too fast in criticizing ;-) > >>> > >>> I would consider code like that "less easy" to maintain, however. > >>> > >>> Nice thinking Kata ;-) > >>> > >>> Joachim > >>> > >>> > >>> > >>> Am 30.06.15 um 14:22 schrieb Esteban Lorenzano: > >>>> ah yeah :) > >>>> > >>>> I assumed > >>>> > >>>> first "something aMsg" ~= second "something aMsg? > >>>> > >>>> In case is the same, the correct way is as you say: > >>>> > >>>> ^ something aMsg ifNil: [ anotherResult ] > >>>> > >>>> (sorry, he :P) > >>>> > >>>>> On 30 Jun 2015, at 13:43, jtuchel(a)objektfabrik.de wrote: > >>>>> > >>>>> Am 30.06.15 um 13:40 schrieb Peter Uhn?k: > >>>>>> Make sense if there's code in between. > >>>>> not sure what you're saying. I mean, sending the message twice > >>>>> makes sense if you already know the outcome? Hmmm... > >>>>> > >>>>>> something aMsg ifNil:[ ^ something aMsg ]. "yay for guards!" > >>>>>> "much more code" > >>>>>> ^ aNotherResult > >>>>>> > >>>>>> Peter > >>>>> > >>>>> -- > >>>>> ----------------------------------------------------------------------- > >>>>> > >>>>> Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de > >>>>> Fliederweg 1 http://www.objektfabrik.de > >>>>> D-71640 Ludwigsburg http://joachimtuchel.wordpress.com > >>>>> Telefon: +49 7141 56 10 86 0???????? Fax: +49 7141 56 10 86 1 > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > > > >

July 3, 2015

Re: [Pharo-users] an elegant way to return a result

by jtuchel＠objektfabrik.de

Stef, So we're finding more and more problems in just a single line of code ;-) Do you see advantages in this piece of code? Would it be friendlier to the Compiler/VM or a programmer in your opinion? |nextOrNextAfterNext| nextOrNextAfterNext := stream next ifNil: [stream next]. ^nextOrNextAfterNext Joachim Am 02.07.15 um 23:23 schrieb stepharo: > Hi matthieu > > on my side: > > stream next ifNil: [^stream next]. > > When you execute a block (far away from the place it was created), it > acts as an exception, it stops the execution of currently executed > methods and > return to its home context (method that led to the creation of the > block) Read deep into Pharo because this is a great chapter. > So people should avoid to put return statement into a block since a > block returns already the value of its last expression. > > So for me > arg: [ ^ ... ] > > is a big warning. > > Stef > > > > Le 1/7/15 23:55, Matthieu Lacaton a Ã©crit : >> >> This whole conversation really makes me want to ask: How do you know >> if some code is bad, good or completely ugly ? I've not been >> programming for long but I've already heard sentences like this: >> "Damn this piece of code is so bad !" so often that I am really >> wondering. What are the rules ? Performant code makes total sense but >> it seems there is something else. >> >> Le 1 juil. 2015 23:36, "stepharo" <stepharo(a)free.fr >> <mailto:stepharo@free.fr>> a Ã©crit : >> >> I know :D >> >> Le 1/7/15 15:19, jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> a Ã©crit : >> >> Stef, >> >> you're shooting the wrong man! ;-) The crime was committed in >> your team ;-)))) >> >> See you in Brescia >> >> Joachim >> >> Am 30.06.15 um 19:19 schrieb stepharo: >> >> >> >> Le 30/6/15 14:39, jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> a Ã©crit : >> >> Ah, Okay, you are mentioning the one and only one >> case in which this could make sense.... ;-) >> >> Something like >> >> stream next ifNil: [^stream next]. >> >> >> so ugly. >> Please we should not teach how to do exception with blocks :) >> >> >> So there may be cases where the two sends do not >> return the same result. But that is, of course, not >> what the OP suggested. Nevertheless, I was too fast >> in criticizing ;-) >> >> I would consider code like that "less easy" to >> maintain, however. >> >> Nice thinking Kata ;-) >> >> Joachim >> >> >> >> Am 30.06.15 um 14:22 schrieb Esteban Lorenzano: >> >> ah yeah :) >> >> I assumed >> >> first "something aMsg" ~= second "something aMsgâ >> >> In case is the same, the correct way is as you say: >> >> ^ something aMsg ifNil: [ anotherResult ] >> >> (sorry, he :P) >> >> On 30 Jun 2015, at 13:43, >> jtuchel(a)objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> wrote: >> >> Am 30.06.15 um 13:40 schrieb Peter UhnÃ¡k: >> >> Make sense if there's code in between. >> >> not sure what you're saying. I mean, sending >> the message twice makes sense if you already >> know the outcome? Hmmm... >> >> something aMsg ifNil:[ ^ something aMsg >> ]. "yay for guards!" >> "much more code" >> ^ aNotherResult >> >> Peter >> >> >> -- >> ----------------------------------------------------------------------- >> >> Objektfabrik Joachim Tuchel >> mailto:jtuchel@objektfabrik.de >> <mailto:jtuchel@objektfabrik.de> >> Fliederweg 1 http://www.objektfabrik.de >> D-71640 Ludwigsburg >> http://joachimtuchel.wordpress.com >> Telefon: +49 7141 56 10 86 0 >> <tel:%2B49%207141%2056%2010%2086%200> >> Fax: +49 7141 56 10 86 1 >> <tel:%2B49%207141%2056%2010%2086%201> >> >> >> >> >> >> >> >> >> >> >> >> >> > -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1

July 3, 2015

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

by phil＠highoctane.be

On Thu, Jul 2, 2015 at 11:39 PM, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > Flush is, in the store benchmark I used, called from from > MultiByteFileStream(WriteStream) >>#nextChunkPut: and from > CompiledMethod>>#putSource:inFile:withPreamble: ... when I comment out > calling flush in these two methods, it is fast like when whole content of > flush method is commented out. However, If I keep these two flush calls > commented, but I once call flush manually in the end of the "store" code, > it > is slow again (well, instead of 8-18 runs per sec it runs 40-50 times per > sec, but it is far from 9000 when flush does not happen at all). It seems > to > me like the problem is not in how many times flush is called, but more in > what actually happens when flush is called (how is the primitive primFlush: > achieved on Windows). > In pharo-vm\platforms\win32\plugins\FilePlugin\sqWin32FilePrims.c sqInt sqFileFlush(SQFile *f) { if (!sqFileValid(f)) FAIL(); /* note: ignores the return value in case of read-only access */ FlushFileBuffers(FILE_HANDLE(f)); return 1; } http://blogs.msdn.com/b/oldnewthing/archive/2010/09/09/10059575.aspx "If you perform one of these explicit flush operations, you aren't letting the disk cache do its job." I guess we do just that. More on that issue: http://stackoverflow.com/questions/18276554/windows-fsync-flushfilebuffers-… http://winntfs.com/2012/11/29/windows-write-caching-part-2-an-overview-for-… Side question: is write caching enabled on that drive? Phil > > Jan > > > Nicolai Hess wrote > > 2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe < > > > sven@ > > > >: > > > >> #flush on a stream means pushing all data to the final destination, > >> clearing buffers, doing actual network transfers. > >> > >> What can happen when you disable that ? > >> > >> That some data does not arrive where it should I guess. > >> > >> Mind that #close most of the time does an automatic/implicit #flush. > >> > >> Anyway, I don't think disabling #flush is a real solution. > >> > > > > +1 > > > > Maybe it is enough, if we remove the call to "self flush" in > > WriteStream>>#nextChunkPut: > > ? > > > > I see that squeak does not call flush, and :) in Squeak > > WriteStream>>#flush > > is empty (!) > > (But I think in squeak and pharo are many differences for stream and > > source/changes handling) > > > > > > -- > 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 3, 2015

Re: [Pharo-users] an elegant way to return a result

by Peter UhnÃ¡k

> > > So for me > > arg: [ ^ ... ] > > > > is a big warning. > > > > Stef > > Is there a code critic for that ? :) > > There is code critic that encourages you to use it for guards. :) Peter

July 3, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Thierry Goubier

Le 02/07/2015 23:16, stepharo a Ã©crit : > > > Le 1/7/15 21:10, Thierry Goubier a Ã©crit : >> Le 01/07/2015 21:07, jtuchel(a)objektfabrik.de a Ã©crit : >>> I gave up on porting tests. VAST doesn't support creating Arrays with >>> curly braces, and they are used all over the place in Pharo code. I wuld >>> use them if I had them, so this is not an accuse or anything. It's just >>> a huge load of work to keep tests up to date when porting newer >>> versions, so I just ignore tests when porting. A sad truth. >> >> Maybe we should write a refactoring to change those curly braces into >> an equivalent Array based syntax? >> >> I'll have some significant porting from Pharo to do one of these days, >> so maybe I'll setup something for that. > Why from Pharo? What is the problem? Not really any problem. There are just a thing or two I'd like to try, and I need to get up to speed on refactorings. Thierry

July 3, 2015

Re: [Pharo-users] NeoCSVReader and an empty field at the very end of a file

by Thierry Goubier

Hi Stef, Le 02/07/2015 23:18, stepharo a Ã©crit : > Hi thierry > > mark will arriv at Lille saturday for a month. He is working with > Camille on a new tree pattern matching algorithm A generic algorithm or one tied to the RB AST? > because we lost energy on RB matcher. What was your analysis? Thanks, Thierry > > Stef > > Le 1/7/15 21:29, Thierry Goubier a Ã©crit : >> Le 01/07/2015 21:16, jtuchel(a)objektfabrik.de a Ã©crit : >>> You mean RewriteRules? I was planning to do that, for this exact reason. >>> But you know how things go when there is a long list of priorities. >>> I know it saves a lot of time and makes porting so much more safe, but >>> it needs an up-front investment in time... >> >> Yes, rewrite rules. Mark Rizun GUI attempts are a very interesting >> direction to handle that... >> >> Oh, by the way, Mark, if you're listening... I did what you were >> trying to do by changing AST nodes positions in Pharo, but on a SmaCC >> based AST for another language. I have to admit that you were right to >> try to do it that way, but that the Pharo/RB AST infrastructure wasn't >> suitable whereas SmaCC infrastructure is. >> >> Thierry >> >> > > >

July 3, 2015

Re: [Pharo-users] an elegant way to return a result

by Ben Coman

On Fri, Jul 3, 2015 at 5:23 AM, stepharo <stepharo(a)free.fr> wrote: > Hi matthieu > > on my side: > > stream next ifNil: [^stream next]. > > When you execute a block (far away from the place it was created), it acts > as an exception, it stops the execution of currently executed methods and > return to its home context (method that led to the creation of the block) > Read deep into Pharo because this is a great chapter. > So people should avoid to put return statement into a block since a block > returns already the value of its last expression. > > So for me > arg: [ ^ ... ] > > is a big warning. > > Stef Is there a code critic for that ? :) cheers -ben

July 3, 2015

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

by Sven Van Caekenberghe

Jan, I find it rather hard to believe you are the only Windows users for who #flush is slow. This is such a fundamental operation that it should have been caught earlier. Remember that the Pharo code itself is cross platform identical. Anyway, that is how I feel it. Just an idea: does your source code contain non-Latin-1 characters (i.e. WideStrings), even a single one ? Maybe your name itself (the Ä). Sven > On 02 Jul 2015, at 23:39, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > Flush is, in the store benchmark I used, called from from > MultiByteFileStream(WriteStream) >>#nextChunkPut: and from > CompiledMethod>>#putSource:inFile:withPreamble: ... when I comment out > calling flush in these two methods, it is fast like when whole content of > flush method is commented out. However, If I keep these two flush calls > commented, but I once call flush manually in the end of the "store" code, it > is slow again (well, instead of 8-18 runs per sec it runs 40-50 times per > sec, but it is far from 9000 when flush does not happen at all). It seems to > me like the problem is not in how many times flush is called, but more in > what actually happens when flush is called (how is the primitive primFlush: > achieved on Windows). > > Jan > > > Nicolai Hess wrote >> 2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe < > >> sven@ > >> >: >> >>> #flush on a stream means pushing all data to the final destination, >>> clearing buffers, doing actual network transfers. >>> >>> What can happen when you disable that ? >>> >>> That some data does not arrive where it should I guess. >>> >>> Mind that #close most of the time does an automatic/implicit #flush. >>> >>> Anyway, I don't think disabling #flush is a real solution. >>> >> >> +1 >> >> Maybe it is enough, if we remove the call to "self flush" in >> WriteStream>>#nextChunkPut: >> ? >> >> I see that squeak does not call flush, and :) in Squeak >> WriteStream>>#flush >> is empty (!) >> (But I think in squeak and pharo are many differences for stream and >> source/changes handling) > > > > > > -- > 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 3, 2015

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

by Jan BlizniÄenko

Flush is, in the store benchmark I used, called from from MultiByteFileStream(WriteStream) >>#nextChunkPut: and from CompiledMethod>>#putSource:inFile:withPreamble: ... when I comment out calling flush in these two methods, it is fast like when whole content of flush method is commented out. However, If I keep these two flush calls commented, but I once call flush manually in the end of the "store" code, it is slow again (well, instead of 8-18 runs per sec it runs 40-50 times per sec, but it is far from 9000 when flush does not happen at all). It seems to me like the problem is not in how many times flush is called, but more in what actually happens when flush is called (how is the primitive primFlush: achieved on Windows). Jan Nicolai Hess wrote > 2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe < > sven@ > >: > >> #flush on a stream means pushing all data to the final destination, >> clearing buffers, doing actual network transfers. >> >> What can happen when you disable that ? >> >> That some data does not arrive where it should I guess. >> >> Mind that #close most of the time does an automatic/implicit #flush. >> >> Anyway, I don't think disabling #flush is a real solution. >> > > +1 > > Maybe it is enough, if we remove the call to "self flush" in > WriteStream>>#nextChunkPut: > ? > > I see that squeak does not call flush, and :) in Squeak > WriteStream>>#flush > is empty (!) > (But I think in squeak and pharo are many differences for stream and > source/changes handling) -- 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 2, 2015