- Pharo-dev - lists.pharo.org

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

by Igor Stasenko

On 1 July 2011 16:55, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 01 Jul 2011, at 15:52, Janko MivÅ¡ek wrote: > >> I'd just introduce yet that ZnResponse ok: 'Hello world'. To cover the >> most common response body and this will be really easy to grasp for >> newcomers. Nothing specially to learn upfront, just that simple two >> lines with seamless way to respond with some text. >> >> This complicate a bit Zinc internals, but the gain on simplicity on API >> level is IMHO worth that. > > I saw your code, and I considered it, but it feels too much out of place (the implementation that is), architecturally wrong and not that usefull. Although ZnResponse ok: (ZnEntity text: 'Hello World!') is longer it is also more intention revealing, it tells you something about HTTP without being too verbose. > > These are opinions and aesthetics, of course. > IMO. API should be focused on most often use cases. Not on useless cases , like showing 'hello world'. Because going that road, you will just ruin the beautiful design of what you really need in favor of supporting useless things. > Sven -- 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 15:52, Janko MivÅ¡ek wrote: > I'd just introduce yet that ZnResponse ok: 'Hello world'. To cover the > most common response body and this will be really easy to grasp for > newcomers. Nothing specially to learn upfront, just that simple two > lines with seamless way to respond with some text. > > This complicate a bit Zinc internals, but the gain on simplicity on API > level is IMHO worth that. I saw your code, and I considered it, but it feels too much out of place (the implementation that is), architecturally wrong and not that usefull. Although ZnResponse ok: (ZnEntity text: 'Hello World!') is longer it is also more intention revealing, it tells you something about HTTP without being too verbose. These are opinions and aesthetics, of course. Sven

July 1, 2011

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

by Julian Fitzell

2011/7/1 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > 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? No. That's the point of one particular feature of Seaside. > This code is > blocking until the call: returns, isn't that so? > Yes, you are correct. > 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. " > Of course. #call: both creates a continuation and interrupts the action phase of request handling (beginning response generation immediately). What I said was if you don't want to "block", you can use #show:onAnswer: instead. That method will delegate to the desired component and specify a block of code to call whenever that component answers. Then it will return and your code will keep running. Julian

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Igor Stasenko

On 1 July 2011 15:56, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Jul 1, 2011, at 2:55 PM, Igor Stasenko wrote: >> >> So, after couple of hiccups and show-stoppers now everything more-or >> less run smoothly on Hudson, (except from stack vm on win32). >> > Very nice!!! > > What this VM has (as it merges all changes of Igor) is support for Ephemerons. > > The ephemerons-imageside.3.cs from http://code.google.com/p/cog/issues/detail?id=44 > has the image side. > Yes, and it contains a long awaited fix for problems with large images on windows. So i'd like to hear from Tudor if it works for him. http://code.google.com/p/cog/issues/detail?id=46 -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

Re: [Pharo-project] Cog VM continuous integration: update

by Marcus Denker

On Jul 1, 2011, at 2:55 PM, Igor Stasenko wrote: > > So, after couple of hiccups and show-stoppers now everything more-or > less run smoothly on Hudson, (except from stack vm on win32). > Very nice!!! What this VM has (as it merges all changes of Igor) is support for Ephemerons. The ephemerons-imageside.3.cs from http://code.google.com/p/cog/issues/detail?id=44 has the image side. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 1, 2011

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

by Janko MivÅ¡ek

S, Sven Van Caekenberghe piÅ¡e: > 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) ]. I'd just introduce yet that ZnResponse ok: 'Hello world'. To cover the most common response body and this will be really easy to grasp for newcomers. Nothing specially to learn upfront, just that simple two lines with seamless way to respond with some text. This complicate a bit Zinc internals, but the gain on simplicity on API level is IMHO worth that. Janko

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 01:38 PM, Janko MivÅ¡ek wrote: >>>> 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. It terminates from internal framework point of view. But from application programmer point of view it blocks. If I put Transcript messages in your example: first := self askForFirstObject. Transcript show: 'first answered' second := self askForSecondObject. Transcript show: 'second answered' How will messages show up, immediately or waiting for answers first? Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

July 1, 2011

Re: [Pharo-project] Copying text in Pharo 1.3

by Alexandre Bergel

The last 1.3. Try with several selection, it does not always happen Alexandre On 1 Jul 2011, at 15:29, Igor Stasenko wrote: > On 1 July 2011 15:18, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Cmd-c moves the text selection. >> Terrible... > > huh? > > Nothing is moving in my image when i pressing Cmd-c :) > > Are we living on different planets? (what exactly image you talking about?) :) > >> >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > > -- > Best regards, > Igor Stasenko AKA sig. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 1, 2011

Re: [Pharo-project] Copying text in Pharo 1.3

by Igor Stasenko

On 1 July 2011 15:18, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Cmd-c moves the text selection. > Terrible... huh? Nothing is moving in my image when i pressing Cmd-c :) Are we living on different planets? (what exactly image you talking about?) :) > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > -- Best regards, Igor Stasenko AKA sig.

July 1, 2011

[Pharo-project] Copying text in Pharo 1.3

by Alexandre Bergel

Cmd-c moves the text selection. Terrible... Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 1, 2011