- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] [Vm-dev] is there a way to avoid all the #tryNamedPrimitive:with: * in ProtoObject
by Mariano Martinez Peck Jan. 26, 2012

Jan. 26, 2012

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

1 0

[Pharo-project] Squeaksource Mirror Q&A
by Johan Fabry Jan. 26, 2012

Jan. 26, 2012

Hi All, Alex notified me that there were some mails flying around here about the squeaksource mirror. I'm usually not on this mailing list because of its high volume. I'd like to gather some questions that have been raised in the last few days (thanks Nabble!) and give answers / share my thoughts. I'll try to keep it brief. - How to use the mirror. If you don't know or tend to forget, just point a web browser at http://dsal.cl/squeaksource Everything is explained there. Write the URL on a post-it, add it to your browers favorites or whatever ;-) Just remember http://dsal.cl/squeaksource - Mirror not complete: It is supposed to be a full mirror of the public packages on Squeaksource. We are using wget to copy everything over. If you know of a project that misses packages, please send me a mail (personally, not to the list is best I guess) and we will try to debug the issue. - Pharo 1.4 / ObjectAsMethodWrapper issues: The redirect package was written for 1.3, it uses ObjectAsMethodWrapper (i.e. method wrappers). I don't know why ObjectAsMethodWrapper (apparently) is no longer in 1.4 but I would highly recommend including it as it is a very useful package. I thought even the profiler used it. In any case, I welcome any contributions on how to make it work for 1.4 - Friendler configuration / user interface / having it in the core image / ...: I am all for it, but I cannot dedicate the time to this right now. All help is welcome and highly appreciated. I guess that some of you must be much more knowledgeable at preferences settings/user interfaces et al. so what would take you 10 minutes would take me a day ... I subscribed to the list now BTW so any comments/questions simply hit reply :-) ---> 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

6 11

[Pharo-project] OneClick on website's first page?
by Janko MivÅ¡ek Jan. 26, 2012

Jan. 26, 2012

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

5 4

[Pharo-project] [JOB] Researcher Positions at INRIA
by Marcus Denker Jan. 26, 2012

Jan. 26, 2012

Researcher Positions at INRIA ======================== The yearly competition for INRIA research positions started. (Deadline: Feb 17th) RMOD is looking for researchers to apply for joining our team at Lille/France with permanent (tenured) positions: CR2 "Young graduate scientist" http://www.inria.fr/en/institute/recruitment/offers/young-graduate-scientis… - need PhD - formally no other research experience required, in practice the competition is very hard and a strong academic CV is needed on a level that requires, besides a very good PhD, at least 1-2 years of post-doctoral research. CR1 "Young experienced scientist" http://www.inria.fr/en/institute/recruitment/offers/young-experienced-scien… - need PhD and 4 years of research experience. - very strong academic CV. Both positions are tenured after a probation period of 12 Months. Research directions are = Software Engineering / Software Evolution = Dynamic Reflective Programing Languages = Security and Dynamic Languages Duties -> Research (No teaching) -> Help manage the Research group. -> Be involved with the self-governance of the INRIA Lab and INRIA as a whole. -> Guide PhD Students (And therefore get a french habilitation to be able to formally supervise PhD students) -> Help acquiring additional funds for PhD Students, Postdocs and Engineers -> Transfer of research results to the real world. (this means: making things real is valued. Not just paper writing) 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 Interested? Please contact Marcus Denker <marcus.denker(a)inria.fr> and StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> (permanent Link to this text: http://rmod.lille.inria.fr/web/pier/blog/2012-01-26) -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Jenkins down?
by Bernat Romagosa Jan. 26, 2012

Jan. 26, 2012

http://ci.lille.inria.fr/pharo is 404ing me -- Bernat Romagosa.

2 1

[Pharo-project] Fwd: [Moose-dev] cogwin/Croquet (Win7) + Moose + very large model = crash (out of Memory)
by StÃ©phane Ducasse Jan. 26, 2012

Jan. 26, 2012

Begin forwarded message: > From: Hani Abdeen <hani.abdeen(a)gmail.com> > Subject: [Moose-dev] Re: cogwin/Croquet (Win7) + Moose + very large model = crash (out of Memory) > Date: January 26, 2012 8:52:15 AM GMT+01:00 > To: Moose-related development <moose-dev(a)iam.unibe.ch> > Reply-To: Moose-related development <moose-dev(a)iam.unibe.ch> > > Hi Doru, > > the image size starts at 400M, before doing anything on the model. > Now, as I start manipulating the model and sending navigation queries, trying to create an Arki report about the model, the image size apparently exceed 500M and the VM crashes! > For more information I enclosed the header of the crash.dmp file. > > Cheers, > Hani > > --------------------------------------------------------------------- > Fri Jan 13 14:57:11 2012 > > > Error in the VM thread > Reason: out of memory > > > > Hardware information: > Manufacturer: Unknown > Model: Unknown > Number of processors: 4 > Page size: 4096 > > Memory Information (upon launch): > Physical Memory Size: 4194303 kbytes > Physical Memory Free: 4194303 kbytes > Page File Size: 4194303 kbytes > Page File Free: 4194303 kbytes > Virtual Memory Size: 2097024 kbytes > Virtual Memory Free: 2025868 kbytes > Memory Load: 20 percent > > Processor 0: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 1: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 2: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Processor 3: Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz > Identifier: Intel64 Family 6 Model 42 Stepping 7 > ~MHZ: 2494 > > Operating System: Windows 7 Ultimate (Build 7600 ) > Registered Owner: Microsoft > Registered Company: Microsoft > SP major version: 0 > SP minor version: 0 > Suite mask: 100 > Product type: 1 > > Display Information: > Graphics adapter name: Intel(R) HD Graphics Family > Primary monitor resolution: 1366 x 768 > > Device: RDPDD Chained DD > Adapter String: ??? > Bios String: ??? > Chip Type: ??? > DAC Type: ??? > Memory Size: 0xFFFFFFFF > > Driver Versions: > RDPDD: > > VM Version: Cog VM 4.0.0 (release) from Dec 1 2011 > Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > Interpreter Build: CoInterpreter VMMaker.oscog-eem.138 uuid: f9a63bdf-7bbc-4ae5-9634-ecd6fd814c9d Dec 1 2011 > Cogit Build: StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: c2849383-9768-4948-b9b2-a5c22d482b07 Dec 1 2011 > > > > > On 26 January 2012 07:29, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > What does large mean in your case? I routinely work with 500MB images on Windows 7 using the same VM. > > Cheers, > Doru > > > On 25 Jan 2012, at 23:25, Hani Abdeen wrote: > > > Hello, > > > > I'm using cogwin/Croquet VM (last version http://www.mirandabanda.org/files/Cog/VM/VM.r2522/) on windows7, > > and today I had this probelm: when the size of the pharo image become so large the VM crashes with reason 'out of memory'. > > The same problem with previous versions of cogwin. > > I've only one, but very large, Java model in Moose. > > Note that I use a PC with 8G of RAM, so it's really damage to have such a problem. > > > > Any idea about another VM working well on Windows and does not have such an issues? > > Any urgent solution? > > > > Unfortunately I've not Mac and the company for which I'am going to demonstrate Moose, on their code base and Tomorrow morning do not use Mac. > > > > Thanks, > > Hani > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

3 3

[Pharo-project] DosFileDirectory class>>privateFullPathForURI: aURI [WAS] Re: [Vm-dev] Primitive failed when compiling Vm on Windows
by Mariano Martinez Peck Jan. 26, 2012

Jan. 26, 2012

On Thu, Jan 26, 2012 at 12:13 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > > Hi! > > I've downloaded version 3.8 of ConfigurationOfCog on Pharo 1.4, and when > sending #topDir: to a CogWindowsConfig instance, I get a primitive failed > error: > > Guille, if you see the family of Windows confs, regarding the file paths, they usually use #msysPathFor: Check its senders as an example. Maybe we can adapt topDir to use that. But I am not sure if that's a good idea. I think several months ago I was bitten but the same problem. I would like if your change to: DosFileDirectory class>>privateFullPathForURI: aURI is correct. Because maybe we can just integerate that. anyone? > PrimitiveFailed: primitive #primCreateDirectory: in DosFileDirectory failed > 25 January 2012 7:24:30 pm > > VM: Win32 - IX86 - 5.1 - CoInterpreter VMMaker.oscog-eem.140 uuid: > 2487009c-2c13-4609-b89e-77f0e195f433 Dec 12 2011, > StackToRegisterMappingCogit VMMaker.oscog-eem.139 uuid: > c2849383-9768-4948-b9b2-a5c22d482b07 Dec 12 2011, r2522 > http://www.squeakvm.org/svn/squeak/branches/Cog > Image: Pharo1.4a [Latest update: #14296] > > DosFileDirectory(Object)>>primitiveFailed: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > selector: #primCreateDirectory: > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(Object)>>primitiveFailed > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>primCreateDirectory: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > fullPath: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>createDirectory: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > localFileName: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '' > Arguments and temporary variables: > lPath: '\\MinGW' > localPath: '\\MinGW' > Receiver's instance variables: > pathName: FilePath('') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW' > Arguments and temporary variables: > lPath: 'msys' > localPath: 'msys' > Receiver's instance variables: > pathName: FilePath('\\MinGW') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys' > Arguments and temporary variables: > lPath: '1.0' > localPath: '1.0' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0' > Arguments and temporary variables: > lPath: 'home' > localPath: 'home' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home' > Arguments and temporary variables: > lPath: 'Guille' > localPath: 'Guille' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0\home') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home\Guille' > Arguments and temporary variables: > lPath: 'cog' > localPath: 'cog' > Receiver's instance variables: > pathName: FilePath('\\MinGW\msys\1.0\home\Guille') > > > DosFileDirectory(FileDirectory)>>assureExistenceOfPath: > Receiver: DosFileDirectory on '\\MinGW\msys\1.0\home\Guille\cog' > > > I followed the error up to: > > DosFileDirectory class>>privateFullPathForURI: aURI > | path | > path := aURI path unescapePercents. > > "Check for drive notation (a: etc)" > path size > 1 > ifTrue: [ > ((path at: 3) = $:) > ifTrue: [path := path copyFrom: 2 to: path size] > ifFalse: [ > "All other cases should be network path names (\\xxx\sdsd etc)" > path := '/' , path]]. > > ^path copyReplaceAll: '/' with: self slash > > Which seems not being resolving well a full path like > 'c:\something\another\directory' and is answering something like > > '\\MinGW\msys\1.0\home\Guille\cog\gpolito-cogvm' > > which then is treated as a relative path... > > I've done a temporary fix like this in my image so I can continue, but > maybe someone has a little more knowledge on this class: > > DosFileDirectory class>>privateFullPathForURI: aURI > | path | > path := aURI asString unescapePercents. > > "Check for drive notation (a: etc)" > path size > 1 > ifTrue: [ > ((path at: 2) = $:) > ifTrue: [path := path copyFrom: 1 to: path size] > ifFalse: [ > "All other cases should be network path names (\\xxx\sdsd etc)" > path := '/' , path]]. > > ^path copyReplaceAll: '/' with: self slash > > Guille > > -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] [Event related] [Unix] Input event Sensor key decoding
by Guillermo Polito Jan. 25, 2012

Jan. 25, 2012

Hi! I was looking why alt and ctrl keys behave the same in unix, jeje, so I looked at the vm and everything seemed to be alright, but in the image I always had *Cmd+a key* when doing *alt+akey* :S. And this is pretty annoying since it limits the ammount of shortcuts I can work with, and I also make things work different than the rest of the OS. So, searching I found a *KeyDecodeTable *in InputEventSensor, which was built with this method: installDuplicateKeyEntryFor: c | key | key := c asInteger. "first do control->alt key" KeyDecodeTable at: { key bitAnd: 16r9F . 2 } put: { key . 8 }. "then alt->alt key" KeyDecodeTable at: { key . 8 } put: { key . 8 } So, every character keypress that had a 2 as a modifier (a control) is converted as a command in here: processEvent: evt "Process a single event. This method is run at high priority." | type | 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: [ * "Sswap ctrl/alt keys if neeeded" KeyDecodeTable at: {evt at: 3. evt at: 5} ifPresent: [:a | evt at: 3 put: a first; at: 5 put: a second]. * "Update state for polling calls" modifiers := evt at: 5. ^evt]. "Handle all events other than Keyborad or Mouse." ^evt. Now, I think this hack is there to allow the same behavior cross platform, but it is very ugly :( And bring a lot of UI limitations to the people who only have alt and ctrl and no Cmd button :P... Ok, removing this ugly code made my shortcuts work now with only with alt (cmd to the vm) and not with control, hehe, but I think that to fix things we have to clean them first :). Does anyone know the reason of the existance of this table (besides cross platform hacking)? Is this really useful? Can it be removed? Do I open a ticket? Guille

2 1