- Pharo-dev - lists.pharo.org

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

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

by Philippe Marschall

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. 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 ] Sure you could write that in CSP but would you really want to? Cheers Philippe

July 1, 2011

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

by Janko MivÅ¡ek

Hi Sven, Why not simply: (ZnServer startOn: 1337) onRequestRespond: [:request |: ZnResponse ok: 'Hello world'] This is the closest form to that node.js example and really show the power of Smalltalk and its closures. Also understandable to everyone including the (IMHO) majority, who don't understand design patterns like Delegate well. Best regards Janko S, Sven Van Caekenberghe piÅ¡e: > > 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. > > Sven > > > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

July 1, 2011

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

by 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! :) > Sven -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

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

by 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. " [1] http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 1, 2011