- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by StÃ©phane Ducasse

The diff algorithm of mc is good. Now miguel we can talk about that. It will not happen if nobody build it for real. Sorry to be a pain in the ass but this is reality. When something works (because it works - look at Moose) then you need a lot of effort to move to the next level. Stef > Do you think that a trunk process like the Squeak one would be good for > Pharo? Any improvement to introduce in the process? Any drawback to > remove? > > In the end the process is dictated by the underlying tools (MC and > squeaksource in this case). What kind of process of > patching/contributing would we have if tools like git and infrastructure > like github were available to Pharo/Squeak users/developers just as easy > like they are for any other open source project? > > Many of the problems are products of the way that MC, Squeaksource, > Squeak/Pharo changesets, author/contributor attribution works in the > Squeak/Pharo world. Maybe the problem isn't the process but the current > tools. Maybe a profound solution is the only way to escape the tortuous > process we have? > > Cheers > > El mar, 01-02-2011 a las 01:47 +0100, Nicolas Cellier escribiÃ³: >> The fact is that, while many patches find their way from Squeak to >> Pharo, very few take the other way. >> >> Why is that ? >> - squeak people are sobing pharoers >> - squeak people are too few to achieve this task >> - there is nothing interesting happening in Pharo >> No no, please don't answer, I innoculate this bullshit intentionnally >> to vaccine this thread against further crap. >> >> What IMO is the main explanation is this: >> - it's very easy to cherry pick squeak changes thanks to trunk: diff >> messages, while there is nothing equivalent in Pharo. >> >> Just browsing Squeak/Pharo diffs, it's easy to recognize text >> copy/pasted via web with tabs changed in spaces. >> Also the pharo issue tracker is full of these. >> This gives some clues. >> >> This is a very good thing that patches can be shared. But why not the >> other way around ? >> This is surprising because: >> - 1) Pharo is very active these days. >> - 2) Pharo was apparently setting a higher quality hurdle by forcing >> each modification to be traced >> ( http://code.google.com/p/pharo/issues ) >> So we could have expected more fixes coming from Pharo. >> >> Maybe it's because the process only have appearances of quality, but >> doesn't really pay off. >> Maybe I had some bad luck with >> http://code.google.com/p/pharo/issues/detail?id=3468 >> Or is there many examples of issues closed without a clue ? >> Imagine you can recognize the symptoms of this bug in Pharo 1.1 and >> want to backport the patch... >> I'm interested to hear how to proceed. >> >> The simple squeak trunk diff messages are not a panacea. >> A database of changes in all flavours of Squeak might help better. >> But it's very practicle and I wish I could see an equivalent in Pharo. >> >> On the other end, I was finally forced to filter out the automated >> [Pharo-Issues] posts. >> The signal/noise ratio is far too low to sustain attention, though I >> for one care about patches. >> >> I wish my criticism could bring introspection, better and - why not - >> squeak friendly :) practices. >> >> Nicolas >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

Feb. 1, 2011

Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Miguel CobÃ¡

Do you think that a trunk process like the Squeak one would be good for Pharo? Any improvement to introduce in the process? Any drawback to remove? In the end the process is dictated by the underlying tools (MC and squeaksource in this case). What kind of process of patching/contributing would we have if tools like git and infrastructure like github were available to Pharo/Squeak users/developers just as easy like they are for any other open source project? Many of the problems are products of the way that MC, Squeaksource, Squeak/Pharo changesets, author/contributor attribution works in the Squeak/Pharo world. Maybe the problem isn't the process but the current tools. Maybe a profound solution is the only way to escape the tortuous process we have? Cheers El mar, 01-02-2011 a las 01:47 +0100, Nicolas Cellier escribiÃ³: > The fact is that, while many patches find their way from Squeak to > Pharo, very few take the other way. > > Why is that ? > - squeak people are sobing pharoers > - squeak people are too few to achieve this task > - there is nothing interesting happening in Pharo > No no, please don't answer, I innoculate this bullshit intentionnally > to vaccine this thread against further crap. > > What IMO is the main explanation is this: > - it's very easy to cherry pick squeak changes thanks to trunk: diff > messages, while there is nothing equivalent in Pharo. > > Just browsing Squeak/Pharo diffs, it's easy to recognize text > copy/pasted via web with tabs changed in spaces. > Also the pharo issue tracker is full of these. > This gives some clues. > > This is a very good thing that patches can be shared. But why not the > other way around ? > This is surprising because: > - 1) Pharo is very active these days. > - 2) Pharo was apparently setting a higher quality hurdle by forcing > each modification to be traced > ( http://code.google.com/p/pharo/issues ) > So we could have expected more fixes coming from Pharo. > > Maybe it's because the process only have appearances of quality, but > doesn't really pay off. > Maybe I had some bad luck with > http://code.google.com/p/pharo/issues/detail?id=3468 > Or is there many examples of issues closed without a clue ? > Imagine you can recognize the symptoms of this bug in Pharo 1.1 and > want to backport the patch... > I'm interested to hear how to proceed. > > The simple squeak trunk diff messages are not a panacea. > A database of changes in all flavours of Squeak might help better. > But it's very practicle and I wish I could see an equivalent in Pharo. > > On the other end, I was finally forced to filter out the automated > [Pharo-Issues] posts. > The signal/noise ratio is far too low to sustain attention, though I > for one care about patches. > > I wish my criticism could bring introspection, better and - why not - > squeak friendly :) practices. > > Nicolas > -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Feb. 1, 2011

Re: [Pharo-project] About KeyBindings

by StÃ©phane Ducasse

On Jan 31, 2011, at 10:26 PM, Fernando Olivero wrote: > Stef: Yes! as soon as i'm finished with a paper (till next week) i > will work on integrating the functionality into the latest Pharo. > And publish it as a slice perhaps? In Morphic-Keybindings ? ok good luck for ICPC :) I cross my fingers for you. > Dennis: GMCondition (GauchoMorphic = GM ) are preconditions that must > be satisfied for the key binding to be applied. In case they aren't > satisfied, an rejected event is recorded, specifying the violated > conditions. For example, you might want to restrict that a particular > morph can only be closed ( cmd-w in the example above) if its selected > (selected condition). I found it useful for customizing the Gaucho > interface to a particular set of interaction rules. > > Fernando >

Feb. 1, 2011

Re: [Pharo-project] how to use dejavu bitmap fonts

by StÃ©phane Ducasse

> >> The package should be updated to 1.2. >> >> It should declare fonts probably in one of the classVar of the TextConstant SharedPool. >> Probably >> TextSharedInformation have a look. >> >> In 1.2 we cleaned the last global poolvar = textConstant which was used as a pool but also as a repository to plug anything inside >> instead of specific classVariable in adequate classes. It was a good plate of spaghettis code. >> >> I know that benjamin wants to take some times to do another pass and move the left over to the class they belongs to but it will >> take some time. >> >> Stef >> > > Nice effort to clean this up. > Among the so called "Constants", I remember browsing one recently : > (TextConstants at: #pixelsPerInch). > Uh, this one should be device dependent, shouldn't it ? > > No, 96 seems the only figures written in the stone, and you'll hardly > find any other thing but this default value in a Squeak image. > Moreover, if you analyze Squeak code, you'll see some hardcoded 96 DPI > here and there. > Hope Pharo will give a kick in the anthill (literal translation of a > french saying). Join and help. There are a lot of things that are like that. > > Nicolas >

Feb. 1, 2011

[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

by Nicolas Cellier

The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Why is that ? - squeak people are sobing pharoers - squeak people are too few to achieve this task - there is nothing interesting happening in Pharo No no, please don't answer, I innoculate this bullshit intentionnally to vaccine this thread against further crap. What IMO is the main explanation is this: - it's very easy to cherry pick squeak changes thanks to trunk: diff messages, while there is nothing equivalent in Pharo. Just browsing Squeak/Pharo diffs, it's easy to recognize text copy/pasted via web with tabs changed in spaces. Also the pharo issue tracker is full of these. This gives some clues. This is a very good thing that patches can be shared. But why not the other way around ? This is surprising because: - 1) Pharo is very active these days. - 2) Pharo was apparently setting a higher quality hurdle by forcing each modification to be traced ( http://code.google.com/p/pharo/issues ) So we could have expected more fixes coming from Pharo. Maybe it's because the process only have appearances of quality, but doesn't really pay off. Maybe I had some bad luck with http://code.google.com/p/pharo/issues/detail?id=3468 Or is there many examples of issues closed without a clue ? Imagine you can recognize the symptoms of this bug in Pharo 1.1 and want to backport the patch... I'm interested to hear how to proceed. The simple squeak trunk diff messages are not a panacea. A database of changes in all flavours of Squeak might help better. But it's very practicle and I wish I could see an equivalent in Pharo. On the other end, I was finally forced to filter out the automated [Pharo-Issues] posts. The signal/noise ratio is far too low to sustain attention, though I for one care about patches. I wish my criticism could bring introspection, better and - why not - squeak friendly :) practices. Nicolas

Feb. 1, 2011

Re: [Pharo-project] Hudson now Jenkins

by Igor Stasenko

On 31 January 2011 23:04, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > I think it is intentional strategy for Pharo to temporarily break > things as it is seen as the fastest way to perform large/deep > refactorings. > Squeak strategy is much more conservative, and the process is near > continuous integration... but of course refactorings are more > superficials. > That's the price to pay. I like the difference. Pharo younger so, its not a surprise that its more agile. > > Nicolas > > 2011/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> >>> Hudson/Jenkins release once a week, pretty amazing. >> >> Well I'm sure that it makes sense but this is their problem. >> For Pharo1.3 we want to be able to release after any green build. >> We want to make sure that all the process is fluid so that we do not have any stress about releasing. >> Now we will release 2 or 3 times a year maximum. >> >> Stef >> > > -- Best regards, Igor Stasenko AKA sig.

Jan. 31, 2011

Re: [Pharo-project] About KeyBindings

by Guillermo Polito

Keymapping is very close to it, but is has a few differences: - shortcuts are organized in categories - categories are attached to Morphs (to classes, not to instances) - every instance of the morphs who has attached the category, uses its shortcuts. Now I'm a little busy and stuck with Keymapping UI, but I expect to have something working in the near future too :). Guille On Mon, Jan 31, 2011 at 6:26 PM, Fernando Olivero <fernando.olivero(a)usi.ch>wrote: > Stef: Yes! as soon as i'm finished with a paper (till next week) i > will work on integrating the functionality into the latest Pharo. > And publish it as a slice perhaps? In Morphic-Keybindings ? > > Dennis: GMCondition (GauchoMorphic = GM ) are preconditions that must > be satisfied for the key binding to be applied. In case they aren't > satisfied, an rejected event is recorded, specifying the violatedMmm, > conditions. For example, you might want to restrict that a particular > morph can only be closed ( cmd-w in the example above) if its selected > (selected condition). I found it useful for customizing the Gaucho > interface to a particular set of interaction rules. > > Fernando > > On Mon, Jan 31, 2011 at 7:59 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > > I have the impression that Guillermo work is not the same as > GlobalKeyBinding but I may be wrong > > Anyway fernando could I have a look at your code? > > Because I really want that. > > > > Stef > > > > On Jan 31, 2011, at 4:18 PM, 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. > >> > > > > > >

Jan. 31, 2011

Re: [Pharo-project] pharo.st should be a permanent domain, I think

by Igor Stasenko

On 31 January 2011 22:42, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > ok, ok... I'm a minority :P > I retire my proposition. > :) To change a name there should be a serious reasons. I felt in love with Squeak because i like the project and people and overall spirit, not because of its name (i admit i never liked it). Names could serve you a bad service if you change them often for no strong reason. > best, > Esteban > > > El 31/01/2011, a las 6:36p.m., Tudor Girba escribiÃ³: > >> +1 >> >> Doru >> >> >> On 31 Jan 2011, at 22:24, Alexandre Bergel wrote: >> >>> I agree with Adrian >>> >>> Alexandre >>> >>> >>> >>> Le 31 janv. 2011 Ã 15:31, Adrian Lienhard <adi(a)netstyle.ch> a Ã©crit : >>> >>>> -1 >>>> >>>> ...because in my opinion there should be exactly one main domain name. The additional names should just redirect to this one. Of course we could discuss whether pharo.st should be that main domain. But (already quite long time ago) we decided to go for pharo-project.org. I still think that is the better name, in particular for people who don't know what the meaning of .st is. I think they are less likely to klick on www.pharo.st in a search engine than on www.pharo-project.org. >>>> >>>> Cheers, >>>> Adrian >>>> >>>> On Jan 31, 2011, at 21:15 , Diogenes Moreira wrote: >>>> >>>>> Always ready. as a boy scout.. only send me de ssh conxion... >>>>> >>>>> >>>>> On Mon, Jan 31, 2011 at 5:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >>>>> >>>>>> Hi, >>>>>> I tried pharo.st to reach pharo. I liked. It's small, concise, beautiful >>>>>> (and it has a .st!) >>>>>> One problem is that as soon as you type pharo.st, you loose the url. I >>>>>> would like to stay in the url I entered to pharo-project. I think this is >>>>>> easily doable with an apache configuration. >>>>>> I'm not an apache guy, but I'm sure if there are some problem with this, >>>>>> and all of you agree this is desirable, someone from the list (cough, cough, >>>>>> DiÃ³genes, cough, cough) can do the job :) >>>>>> >>>>>> Cheers, >>>>>> Esteban >>>>>> >>>> >>>> >>> >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> > > > -- Best regards, Igor Stasenko AKA sig.

Jan. 31, 2011

Re: [Pharo-project] how to use dejavu bitmap fonts

by Nicolas Cellier

2011/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > The package should be updated to 1.2. > > It should declare fonts probably in one of the classVar of the TextConstant SharedPool. > Probably > Â Â Â Â TextSharedInformation have a look. > > In 1.2 we cleaned the last global poolvar = textConstant which was used as a pool but also as a repository to plug anything inside > instead of specific classVariable in adequate classes. It was a good plate of spaghettis code. > > I know that benjamin wants to take some times to do another pass and move the left over to the class they belongs to but it will > take some time. > > Stef > Nice effort to clean this up. Among the so called "Constants", I remember browsing one recently : (TextConstants at: #pixelsPerInch). Uh, this one should be device dependent, shouldn't it ? No, 96 seems the only figures written in the stone, and you'll hardly find any other thing but this default value in a Squeak image. Moreover, if you analyze Squeak code, you'll see some hardcoded 96 DPI here and there. Hope Pharo will give a kick in the anthill (literal translation of a french saying). Nicolas

Jan. 31, 2011

Re: [Pharo-project] Hudson now Jenkins

by Nicolas Cellier

I think it is intentional strategy for Pharo to temporarily break things as it is seen as the fastest way to perform large/deep refactorings. Squeak strategy is much more conservative, and the process is near continuous integration... but of course refactorings are more superficials. That's the price to pay. Nicolas 2011/1/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >> Hudson/Jenkins release once a week, pretty amazing. > > Well I'm sure that it makes sense but this is their problem. > For Pharo1.3 we want to be able to release after any green build. > We want to make sure that all the process is fluid so that we do not have any stress about releasing. > Now we will release 2 or 3 times a year maximum. > > Stef >

Jan. 31, 2011