July 2015 - Pharo-users - lists.pharo.org

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

by Jan BlizniÄenko

I tried making store benchmark based on caching settings on Windows which look like this: http://www.windows7library.com/blog/wp-content/uploads/2011/07/Write-Cachin… both options checked: desktop 690 per sec, laptop 490 per sec caching checked (enabled), second one not checked (which is default setting): desktop 18 per sec, laptop 480 per sec neither checked: desktop 17 per sec, laptop 9 per sec All is still very far from more than 20 000 on linux in virtual box on the same PC. Also pretty curious how it has different influence on them. I should note that desktop HDD is much older - laptop is 3 years old, but desktop HDD is WD Blue WD6400AAKS made almost 8 years ago. However, disc monitoring utilities report that it is in perfect health (but still old, technologies improved since then I believe). Jan philippeback wrote > Side question: is write caching enabled on that drive? > > Phil -- 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

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 2, 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 2, 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

Re: [Pharo-users] Mofify websockets status to deliver SVG?

by stepharo

quite nice :) Le 30/6/15 23:43, Stephan Eggermont a Ã©crit : > On 30/06/15 22:56, Sean P. DeNigris wrote: >> Stephan Eggermont wrote >>> Screenshot from 2015-06-30 22:46:08.png (110K) >>> <http://forum.world.st/attachment/4834997/0/Screenshot%20from%202015-06-30%2022%3A46%3A08.png> >>> >> >> I'm not following. What is the screenshot? A working app in the >> browser? an >> exported read-only view? > > Exported read-only view, synchronized every second with the Morphic > cardwall. > > Stephan > > > >

July 2, 2015

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

by 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> > > > > > > > > > > > > >

July 2, 2015

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

by stepharo

Hi thierry mark will arriv at Lille saturday for a month. He is working with Camille on a new tree pattern matching algorithm because we lost energy on RB matcher. 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 2, 2015

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

by stepharo

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? Stef

July 2, 2015

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

by stepharo

Le 1/7/15 12:35, jtuchel(a)objektfabrik.de a Ã©crit : > Hi there, > > I am on VA Smalltalk For your next successful project you should jump in Ph.... :) > and therefor using an older version of NeoCSV > (SvenVanCaekenberghe.14). I found a bug in this old version that is > somewhat special. > > It seems NeoCSV cannot handle the situation where the very last field > is just empty AND if there is no trailing CRLF at the end of the file. > Somethinng like this: > > SecondLastColumnValue;;<EOF> > > In that case, readField fails because it tries to do a readQuotedField > or readUnquotedField, both of which try to read beyond EOF. > > So I changed readField to this: > > readField > > ^self atEnd "In case the very last field of a file is empty, like > '45;56;;'" > ifTrue: [''] > ifFalse: [self peekQuote ifTrue: [self readQuotedField] > ifFalse: [self readUnquotedField]] > > and all seems fine so far. > > Side note: My original file has a trailing CrLf but if I upload it via > a browser to a Seaside Server, the Browser cuts off the trailing CrLf > (I can see this in the Browser's Network debugging tools - both in IE > and FF) - so it seems NeoCSV has to be ready for this situation. > > Joachim > >

July 2, 2015

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

by Nicolai Hess

2015-07-02 19:01 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > #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) > > > On 02 Jul 2015, at 17:46, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > > > I'm experimenting with commenting the flush automatically by startup > script > > and loading now takes reasonable amount of time ( StandardFileStream > > compile: 'flush'. ). > > I haven't found any drawbacks so far, but it doesn't mean anything and > that > > "manual" flushing probably is there for a reason, what is the reason? > > > > Jan > > > > > > Jan BlizniÄenko wrote > >> 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 > > > > > > > > > > > > -- > > 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

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

by Sven Van Caekenberghe

#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. > On 02 Jul 2015, at 17:46, Jan BlizniÄenko <bliznjan(a)fit.cvut.cz> wrote: > > I'm experimenting with commenting the flush automatically by startup script > and loading now takes reasonable amount of time ( StandardFileStream > compile: 'flush'. ). > I haven't found any drawbacks so far, but it doesn't mean anything and that > "manual" flushing probably is there for a reason, what is the reason? > > Jan > > > Jan BlizniÄenko wrote >> 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 > > > > > > -- > 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

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

by Jan BlizniÄenko

I'm experimenting with commenting the flush automatically by startup script and loading now takes reasonable amount of time ( StandardFileStream compile: 'flush'. ). I haven't found any drawbacks so far, but it doesn't mean anything and that "manual" flushing probably is there for a reason, what is the reason? Jan Jan BlizniÄenko wrote > 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 -- 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

Re: [Pharo-users] 1$ Recognizer in Pharo

by Alexandre Bergel

> This is cool indeed! > > It would be interesting to integrate it with Roassal to drag elements around. :) +1 Alexandre > > On Thu, Jul 2, 2015 at 12:33 AM, Johan Fabry <jfabry(a)dcc.uchile.cl> wrote: > Very cool ! > > > On Jul 1, 2015, at 18:52, stepharo <stepharo(a)free.fr> wrote: > > > > > > Now that we have gestures we can interface recognisers. > > Thanks Thales for the sponsoring. > > > > http://youtu.be/Ghxgv8c9OWM > > > > Stef > > > > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 2, 2015

Re: [Pharo-users] Phratch: Support for Spanish language in the interface

by Thierry Goubier

Hi Jannik, about that. Why is Phratch not picking the language from the environment? Scratch on the same platform (linux / french) does it. Regards, Thierry Le 02/07/2015 14:00, Offray Vladimir Luna CÃ¡rdenas a Ã©crit : > Thanks Jannik, it worked. I miss the little globe. > > Cheers, > > Offray > > On 02/07/15 06:48, jannik laval wrote: >> Dear Offray, >> >> Thank you for using phratch. >> Spanish is available. You just have to click on the sphere on the left >> of "file" menu. Here, you will find a list of available languages. >> Sometimes, there are blocks that are not translated. In this case, >> don't hesitate to contact me, we will translate them. >> >> Best regards, >> Jannik >> >> 2015-07-02 5:09 GMT+02:00 Offray Vladimir Luna CÃ¡rdenas >> <<mailto:offray@riseup.net>offray(a)riseup.net>: >> >> Hi, >> >> Some teachers are considering to make some field work with Phratch >> on learning physics by modelling simple real world phenomena >> (uniform accelerated movement, free fall etc). I downloaded it >> today and try to change the interface to Spanish, but I couldn't >> find the proper place to do it. Has Phratch support for a Spanish >> interface. If not, how difficult will be to provide this and how >> can we help? >> >> Cheers, >> >> Offray >> >> >> >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://www.approchealpes.info >> http://car.mines-douai.fr/ >> >

July 2, 2015

Re: [Pharo-users] DNS level changes for smalltalkhub.com Friday

by Marcus Denker

Hello, Again: we didnât manage to do it last friday, so it will be tomorrow. > On 25 Jun 2015, at 16:33, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > Friday morning we will do some DNS level changes for smalltalkhub.com. > > This should normally have no impact on the server, as the new DNS server will > point to the same IP as the old. > > Marcus

July 2, 2015

[Pharo5] Update 150!

by Marcus Denker

Hi, We have update 150! https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-5-Publish/ <https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-5-Publish/> On the issue tracker, we already closed 451 issues for Pharo5. Marcus

July 2, 2015

Re: [Pharo-users] Phratch: Support for Spanish language in the interface

by Offray Vladimir Luna CÃ¡rdenas

Thanks Jannik, it worked. I miss the little globe. Cheers, Offray On 02/07/15 06:48, jannik laval wrote: > Dear Offray, > > Thank you for using phratch. > Spanish is available. You just have to click on the sphere on the left > of "file" menu. Here, you will find a list of available languages. > Sometimes, there are blocks that are not translated. In this case, > don't hesitate to contact me, we will translate them. > > Best regards, > Jannik > > 2015-07-02 5:09 GMT+02:00 Offray Vladimir Luna CÃ¡rdenas > <offray(a)riseup.net <mailto:offray@riseup.net>>: > > Hi, > > Some teachers are considering to make some field work with Phratch > on learning physics by modelling simple real world phenomena > (uniform accelerated movement, free fall etc). I downloaded it > today and try to change the interface to Spanish, but I couldn't > find the proper place to do it. Has Phratch support for a Spanish > interface. If not, how difficult will be to provide this and how > can we help? > > Cheers, > > Offray > > > > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://www.approchealpes.info > http://car.mines-douai.fr/ >

July 2, 2015

Re: [Pharo-users] Phratch: Support for Spanish language in the interface

by jannik laval

Dear Offray, Thank you for using phratch. Spanish is available. You just have to click on the sphere on the left of "file" menu. Here, you will find a list of available languages. Sometimes, there are blocks that are not translated. In this case, don't hesitate to contact me, we will translate them. Best regards, Jannik 2015-07-02 5:09 GMT+02:00 Offray Vladimir Luna CÃ¡rdenas <offray(a)riseup.net>: > Hi, > > Some teachers are considering to make some field work with Phratch on > learning physics by modelling simple real world phenomena (uniform > accelerated movement, free fall etc). I downloaded it today and try to > change the interface to Spanish, but I couldn't find the proper place to do > it. Has Phratch support for a Spanish interface. If not, how difficult will > be to provide this and how can we help? > > Cheers, > > Offray > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info http://car.mines-douai.fr/

July 2, 2015