January 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Proposed (or just written down desired) Keyboard Event Model

by Guillermo Polito

On Fri, Jan 27, 2012 at 1:52 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 January 2012 19:07, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > Following the Event chronicles :P > > > > Since I know that some people are working on event Stuff(Stef, Fernando, > > Igor), I'd like to listen to what they(or anybody else :) ) think about > > this. > > I've no code (yet) except for the one I've written to play with the vm > and > > test the keyboard stuff :P. And I know there is some package where Stef > and > > Igor where refactoring the event stuff and I don't want to duplicate > efforts > > either, jeje. > > > see sqs/EventModel > > > So, this is what from other models I think a complete keyboard event > model > > should have: > > > > Keyboard interaction raises 3 events (3 different kind of objects!): > > > > Keydown > > > > When a key is pressed, it informs the pressed key with modifiers (it > should > > not send a unicode value of a character). > > > > Should understand the messages: > > > > "boolean indicating which modifiers where pressed" > > #alt > > #cmd > > #shift > > #ctrl > > #opt? > > > > <RANT> > why we can't just send a key code to image and be done with it? > what if i want , in my image, for some weird reason, to use 'A' key as > a 'modifier'? > why at all, we need to distinguish between normal keys from 'modifier' > keys, when VM and OSes are capable to generate a same events for all > keys user punching? > IMO, those 'modifiers' are serving for nothing, but just unnecessary > increase of complexity in VM , and data structures (events) we > exchanging with VM. > > There are 3 bits for modifiers namely , shift, alt, cmd .. so i cannot > distinguish between left and right shift pressed (cool! awesome! > wonderful!). > Not mentioning that some laptops having a 'fn' modifier key, but who > needs that, right? > </RANT> > Ok, but, what if you have alt+a? You have to send 2 keycodes. And Alt+shift+r 3 keycodes. Or maybe we just send a keydown for each pressed key and handle the combinations inside the image playing with keyups and keydowns... Keydown ctrl -> ctrl pressed keydown shit -> ctrl shift pressed Keydown a -> ctrl shift a pressed keyup ctrl -> shift a pressed Keyup a -> shift pressed keyup shift -> nothing pressed > > "a collection of modifier objects" > > #modifiers > > > > "the key pressed. It is not a Character, it should be an instance of Key > > (read about Keys in the Glitches below)" > > #key > > > > "to know if the event wasHandled" > > #handled: > > #handled > > > > Keypress > > > > When a key with a unicode representation is pressed, informs it. > > > > should understand the messages: > > > > "the unicode character representation of this event. It is a Character, > not > > an instance of Key" > > #character > > > > "to know if the event wasHandled" > > #handled: > > #handled > > > who will handle that? if even not handled, what you do next? what is > purpose of it? > Hmm, actually, I was modeling them as morphic events, and it has a meaning there so the event can bubble until it is handled :) > i mean, at low level (between VM and image) you need only the way to > deliver events. who handling them or what happens later is absolutely > not our concern at this level. > Yeap, SystemEvents and Morphic events should differ I think (one wrapping the other or not...). > > > Keyup > > > > When a key is released, it informs the released key with modifiers (it > > should not send a unicode value of a character). > > > > Should understand the messages: > > > > "the main key pressed. It is not a Character, it should be an instance > of > > Key (read about Keys in the Glitches below)" > > #key > > > > "to know if the event wasHandled" > > #handled: > > #handled > > > ditto > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > Glitches > > > > 1) Today every keyboard event handled on the image side is handled on > > keypress, which: > > - limits the ammount of shortcuts you can have (because there are keys > > that you can't handle) > > - to make it work, there are some hacks (at image and vm side) to allow > > keys with no char representation enter as keypresses (like arrow keys). > > - changing this is ALOT of work :P > > > yeah :) > > > 2) Some key representation varies from platform to platform. i.e.: A > > Shift-only press generates today a keydown event with: > > - a 254 keyCode value in unix > > - a 16 keyCode value in windows > > > IMO, we should deal with this at image side. It is much easier to fix > code in image, than digging into VM every time we need to fix it. > why every time? :/ Ok, if we change the model every 2 months yes, it will be a trouble. But if we don't? How much time has passed since the last time the event stuff was touched? I think it does not happen every day... Wasn't it the vm's job to abstract these differences between platforms? Cheers, Guille

Jan. 27, 2012

Re: [Pharo-project] This is so cool, and we can compute it !

by Nicolas Cellier

It could have been a rounding problem, but it's not , the following digits are 001. The serie is tailored on purpose, to have a short fraction. It is based on 12345679/999999999 -> (1/81) You can also try to evaluate 9801 sqrt in a recent squeak or pharo, then 998001 sqrt. Nicolas 2012/1/27 Chris Cunningham <cunningham.cb(a)gmail.com>: > On Fri, Jan 27, 2012 at 2:08 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>... >> I think I've found a bug. Mine ends with >> >> ... >> >> 990991992993994995996997999000s3000 >> >> You can see after 997 there is 999. :) >> > I suspect it should be ...997998999 and not ...997999000. > The 'issue' is that ScaledDecimal rounds the the number off that is is printing. > You can find this in ScaledDecimal>>printOn: > > -Chris >

Jan. 27, 2012

Re: [Pharo-project] Enthousiasm is the main currency among developers

by Ben Coman

Marcus Denker wrote: > On Jan 27, 2012, at 6:13 AM, dimitris chloupis wrote: > > >> This article is really encapsulates the attitude and what is wrong with programming in general. The attitude of superiority and intelligence that seems to plague coders and being the biggest obstacle to progress. >> > > Yes! The "Everyone is dumb but me" phenomenon... > > What those "intelligent" people don't get is that complexity is inherently exponential. So even if you are > 10 times more intelligent than me (very well possible), it is *completely* irrelevant considering that complexity > grows non-linearly. > > If you combine this with the notion of Evolution: that it is impossible to creat "the perfect" out of nothing, yet > entropy grows when you incrementally improve things... than this has some very serious consequences. > > The philosophy "Given enough eyeballs, all bugs are shallow" [1] appears to have worked well for Linux. I particularly like this... "[the] original formulation was that every problem 'will be transparent to somebody'. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. 'Somebody finds the problem,' he says, 'and somebody /else/ understands it. And I'll go on record as saying that finding it is the bigger challenge.' " The success of Linux is attributed not to Linus' great hacking skills but to his cultivation of his co-developers. [1] http://catb.org/~esr/writings/homesteading/cathedral-bazaar/ar01s04.html >> For me the main problem with is the whole aura of "elitism" , what better example than Lisp, where beginners are attacked and be excluded. >> > > We had the same effect in Squeak at the end. No progress, every improvement was actively fighted against, if needed with the nice argument that > one can do it even better, and only "the best" is worth for Squeak. > > Another thing that "intelligent" people don't get is that critizising is trivial: You can *always* do better, there is no perfection. It's an endless process. > This implies that one has to accept and embrace imperfection if one wants to have a future. Else you end up never finishing anything, the death of any > incremental progress. > > Pharo was started with the explicit goal to do as many mistakes as possible, as fast as possible. > Same link [1] above... " In those early times (around 1991) it wasn't unknown for [Linus] to release a new kernel more than once a /day!/" alternatively at [2] Linus relates how today a more mature Linux manages "low risk" users as well as how features are selected to match the two month release cycle based on "the most important thing about features are simply whether they are ready, and whether they have actual real users. A lot of that is tied to our release process - it's largely based on _timing_ rather than on features. If something is ready to be merged, works, and has real users, it gets merged." [3] [2] http://www.itwire.com/opinion-and-analysis/open-sauce/44975-linus-torvalds-… [3] http://www.itwire.com/opinion-and-analysis/open-sauce/44975-linus-torvalds-… > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > >

Jan. 27, 2012

Re: [Pharo-project] Proposed (or just written down desired) Keyboard Event Model

by Igor Stasenko

On 27 January 2012 14:25, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > On Jan 27, 2012, at 1:39 30PM, Guillermo Polito wrote: > > "Event handling, and the philosopher's keyboard" > > I've downloaded Stef and Igor's EventModel to play with their new event > model :).Â I've created KeydownEvent and KeyupEvent in contrast to the > generic KeyboardEvent with all the information.Â It's very simple code, but, > that is the api I'm talking about. > > Gofer it > Â Â Â Â Â Â squeaksource: 'GuilleUtils'; > Â Â Â Â Â Â package: 'EventModel'; > Â Â Â Â Â Â load > > | ann evt | > ann := SystemInputEventAnnouncer new. > ann subscribe: SystemInputEvent send: #dispatchEvent: to: World activeHand. > > 10 timesRepeat: [ > Â Â Â Â 500 milliSeconds asDelay wait. > Â Â Â Â evt := Sensor nextEvent. > Â Â Â Â evt ifNotNil: [ > Â Â Â Â Â Â Â Â ann handleEvent: evt > Â Â Â Â ]. > ]. > > > My 2c: > > To me, the events just look like thin wrappers around the buffers where you > can get values by nameÂ rather than by indexâ¦ > You need to do the deconstruction of buffers to objects _somewhere_, > personally I that place should be before they are handed to specific > consumers (like Morphic). > I mean, the types are defined by the VM, and not really up for individual > interpretation by different frameworks... Indeed. This is what we done for SystemXYZEvents. There can be various ways how you can represent "events" in your framework, but it doesn't changing the interface between VM and language side, and those thin wrappers serve as a clean and simple layer. Simply because we don't want a smelly code to spread around in image, which deals with bits and bytes generated by VM. > > For SystemKeyboardEvent, that would mean: > > - Create subclasses of SystemKeyboardEvent, one each for > KeyPressed/KeyDown/KeyUp. > - Change SystemInputEvent to do newFromBuffer: instead of new > initFromBuffer: > - Change SystemKeyboardInputEvent to instantiate the correct subclass. > > Same applies for f.ex.Â SystemWindowInputEvent, where a consumer might look > like: > > SystemInputAnnouncer subscribe: WindowMetricChanged do: [:ann| ...], > and not > SystemInputAnnouncerÂ subscribe: SystemInputAnnouncer: SystemWindowInputEvent > do: [ann | ann action = WindowEventMetricChange ifTrue: [â¦]] > > Will there be duplication between Morphic and SystemEvent announcer in > distinction of events? > Yes, until Morphic is rewritten to use the announcements directly, instead > of creating its own representation of the same classes. > But removing that duplication (on the Morphic side of things) is a very > natural next step... > Morphic can wrap system events (so you can always access the original in case if you really want them), or convert them into own. For instance , there is no "double-click" events generated by VM, while morphic having them. There can be other examples, like mouse gestures.. so morphic events are operating at completely different level than basic system events and while for some of them there can be straight correspondence between them, for some of them, obviously not . -- Best regards, Igor Stasenko.

Jan. 27, 2012

Re: [Pharo-project] This is so cool, and we can compute it !

by Chris Cunningham

On Fri, Jan 27, 2012 at 2:08 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >... > I think I've found a bug. Mine ends with > > ... > > 990991992993994995996997999000s3000 > > You can see after 997 there is 999. :) > I suspect it should be ...997998999 and not ...997999000. The 'issue' is that ScaledDecimal rounds the the number off that is is printing. You can find this in ScaledDecimal>>printOn: -Chris

Jan. 27, 2012

Re: [Pharo-project] Proposed (or just written down desired) Keyboard Event Model

by Igor Stasenko

On 26 January 2012 19:07, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Following the Event chronicles :P > > Since I know that some people are working on event Stuff(Stef, Fernando, > Igor), I'd like to listen to what they(or anybody else :) ) think about > this. > I've no code (yet) except for the one I've written to play with the vm and > test the keyboard stuff :P. Â And I know there is some package where Stef and > Igor where refactoring the event stuff and I don't want to duplicate efforts > either, jeje. > see sqs/EventModel > So, this is what from other models I think a complete keyboard event model > should have: > > Keyboard interaction raises 3 events (3 different kind of objects!): > > Keydown > > When a key is pressed, it informs the pressed key with modifiers (it should > not send a unicode value of a character). > > Should understand the messages: > > "boolean indicating which modifiers where pressed" > #alt > #cmd > #shift > #ctrl > #opt? > <RANT> why we can't just send a key code to image and be done with it? what if i want , in my image, for some weird reason, to use 'A' key as a 'modifier'? why at all, we need to distinguish between normal keys from 'modifier' keys, when VM and OSes are capable to generate a same events for all keys user punching? IMO, those 'modifiers' are serving for nothing, but just unnecessary increase of complexity in VM , and data structures (events) we exchanging with VM. There are 3 bits for modifiers namely , shift, alt, cmd .. so i cannot distinguish between left and right shift pressed (cool! awesome! wonderful!). Not mentioning that some laptops having a 'fn' modifier key, but who needs that, right? </RANT> > "a collection of modifier objects" > #modifiers > > "the key pressed. Â It is not a Character, it should be an instance of Key > (read about Keys in the Glitches below)" > #key > > "to know if the event wasHandled" > #handled: > #handled > > Keypress > > When a key with a unicode representation is pressed, informs it. > > should understand the messages: > > "the unicode character representation of this event. Â It is a Character, not > an instance of Key" > #character > > "to know if the event wasHandled" > #handled: > #handled > who will handle that? if even not handled, what you do next? what is purpose of it? i mean, at low level (between VM and image) you need only the way to deliver events. who handling them or what happens later is absolutely not our concern at this level. > Keyup > > When a key is released, it informs the released key with modifiers (it > should not send a unicode value of a character). > > Should understand the messages: > > "the main key pressed. Â It is not a Character, it should be an instance of > Key (read about Keys in the Glitches below)" > #key > > "to know if the event wasHandled" > #handled: > #handled > ditto > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Glitches > > 1) Today every keyboard event handled on the image side is handled on > keypress, which: > Â - limits the ammount of shortcuts you can have (because there are keys > that you can't handle) > Â - to make it work, there are some hacks (at image and vm side) to allow > keys with no char representation enter as keypresses (like arrow keys). > Â - changing this is ALOT of work :P > yeah :) > 2) Some key representation varies from platform to platform. Â i.e.: A > Shift-only press generates today a keydown event with: > Â - a 254 keyCode value in unix > Â - a Â 16 keyCode value in windows > IMO, we should deal with this at image side. It is much easier to fix code in image, than digging into VM every time we need to fix it. > So I think a "table" has to be built and documented for mappings for each > key in a keyboard. Â Examples of this can be found in enums/defs from other > platforms: > > Windows platform: > http://msdn.microsoft.com/en-us/library/windows/desktop/dd375731(v=vs.85).a… > .Net: > http://msdn.microsoft.com/en-us/library/system.windows.forms.keys(v=vs.71).… > X11 (current used window system in unix vm): > http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h > Javascript: > http://www.cambiaresearch.com/articles/15/javascript-char-codes-key-codes > Gtk: > http://www.koders.com/c/fidD9E5E78FD91FE6ABDD6D3F78DA5E4A0FADE79933.aspx > right. > After that, both vm's and image should follow that table :). Â And of course, > these keys should be reified in the image side independently of their > character pairs. > > Guille > -- Best regards, Igor Stasenko.

Jan. 27, 2012

Re: [Pharo-project] Artifacts Mirroring

by Guillermo Polito

+1 On Fri, Jan 27, 2012 at 1:31 PM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > that'll do :) > > > ./googlecode_upload.py --help > Usage: googlecode-upload.py -s SUMMARY -p PROJECT [options] FILE > > Options: > -h, --help show this help message and exit > -s SUMMARY, --summary=SUMMARY > Short description of the file > -p PROJECT, --project=PROJECT > Google Code project name > -u USER, --user=USER Your Google Code username > -w PASSWORD, --password=PASSWORD > Your Google Code password > -l LABELS, --labels=LABELS > An optional lis > > On 2012-01-27, at 17:27, Guillermo Polito wrote: > > > > On Fri, Jan 27, 2012 at 10:11 AM, Camillo Bruni <camillo.bruni(a)inria.fr> > wrote: > > hi everyone, > > > > I thought about mirroring the fresh artifacts from our jenkins server to > the google-code site. > > Like this we would have at least a second place to download fresh builds > even if the jenkins site is down again. > > > > What do you think? > > > > (don't know much about google code api there, so:) > > > > Automatically? :P (because if not, it's a pain in the ass to mantain, > hehe) > > > > Guille > > >

Jan. 27, 2012

Re: [Pharo-project] Artifacts Mirroring

by Camillo Bruni

that'll do :) ./googlecode_upload.py --help Usage: googlecode-upload.py -s SUMMARY -p PROJECT [options] FILE Options: -h, --help show this help message and exit -s SUMMARY, --summary=SUMMARY Short description of the file -p PROJECT, --project=PROJECT Google Code project name -u USER, --user=USER Your Google Code username -w PASSWORD, --password=PASSWORD Your Google Code password -l LABELS, --labels=LABELS An optional lis On 2012-01-27, at 17:27, Guillermo Polito wrote: > > On Fri, Jan 27, 2012 at 10:11 AM, Camillo Bruni <camillo.bruni(a)inria.fr> wrote: > hi everyone, > > I thought about mirroring the fresh artifacts from our jenkins server to the google-code site. > Like this we would have at least a second place to download fresh builds even if the jenkins site is down again. > > What do you think? > > (don't know much about google code api there, so:) > > Automatically? :P (because if not, it's a pain in the ass to mantain, hehe) > > Guille

Jan. 27, 2012

Re: [Pharo-project] Meaning of the name "Pharo"

by Nicolas Cellier

2012/1/27 blake <dsblakewatson(a)gmail.com>: > Careful: We're wandering into Big Talk. :-P > :) > > On Fri, Jan 27, 2012 at 8:09 AM, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> 2012/1/27 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> > >> > On Jan 27, 2012, at 8:17 AM, Max Leske wrote: >> > >> >> I always enjoy it if a product / project with a "funny" name explains >> >> that name somewhere (origin, intention). I think it says a lot about the >> >> kind of project it is (how dedicated are the people? If the name is crap, >> >> the product will probably be tooâ¦). So I thought, it might be cool to >> >> introduce a paragraph (in the "About" section maybe) that explains the >> >> origins of the name "Pharo". >> >> >> >> Any thoughts? >> > >> > Yes! >> > I love lighthouse because >> > Â Â Â Â - it is protecting boats from crashing on the coast >> > Â Â Â Â - stand against the wind and is wild sea >> > Really positive image. >> > >> > Pharo: solid software with a vision, helping large programs to get to >> > the coast nicely. >> > >> >> And even a rock solid Pharo requires maintenance. >> An abandoned Â Pharo would not be of much help, just a seamark, but not >> an active guide, and it will sooner or later be tumbling down. >> That's a good software metaphor, and we shall rejoice of current level >> of activity. >> >> Nicolas >> >> >> >> >> Cheers, >> >> Max >> > >> > >> >

Jan. 27, 2012

Re: [Pharo-project] Artifacts Mirroring

by Guillermo Polito

On Fri, Jan 27, 2012 at 10:11 AM, Camillo Bruni <camillo.bruni(a)inria.fr>wrote: > hi everyone, > > I thought about mirroring the fresh artifacts from our jenkins server to > the google-code site. > Like this we would have at least a second place to download fresh builds > even if the jenkins site is down again. > > What do you think? > (don't know much about google code api there, so:) Automatically? :P (because if not, it's a pain in the ass to mantain, hehe) Guille

Jan. 27, 2012