- Pharo-users - lists.pharo.org

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

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

by Alain Busser

So it was that simple! Thanks alot for these messages, now I will be able to make *new* and *classy* things instantly :-D Alain On Tue, May 14, 2013 at 10:21 PM, Chris <cpmbailey(a)btinternet.com> wrote: > This method is on the instance side of the class and therefore requires > TextEditorDialogWindow new newTextEditorMorph. If it were on the class > side, it would be like you were trying it. > > 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 > > >

May 15, 2013

Re: [Pharo-users] InputEventSensor and polling

by stephane ducasse

Hi eric > Hi all, > I've been working on Phratch, a port of MIT Scratch to Pharo, mostly to learn Smalltalk and also because Scratch is a great learning environment and I can't bear to see it end up in Flash. > > So I've been digging about in the old code to fix bugs and I'm getting a sense that there's some conflict between the way the Scratch team got things working in Squeak, and the way the Pharo team things want things done. > > I must say I think the Pharo team have things right in their drive for a cleaner, simpler system, however that means I'm a bit stuck. > > See the attached image of my Scratch script. > > Here's where I am... > 1. Keyboard events for 'When <key> pressed' HatBlockMorph (with then pen commands) work fine as these follow the regular Morphic event model > 2. But 'if <key> pressed' operation (with the stamp command inside) doesn't work because it relies on polling the InputEventSensor, and I think this bit of this class doesn't work as I expect. > > My view right now is that for 2, I need to use some kind of polling, and InputEventSensor has methods such as keyboardPeek and peekKeyboardEvent that imply you can poll, Why do you need to poll for event? In Pharo 30 we should integrate a fix and normally you can just register to get notified when a new event is happening. May be have a look at the EventModel package http://www.squeaksource.com/EventModel/ I hope it gets the latest version of the code. Fernando used it in gaucho so soon it will be in Pharo3.0 but we should do another serious pass on it. > but looking at the implementation, which uses WaitfreeQueue I can see that calling these methods results in events being consumed, hence my post to Stack Overflow... > http://stackoverflow.com/questions/16395418/cant-peek-keyboard-events-multi… > > I've hacked around to come up with something that sort of works, outlined in this post: > http://stackoverflow.com/questions/16495436/saving-modifications-to-existin… > ...but I get the feeling I'm doing the wrong thing here, and that I should come up with a solution that better fits the 'Pharo way'. > > So, let me know what you think. I'm happy to provide more info and to research better solutions, let me know... > > Finally, apologies for the long post! > > Best regards, > -Eric. > > -- > Eric Clack > ericclack(a)googlemail.com > East Sussex, England. > <keypress.gif>

May 15, 2013