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

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

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

by Igor Stasenko

On 1 July 2011 12:00, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Jul 1, 2011, at 10:56 AM, Igor Stasenko wrote: > >> On 1 July 2011 07:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> Indeed. Actually the recent JS popular libraries coding style reminds >>>> me more and more smalltalk. >>>> Looks like they are inventing new wheel, going long road from creepy C >>>> syntax and C programming style >>>> to smalltalk. >>> >>> >>> The problem igor is that they will get there and fast because the world is faster. >>> Microsoft is creating a new lab at Zurich for example. And our nice little community >>> did not move since at least one decade. >>> Sometimes I'm immensely sad to see for example that while julian is working for cincom >>> he does not lead an effort to bring Seaside to the next level. Company vision are puzzling me. >>> >> >> To get to the next level, first you have to define what is next level. >> For me , i don't see what is the next level for web application >> framework like seaside. Do you? > > > No but I'm not in the field. > Well, to my observations, web slowly but steady closing the gap between desktop based application and remote ones. HTML5 enabling a rich graphics to be delivered to user, Web 2.0 about better interaction & dynamism of web content and so on. So, doing something in this regard could bring us to this level. > Stef > -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

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

by Sven Van Caekenberghe

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

July 1, 2011

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

by Nick Ager

> > (ZnServer defaultOn: 1337) > logToTranscript; > delegate: (ZnValueDelegate with: [ :request | > ZnResponse ok: (ZnEntity text: 'Hello World!') ]); > start. > > ZnClient get: 'http://localhost:1337'. > > (ZnServer defaultOn: 1337) > logToTranscript; > delegate: (ZnValueDelegate with: [ :request | > ZnResponse ok: (ZnEntity with: request contents) ]); > start. > > ZnClient post: 'http://localhost:1337' data: (ZnEntity text: 'Echo'). > > ZnServer stopDefault. > > > Smalltalk is a beautiful language, isn't it ? 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

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Mariano Martinez Peck

On Fri, Jul 1, 2011 at 10:40 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Dear Pharoers > > I think that we are doing a great work: when I look at the work on the > theme, better widgets, network.....Excellent! and thanks. > Now we were discussing with Doru about how we as community could coordinate > and structure ourselves better to create more energy. > > Analysis of the current situation: > Right now we have individuals doing great projects, sometimes we > have a group of people but this is often not visible. > Now often happens a bit in ad-hoc way. Because someone ask > something, then somebody replies and we integrate the replies. > > What I would like to see emerging are First Class Tasks with > a name > DBXTalk > a topic > Smalltalk relational database suite of tools > a coordinator > Mariano Martinez Peck > a group of interested participants, > - Esteban Lorenzano - Diogenes Moreira - Guillermo Polito - Gisela Decuzzi - Santiago Bragagnolo > a set of identified clients (because clients are the ones that often > make us deliver more), > Real applications needing relational databases. > a little agenda, > - Continue the development - PBE2 chapter - new website > a web presence on the web page > > http://www.squeakdbx.org/ We need a new domain for dbxtalk and update lot of documentation. Consider it part of the agenda :) > If we look at what we have right now that are potential Tasks and really > important clients > > - The Z connection: > Network/Socket > Coordinator (proposed): Sven > Socket: Noury Luc Jannik Olivier > Clients: Seasiders, Clouders, > > - Morphic 2: > UI: Alain Gary Igor > Coordinator (proposed): ? > Presenty framework > VoidNullPointer UIBuilder > Athens > Clients: Moose, Pharo IDE > > - Pharo IDE: > Coordinator (proposed): Doru > work around TWM Laurent > Nautilus: Benjamin Laurent > Glamourous: Doru Damien > > - OPAL: > Compiler tool chain > Coordinator (proposed): Marcus? > Jb, Jorge, Marcus, > Helvetia lukas > Niko Schwarz? > > - Package: > Stef, Cyrille > Coordinator (proposed): Stephane > Client: Nautilus, Doru Moose, > > - Metacello > Dale Mariano > Coordinator (proposed): Dale? > Client: Stef with the idea of distribution, Torsten don't > you want to help here? > > - Coral: > Coordinator (proposed): Damien? > Damien, Luc, Adrien, Stef, > Client: Damien, Olivier? > > So what would be good is to have the identification on the web site of > these groups. > More discussions and concentration with a set of little tasks to be > performed > We could tag the mails with [Task-UI], [Task-OPAL], have a little visible > agenda. > > What do you think? I think that it is important. > > > > Stef > > -- Mariano http://marianopeck.wordpress.com

July 1, 2011

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

by StÃ©phane Ducasse

On Jul 1, 2011, at 10:56 AM, Igor Stasenko wrote: > On 1 July 2011 07:32, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Indeed. Actually the recent JS popular libraries coding style reminds >>> me more and more smalltalk. >>> Looks like they are inventing new wheel, going long road from creepy C >>> syntax and C programming style >>> to smalltalk. >> >> >> The problem igor is that they will get there and fast because the world is faster. >> Microsoft is creating a new lab at Zurich for example. And our nice little community >> did not move since at least one decade. >> Sometimes I'm immensely sad to see for example that while julian is working for cincom >> he does not lead an effort to bring Seaside to the next level. Company vision are puzzling me. >> > > To get to the next level, first you have to define what is next level. > For me , i don't see what is the next level for web application > framework like seaside. Do you? No but I'm not in the field. Stef

July 1, 2011

Re: [Pharo-project] [Pharo-users] **Important Please read** Towards First Class Tasks

by Mariano Martinez Peck

On Fri, Jul 1, 2011 at 10:40 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Dear Pharoers > > I think that we are doing a great work: when I look at the work on the > theme, better widgets, network.....Excellent! and thanks. > Now we were discussing with Doru about how we as community could coordinate > and structure ourselves better to create more energy. > > Analysis of the current situation: > Right now we have individuals doing great projects, sometimes we > have a group of people but this is often not visible. > Now often happens a bit in ad-hoc way. Because someone ask > something, then somebody replies and we integrate the replies. > > What I would like to see emerging are First Class Tasks with > a name > Fuel > a topic > An object graph serializer > a coordinator > Mariano Martinez Peck > a group of interested participants, > Martin Dias > a set of identified clients (because clients are the ones that often > make us deliver more), > - Pharo itself - persistency - SandstoneDB (already done). - Pier kernel persistency (already done). - Moose model import/export (already done). - Newspeak. > a little agenda, > Lot of open issues: http://code.google.com/p/fuel/issues/list > a web presence on the web page > > http://rmod.lille.inria.fr/web/pier/software/Fuel > > If we look at what we have right now that are potential Tasks and really > important clients > > - The Z connection: > Network/Socket > Coordinator (proposed): Sven > Socket: Noury Luc Jannik Olivier > Clients: Seasiders, Clouders, > > - Morphic 2: > UI: Alain Gary Igor > Coordinator (proposed): ? > Presenty framework > VoidNullPointer UIBuilder > Athens > Clients: Moose, Pharo IDE > > - Pharo IDE: > Coordinator (proposed): Doru > work around TWM Laurent > Nautilus: Benjamin Laurent > Glamourous: Doru Damien > > - OPAL: > Compiler tool chain > Coordinator (proposed): Marcus? > Jb, Jorge, Marcus, > Helvetia lukas > Niko Schwarz? > > - Package: > Stef, Cyrille > Coordinator (proposed): Stephane > Client: Nautilus, Doru Moose, > > - Metacello > Dale Mariano > Coordinator (proposed): Dale? > Client: Stef with the idea of distribution, Torsten don't > you want to help here? > > - Coral: > Coordinator (proposed): Damien? > Damien, Luc, Adrien, Stef, > Client: Damien, Olivier? > > So what would be good is to have the identification on the web site of > these groups. > More discussions and concentration with a set of little tasks to be > performed > We could tag the mails with [Task-UI], [Task-OPAL], have a little visible > agenda. > > What do you think? I think that it is important. > > > > Stef > > -- Mariano http://marianopeck.wordpress.com

July 1, 2011