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

[Pharo-project] Beginner question about "self" in block

by Garret Raziel

Hi, I have one begginer question. It is may be simple, but it very baffles me. I am reading Pharo by Example (great book btw, thanks!). I'm in chapter two where I'm creating Lights Out game. There is this simple code http://pastebin.com/eQregZ35. What baffles me is line 10. I assign "Block of code" to mouseAction variable of LOCell. In this Block, there is "self", that obviously refers to LOGame object in that time. But when is this Block actualy EVALUATED (when I click on Cell), "self" should be reffering to LOCell object, isn't it? If I inspect one LOCell, inspector shows that it has instance variable "mouseAction", which is BlockClosure, that looks like "[self toggleNeighboursOfCellAt: i at: j]". If "LOCell" is the "owner" of this block and also it is the one that evaluates it, shouldn't "self" refer to LOCell object? How BlockClosure desides where "self" actually points? Thanks for explanation. Jan

Jan. 25, 2012

Re: [Pharo-project] Let's change DamageRecorder>>new

by Henrik Johansen

On Jan 25, 2012, at 3:32 20PM, 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 from me at leastâ¦ Cheers, Henry

Jan. 25, 2012

Re: [Pharo-project] Let's change DamageRecorder>>new

by StÃ©phane Ducasse

add an entry that we do not forget. 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 >

Jan. 25, 2012

Re: [Pharo-project] Let's change DamageRecorder>>new

by Fernando Olivero

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 >> >

Jan. 25, 2012

Re: [Pharo-project] Let's change DamageRecorder>>new

by StÃ©phane Ducasse

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 >

Jan. 25, 2012

[Pharo-project] Let's change DamageRecorder>>new

by Fernando Olivero

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

Jan. 25, 2012

[Pharo-project] Pharo mini conference in may

by Norbert Hartl

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

Jan. 25, 2012

Re: [Pharo-project] [Vm-dev] Split sound package -> Cog not loading in last 1.4

by Mariano Martinez Peck

On Tue, Jan 24, 2012 at 10:07 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > > On Jan 24, 2012, at 8:12 14PM, Mariano Martinez Peck wrote: > > > 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 ? > > > My 2c: Just split of Sound-Scores into a separate package, leaving Sound > containing Sound-Synthesis. > Other than that, it sounds like a good plan. > > Why? Because it: > 1. Makes it easy to still synch with the version in Squeak. > 2. Avoids having to create a new baseline. > 3. The extra work of either a), b), or c) is unnecessary. > > Good idea. I have just do that. And I have created a new baseline/version if ConfigurationOfPharo sound so that to include SoundScores.... But Cog still uses Sound, so now it is working :) > Cheers, > Henry -- Mariano http://marianopeck.wordpress.com

Jan. 25, 2012

Re: [Pharo-project] [Event related] Character vs Keys

by Fernando Olivero

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 > >

Jan. 24, 2012

Re: [Pharo-project] [Event related] Character vs Keys

by StÃ©phane Ducasse

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

Jan. 24, 2012