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

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

by StÃ©phane Ducasse

Nicolas We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is years that we passed it. > Maybe it's because the process only have appearances of quality, but > doesn't really pay off. Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life. Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server is subject to missing some parts. But this is life. Now let me repeat myself again: Pharo is important because I want people to find/build jobs in Smalltalk and not in Ruby or Javascript. Simple/straight/may be it will not succeed but this is my goal. Else I would do Javascript or Lua. In fact I thought a lot of Lua, python or ruby for a while - before doing pharo because of the state of our 'nice' community and its lack of vision. I'm sure that other communities are pleasant too and may be I'm stuck in Smalltalk. Stef

Feb. 1, 2011

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