- Pharo-dev - lists.pharo.org

[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

Re: [Pharo-project] [Event related] Character vs Keys
by Fernando Olivero Jan. 25, 2012

Jan. 25, 2012

YES! the keyboard events handling is a mess that should be rethought and simplified. I've recently played with Cocoa, and created a windowed app, that captures events and sends them to a pharo image via sockets. so i learned how is done in COCOA. In Cocoa, there are 3 key events: NSKeyDown: The user generated a character or characters by pressing a key. NSKeyUp: The user released a key. This event is always preceded by a NSKeyDown event. NSFlagsChanged: The user pressed or released a modifier key, or turned Caps Lock on or off. "When the type of an event is NSKeyDown, the next step is typically to get the characters generated by the key-down using the characters method." I think the COCOA VM, should simply forward this events to the image. Esteban, would this be possible? The three are enough, to preserve all the current behavior of Morphic. In short, the VM should omit keyChar keyboard events, and start announcing non-characters pressed or released events. Fernando On Tue, Jan 24, 2012 at 10:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I should learn more on the topic :). > But on the principle yes I want to avoid all the hardcode stuff everywhere. > Guillermo in feb we should have a coffee meeting with a group building new UI using Python (of course) > and I could ask them how they manage keystrokes. Or we can also interact with them by mail. > May be they do not have the answer. > >> Hi! >> >> While playing (again) to add Function keys support, reading documentation of how keyboard handling works on our vm and other platforms: >> >> .Net: http://msdn.microsoft.com/en-us/library/system.windows.forms.control.keydow… >> Javascript: http://www.quirksmode.org/js/keys.html >> >> And a quick explanation of Igor of how our vm works: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-November/009661.html >> >> >> What puzzles me is some of the following: >> >> - Keypress event should only be raised to send keystrokes having a character representation. >> - but some keystrokes with no character representation are taken as keypresses! (arrowup, arrowdown, esc...) (and so, used to handle events instead of doing it on keydown) >> - the strokes above should be only raised in keydowns IMHO. >> - more on, we have in Character class representations for those non characters :P which is funny because they are not characters. >> >> And everything works, and fits in a kind of strange way :). >> >> Now, rearranging this to follow those conventions means: >> - reify Keys (vs Characters). Â So we can model modifier keys, function keys, arrow keys, independent from Characters. >> - Keys (non-characters) should only be raised as single events on keydown. >> - and the worse part is to fix all the hardcoded shortcuts messed everywhere in the image. >> >> Any thoughts on this? >> >> Thanks! >> Guille > >

3 2

[Pharo-project] Let's change DamageRecorder>>new
by Fernando Olivero Jan. 25, 2012

Jan. 25, 2012

Found a really bad looking code here... DamageRecorder class>>new ^ super new reset Should be: Delete: DamageRecorder class>>new. DamageRecorder>>initialize super initialize. self reset. Right? Fernando

3 3

Re: [Pharo-project] Let's change DamageRecorder>>new
by Fernando Olivero Jan. 25, 2012

Jan. 25, 2012

no, I think it wont change the behavior, the change would just fix a bad style of coding. Fernando On Wed, Jan 25, 2012 at 3:47 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > does it solve some redraw problems we experienced? > > Stef > > On Jan 25, 2012, at 3:32 PM, Fernando Olivero wrote: > >> Found a really bad looking code here... >> >> DamageRecorder class>>new >> Â Â Â ^ super new reset >> >> Should be: >> Delete: DamageRecorder class>>new. >> DamageRecorder>>initialize >> Â Â Â super initialize. >> Â Â Â self reset. >> >> >> Right? >> Fernando >> >

1 0

[Pharo-project] Pharo mini conference in may
by Norbert Hartl Jan. 25, 2012

Jan. 25, 2012

Was there a decision about at which date the mini conference should take place? Norbert

1 0

[Pharo-project] Split sound package -> Cog not loading in last 1.4
by Mariano Martinez Peck Jan. 25, 2012

Jan. 25, 2012

Hi guys. Cog is not loading anymore in 1.4 because of some classes depending on Project from the 'Sound' package found in PharoSound repo in SS. At the beginning I thought to create a separate package "SoundVMSupport" and put there the needed classes, but I discover that there are a lot which are needed. And moreover, all of those needed classes are in the category Sound-Synthesis. The classes problematic (regarding Project and morphs) are in the other package Sound-Scores. I have just tried and split the Sound package in two: SoundScores and SoundSynthesis. Then I changed ConfigurationOfCog to load SoundSynthesis rather than Sound. That works and I can now build the VM without problems. I think that the split makes sense even without of the need of Cog. Do you agree? If true, I can commit everything. One of the things I am not sure is how to make sure Sound package is not used anymore. All I can do is: a) Put a comment in squeaksource page saying that the packages are now SoundScores and SoundSynthesis. b) Create a new baseline and version of ConfigurationOfPharoSound which reflecs this change c) Commit a version of everything empty (no single class) to the package Sound. Which ones of these should I do ? Thanks -- Mariano http://marianopeck.wordpress.com

2 2

[Pharo-project] [Event related] Character vs Keys
by Guillermo Polito Jan. 24, 2012

Jan. 24, 2012

Hi! While playing (again) to add Function keys support, reading documentation of how keyboard handling works on our vm and other platforms: .Net: http://msdn.microsoft.com/en-us/library/system.windows.forms.control.keydow… Javascript: http://www.quirksmode.org/js/keys.html And a quick explanation of Igor of how our vm works: http://lists.squeakfoundation.org/pipermail/vm-dev/2011-November/009661.html What puzzles me is some of the following: - Keypress event should only be raised to send keystrokes having a character representation. - but some keystrokes with no character representation are taken as keypresses! (arrowup, arrowdown, esc...) (and so, used to handle events instead of doing it on keydown) - the strokes above should be only raised in keydowns IMHO. - more on, we have in Character class representations for those *non characters* :P which is funny because they are not characters. And everything works, and fits in a kind of strange way :). Now, rearranging this to follow those conventions means: - reify Keys (vs Characters). So we can model modifier keys, function keys, arrow keys, independent from Characters. - Keys (non-characters) should only be raised as single events on keydown. - and the worse part is to fix all the hardcoded shortcuts messed everywhere in the image. Any thoughts on this? Thanks! Guille

3 2

[Pharo-project] [update 1.4] #14296
by Marcus Denker Jan. 24, 2012

Jan. 24, 2012

14296 ----- - actually add the code missed in the last update -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [update 1.4] #14295
by Marcus Denker Jan. 24, 2012

Jan. 24, 2012

14295 ----- Issue 5215: FailingTest: Uncategorized Method http://code.google.com/p/pharo/issues/detail?id=5215 Issue 5216: Failing Test: Obsolete classes http://code.google.com/p/pharo/issues/detail?id=5216 Issue 5212: Fix CompiledMethod>>#browse http://code.google.com/p/pharo/issues/detail?id=5212 - do #cleanUpForRelease -- Marcus Denker -- http://marcusdenker.de

1 0