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

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

by Johan Fabry

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

July 1, 2015

Re: [Pharo-users] Modern Events Touch and Gestures in Pharo.

by Merwan Ouddane

On 30/06/2015 22:35, J.F. Rick wrote: > Awesome! There's a reasonable chance that I can contribute to this (or > at least utilize it), depending on what contracts I get. If I do get > that in the near future, who do I contact about contributing? I will maintain it for a while, if you have any suggestions or questions, don't hesitate :) > > Cheers, > > Jeff > > On Tue, Jun 30, 2015 at 1:18 PM stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Thanks Thales for the sponsoring. > > https://youtu.be/eNrbH8A5nyY > > Stef and the rmod team >

July 1, 2015

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

by Merwan Ouddane

The DollarP is available too: (Gofer it smalltalkhubUser: 'MerwanOuddane' project: 'DollarPRecognizer'; package: 'DollarPRecognizer') load. On 02/07/2015 00:02, Sven Van Caekenberghe wrote: > Cool, cool, cool ! > >> On 01 Jul 2015, at 23: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 >> >

July 1, 2015

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

by Sven Van Caekenberghe

Cool, cool, cool ! > On 01 Jul 2015, at 23: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 >

July 1, 2015

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

by Matthieu Lacaton

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> a Ã©crit : > 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 1, 2015

1$ Recognizer in Pharo

by stepharo

Now that we have gestures we can interface recognisers. Thanks Thales for the sponsoring. http://youtu.be/Ghxgv8c9OWM Stef

July 1, 2015

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

by stepharo

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 1, 2015

Re: [Pharo-users] does anybody use the AST navigation?

by stepharo

> > Because we could remove it. > > I think we never enabled it because we could not use good key > combinationsâ¦ the idea > was to use ctrl-arrow keys for itâ¦ > > I still think that AST based navigation is a very good idea, > removing it now without having > ever used it for real is not good. > > > Marcus, would that make sense to: > > * extract the core of the AST navigation as an API onto the RB AST > (the ability to go up, down, left and right in a RB AST, basically), > i.e. trying to preserve that way a bit some of the patterns solved by > the AST navigation... > > * and reduce whatever is linked with the GUI / text morph components ? > > Oh, looking at the code, the two aspects are implemented together, so > it will be painfull to refactor. Looking a bit more at the code... I'm > interested by the rationale for askForNodeSelectionFrom: > > Thierry > Marcus the problem is that the idea is cool but if nobody spent time making it useful for real then we will never know if it is working for real. I think that finding the right operations that makes sense can be probably difficult. Now we did the same analysis that thierry. The tree operations like parten children sibbling should not be on class side of nodes navigation but in the AST itself. We can keep used code in the image but I do not really understand why? So we have working tools such as the dependencies browser that could help us that were out of the image and things that nobody ever used in. For me I would unload the code and find a student or somebody interested to improve for real. Stef

July 1, 2015

Re: [Pharo-users] RAM-efficient alternative to ZnMultiPartFormDataEntity

by Stephan Eggermont

On 01/07/15 23:07, Stephan Eggermont wrote: > On 29/06/15 10:00, mikefilonov wrote: >> Hi Sven, >> >> Thank you for a prompt reply. >> >> I have in mind something similar to the followin nginx plugin: >> http://www.grid.net.ru/nginx/upload.en.html > > That is in http://www.squeaksource.com/fileupload I should read the whole thread before posting. Large files in web services provide many more challenges than ram efficiency. Oh, the enterprise buses I've crashed... Stephan

July 1, 2015

Re: [Pharo-users] RAM-efficient alternative to ZnMultiPartFormDataEntity

by Stephan Eggermont

On 30/06/15 06:01, mikefilonov wrote: > Thank you for the link. It is a useful example of how ajax upload can be > implemented in Seaside. > > However, by looking at the code which works without nginx plugin I see the > project does not change the mechanism of request reading, meaning if you > upload 1Gb file you still need 1Gb of RAM to store WAFile rawContent. Yes, you want the code that uses the nginx plugin. Stephan

July 1, 2015