July 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] little challenge for sven and us

by Philippe Marschall

On 07/01/2011 01:38 PM, Janko MivÅ¡ek wrote: > > > S, Philippe Marschall piÅ¡e: >> On 07/01/2011 12:47 PM, Janko MivÅ¡ek wrote: >>> S, Julian Fitzell piÅ¡e: >>>> 2011/6/30 Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>>> >>>> Whole point is that this is a non-blocking code, in contrast to >>>> continuation based approach like in Seaside, where similar code would >>>> block and wait until dialog component returns answer. >>>> >>>> Janko, what are you talking about? If it's not blocking, it's just a >>>> callback. Of course Seaside can do the same thing: you just use >>>> #show:onAnswer:. >>> >>> Isn't the whole point of Seaside and continuations to enable worklow >>> like in below example from the HPI Seaside tutorial? This code is >>> blocking until the call: returns, isn't that so? >>> >>> From HPI tutorial [1], chapter 5-Forms, figure 5-2 : >>> >>> (self call: self taskEditor) >>> ifTrue: [aTask copyFrom: self taskEditor task] >>> >>> Text bellow: "Even better, Seaside remembers the position in your code >>> and runs it from there again, after the called component finished. This >>> means, #call: blocks your current component, that is your callback >>> evaluation, waits for the called component to be finished, and >>> afterwards goes on with your callback. " >> >> Yes, but continuations don't block a Process. All they do is allow you >> to write code that is more readable. > > Yes, technically it doesn't block that process because it must return > something to the browser, but method execution actually blocks on that > point. No. The method terminates. Cheers Philippe

July 1, 2011

Re: [Pharo-project] Please test Pharo 1.3!

by Schwab,Wilhelm K

My objective was to make it respect the enable/disable setting, and I tracked it to ECToolSet class>>codeCompletionAround:textMorph:keyStroke:. At that level, completion reduces to having a controller and doing some event handling. HTH. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Torsten Bergmann [astares(a)gmx.de] Sent: Friday, July 01, 2011 3:10 AM To: Mariano Martinez Peck; Pharo-project(a)lists.gforge.inria.fr Cc: benjamin.vanryseghem.pharo(a)gmail.com Subject: Re: [Pharo-project] Please test Pharo 1.3! > > > > - Script Manager is broken: adding a script produces an error > > > > Torsten, can you take a look? When I downloaded a fresh Pharo-dev 1.3 from Hudson this morning I was not able to reproduce this. ScriptManager worked without a problem. The only problem I noticed was that there was no styling (which is fixed by replacing MorphicTextEditor with PluggableTextMorph in a new "ScriptManager-Core-tbn.13"). Feel free to integrate this version. It would also nice if ScriptManager would support autocompletion but I got lost in all these completionController stuff... If anyone knows how to apply it feel free to have a look. Dont know about the state of completion these days ... but it would be nice if this would just be an option one sets on the editor. Bye T. -- NEU: FreePhone - kostenlos mobil telefonieren! Jetzt informieren: http://www.gmx.net/de/go/freephone

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Nick Ager

Hi Philippe, In theory yes, in pratice no. You need to to async all the way down and > then all the libraries (DNS, SQL, HTTP, â¦) need to be rewritten to be > async. > > then > your > code > will > read > like > this > > and exception handling is impossible. You can make it read like sync > code again with continuations but you still have to solve the exception > problem. At that point you have gained what exactly besides being > trendy? Don't get me wrong, async has it's place but not in user code. > Node has to be async because it has only a single process and a single > green thread but we don't. > Thanks for the hype busting and for clearest explanation I've yet seen on Internet as to why Node.js is designed the way it as. The CSP analogy is interesting - I hadn't thought of it that way. Nick

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Janko MivÅ¡ek

S, Philippe Marschall piÅ¡e: > On 07/01/2011 12:47 PM, Janko MivÅ¡ek wrote: >> S, Julian Fitzell piÅ¡e: >>> 2011/6/30 Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>> >>> Whole point is that this is a non-blocking code, in contrast to >>> continuation based approach like in Seaside, where similar code would >>> block and wait until dialog component returns answer. >>> >>> Janko, what are you talking about? If it's not blocking, it's just a >>> callback. Of course Seaside can do the same thing: you just use >>> #show:onAnswer:. >> >> Isn't the whole point of Seaside and continuations to enable worklow >> like in below example from the HPI Seaside tutorial? This code is >> blocking until the call: returns, isn't that so? >> >> From HPI tutorial [1], chapter 5-Forms, figure 5-2 : >> >> (self call: self taskEditor) >> ifTrue: [aTask copyFrom: self taskEditor task] >> >> Text bellow: "Even better, Seaside remembers the position in your code >> and runs it from there again, after the called component finished. This >> means, #call: blocks your current component, that is your callback >> evaluation, waits for the called component to be finished, and >> afterwards goes on with your callback. " > > Yes, but continuations don't block a Process. All they do is allow you > to write code that is more readable. Yes, technically it doesn't block that process because it must return something to the browser, but method execution actually blocks on that point. This blocking is not as hard as blocking like on long I/O, but it is still. While on the other side a non-blocking style continues execution of that method instead. Here is the point, and main diffenrec of blocking vs. non-blocking styles. > Instead of > > self call: self taskEditor [ :value | > value ifTrue: [ > aTask copyFrom: self taskEditor task ] ] > > you can write > > (self call: self taskEditor) > ifTrue: [aTask copyFrom: self taskEditor task] > > There is no Process in the background waiting or anything. > > In this simple case the benefit may not be that obvious but look at the > case with only two steps. > > first := self askForFirstObject. > second := self askForSecondObject. > (first aSelector: second) > ifTrue: [ self something ] > ifFalse: [ self somethingElse ] Asynchronous way would be something like: self askForFirstObject onAnswerDo: [:first | self askForSecondObject onAnswerDo: [:second | (first aSelector: second) ifTrue: [self something] ifFalse: [self somethingElse] ] ] This surely looks less nice than your example but it is closer to event driven nature of browser and web apps. And because such workflow is actually rare, it is IMHO not worth such a big expense in framework complexity. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Igor Stasenko

On 1 July 2011 13:13, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 01.07.2011 um 12:47 schrieb Igor Stasenko: > > On 1 July 2011 12:39, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 01 Jul 2011, at 12:31, Nick Ager wrote: > > or even: > > hello world: > > ((ZnServer defaultOn: 1337) > > Â Â Â delegate: (ZnDispatcherDelegate new > > Â Â Â Â Â Â Â map: '/' to: [ :request :response | response entity: (ZnEntity > text: Â 'Hello World!') ])) start > > echo: > > ((ZnServer defaultOn: 1337) > > Â Â Â delegate: (ZnDispatcherDelegate new > > Â Â Â Â Â Â Â map: '/' to: [ :request :response | response entity: (ZnEntity > with: request contents) ])) start > > > > Yes, of course Nick, but then you better use the prefixes: > > ((ZnServer defaultOn: 1337) > > Â Â Â Â delegate: (ZnDispatcherDelegate new > > Â Â Â Â Â Â Â Â map: '/hello' to: [ :request :response | response entity: > (ZnEntity text: Â 'Hello World!') ])) start > > ((ZnServer defaultOn: 1337) > > Â Â Â delegate: (ZnDispatcherDelegate new > > Â Â Â Â Â Â Â Â map: '/echo' to: [ :request :response | response entity: > (ZnEntity with: request contents) ])) start > > Writing the shortest possible server code is a dubioius challenge. Although > few Smalltalker would be happy to use verbose and heavy Java and XML. It is > important that simple things be easy, short and elegant and complex things > be possible. > > > The problem with such short examples is that they usually serve as a > advertisement to attract new users, but has nothing to do with > reality. > Because once you put a real requirements before a framework which you > would like to use for your needs, and measure how easy/fast you could > implement it, > then you realising that simple things are not so simple as shown in > 'hello world' examples. > So, such pieces of code could actually thwart users away: because once > you hit a wall (and you will always hit it no matter what framework > you using), the first reaction could be: > - hey but you said it will be easy! > > :) > > And if you wouldn't say it they won't even try it at first. No, i think that showing a real-world example, a nice killer app implemented on top of your framework will sell it much better than silly and useless helloworld code snippets. > Norbert > -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

[Pharo-project] Opal now on Jenkins

by Marcus Denker

https://ci.lille.inria.fr/pharo/job/OpalCompiler/ I will delete the Hudson project. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 1, 2011

Re: [Pharo-project] 1.3 profiler - nice stuff!

by Schwab,Wilhelm K

It is now 4482. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck [marianopeck(a)gmail.com] Sent: Friday, July 01, 2011 3:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] 1.3 profiler - nice stuff! On Fri, Jul 1, 2011 at 12:34 AM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Recent mention of the profiler prodded me to take a look at the profiler in 1.3. Very nice! Some "quick" changes that I think would be good: (1) Shout in the code pane; (2) Use tabs to show the gc data or the code; (3) Add a tab to show the result rather than using a modal notifier (which probably quickly gets dismissed, and then missed<g>). Yes, that would be nice. Open a ticket :) A non-quick change, if it's even possible... Some of the slickest Dolphin goodies in existence include: Ian Bartholomew's ChunkBrowser (Pharo's lost changes is close and useful, but not the same) and Profiler, the SUnitBrowser (nicer than the SUnit test runner), and Ghoul. Ghoul is well named. It presents Dolphin crash dumps in a debugger-like view: http://metagnostic.org/DolphinSmalltalk/Ghoul.html If there is, or could/should be enough data in a profile to do the same thing, it would make an interesting addition. Then interacting with the code includes the ability to see the values of variables. Bill -- Mariano http://marianopeck.wordpress.com

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Norbert Hartl

Am 01.07.2011 um 12:47 schrieb Igor Stasenko: > On 1 July 2011 12:39, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> >> On 01 Jul 2011, at 12:31, Nick Ager wrote: >> >>> or even: >>> >>> hello world: >>> ((ZnServer defaultOn: 1337) >>> delegate: (ZnDispatcherDelegate new >>> map: '/' to: [ :request :response | response entity: (ZnEntity text: 'Hello World!') ])) start >>> >>> echo: >>> ((ZnServer defaultOn: 1337) >>> delegate: (ZnDispatcherDelegate new >>> map: '/' to: [ :request :response | response entity: (ZnEntity with: request contents) ])) start >>> >>> >> >> Yes, of course Nick, but then you better use the prefixes: >> >> ((ZnServer defaultOn: 1337) >> delegate: (ZnDispatcherDelegate new >> map: '/hello' to: [ :request :response | response entity: (ZnEntity text: 'Hello World!') ])) start >> >> ((ZnServer defaultOn: 1337) >> delegate: (ZnDispatcherDelegate new >> map: '/echo' to: [ :request :response | response entity: (ZnEntity with: request contents) ])) start >> >> Writing the shortest possible server code is a dubioius challenge. Although few Smalltalker would be happy to use verbose and heavy Java and XML. It is important that simple things be easy, short and elegant and complex things be possible. >> > > The problem with such short examples is that they usually serve as a > advertisement to attract new users, but has nothing to do with > reality. > Because once you put a real requirements before a framework which you > would like to use for your needs, and measure how easy/fast you could > implement it, > then you realising that simple things are not so simple as shown in > 'hello world' examples. > So, such pieces of code could actually thwart users away: because once > you hit a wall (and you will always hit it no matter what framework > you using), the first reaction could be: > - hey but you said it will be easy! > > :) > And if you wouldn't say it they won't even try it at first. Norbert

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Norbert Hartl

Am 01.07.2011 um 12:47 schrieb Janko MivÅ¡ek: > S, Julian Fitzell piÅ¡e: >> 2011/6/30 Janko MivÅ¡ek <janko.mivsek(a)eranova.si >> >> Whole point is that this is a non-blocking code, in contrast to >> continuation based approach like in Seaside, where similar code would >> block and wait until dialog component returns answer. >> >> Janko, what are you talking about? If it's not blocking, it's just a >> callback. Of course Seaside can do the same thing: you just use >> #show:onAnswer:. > > Isn't the whole point of Seaside and continuations to enable worklow > like in below example from the HPI Seaside tutorial? This code is > blocking until the call: returns, isn't that so? > > From HPI tutorial [1], chapter 5-Forms, figure 5-2 : > > (self call: self taskEditor) > ifTrue: [aTask copyFrom: self taskEditor task] > > Text bellow: "Even better, Seaside remembers the position in your code > and runs it from there again, after the called component finished. This > means, #call: blocks your current component, that is your callback > evaluation, waits for the called component to be finished, and > afterwards goes on with your callback. " Janko, it is just the style of continuity you choose. If you want to do an asynchronous thing than you split your method into two parts. The first registers the second part as callback anywhere and if the callback is activated the second part of your method is executed. That can be very cumbersome if you have to split it all up. With continuations you split the code at the point the continuation is created. You return from that method and if the callback (the continuation) is invoked you just step into the old method and proceed from there. The only difference I can see is that the latter is far more elegant and powerful. Norbert

July 1, 2011

Re: [Pharo-project] little challenge for sven and us

by Philippe Marschall

On 06/30/2011 05:37 PM, Norbert Hartl wrote: > > Am 30.06.2011 um 17:23 schrieb StÃ©phane Ducasse: > >>>> Hi guys >>>> >>>> apparently people get excited by nodeJS and I would like to know the equivalence of >>>> >>> What does it mean? >> >> in Pharo.. how do you have the same: > > It depends what is in your head when you wrote this. The code snippet doesn't tell that much. Registering a Block for execution on request is probably not what makes you excited about. What is exciting about it is that javascript is written in a strictly asynchronous manner (event driven) and that matches perfectly the implementation with asynchronous I/O. Suddenly you can write programs they way you ever wanted it. And lucky for us smalltalk itself is event driven so it can go there easily, too. ... In theory yes, in pratice no. You need to to async all the way down and then all the libraries (DNS, SQL, HTTP, â¦) need to be rewritten to be async. then your code will read like this and exception handling is impossible. You can make it read like sync code again with continuations but you still have to solve the exception problem. At that point you have gained what exactly besides being trendy? Don't get me wrong, async has it's place but not in user code. Node has to be async because it has only a single process and a single green thread but we don't. Cheers Philippe

July 1, 2011