- Pharo-dev - lists.pharo.org

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

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

by phil＠highoctane.be

Ok. Looks like there is still a lot of dirty corners under the hood by looking at this list of senders... 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

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

by phil＠highoctane.be

Ok, got it. >From http://java.ociweb.com/mark/programming/Smalltalk.html Comments Comments are surrounded by double quotes and can span multiple lines. To add "todo" comments that can be easily found later, enter "self flag: #todo." followed by a regular comment which can be on the same line. To find all occurrences of that, select "todo" and press alt-n which displays all the senders of #todo in a new window. In OmniBrowser<http://java.ociweb.com/mark/programming/Smalltalk.html#OmniBrowser>, methods containing those have a wrench icon in front of them in the method plane. 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

Re: [Pharo-project] probably modal problem

by StÃ©phane Ducasse

Apparently something got corrupted in my system, because I cannot reproducing it in a freshly downloaded image. :( On Apr 21, 2012, at 11:24 PM, StÃ©phane Ducasse wrote: > Hi guys > > when I open 1.4 and > I use the default browser > edit a method then do not accept it > click on another method. > I get prompt > (method promptForCancel) and the discard or accept do not work. > > I think that there is a problem with exception or something like that. > Apparently the method > confirm: 'Code has been modified.\What do you want to do?' translated withCRs > trueChoice: 'Accept' translated > falseChoice: 'Discard' translated > cancelChoice: 'Cancel' translated > default: nil. > > never returns > it seems that findContextSuchThat: is sent to nil. > > I tried to understand if this is related to the introduction of a breakpoint in the method but I do not think so. > > > > calleeOf: aContext > "Return the context whose sender is aContext. Return nil if aContext is on top. Raise error if aContext is not in process chain." > > suspendedContext == aContext ifTrue: [^ nil]. > ^ (suspendedContext findContextSuchThat: [:c | c sender == aContext]) > ifNil: [self error: 'aContext not in process chain'] > > > promptForCancel > "Ask for the appropriate action to take when unaccepted contents > would be overwritten." > > | choice | > choice := ( UIManager default > confirm: 'Code has been modified.\What do you want to do?' translated withCRs > trueChoice: 'Accept' translated > falseChoice: 'Discard' translated > cancelChoice: 'Cancel' translated > default: nil ). > choice ifNotNil: [ > choice > ifTrue: [ self accept ] > ifFalse: [ self model clearUserEditFlag ]] > > => > > confirm: queryString trueChoice: trueChoice falseChoice: falseChoice cancelChoice: cancelChoice default: defaultOption > "Put up a yes/no/cancel menu with caption queryString. The actual wording for the choices will be as provided in the trueChoice, falseChoice and cancelChoice parameters. > defaultOption should be one of true, false or nil to set the default button. > Answer true if the response is the true-choice, false if it's the false-choice, nil if the cancelChoice. > This is a modal question -- the user must respond." > > (ProvideAnswerNotification signal: queryString) ifNotNil: [:answer | > ^answer]. > ^ self theme > customQuestionIn: self modalMorph > text: queryString > yesText: trueChoice > noText: falseChoice > cancelText: cancelChoice > default: defaultOption > title: 'Question' translated > > Stef

April 22, 2012

Re: [Pharo-project] Kernel jobs for 2.0

by Pavel Krivanek

On Sun, Apr 22, 2012 at 2:15 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 22, 2012, at 12:47 PM, Pavel Krivanek wrote: > >> Hi, >> >> I created Kernel jobs for the version 2.0. It uses separate set of >> scripts so new big changes will not break 1.4. >> https://ci.lille.inria.fr/pharo/view/Pharo-Kernel%202.0/ >> >> Now is pointless to run them because 2.0 repository doesn't include >> all packages. Some things that should be done: >> - start Trello board for 2.0 ;-) > > Done: https://trello.com/board/pharo-2-0/4f7ae7371d239ca86263c96f Please add me as the member (pavel.krivanek(a)gmail.com) -- Pavel > >> - the package Deprecated 14 should be replaced by Deprecated20. >> - integrate basic Fuel packages (Fuel, FuelMetalevel, FuelPackageLoader + tests) >> >> -- Pavel >> > > -- > Marcus Denker -- http://marcusdenker.de > >

April 22, 2012