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

Re: [Pharo-project] System announcements and MC

by Sean P. DeNigris

Mariano Martinez Peck wrote > > Probably the easiest yet not-so-beatiful solution is to do something like > this: > Yes, I was thinking the same... Not too bad a temporary solution since the notification stuff needs to be cleaned anyway... -- View this message in context: http://forum.world.st/System-announcements-and-MC-tp4577351p4578308.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2012

Re: [Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Guillermo Polito

On Sun, Apr 22, 2012 at 4:56 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > And there is also a ControlAltKeyDecodePolicy class var that gets not used > nor updated by anybody, nor appearing in settings. > Ok, I found the setting, I was looking for the mutator :). Does someone use it? :S > > > On Sun, Apr 22, 2012 at 4:53 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> It's supposed to do some conversions, but sometimes, it just screws up >> the use input. It's main responsibility is to change *ctrl* into *alt*: >> >> 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 } >> >> >> And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + >> $i, since >> >> $i asInteger bitAnd: 16r9F = Character tab asInteger >> >> >> And btw, I love my ctrl key and want to have more fancy and sexy >> shortcuts, so this F*** table is bothering :). >> >> Opinions? >> Guille >> > >

April 22, 2012

Re: [Pharo-project] System announcements and MC

by Mariano Martinez Peck

On Sun, Apr 22, 2012 at 6:39 AM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > Sean P. DeNigris wrote > > > > I get notifications when MC is loading things > > Strange... I only get the announcements when class-side instance variables > are added via MC... > > It seems that the reason is that MCClassDefinition>>load creates the class > in two steps: > 1. MCClassDefinition>>createClass takes care of all the instance side > stuff, > and correctly notifies of a new class > 2. Metaclass>>instanceVariableNames: adds the class-side instance variable > names to the class, which now already exists; so the notification is of a > changed class definition > hahahaa I think that's a good catch ;) Probably the easiest yet not-so-beatiful solution is to do something like this: load self createClass ifNotNil: [:class | SystemChangeNotifier uniqueInstance doSilently: [ class class instanceVariableNames: self classInstanceVariablesString. self hasComment ifTrue: [class classComment: comment stamp: commentStamp]] ] :( > > -- > View this message in context: > http://forum.world.st/System-announcements-and-MC-tp4577351p4577658.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- Mariano http://marianopeck.wordpress.com

April 22, 2012

[Pharo-project] Nautilus first impression

by Sean P. DeNigris

Wow, Nautilus is *really* fun to use! I have quite a few ideas for plugins... A few suggestions... * Hierarchical package list - also, since with Metacello the convention is (e.g. P-Core, P-UI, P-Tests) with no overarching package, it should group all packages matching P-*, even if they are technically separate packages * I miss the search bar from OB where I could just start typing as soon as I opened the window. It seems that Nautilus doesn't set the keyboard focus anywhere useful. Options: - search bar - typing brings up the class search dialog - give keyboard focus to the package list so I can use the shortcuts right away. This may be the best one because I have access to 3 options: - cmd-F to search packages - cmd-f to search classes - start typing to do a basic package search * creating new methods - when you click a protocol name, the "messageSelectorAndArgumentNames" template is displayed in the code pane, and is pre-selected. I found this very confusing as a newbie because the selection made me think that I could start typing to replace the template, but the keyboard focus is not on the template. It's also useless because when you click on the code pane, it unselects, so you have to double-click anyway. Two suggestions - from the class pane, protocol pane, or both, have an "add method" menu item that transfers focus to the preselected template - when just clicking on a protocol, don't pre-select the template * back/forward buttons for history navigation? * a centralized place to put/list plugins so we can share them Many thanks to Benjamin. This was sorely needed! Cheers, Sean -- View this message in context: http://forum.world.st/Nautilus-first-impression-tp4578301p4578301.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 22, 2012

Re: [Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Guillermo Polito

http://code.google.com/p/pharo/issues/detail?id=5658&thanks=5658&ts=1335106… On Sun, Apr 22, 2012 at 4:56 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > And there is also a ControlAltKeyDecodePolicy class var that gets not used > nor updated by anybody, nor appearing in settings. > > > On Sun, Apr 22, 2012 at 4:53 PM, Guillermo Polito < > guillermopolito(a)gmail.com> wrote: > >> It's supposed to do some conversions, but sometimes, it just screws up >> the use input. It's main responsibility is to change *ctrl* into *alt*: >> >> 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 } >> >> >> And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + >> $i, since >> >> $i asInteger bitAnd: 16r9F = Character tab asInteger >> >> >> And btw, I love my ctrl key and want to have more fancy and sexy >> shortcuts, so this F*** table is bothering :). >> >> Opinions? >> Guille >> > >

April 22, 2012

Re: [Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Guillermo Polito

And there is also a ControlAltKeyDecodePolicy class var that gets not used nor updated by anybody, nor appearing in settings. On Sun, Apr 22, 2012 at 4:53 PM, Guillermo Polito <guillermopolito(a)gmail.com > wrote: > It's supposed to do some conversions, but sometimes, it just screws up the > use input. It's main responsibility is to change *ctrl* into *alt*: > > 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 } > > > And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + > $i, since > > $i asInteger bitAnd: 16r9F = Character tab asInteger > > > And btw, I love my ctrl key and want to have more fancy and sexy > shortcuts, so this F*** table is bothering :). > > Opinions? > Guille >

April 22, 2012

[Pharo-project] Do we get rid of the KeyDecodeTable in InputEventSensor?

by Guillermo Polito

It's supposed to do some conversions, but sometimes, it just screws up the use input. It's main responsibility is to change *ctrl* into *alt*: 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 } And then it confuses stuff. For example, Ctrl + tab is decoded as ctrl + $i, since $i asInteger bitAnd: 16r9F = Character tab asInteger And btw, I love my ctrl key and want to have more fancy and sexy shortcuts, so this F*** table is bothering :). Opinions? Guille

April 22, 2012

Re: [Pharo-project] Inspect fails - Pharo 1.4 / OSX 10.7.3

by Nicolas Cellier

It's probably a bug, and I just corrected some miss-initialization of lastJumpIfPcStack instance variable in Decompiler in Squeak. But you didn't provide enough information... Can you reliably reproduce it? Or provide full contents of PharoDebug.log. If you can, please open a bug report. Nicolas Le 21 avril 2012 01:54, <recursive68(a)gmail.com> a Ã©crit : > Hi, > > When I try and inspect some FFI code in Pharo 1.4 on OSX 10.7.3, it fails > and gets stuck in a loop doing this: > > MessageNotUnderstood: receiver of "addLast:" is nil > UndefinedObj > ect(Object)>>doesNotUnderstand: #addLast: > Decompiler>>jump:if: > Decompiler(InstructionStream)>>interpretNextInstructionFor: > Decompiler>>interpretNextInstructionFor: > Decompiler>>statementsTo: > Decompiler>>blockTo: > Decompiler>>doClosureCopyCopiedValues:numArgs:blockSize: > Decompiler>>pushClosureCopyNumCopiedValues:numArgs:blockSize: > Decompiler(InstructionStream)>>interpretExtension:in:for: > Decompiler(InstructionStream)>>interpretNextInstructionFor: > > Any ideas ? > > Thanks

April 22, 2012

Re: [Pharo-project] Suggestion: introducing a fixme/issue/todo pragma

by Mariano Martinez Peck

On Sun, Apr 22, 2012 at 3:53 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > Ok. > > Looks like there is still a lot of dirty corners under the hood by looking > at this list of senders... > Indeed. But the first step is to identify them, right? So at least we know those dirty corners ;) > > Phil > > 2012/4/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> >> >> On Sun, Apr 22, 2012 at 11:55 AM, StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> we use self flag: #fixMe >>> you can then query either #fixMe or flag: >>> >>> and yes this is a good idea to mark things and create bug entries. >>> >>> Stef >>> >>> >>> On Apr 22, 2012, at 11:18 AM, phil(a)highoctane.be wrote: >>> >>> > While looking around in the image, I am in need of knowing where I >>> found thngs that either puzzle me or are "wrong" (well, a code smell). >>> > >>> > What I do is that I put pragmas in there like this (not that this >>> sample is meant to be representative) >>> > >>> > privCleanTextConstants >>> > <fixme> >>> > TextConstants TextSharedInformation removeKey: #DefaultTextStyle. >>> > TextConstants TextSharedInformation removeKey: >>> #DefaultMultiStyle. >>> > TextConstants TextSharedInformation removeKey: >>> #DefaultFixedTextStyle. >>> > TextConstants TextSharedInformation removeKey: StrikeFont >>> defaultFontKey. >>> > >>> > Smalltalk allClasses select: [:c | c sharedPools includes: >>> TextConstants] thenDo: [:c | c compileAll ]. >>> > >>> > And I can then find back the things with: >>> > >>> > pc := (PragmaCollector filter: [:prg | prg keyword = 'fixme']) reset. >>> > pc collected size. "(Print It: 1)" >>> > pc collected explore. >>> > >>> > And then finding back the Class and Method Name >>> > >>> > Building upon that, why not do what is done in other environments >>> (well, I've got that in PHP, Java, ...) and use: >>> > >>> > <todo:do this and that> or plain <todo> >>> > <fixme: this and that> or plain <fixme> >>> > <issue:issue#> >>> > >>> >> >> As Stef said, we usually use #flag: Normal cases are #flag:todo, >> #flag:fixMe, etc .. and the browser is aware of that and shows you a flag >> in the icon of the method. >> >> >> >> >>> > And have a specific tool to help the navigation (explore is fine for a >>> moment but...) >>> > >>> > This would allow us to have an idea on the technical debt inside the >>> system, broken down by areas if we start leveraging Packages. >>> > >>> > What I do not know is how much stress this would put on the system. >>> Are pragmas eating a lot or a just markers? >>> > >>> > Phil >>> > >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be| Web: > http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges > > -- Mariano http://marianopeck.wordpress.com

April 22, 2012

Re: [Pharo-project] Suggestion: introducing a fixme/issue/todo pragma

by StÃ©phane Ducasse

On Apr 22, 2012, at 3:53 PM, phil(a)highoctane.be wrote: > Ok. > > Looks like there is still a lot of dirty corners under the hood by looking at this list of sendersâ¦ :) and many more. Now every day we (most of the time) make progress. Stef > > Phil > > 2012/4/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Sun, Apr 22, 2012 at 11:55 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > we use self flag: #fixMe > you can then query either #fixMe or flag: > > and yes this is a good idea to mark things and create bug entries. > > Stef > > > On Apr 22, 2012, at 11:18 AM, phil(a)highoctane.be wrote: > > > While looking around in the image, I am in need of knowing where I found thngs that either puzzle me or are "wrong" (well, a code smell). > > > > What I do is that I put pragmas in there like this (not that this sample is meant to be representative) > > > > privCleanTextConstants > > <fixme> > > TextConstants TextSharedInformation removeKey: #DefaultTextStyle. > > TextConstants TextSharedInformation removeKey: #DefaultMultiStyle. > > TextConstants TextSharedInformation removeKey: #DefaultFixedTextStyle. > > TextConstants TextSharedInformation removeKey: StrikeFont defaultFontKey. > > > > Smalltalk allClasses select: [:c | c sharedPools includes: TextConstants] thenDo: [:c | c compileAll ]. > > > > And I can then find back the things with: > > > > pc := (PragmaCollector filter: [:prg | prg keyword = 'fixme']) reset. > > pc collected size. "(Print It: 1)" > > pc collected explore. > > > > And then finding back the Class and Method Name > > > > Building upon that, why not do what is done in other environments (well, I've got that in PHP, Java, ...) and use: > > > > <todo:do this and that> or plain <todo> > > <fixme: this and that> or plain <fixme> > > <issue:issue#> > > > > As Stef said, we usually use #flag: Normal cases are #flag:todo, #flag:fixMe, etc .. and the browser is aware of that and shows you a flag in the icon of the method. > > > > > And have a specific tool to help the navigation (explore is fine for a moment but...) > > > > This would allow us to have an idea on the technical debt inside the system, broken down by areas if we start leveraging Packages. > > > > What I do not know is how much stress this would put on the system. Are pragmas eating a lot or a just markers? > > > > Phil > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com > > > > > -- > Philippe Back > "Helping you hit the top 3 outcomes you really want to achieve" > > Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027 Mail: phil(a)highoctane.be | Web: http://philippeback.eu | Blog: > http://philippeback.be > > High Octane SPRL > rue cour Boisacq 101 > 1301 Bierges >

April 22, 2012