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

[Pharo-project] Proposed (or just written down desired) Keyboard Event Model
by Guillermo Polito Jan. 27, 2012

Jan. 27, 2012

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. 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? "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 - 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 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= *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 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 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 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

4 7

[Pharo-project] This is so cool, and we can compute it !
by Sven Van Caekenberghe Jan. 27, 2012

Jan. 27, 2012

This is so cool, and we can compute it using Pharo Smalltalk. Try inspecting or printing the result of these expressions: 1/9801 asScaledDecimal: 200 1/998001 asScaledDecimal: 3000 And have a good look at the regularity in the digits of the fraction. Amazing ! Sven

5 8

[Pharo-project] Pharo sprint in Brussels on Feb 4th
by Andy Kellens Jan. 27, 2012

Jan. 27, 2012

Dear Pharoers, In an earlier mail Stephan Eggermont already mentioned that there will be Pharo sprint collocated with the FOSDEM conference next week. This sprint will take place on Saturday February 4th from 10h until 18h in the rooms of the Software Languages Lab of the Vrije Universiteit Brussel. More precisely: Room 10F720 (10th floor of building F) Vrije Universiteit Brussel Pleinlaan 2 1050 Brussels Due to renovations to our building, you will have to enter via the entrance between buildings F and G. As the university is normally closed on a Saturday, you might have to pass via security in order to be allowed entrance to the building (they have been notified about the sprint). If you are coming by car, please send me your license plate so that I can make sure that you are allowed to enter the campus. To get some idea of how many people to expect, could you please let us know if you are planning to attend. Kind regards, Andy

2 1

[Pharo-project] Enthousiasm is the main currency among developers
by Sven Van Caekenberghe Jan. 27, 2012

Jan. 27, 2012

The following 10 year old Usenet article is quite interesting: http://groups.google.com/group/comp.lang.lisp/msg/4563e504dba92253 Although it is quite long and partly about Common Lisp, its main point is that enthousiasm and positive energy are the main/natural currency among developers. I think that this is also the main driving force behind Pharo. The author is Erik Naggum (http://en.wikipedia.org/wiki/Erik_Naggum) a programmer and (in)famous, provocative participant to many discussions. He died a couple of years ago. Sven

4 5

Re: [Pharo-project] Enthousiasm is the main currency among developers
by Fernando Olivero Jan. 27, 2012

Jan. 27, 2012

Gerald Weinberg accurately describes us in this book titled: The Psychology Of Computer Programming, published in 1971. He talked about Ego-less programming[2], which nowadays empowers open source projects. [1] http://www.amazon.com/Psychology-Computer-Programming-Silver-Anniversary/dp… [2] http://c2.com/cgi/wiki?EgolessProgramming On Fri, Jan 27, 2012 at 10:12 AM, dimitris chloupis <thekilon(a)yahoo.co.uk> 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. And what biggest proof of lack of progress than the fact that Lips is probably the very best that programming languages have to offer. 40 year old technology, how sad that is ? Actually if there is one thing thats driving the coding community is lack of enthusiasm, is about sticking to what is already there , is the fact of being "practical" and "realistic" about code in general. How much progress we have seen the last 40 years ? Sure its alot , but what happens if you take games out of it , how much hardware would have progress ? How much software ? Very little. > > If you take out games that exercise a clear push to graphics and processing power and complex data manipulation approaches , AI and many other things , the rest of software out there , if you remove some exceptions here and there, is the same boring stuff which makes you wait for a year to add a single feature you need with a dozen more you don't need. > > Its not enthusiasm that drives coding, its money and profit. > > Then we arrive at the open source phenomenon, which I agree its great and amazing and where exciting stuff really happens. But even open has some major issue to resolve. First is to anyone surprise is that all that open source is rarely used and recycled, most open source projects seem to start from scratch , rarely using source from other projects. And then of course there is the big issue of licence , its open source, but its not really open ... GPL as an example of Â a licence driving open source back instead of forward. > > For me the main problem with is the whole aura of Â "elitism" , what better example than Lisp, where beginners are attacked and be excluded. It took me 4 years to really get into Lisp after hearing about because of all the bad attitude. Its the whole motivation to prove that coding is for "smart people" and not "normal" people as he mentions in his article. There is something "mysteriously" superior about coders .... The only thing I find "mysterious" about coders is that they think they are "superior" or somewhat special. They are not. > > And if we can really kick all that non sense outside coding, if we can make coding for "stupid" , "normal" people and open source project non "VIP Clubs" , if we really make coding inviting for people then maybe just maybe we will see open source that instead of 10 developers and 1 million user will have 1 million developer that are also users. > > Of course in the end what is wrong with the coding community is not detached with what is wrong with the world and human attitude in general. > > Saying that I am not saying there not some amazing projects out there and some great people, but I really cant share his enthusiasm and optimism. > > PS : he seems to complain a lot about the forks of Lisp. Is it not Lisp a factory of programming languages ? I agree with him that those should not be called Common Lisp if they do not conform but I disagree that their existence is a bad thing. You cant go forward if you dont reinvent the wheel. Even though "reinventing" seems to be a forbidden word in coding. > > ________________________________ > From: Sven Van Caekenberghe <sven(a)beta9.be> > To: "Pharo-project(a)lists.gforge.inria.fr Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, 27 January 2012, 10:18 > Subject: [Pharo-project] Enthousiasm is the main currency among developers > > The following 10 year old Usenet article is quite interesting: > > Â http://groups.google.com/group/comp.lang.lisp/msg/4563e504dba92253 > > Although it is quite long and partly about Common Lisp, its main point is that enthousiasm and positive energy are the main/natural currency among developers. I think that this is also the main driving force behind Pharo. > > The author is Erik Naggum (http://en.wikipedia.org/wiki/Erik_Naggum) a programmer and (in)famous, provocative participant to many discussions. He died a couple of years ago. > > Sven > >

1 0

[Pharo-project] Written down current Keyboard Event Model
by Guillermo Polito Jan. 27, 2012

Jan. 27, 2012

Maybe this has to be written in the wiki, the book, or something :P. Keyboard interaction raises 3 events: - Keydown When a key is pressed, it informs the same as a keystroke. *Nobody uses it :/.* Also, between platforms, the keydown events are different Â¬Â¬. Even more!! These events are not taken into account by morphic EventHandler :D. Just try: aMorph on: #keyDown send: #value to: [ UIManager inform: 'hello!'] - Keyup When a key is released, it informs the same as a keystroke. *Nobody uses it :/.* Also, between platforms, the keyup events are different Â¬Â¬. Even more!! Those events are not taken into account in morphic EventHandler :D. Just try: aMorph on: #keyUp send: #value to: [ UIManager inform: 'hello!'] - Keypress When a key with a unicode representation is pressed, informs: -modifiers. Hey guess what? If you type ctrl+a character, you'll get cmd+that character. Be careful ;). -keyCode: a value representing the key pressed (not the character equivalent) -keyCharacter: a character representing the key pressed. It may not be a printable character, so, be careful ;). to subscribe a morph to this event just do: Even more!! They are not took into account in morphic EventHandler :D. Just try: aMorph on: #keyStroke send: #value to: [ UIManager inform: 'hello!' ]. Guille, messing with events and stuff, and vms, and bored :P

2 2

[Pharo-project] Zodiac Alpha Release 2012-01-26
by Sven Van Caekenberghe Jan. 27, 2012

Jan. 27, 2012

Hi, I uploaded a new, updated version of Pharo 1.3 One-Click containing the latest Zinc HTTP Components and Zodiac code, as well as the necessary SSL VM plugin, for a good out-of-the-box experience for those interested in TLS/SSL secure socket streams. http://dl.dropbox.com/u/16235440/Pharo-1.3-Zodiac-OneClick.app.zip (~25Mb) Features: - ZnSecureSocketStream - HTTPS client access - HTTPS server (not on Mac OS X though) - ZdcSecureSMTPClient - ZdcSecurePOP3Client I tested this on Mac OS X 10.7, Ubuntu 11.10 and Windows 8. This is a stock #13315 Pharo image customized as follows: "Update Zinc HTTP Components" Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; load. "Load Zodiac including extras" Gofer it squeaksource: 'Zodiac'; package: 'Zodiac-Core'; package: 'Zodiac-Tests'; package: 'Zodiac-Extra'; load. "Load extra Zinc support for Zodiac" Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-Zodiac'; load. Pharo 1.4 does not need the Zn update since it contains the latest version of Zn already. For more information, visit http://zdc.stfx.eu Enjoy, Sven PS: Zodiac development was partly sponsored by ESUG

3 2

[Pharo-project] Fwd: about athens cairo
by Fernando Olivero Jan. 26, 2012

Jan. 26, 2012

In this example i'm "painting" the backgroundSurface over the destination: the overlaySurface. Since i dont have to specify a path to do so, i have to bypass #drawShape:, and send #loadOn: and paintOn:. overlaySurface drawDuring:[:canvas| | paint | paint := canvas setPaint: backgroundSurface. paint loadOn: canvas at: 0@0; paintOn: canvas. ..]. i'm not sure that fill is the only verb in place. Would like to know your thoughts on this. Fernando ---------- Forwarded message ---------- From: Fernando Olivero <fernando.olivero(a)usi.ch> Date: Thu, Jan 26, 2012 at 9:06 PM Subject: Re: about athens cairo To: Igor Stasenko <siguctua(a)gmail.com> Cc: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> On Thu, Jan 26, 2012 at 2:19 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 26 January 2012 13:46, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I noticed the class SurfaceManager. I understand now, you want to >> reify the surface plugin within the image! Cool. >> >> Since i'm redoing the DamageRecorder, for a vectorial UI, instead of a >> single global display as Morphic, i'm adding AthensCairoSurfacePaint, >> to be able to use surfaces as cairo sources for painting, not filling. >> >> paint: A drawing operator that paints the current source everywhere >> within the current clip region. >> > so if i understood you want to do something like: > > paint := AthensCairoSurfacePaint new init .... > > canvas setPaint: paint. > > canvas drawShape: someShape. > > ? > Because there is no other way. Only one :) well, in cairo filling and painting are different operations. Paint doesn't rely on the path, its useful for clearing surfaces, all of its contents. Surely you can achieve the same with fill and a rectangle, but you have to explicitly load it in the latter case. The only "verb" Athens supports is fill. but shouldn't it support paint and mask too? According to you answer below, then the paint should know the proper "verb" to execute, fill,paint, mask or stroke. Another "verb" i've added is Â AthensCairoPaint>>preservePath:, because in Cairo a fill or stroke, clears the path, therefore you can use fill_preserve or stroke_preserve. http://cairographics.org/tutorial/ Paint The cairo_paint() operation uses a mask that transfers the entire source to the destination. Some people consider this an infinitely large mask, and others consider it no mask; the result is the same. Mask The cairo_mask() and cairo_mask_surface() operations allow transfer according to the transparency/opacity of a second source pattern or surface. Where the pattern or surface is opaque, the current source is transferred to the destination. Where the pattern or surface is transparent, nothing is transferred. > > >> >> The question is whom should be responsible for dispatching either a >> paint of a fill command? >> >> Rectangle>>paintFillsUsing: aPaint on: anAthensCanvas >> Â Â Â Â ^ aPaint fillRectangle: self on: anAthensCanvas >> >> sent by Canvas>>drawShape: >> > > There is no "paint shape" command, only fill shape (refer to above response ;). > > Ultimately, paint's only responsibility is to fill the shape. there is > no "half fill , or stroke shape" > this is specific to paint how it will fill the shape, and so, canvas > always starts dispatch from shape, > and then shape does more precise (like fillRectangle: ) dispatch to > paint object, > so paint having better idea, about proper way to fill such kind of shape. > > So, at the end, a paint should receive message like: > > fillXYZ: shape on: canvas > > and how it fills it, is completely up to paint. > >> Options: >> 1) Canvas>>paintShape: >> 2) Canvas>>drawShape: and the paint itself knows wether to fill of paint? >> >> Option 2 seems more suited to the overall design in Athens. In that >> case, can we define the following ivars? >> >> AthensPaint.paintOrFill >> AthensPaint.paintOperator (compositing operators, similar to the ones in BitBlt) >> > > No. Not in paints IMO. Because paint mode is usually globally set and > applied to all operations. > Setting paint mode per each paint is also expensive. Because you > usually switching paints more often than paint mode. > > For composing rules i thinking about same way as with with matrices: > > canvas paintMode over. Â "set 'over' paint mode" > > canvas paintMode alphablend. "set alpha-blend paint mode" > .. etc.. > > mode := canvas paintMode current "get current paint mode" > canvas paintMode setTo: mode Â "set to previously remembered mode" > > paint can query the paint mode from canvas, before performing "fill on > shape" and pick appropriate method if needed. > >> Fernando ahh..ok. much better this way.

1 0

[Pharo-project] [JOB] Professor Position at Lille
by Marcus Denker Jan. 26, 2012

Jan. 26, 2012

Permanent Professor (MaÃ®tre de confÃ©rence) position. ========================================= The University of Lille-1 has 3 professor positions for September 2012 one of which (MCF-1170) is in software engineering. - Duration: permanent (tenured) - Starting date: September 2012 - Where: University of Lille-1 - Topic: Software Engineering About Lille and the University and RMOD: -------------------------------------------------------- - Lille is located in the north of france. -- one hour from Paris, 1h20 from London, 35 min from Brussels, by train. - RMoD: http://rmod.lille.inria.fr - UniversitÃ© Lille 1: --http://en.wikipedia.org/wiki/UniversitÃ©_Lille_1 --http://www.univ-lille1.fr - Lille: --http://en.wikipedia.org/wiki/Lille --http://wikitravel.org/en/Lille For more information enter in contact with StÃ©phane Ducasse or Nicolas Anquetil (see in http://rmod.lille.inria.fr/web/pier/team) Permanent link: http://rmod.lille.inria.fr/web/pier/blog/2012-01-20 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [JOB] 18 months PostDoc Position INRIA Lille
by Marcus Denker Jan. 26, 2012

Jan. 26, 2012

18 months PostDoc Position INRIA Lille =============================== - Duration: 18 months - Starting date: Begining 2012 - Where: RMOD team at INRIA Lille Nord Europe - Salary: 55 Keuros net (before taxes) - Keywords: dynamic languages, security, information flow, Smalltalk, Javascript The position will take place in the context of the Systematic Resilience project. We will focus on the following main tasks: - Identification and understanding of security problems in Javascript and other dynamic languages - Study and analyze existing approaches towards securing Javascript (Caja, isolates...) - Comparison of different approaches to secure dynamic applications (Zope model, ZTK), Ruby - Study of Mirrors/Capabilities as a basis for security in Javascript - Proposition of an safe architecture for Resilience About Lille and INRIA: ====================== Lille is located in the north of france. (one hour from Paris, 1h20 from London, 35 min from Brussels, by train) -> French food, combined with good Belgium beer. -> RMoD: http://rmod.lille.inria.fr -> INRIA Lille: http://www.inria.fr/lille/ -> INRIA in General: http://www.inria.fr -> Lille: - http://en.wikipedia.org/wiki/Lille - http://wikitravel.org/en/Lille Please contact Stephane Ducasse (Stephane.Ducasse(a)inria.fr) for more information. -- Marcus Denker -- http://marcusdenker.de

1 0