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

Re: [Pharo-project] Text Selection problem in 1.2 dev

by StÃ©phane Ducasse

Ok! Laurent can you fix profStef? Stef On Jan 31, 2011, at 6:41 PM, Alain Plantec wrote: > >>> I do not understand why but it looks really a problem with text selection > It's not a problem with text selection. > The problem is that profStef next changes the contents of the morph (with setText:). > Nothing anormal here but, while doing so it kills the editor from where the selection is evaluated. > See the portion of #evaluateSelection given below: > -------------------- > evaluateSelection > ... > result := [ > rcvr class evaluatorClass new > evaluate: self selectionForDoitAsStream > in: ctxt > to: rcvr > notifying: self <------***** the problem is here ***** > ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] > logged: true. > ] > ... > ----------------- > The receiver is passed as the requestor and it is bad because after the selection has been evaluated, > the receiver is destroyed by the #setText: and a new editor is built. > After having evaluated the selection, the compiler sends several messages to the requestor. > Then it crashes because the requestor is destroyed by the evaluation ... :) > So the solution is to set the editor morph as the requestor (which is stable), not the editor. > > Cheers > Alain > >

Jan. 31, 2011

Re: [Pharo-project] would be nice if configuration comment always contain how to load them :(

by StÃ©phane Ducasse

Why not put this comment by default in all the configurationOfXXX I spent 10 min to find how to load Profstef to check a bug and I wrote the chapter on metacello with mariano so there is something wrong. Stef > Don't forget that the aim is to have all the configurations updated to > the new symbolic version capabilities of the Metacello. > > Given that, then the standard (official) way to load (either by hand or > by tools like the browser) *any* configuration will be something similar > to: > > Gofer it "or new" > squeaksource: "MetacelloRepository"; > project: "XXX"; > load. > > ((Smalltalk globals at: #ConfigurationOfXXX) project version: #stable) > load > > This of course will be hidden from users by the existence of the > user-tools and will install the stable version tested for the image > version metacello it is running on. > > Of course it will be way to load a specific version (either because a > bug fix hunting or simply by personal preference) of a given > configuration. Something like: > > ((Smalltalk globals at: #ConfigurationOfXXX) project version: > '1.4-something') load > > But this will be only for specific users and for specific reasons. Most > users only want the stable version for its platform and metacello's > symbolic versions give them that. > > Cheers. > > > El lun, 31-01-2011 a las 17:23 +0100, Luc Fabresse escribiÃ³: >> +1 >> >> >> #Luc >> >> >> 2011/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> >> >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

Jan. 31, 2011

[Pharo-project] Smalltalk Stammtisch ZÃ¼rich Februar: 09.02.

by Philippe Marschall

Hallo, Der Stammtisch findet statt am - Mittwoch, 09.02.2011, 18h - Steinfels ZÃ¼rich , http://www.steinfels-zuerich.ch/ - http://maps.google.com/maps?ie=UTF8&q=restaurant+steinfels+z%C3%BCrich&fb=1… Wer kommen will soll sich bitte per EMail melden damit wir wissen fÃ¼r wie viele Leute wir reservieren mÃ¼ssen. Nein, es gibt keine RÃ¶sti. Philippe ============================================ Smalltalk Beer-trinking event: - Wednesday, 09.02.2011, 18h - Steinfels ZÃ¼rich , http://www.steinfels-zuerich.ch/ - http://maps.google.com/maps?ie=UTF8&q=restaurant+steinfels+z%C3%BCrich&fb=1… If you plan to attend please send a mail. No, there won't be any RÃ¶sti. Philippe

Jan. 31, 2011

Re: [Pharo-project] Hudson now Jenkins

by Philippe Marschall

On 31.01.2011 15:08, Marcus Denker wrote: > > On Jan 31, 2011, at 3:04 PM, Geert Claes wrote: > >> >> Since we are using Hudson I was wondering if anyone has been following >> Hudson's issues with Oracle at all? >> >> This is how I understand it; the creator of Hudson (Kohsuke Kawaguchi) and >> founder of infradna.com (which has now joined forces with Cloudbees - >> offering Hudson support) has had some disagreements with Oracle mainly >> regarding the ownership of the "Hudson" name. The Hudson community has >> recently voted for the project to be renamed to Jenkins, so hudson-labs.org >> is now jenkins-ci.org >> >> ps. I actually started looking at Hudson because I was baffled at the fact >> that the success icon is "blue" rather than a more intuitive "green" and >> hey, there is a plugin for that: >> http://wiki.hudson-ci.org/display/HUDSON/Green+Balls >> > Yes, but sadly the installed version of hudson is too old for this plugin. > (yes, we need to update. I will ask again) Hudson/Jenkins release once a week, pretty amazing. Cheers Philippe

Jan. 31, 2011

Re: [Pharo-project] Hudson now Jenkins

by Philippe Marschall

On 31.01.2011 15:04, Geert Claes wrote: > > Since we are using Hudson I was wondering if anyone has been following > Hudson's issues with Oracle at all? > > This is how I understand it; the creator of Hudson (Kohsuke Kawaguchi) and > founder of infradna.com (which has now joined forces with Cloudbees - > offering Hudson support) has had some disagreements with Oracle mainly > regarding the ownership of the "Hudson" name. The Hudson community has > recently voted for the project to be renamed to Jenkins, so hudson-labs.org > is now jenkins-ci.org > > ps. I actually started looking at Hudson because I was baffled at the fact > that the success icon is "blue" rather than a more intuitive "green" and > hey, there is a plugin for that: > http://wiki.hudson-ci.org/display/HUDSON/Green+Balls My understanding is that blue in Japanse culture has the same meaning as green in "western" culture. Cheers Philippe

Jan. 31, 2011

Re: [Pharo-project] About KeyBindings

by Tudor Girba

Hi Fernando, Sounds nice. I would be interested in having a bindings-per-morph solution. Cheers, Doru On 31 Jan 2011, at 16:18, Fernando Olivero wrote: > Hi, recently there were some discussion on implementing KeyBindings for our IDE. > > There are at least 3 frameworks which address this functionality, the > last one mentioned is the work done by Guillermo. > I've implemented another one, for Gaucho. > > From what i understand, the previous work focuses on implementing > GLOBAL keybindings . > Basically adding behavior to HandMorph or PasteUpMorph or the toolbar > ( docking bar) present in the World. > > My implementation is a generic keybinding for any Morph, which can be > applied to any morph. Special cases for the docking bar or the paste > up Morph can be easily implemented following this uniform scheme. > > I didn't have the time to integrate it into Pharo yet, but will do in > one week from now. > > I like to bring up the discussion on which one we should adopt and > integrate into Morphic, points in favor of my approach: > 1) clean > 2) customizable > 3) generic: no special cases > > I believe the other Global keybindings should be a subset of this > generic keybinding mechanism. > > Fernando > > pd: From a previous mail: > > "... > So for example, if you want to delete any Morph from the system > by pressing cmd-w, you have to add the following binding: > > condition := GMCondition > compositeWith: > #( #understandsKeyBindingCommandCondition > #uneditedCondition ) ). > binding := GMKeyBinding > actingOn: $w asciiValue > modifiedBy: #(#command) > satisfying: condition > applying: #close. > m := Morph new. > m addKeyBinding: binding . > ... > " > > pd2: Useful and related comment from Stef > ".. > A classVar Binding and an instance var binding. > **All** the methods only access binding > binding get initialized with the default table defined in Binding > => we can have table binding sharing > => we can have instance based customization. > -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Jan. 31, 2011

Re: [Pharo-project] TODO 1.2

by Lukas Renggli

> Can I suggest that we really remove the non show stopper? > and I'm sorry but we cannot maintain packages we do not know. > > Lukas could you integrate the fix I did for OB? I suggest that you publish the changes to your own repository. I would like to keep the code in http://source.lukas-renggli.ch/omnibrowser/ working in Pharo 1.1. I started to fix several of the tools for Pharo 1.2 in http://source.lukas-renggli.ch/pharo12, but there is so much broken that I run out of time :-( Lukas -- Lukas Renggli www.lukas-renggli.ch

Jan. 31, 2011

Re: [Pharo-project] About KeyBindings

by Denis Kudriashov

Hello, very interesting work. Can you provide some description? What is GMCondition? What is #compositeWith: , #modifiedWith:? Best regards, Denis 2011/1/31 Fernando Olivero <fernando.olivero(a)usi.ch> > Hi, recently there were some discussion on implementing KeyBindings for our > IDE. > > There are at least 3 frameworks which address this functionality, the > last one mentioned is the work done by Guillermo. > I've implemented another one, for Gaucho. > > From what i understand, the previous work focuses on implementing > GLOBAL keybindings . > Basically adding behavior to HandMorph or PasteUpMorph or the toolbar > ( docking bar) present in the World. > > My implementation is a generic keybinding for any Morph, which can be > applied to any morph. Special cases for the docking bar or the paste > up Morph can be easily implemented following this uniform scheme. > > I didn't have the time to integrate it into Pharo yet, but will do in > one week from now. > > I like to bring up the discussion on which one we should adopt and > integrate into Morphic, points in favor of my approach: > 1) clean > 2) customizable > 3) generic: no special cases > > I believe the other Global keybindings should be a subset of this > generic keybinding mechanism. > > Fernando > > pd: From a previous mail: > > "... > So for example, if you want to delete any Morph from the system > by pressing cmd-w, you have to add the following binding: > > condition := GMCondition > compositeWith: > #( #understandsKeyBindingCommandCondition > #uneditedCondition ) ). > binding := GMKeyBinding > actingOn: $w asciiValue > modifiedBy: #(#command) > satisfying: condition > applying: #close. > m := Morph new. > m addKeyBinding: binding . > ... > " > > pd2: Useful and related comment from Stef > ".. > A classVar Binding and an instance var binding. > **All** the methods only access binding > binding get initialized with the default table defined in Binding > => we can have table binding sharing > => we can have instance based customization. > >

Jan. 31, 2011

Re: [Pharo-project] Text Selection problem in 1.2 dev

by Alain Plantec

>> I do not understand why but it looks really a problem with text selection It's not a problem with text selection. The problem is that profStef next changes the contents of the morph (with setText:). Nothing anormal here but, while doing so it kills the editor from where the selection is evaluated. See the portion of #evaluateSelection given below: -------------------- evaluateSelection ... result := [ rcvr class evaluatorClass new evaluate: self selectionForDoitAsStream in: ctxt to: rcvr notifying: self <------***** the problem is here ***** ifFail: [FakeClassPool adopt: nil. ^ #failedDoit] logged: true. ] ... ----------------- The receiver is passed as the requestor and it is bad because after the selection has been evaluated, the receiver is destroyed by the #setText: and a new editor is built. After having evaluated the selection, the compiler sends several messages to the requestor. Then it crashes because the requestor is destroyed by the evaluation ... :) So the solution is to set the editor morph as the requestor (which is stable), not the editor. Cheers Alain

Jan. 31, 2011

Re: [Pharo-project] Text Selection problem in 1.2 dev

by Alain Plantec

yes, it doesn't work because the fix has been overwritten with old code. I think that only SmalltalkEditor>>#evaluateSelection has been touched. Just browse this method, then open versions and set #evaluateSelection back to its previous version (12/21/2010). Le 31/01/2011 17:17, StÃ©phane Ducasse a Ã©crit : > Alain in > 13033 > > Gofer > ... metacelloRepository > > > (ConfigurationOfProfStef project version: '1.6') load. > > ProfStef go > > > > >> It seems to me that it has already been reported and fixed a time ago. >> see http://code.google.com/p/pharo/issues/detail?id=3472 >> take >> >> SLICE-Issue-3472-Text-selection-problem-in-Pharo-dev-12 and >> SLICE-Issue-3472-Text-selection-problem-in-Pharo-dev-12-Part-2 >> >> Cheers >> Alain >> >> Le 31/01/2011 14:23, StÃ©phane Ducasse a Ã©crit : >>> hi guys >>> >>> in 1.2 dev when I play with ProfStef go I get an error after a couple of screens normally 3. >>> >>> I do not understand why but it looks really a problem with text selection >>> >>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/ >>> >>> Stef >>> >>> >>> >> > >

Jan. 31, 2011