- Pharo-users - lists.pharo.org

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