May 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [ANN] ZnReadEvalPrintDelegate

by Camillo Bruni

cool :) On 2013-05-16, at 14:36, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > Here is a little tool that might be useful to some you. For others it might be a nice example. > > So you have your shiny Pharo server application running in the cloud. When something goes wrong, most of the time you will just restart, manually or automatically. But sometimes you wish you could interact with a running headless server image. Problem is, you can't out of the box. > > ZnReadEvalPrintDelegate is a simple tool that exports a REPL Web Service. Much like the emergency evaluator. Primitive but better than nothing. Install it on a port of your choice, running in a independent Zn HTTP server, bound to localhost only. > > ZnReadEvalPrintDelegate startInServerOn: 1701. > > There is only one API method: POST a plain/text Smalltalk expression to evaluate, get the result back. > > ZnClient new > url: 'http://localhost:1701/repl'; > contents: '42 factorial'; > post. > > Here is an example terminal session (logged in to the server, not remote): > > A GET on the service /repl gives some help text > > $ curl http://localhost:1701/repl > # Pharo Smalltalk REPL. POST expressions to evaluate > # Here is one way (type ctrl-d to end input) > curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl > > A POST with -d is good for short expressions > > $ curl -X POST -H'Content-Type:text/plain' -d '42 factorial' http://localhost:1701/repl > 1405006117752879898543142606244511569936384000000000 > > For longer or multi line expressions you can read input from stdin and end with ctrl-d (copy the expression returned by the GET). Or you could send text files. > > $ curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl > { (1 to: 10) sum. (1 to: 10) average } > {55. (11/2)} > > There is error handling as well: > > $ curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl > 1 plus: 2 > MessageNotUnderstood: SmallInteger>>plus: > SmallInteger(Object)>>doesNotUnderstand: #plus: > Receiver: 1 > Arguments and temporary variables: > aMessage: plus: 2 > exception: MessageNotUnderstood: SmallInteger>>plus: > resumeValue: nil > Receiver's instance variables: > 1 > UndefinedObject>>DoIt > Compiler>>evaluate:in:to:notifying:ifFail:logged: > Compiler>>evaluate:in:to:notifying:ifFail: > Compiler>>evaluate:in:to: > ZnReadEvalPrintDelegate>>evaluate: in Block: [| result |... > BlockClosure>>on:do: > ZnReadEvalPrintDelegate>>evaluate: in Block: [:out | [| result |... > String class(SequenceableCollection class)>>new:streamContents: > > WARNING: never open this service beyond your local network ! This service gives you absolute control over and access to everything in your image. For example, the following will kill your image: > > $ curl -X POST -H'Content-Type:text/plain' -d 'Smalltalk quitPrimitive' http://localhost:1701/repl > > All this in one class and a handful of methods. > > Enjoy, > > Sven > > PS1: Part of Zinc HTTP Components, in the bleedingEdge version. > > PS2: Of course, basic authentication or HTTPS can be added through simple Zn configuration. > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

May 16, 2013

[ANN] ZnReadEvalPrintDelegate

by Sven Van Caekenberghe

Hi, Here is a little tool that might be useful to some you. For others it might be a nice example. So you have your shiny Pharo server application running in the cloud. When something goes wrong, most of the time you will just restart, manually or automatically. But sometimes you wish you could interact with a running headless server image. Problem is, you can't out of the box. ZnReadEvalPrintDelegate is a simple tool that exports a REPL Web Service. Much like the emergency evaluator. Primitive but better than nothing. Install it on a port of your choice, running in a independent Zn HTTP server, bound to localhost only. ZnReadEvalPrintDelegate startInServerOn: 1701. There is only one API method: POST a plain/text Smalltalk expression to evaluate, get the result back. ZnClient new url: 'http://localhost:1701/repl'; contents: '42 factorial'; post. Here is an example terminal session (logged in to the server, not remote): A GET on the service /repl gives some help text $ curl http://localhost:1701/repl # Pharo Smalltalk REPL. POST expressions to evaluate # Here is one way (type ctrl-d to end input) curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl A POST with -d is good for short expressions $ curl -X POST -H'Content-Type:text/plain' -d '42 factorial' http://localhost:1701/repl 1405006117752879898543142606244511569936384000000000 For longer or multi line expressions you can read input from stdin and end with ctrl-d (copy the expression returned by the GET). Or you could send text files. $ curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl { (1 to: 10) sum. (1 to: 10) average } {55. (11/2)} There is error handling as well: $ curl -X POST -H'Content-Type:text/plain' --data-binary @- http://localhost:1701/repl 1 plus: 2 MessageNotUnderstood: SmallInteger>>plus: SmallInteger(Object)>>doesNotUnderstand: #plus: Receiver: 1 Arguments and temporary variables: aMessage: plus: 2 exception: MessageNotUnderstood: SmallInteger>>plus: resumeValue: nil Receiver's instance variables: 1 UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler>>evaluate:in:to:notifying:ifFail: Compiler>>evaluate:in:to: ZnReadEvalPrintDelegate>>evaluate: in Block: [| result |... BlockClosure>>on:do: ZnReadEvalPrintDelegate>>evaluate: in Block: [:out | [| result |... String class(SequenceableCollection class)>>new:streamContents: WARNING: never open this service beyond your local network ! This service gives you absolute control over and access to everything in your image. For example, the following will kill your image: $ curl -X POST -H'Content-Type:text/plain' -d 'Smalltalk quitPrimitive' http://localhost:1701/repl All this in one class and a handful of methods. Enjoy, Sven PS1: Part of Zinc HTTP Components, in the bleedingEdge version. PS2: Of course, basic authentication or HTTPS can be added through simple Zn configuration. -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 16, 2013

Re: [Pharo-users] About the Mailinglist debacle...

by Robert Shiplett

Sorry to hear of this grief ! No ETA does mean that someone has to make a decision, regardless of what hindsight may or may not eventually show. Thanks for tackling this ... I rely on reading this mail list to feel "in the loop" with Pharo ... and I refrain from filtering it ! On 15 May 2013 14:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hello, > > So now that everything is workingâ¦ sorry for the mess. > > We should have left the gforge infrastructure the last time we had a > multi-day problem, > not wait till we get it again. > > I think this will be my new principle: second real problem -> I leave. No > discussions. > We already saw with the jenkins story just how deadly bad infrastructure > is. > > So what happened was that last Tuesday, the lists (all lists of gforge) > stopped delivering. > Why is not clear, seemingly it was not gforge itself but the upstream > servers did > not deliver. Whatever. > What is clear is that it was completely unclear how long this would take, > and that we > needed a solution after nearly a week of waiting. > > So we decided to move the lists. Of course with the old lists down, this > was harder than > normal (even involved parsing the html to get the subscribersâ¦) but that > is not important. > > Now the problem its hat Mailman does not distinguish between people that > unsubscribe, > and those turning off delivery. So there where just a lot of people listed > with "nomail (U)", > > What to do? It was clear that we can't just subscribe lots of people to a > list that they *actively* > unsubscribed. So the only option was to skip those by > -> unsubscribing them from the old list > -> then get the list of subscribers > -> put that in the new list. > > The only people that will see a bad effect are those using e.g nabble to > read the list. But those > would see the new mails, too. The only problem they have is if the want to > send. So not *that* of > a big deal. > > It seems that we got quite some false positive subscribers anyway in the > form of people who filtered > the mails and then with the new list the filter did not work and they > suddenly saw mails of a long forgotten > list. We even had the case of people who where "nomail (U)", yet they did > get mails delivered. How > that can possibly work, I have no clue *at all*. > > What else is missing (and on my TODO since Sunday/Monday, sorry for not > yet acting on it): > > -> lists.pharo.org has an empty page and needs to point to the > list of the lists inttead > -> the archive needs to be moved from the old jenkins. > -> the (incomplete) archive of the new lists is not working since > I put it as public. > > Soâ¦ maybe it would have been better to just wait until gforge works again > and then moveâ¦ but > it was just far too long already and not clear when it would be working > again. > > Marcus >

May 16, 2013

Re: [Pharo-users] InputEventSensor and polling

by Henrik Johansen

On May 15, 2013, at 10:34 PM, Eric Clack wrote: > Hi Stephane and Jannik, > Well I don't hate the code (yet ;-) So perhaps I'll have a play with it a bit more and see if I can get something that works well, and fits with plans for Pharo3.0. > > Cheers, > -Eric. Would it be possible to translate it to something like alias spaceHandler When space pressed [ set t1 true] When flag clicked [ set t1 false install spaceHandler Loop forever [ move 5 steps turn 5 degrees if t1 [ Stamp the sprite on the screen set t1 false ] ] uninstall spaceHandler ] In general, it should be possible to rewrite polling code to event-driven with some use of temporaries. Cheers, Henry

May 16, 2013

Re: [Pharo-users] InputEventSensor and polling

by Eric Clack

Hi Stephane and Jannik, Well I don't hate the code (yet ;-) So perhaps I'll have a play with it a bit more and see if I can get something that works well, and fits with plans for Pharo3.0. Cheers, -Eric. On 15 May 2013 21:16, jannik.laval <jannik.laval(a)gmail.com> wrote: > Thank you Stef. > > What I understand is that we should make Phratch works, modifying > InputEventSensor. > Then we will modify Phratch when Pharo3.0 will be enough stable to port it. > > Cheers, > Jannik > > On May 15, 2013, at 9:15 PM, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: > > > > I hate this code :) > I remember that in the EventModel we had to store the previous event > somehow but this was one year ago. > I should go back to the code one of these days. > So for now I say make Phrath working we will check the kernel later. > > Stef > > But as far as I can see, that "if key <space> pressed?" cannot be event > driven, because we don't want to start execution at that block if the space > key is pressed, rather we want that to evaluate to true if the space key > has been pressed recently ("recently" seems a problematic term to use here > but that's another issue!). > > Here's the code I started throwing together to make this work -- see the > bit following this line: > type = EventTypeKeyboard > > * InputEventSensor>>processEvent: evt * > "Process a single event. This method is run at high priority. > The event record is: > <type><timestamp><character code><updown><modifier keys>... > where updown is: > 0 - keystroke > 1 - key down > 2 - key up > NOTE: You must ensure that there is an instance variable keyPressed." > | type updown | > type := evt at: 1. > > "Treat menu events first" > type = EventTypeMenu > ifTrue: [ > self processMenuEvent: evt. > ^nil]. > > "Tackle mouse events first" > type = EventTypeMouse > ifTrue: [ > "Transmogrify the button state according to the platform's button map > definition" > evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1). > "Map the mouse buttons depending on modifiers" > evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)). > > "Update state for polling calls" > mousePosition := (evt at: 3) @ (evt at: 4). > modifiers := evt at: 6. > mouseButtons := evt at: 5. > > ^evt]. > "Finally keyboard" > type = EventTypeKeyboard > ifTrue: [ > "Update state for polling calls" > modifiers := evt at: 5. > updown := evt at: 4. > * (updown = 2) ifTrue: [ * > * keyPressed := nil* > * ] ifFalse: [ * > * keyPressed := evt at: 3 ].* > ^evt]. > "Handle all events other than Keyborad or Mouse." > ^evt. > Then I use this: > > *InputEventSensor>>keyPressed: asciiValue* > "Is this key being pressed?" > self nextEvent. > ^keyPressed = asciiValue > > So should I be doing this? Should I test out these changes and suggest a > patch to Pharo? I'm happy that the answer might be "no", but what can I try > instead? > > Thanks for your help. > -Eric. > > > -- > Eric Clack > ericclack(a)googlemail.com > East Sussex, England. > > > > -- Eric Clack ericclack(a)googlemail.com East Sussex, England.

May 15, 2013

Re: [Pharo-users] InputEventSensor and polling

by jannik.laval

Thank you Stef. What I understand is that we should make Phratch works, modifying InputEventSensor. Then we will modify Phratch when Pharo3.0 will be enough stable to port it. Cheers, Jannik On May 15, 2013, at 9:15 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > > > I hate this code :) > I remember that in the EventModel we had to store the previous event somehow but this was one year ago. > I should go back to the code one of these days. > So for now I say make Phrath working we will check the kernel later. > > Stef > >> But as far as I can see, that "if key <space> pressed?" cannot be event driven, because we don't want to start execution at that block if the space key is pressed, rather we want that to evaluate to true if the space key has been pressed recently ("recently" seems a problematic term to use here but that's another issue!). >> >> Here's the code I started throwing together to make this work -- see the bit following this line: >> type = EventTypeKeyboard >> >> InputEventSensor>>processEvent: evt >> "Process a single event. This method is run at high priority. >> >> The event record is: >> <type><timestamp><character code><updown><modifier keys>... >> where updown is: >> 0 - keystroke >> 1 - key down >> 2 - key up >> >> NOTE: You must ensure that there is an instance variable keyPressed." >> >> | type updown | >> >> type := evt at: 1. >> >> "Treat menu events first" >> type = EventTypeMenu >> ifTrue: [ >> self processMenuEvent: evt. >> ^nil]. >> >> "Tackle mouse events first" >> type = EventTypeMouse >> ifTrue: [ >> "Transmogrify the button state according to the platform's button map definition" >> evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1). >> "Map the mouse buttons depending on modifiers" >> evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)). >> >> "Update state for polling calls" >> mousePosition := (evt at: 3) @ (evt at: 4). >> modifiers := evt at: 6. >> mouseButtons := evt at: 5. >> >> ^evt]. >> >> >> "Finally keyboard" >> type = EventTypeKeyboard >> ifTrue: [ >> "Update state for polling calls" >> modifiers := evt at: 5. >> updown := evt at: 4. >> (updown = 2) ifTrue: [ >> keyPressed := nil >> ] ifFalse: [ >> keyPressed := evt at: 3 ]. >> ^evt]. >> >> "Handle all events other than Keyborad or Mouse." >> ^evt. >> >> Then I use this: >> >> InputEventSensor>>keyPressed: asciiValue >> "Is this key being pressed?" >> self nextEvent. >> ^keyPressed = asciiValue >> >> So should I be doing this? Should I test out these changes and suggest a patch to Pharo? I'm happy that the answer might be "no", but what can I try instead? >> >> Thanks for your help. >> -Eric. >> >> >> -- >> Eric Clack >> ericclack(a)googlemail.com >> East Sussex, England. >

May 15, 2013

Re: [Pharo-users] InputEventSensor and polling

by stephane ducasse

I hate this code :) I remember that in the EventModel we had to store the previous event somehow but this was one year ago. I should go back to the code one of these days. So for now I say make Phrath working we will check the kernel later. Stef > But as far as I can see, that "if key <space> pressed?" cannot be event driven, because we don't want to start execution at that block if the space key is pressed, rather we want that to evaluate to true if the space key has been pressed recently ("recently" seems a problematic term to use here but that's another issue!). > > Here's the code I started throwing together to make this work -- see the bit following this line: > type = EventTypeKeyboard > > InputEventSensor>>processEvent: evt > "Process a single event. This method is run at high priority. > > The event record is: > <type><timestamp><character code><updown><modifier keys>... > where updown is: > 0 - keystroke > 1 - key down > 2 - key up > > NOTE: You must ensure that there is an instance variable keyPressed." > > | type updown | > > type := evt at: 1. > > "Treat menu events first" > type = EventTypeMenu > ifTrue: [ > self processMenuEvent: evt. > ^nil]. > > "Tackle mouse events first" > type = EventTypeMouse > ifTrue: [ > "Transmogrify the button state according to the platform's button map definition" > evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1). > "Map the mouse buttons depending on modifiers" > evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)). > > "Update state for polling calls" > mousePosition := (evt at: 3) @ (evt at: 4). > modifiers := evt at: 6. > mouseButtons := evt at: 5. > > ^evt]. > > > "Finally keyboard" > type = EventTypeKeyboard > ifTrue: [ > "Update state for polling calls" > modifiers := evt at: 5. > updown := evt at: 4. > (updown = 2) ifTrue: [ > keyPressed := nil > ] ifFalse: [ > keyPressed := evt at: 3 ]. > ^evt]. > > "Handle all events other than Keyborad or Mouse." > ^evt. > > Then I use this: > > InputEventSensor>>keyPressed: asciiValue > "Is this key being pressed?" > self nextEvent. > ^keyPressed = asciiValue > > So should I be doing this? Should I test out these changes and suggest a patch to Pharo? I'm happy that the answer might be "no", but what can I try instead? > > Thanks for your help. > -Eric. > > > -- > Eric Clack > ericclack(a)googlemail.com > East Sussex, England.

May 15, 2013

Re: [Pharo-users] InputEventSensor and polling

by Eric Clack

Hi Stephane, On 15 May 2013 18:35, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi eric > Why do you need to poll for event? > I'd rather not poll as it seems inefficient, but the logic and ordering of the Scratch commands seems to dictate that it is necessary. Here's my example pseudo code from that picture of the Scratch script in my original email... When flag clicked [ Loop forever [ move 5 steps turn 5 degrees if key <space> pressed? [ Stamp the sprite on the screen ] ] ] So "When flag clicked" is clearly event driven, and that's fine, that's how it works already. But as far as I can see, that "if key <space> pressed?" cannot be event driven, because we don't want to start execution at that block if the space key is pressed, rather we want that to evaluate to true if the space key has been pressed recently ("recently" seems a problematic term to use here but that's another issue!). Here's the code I started throwing together to make this work -- see the bit following this line: type = EventTypeKeyboard * InputEventSensor>>processEvent: evt * "Process a single event. This method is run at high priority. The event record is: <type><timestamp><character code><updown><modifier keys>... where updown is: 0 - keystroke 1 - key down 2 - key up NOTE: You must ensure that there is an instance variable keyPressed." | type updown | type := evt at: 1. "Treat menu events first" type = EventTypeMenu ifTrue: [ self processMenuEvent: evt. ^nil]. "Tackle mouse events first" type = EventTypeMouse ifTrue: [ "Transmogrify the button state according to the platform's button map definition" evt at: 5 put: (ButtonDecodeTable at: (evt at: 5) + 1). "Map the mouse buttons depending on modifiers" evt at: 5 put: (self mapButtons: (evt at: 5) modifiers: (evt at: 6)). "Update state for polling calls" mousePosition := (evt at: 3) @ (evt at: 4). modifiers := evt at: 6. mouseButtons := evt at: 5. ^evt]. "Finally keyboard" type = EventTypeKeyboard ifTrue: [ "Update state for polling calls" modifiers := evt at: 5. updown := evt at: 4. * (updown = 2) ifTrue: [ * * keyPressed := nil* * ] ifFalse: [ * * keyPressed := evt at: 3 ].* ^evt]. "Handle all events other than Keyborad or Mouse." ^evt. Then I use this: *InputEventSensor>>keyPressed: asciiValue* "Is this key being pressed?" self nextEvent. ^keyPressed = asciiValue So should I be doing this? Should I test out these changes and suggest a patch to Pharo? I'm happy that the answer might be "no", but what can I try instead? Thanks for your help. -Eric. -- Eric Clack ericclack(a)googlemail.com East Sussex, England.

May 15, 2013

About the Mailinglist debacle...

by Marcus Denker

Hello, So now that everything is workingâ¦ sorry for the mess. We should have left the gforge infrastructure the last time we had a multi-day problem, not wait till we get it again. I think this will be my new principle: second real problem -> I leave. No discussions. We already saw with the jenkins story just how deadly bad infrastructure is. So what happened was that last Tuesday, the lists (all lists of gforge) stopped delivering. Why is not clear, seemingly it was not gforge itself but the upstream servers did not deliver. Whatever. What is clear is that it was completely unclear how long this would take, and that we needed a solution after nearly a week of waiting. So we decided to move the lists. Of course with the old lists down, this was harder than normal (even involved parsing the html to get the subscribersâ¦) but that is not important. Now the problem its hat Mailman does not distinguish between people that unsubscribe, and those turning off delivery. So there where just a lot of people listed with "nomail (U)", What to do? It was clear that we can't just subscribe lots of people to a list that they *actively* unsubscribed. So the only option was to skip those by -> unsubscribing them from the old list -> then get the list of subscribers -> put that in the new list. The only people that will see a bad effect are those using e.g nabble to read the list. But those would see the new mails, too. The only problem they have is if the want to send. So not *that* of a big deal. It seems that we got quite some false positive subscribers anyway in the form of people who filtered the mails and then with the new list the filter did not work and they suddenly saw mails of a long forgotten list. We even had the case of people who where "nomail (U)", yet they did get mails delivered. How that can possibly work, I have no clue *at all*. What else is missing (and on my TODO since Sunday/Monday, sorry for not yet acting on it): -> lists.pharo.org has an empty page and needs to point to the list of the lists inttead -> the archive needs to be moved from the old jenkins. -> the (incomplete) archive of the new lists is not working since I put it as public. Soâ¦ maybe it would have been better to just wait until gforge works again and then moveâ¦ but it was just far too long already and not clear when it would be working again. Marcus

May 15, 2013

Re: [Pharo-users] a 'doesNotUnderstand' message that I do not understand...

by Mariano Martinez Peck

If you does not understand a #doesNotUnderstand: it seem you are going META to me hehehe. On Tue, May 14, 2013 at 3:10 PM, Alain Busser <alain.busser(a)gmail.com>wrote: > Hi all, > > Exploring the system browser (Pharo 2.0), I see that there exists a class > called TextEditorDialogWindow; as this name sounds interesting to me, I > want to test one, and I see that there is only one method in the category > 'create': this method is called newTextEditorMorph. So, I send the > message newTextEditorMorph to the class TextEditorDialogWindow, daring a: > > TextEditorDialogWindow newTextEditorMorph > > At the 'Do It', I get this error message: 'TextEditorDialogWindow > class(Object) doesNotUnderstand: #newTextEditorMorph' > > That's what I don't understand: If the class has a method called this way, > why does it not understand the corresponding message? What did I miss? > > Alain > -- Mariano http://marianopeck.wordpress.com

May 15, 2013