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

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