- Pharo-dev - lists.pharo.org

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

by Adrian Lienhard

On Feb 1, 2011, at 08:57 , Nicolas Cellier wrote: > I understand that logging diffs of the entire squeaksource repository > is a no go, but there must be another way. > You have automated tests which is a real progress, so I don't see why > simple diffs would be so high a technical problem. I (and likely most others) would love to see diffs. So the question really is a technical one. Could we do diffs locally in the integrator image when he commits a new update to the Pharo repository? MC implements that and we are using it here at Cmsbox. You get a diff mail for each committed package. The diff and mail is created in your local machine. Has that been considered before? Cheers, Adrian

Feb. 1, 2011

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

by Nicolas Cellier

2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 1, 2011, at 7:04 AM, StÃ©phane Ducasse wrote: > >> 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. > > > Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people > said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* > and they should be done more often, but as soon as you require them, nothing will happen. > > The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not > be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict > rule is adopted. > > Strict rules kills human processes. > > Â Â Â Â Marcus > I can only agree with this, the spirit of the rule matters, the letters don't. If the burden become inhuman, change the rules. Nicolas > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Feb. 1, 2011

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

by Nicolas Cellier

2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: > > On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: > >> 2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: >>>> >>>> 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 ? >>> >>> In a case like that, the changeset was just merged in the release. >>> >>> The test is failing, as you can see: >>> >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >>> >>> >> >> This is probably because you must >> Â Â (Object recompile: #perform:withArguments:) >> > > The 1.3 core image was recompiled completely around 13020... > > Â Â Â Â Marcus > > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > Strange, the change worked for me in Squeak once I recompiled. Nicolas

Feb. 1, 2011

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

by Nicolas Cellier

2011/2/1 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > 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. > Sure, I don't want to discuss the goals. I just wonder if the burden of maintaining these logs is usefull for Pharo. What makes me wonder is that I consider it is not usefull for backporting some changes to Squeak. I understand that logging diffs of the entire squeaksource repository is a no go, but there must be another way. You have automated tests which is a real progress, so I don't see why simple diffs would be so high a technical problem. Nicolas > 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 Marcus Denker

On Feb 1, 2011, at 8:13 AM, StÃ©phane Ducasse wrote: > Tx nicolas > >>>> >>> In a case like that, the changeset was just merged in the release. > > Marcus I thought that there was another fix. No, there was no fix. > May be it was already integrated. No, else the test would not fail > we wrote the test to make sure that > the behavior is documented. > >>> >>> The test is failing, as you can see: >>> >>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >>> >>> >> >> This is probably because you must >> (Object recompile: #perform:withArguments:) >> >> Nicolas > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 1, 2011

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

by StÃ©phane Ducasse

Tx nicolas >>> >> In a case like that, the changeset was just merged in the release. Marcus I thought that there was another fix. May be it was already integrated. we wrote the test to make sure that the behavior is documented. >> >> The test is failing, as you can see: >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >> >> > > This is probably because you must > (Object recompile: #perform:withArguments:) > > Nicolas

Feb. 1, 2011

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

by Marcus Denker

On Feb 1, 2011, at 7:04 AM, StÃ©phane Ducasse wrote: > 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. Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice* and they should be done more often, but as soon as you require them, nothing will happen. The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict rule is adopted. Strict rules kills human processes. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 1, 2011

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

by Marcus Denker

On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: > 2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> 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 ? >> >> In a case like that, the changeset was just merged in the release. >> >> The test is failing, as you can see: >> >> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >> >> > > This is probably because you must > (Object recompile: #perform:withArguments:) > The 1.3 core image was recompiled completely around 13020... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 1, 2011

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

by Nicolas Cellier

2011/2/1 Marcus Denker <marcus.denker(a)inria.fr>: >> >> 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 ? > > In a case like that, the changeset was just merged in the release. > > The test is failing, as you can see: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… > > This is probably because you must (Object recompile: #perform:withArguments:) Nicolas > > -- > Marcus Denker Â -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > >

Feb. 1, 2011

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

by StÃ©phane Ducasse

Ok so we should fix it. >> In a case like that, the changeset was just merged in the release. > > The test is failing, as you can see: > > https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompleted… >

Feb. 1, 2011