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

[Pharo-project] Zodiac Alpha Release 2012-01-26

by Sven Van Caekenberghe

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

Jan. 26, 2012

[Pharo-project] Fwd: about athens cairo

by Fernando Olivero

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.

Jan. 26, 2012

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

by Sven Van Caekenberghe

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

Jan. 26, 2012

[Pharo-project] [JOB] Professor Position at Lille

by Marcus Denker

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

Jan. 26, 2012

[Pharo-project] [JOB] 18 months PostDoc Position INRIA Lille

by Marcus Denker

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

Jan. 26, 2012

Re: [Pharo-project] [Vm-dev] is there a way to avoid all the #tryNamedPrimitive:with: * in ProtoObject

by Mariano Martinez Peck

Well. My final proposal is in: http://code.google.com/p/pharo/issues/detail?id=5223 With comments and some small refactors. As said, I would love if someone can take a view before integrating. Cheers On Thu, Jan 26, 2012 at 7:25 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Thu, Jan 26, 2012 at 6:00 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> >> On 26 January 2012 14:42, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> > >> > >> > >> > On Thu, Jan 26, 2012 at 11:38 AM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> >> >> On 26 January 2012 11:25, stephane ducasse <stephane.ducasse(a)gmail.com> >> wrote: >> >> > >> >> >> phew... done reading through overquoting :) >> >> >> >> >> >> +1000 to removing tryXYZprimitive: >> >> >> >> >> >> I was always wondering what those methods for, until i met a need to >> >> >> support debugging when invoking nativeboost-prim methods, >> >> >> because it needs special handing when invoking methods with native >> >> >> code via debugger. >> >> >> >> >> >> Then i understood that this mechanism is necessary.. yet a bit >> awkward.. >> >> >> >> >> >> Funny. Even after implementing the fix, I still do not understand >> why all these is needed. Can someone explain to a newbie why invoking >> primitives (whether they are normal primitives, named primitives or NB >> primitives) from the debugger is different than invoking them normally (as >> when they are invoked by normal code) >> >> > >> >> > Yes I want to understand too. >> >> > >> >> >> >> Here the hint for you: >> >> - what should happen when you doing 'step in' on method, which has a >> primitive? >> >> >> >> Apparently, it should invoke that primitive , otherwise you will have >> >> difference between running and debugging modes, >> >> and will have different results, which makes debugger useless. >> >> So debugger should detect "somehow" if primitive was failed, and then >> >> step in into given method, >> >> or if its not, then step in = step over. >> >> >> >> And these 'tryXYZ ... ' is exactly for solving this dilemma. >> > >> > >> > Thanks Igor. So I wrote what I understood. Problem is that I always >> write for newbies (like me) so if it is too obvios or too long to put it as >> comment, let me know. >> > I would appreaciate if someone can validate what I wrote. >> > Today I will create a slice with mentioned solution + comments + >> removal of all those tryNamedPrimitive*. >> > >> > ---- >> > >> > "When using the debugger we want to run a method step by step. But what >> happens when we do a step into a CompiledMethod which has a primitive? If >> such a method is executed form outside the Debugger (normal scenario) the >> VM knows that such CompiledMethod has a primitive declaration and hence >> executes it. If it fails, then it continues executing all the bytecodes of >> the method. Otherwise, it just returns. >> > >> > Now, what is the problem with the Debugger? The problem is that if the >> primitive fail, we don't want that the VM directly executes all the >> remaining bytecodes of the method. Instead, we would like to go step by >> step with he Debugger, just as happens with normal methods. >> > >> > To solve the mentioned problem, we use the following trick: We have the >> original compiled method (the one that has a primitive invocation), the >> receiver and the arguments. So the idea is to use a template compiled >> method that ONLY contains the primitive declaration (it doesn't include all >> the original smalltalk code after the primitive). >> #tryNamedPrimitiveTemplateMethod answers such a template method which looks >> like: >> > >> > tryNamedPrimitive >> > <primitive:'to be set later' module:'to be ser later'> >> > ^ ContextPart primitiveFailToken' >> > >> > Since this method does not change its bytecodes for every invocation, >> we can reuse it for all methods with primitives. There are only 2 things we >> have to change in the template: the number of arguments and the primitive >> declaration (to use the correct primitive name and module name). >> > >> > Then what we do is to run that compiled method with the receiver and >> arguments we have. The result is that we will be invoking almost the same >> original method but a slightly different version that does not have the >> smalltalk part after the primitive and that in contrast is sends >> #primitiveFailToken (which tells the Debugger what to do after). If this >> method invocation does not fail, then the Debugger continues debugging the >> sender of the primitive method. In this case, the step in is the same as >> step over. If the primitive fails, then the debugger continues executing >> the smalltalk part after the primitive method. In this case, step in is a >> real step in. " >> > >> > >> There's another problem with using "tryXYZ" when primitive doing >> something weird with contexts (like block's #value) >> because then debugger cannot intercept switching contexts so easily, >> when primitive doing manipulation with contexts, >> because debugger have no idea where to put his next "break point" to >> do step-by-step evaluation. >> >> I thinking that there should be special primitive which: >> - takes a context, a receiver, a method and arguments (or just a >> context, if debugger ensures to pass it in prepared state i.e. >> receiver and args already on stack) >> - invokes method's primitive >> - answers a nil if primitive failed or a new context object, which >> holds an updated context state after primitive possibly manipulated >> with context(s) >> > > No, not needed. Manipulation of contexts does not require primitives > since contexts are first-class, and the effect of these primitives can be > simulated in Smalltalk (just as the effect of executing bytecodes can be > simulated). Look at the caller of tryPrimitive:withArgs: and > tryNamedPrimitiveIn:for:withArgs:, namely > ContextPart>doPrimitive:method:receiver:args:. It handles all these > primitives such as perform:[*], value[:value:*], withArgs:executeMethod:. > > > >> so, then debugger will use it like: >> >> contextOrNil := self invokeMethodPrimitive: method context: >> currentContext receiver: recvr arguments: args >> contextOrNil ifNil: [ primitive failed .. ] >> ifNotNil: [ >> currentContext := contextOrNil >> ]. >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > best, > Eliot > > > -- Mariano http://marianopeck.wordpress.com

Jan. 26, 2012

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

by Guillermo Polito

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

Jan. 26, 2012

Re: [Pharo-project] Squeaksource Mirror Q&A

by Johan Fabry

Udo has been conversing with me about this previously and I have had the opportunity to try it out. It is quite fast, even for us far away chileans, so it looks like a cool solution :-). If over time this can replace the mirror I have no objections :-) In the mean time we will keep the dsal.cl/squeaksource mirror up and running as well. On 25 Jan 2012, at 18:15, Udo Schneider wrote: > All, > > building on top of Johan's work I built kind of a squeaksource CDN. This CDN mirrors squeaksource daily and should provide fast access to all packages using "nearby" edge location. Before making this public I'd like to get some feedback on it's speed and reliability - especially if you are far away (in terms of hops and bandwidth) from the real squeaksource server. > > So if you can spare some time please drop me a mail and I'll send you further details. > > Thanks, > > Udo ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Jan. 26, 2012

Re: [Pharo-project] Written down current Keyboard Event Model

by Guillermo Polito

On Thu, Jan 26, 2012 at 2:47 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > to subscribe a morph to this event just do: > > Actually, we do work :). We are the only one. > Just try: > > aMorph on: #keyStroke send: #value to: [ UIManager inform: 'hello!' ]. >

Jan. 26, 2012

Re: [Pharo-project] OneClick on website's first page?

by Camillo Bruni

You somehow have this when clicking on "Download" http://www.pharo-project.org/pharo-download What I suggest is to have the same structure for all the download pages: 1. Pharo Version <version> - short description 2. Downloads Images - link to the images (Standard / Core / OneClick) VMs - link to the VM (as done in http://www.pharo-project.org/pharo-download/release-1-3) 3. Changes (as done in http://www.pharo-project.org/pharo-download/release-1-2) - list / link to changes log cami On 2012-01-26, at 18:34, StÃ©phane Ducasse wrote: > So how do we do it? > My plate is too full. > > Stef (getting sick right now). > > On Jan 26, 2012, at 6:27 PM, Mariano Martinez Peck wrote: > >> +1. And the one click VM is terrible old and buggy >> >> On Thu, Jan 26, 2012 at 6:22 PM, Max Leske <maxleske(a)gmail.com> wrote: >> I agree, the Download section should look different but: the big banner in the top right corner links to the stable one-click image. >> >> Cheers, >> Max >> >> >> On 26.01.2012, at 18:01, Janko MivÅ¡ek wrote: >> >>> Hi guys, >>> >>> For newcommers it would be really good to put a "Stable Pharo OneClick" >>> on the first place of Downloads section on first page at >>> http://www.pharo-project.org. >>> >>> This is important also for all us to use and test it really quich, >>> without dealing with proper VM installation. >>> >>> Best regards >>> Janko >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si >>> >> >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > >

Jan. 26, 2012