- Pharo-dev - lists.pharo.org

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

by Norbert Hartl

Am 01.07.2011 um 13:10 schrieb 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. You don't need to write everything asynchron. In javascript you would to because there is no blocking at all (only in node on system level). In Smalltalk you can just block a call while you are waiting for a callback to fire and you break the chain. So asnych stuff here is not that viral. But you don't have the opportunities like you have in javascript. In javascript you don't have most concurrency problems because it is just a single thread that can only execute one single whole function at a time. That is different in smalltalk thus making the whole async stuff less admirable. Norbert

July 1, 2011

[Pharo-project] Cog VM continuous integration: update

by Igor Stasenko

Hello, all. Last few weeks i concentrated my efforts to make Windows slave working and merge the updates made by Eliot and synchronize source with svn. It took quite a bit time to set up windows slaves (multiple people were involved). I don't want to go into details, but there was some technical issues, as well as complications with connecting windows with non-windows, firewalls etc etc. At least now it is working and we can build windows VMs. A merge also costed me quite of a time, since Andreas reorganized sources and merged cross and win32 plugin codebase with squeak branch using of svn:externals. And while i, no doubt, welcome the merge, i had to spend time learning how i could mirror that on git. The only thing which i can say after this: git is superior tool. Its a pity that i had to waste my time fighting with svn, while its only a question of couple of minutes for developer(s) to clone sources from git and start using it instead of svn. So, after couple of hiccups and show-stoppers now everything more-or less run smoothly on Hudson, (except from stack vm on win32). Here the list of builds which currently available for download. Mac: Cog/Mac Carbon https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Mac%20Carbon/ Stack VM/ Mac Carbon https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/StackVM%20Mac%20Carbon/ Linux: Cog https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Cog%20Unix/ Stack VM/ Unix https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/ A new kid on the block Windows: Cog/Win32 https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/CogWin32/ (the Stack VM has linking problems which is yet to be solved, see my post on vm-dev list) To download VM just follow one of the links and then pick the .zip with VM. As for Mac Cocoa VMs: they are broken for now, because yet unmerged. Hopefully Esteban will find time to update his branch soon. The next step is to run tests for built VMs. For this i planning to create a specialized package, which will contain code snippets for loading & firing off various tests, because currently all tests are a bunch of .st scripts, and managing files over dozen of networked machines is not fun. So, i think i will just take these snippets and put them into single MC package, so then it could be managed much easier. -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

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

by StÃ©phane Ducasse

Mariano could you add a page will all the information on the wiki? Stef > 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

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

by StÃ©phane Ducasse

> > > I think we should try this. IMO a task around SUnit & friends is missing. sign in for it and lead it. What I would like is a small agenda so that other people can see what is happening and if they want to help join. > > Laurent.

July 1, 2011

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

by Sven Van Caekenberghe

On 01 Jul 2011, at 12:53, Janko MivÅ¡ek wrote: > 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. If you compare all the Zn delegates that are included, such as Nick's ZnDispatcherDelegate, I think it is clear that #handleRequest: is a good interface. Different use cases require delegate's with more or less features and thus complexity. But for the sake of short/elegant examples, I added the ZnSingleThreadedServer>>#onRequestRespond: convenience method, so the examples now become: (ZnServer startDefaultOn: 1337) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity text: 'Hello World!') ]. and (ZnServer startDefaultOn: 1337) onRequestRespond: [ :request | ZnResponse ok: (ZnEntity with: request contents) ]. Sven

July 1, 2011

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

by Sven Van Caekenberghe

On 01 Jul 2011, at 09:10, Torsten Bergmann wrote: > It would also nice if ScriptManager would support autocompletion +1

July 1, 2011

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