Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
2011/2/1 Marcus Denker marcus.den...@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.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On Feb 1, 2011, at 8:58 37AM, Nicolas Cellier wrote: 2011/2/1 Marcus Denker marcus.den...@inria.fr: On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: 2011/2/1 Marcus Denker marcus.den...@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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ 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 #perform:withArguments: works in Pharo as well, Igor's fix for it was applied back in May: http://code.google.com/p/pharo/issues/detail?id=2443 What it doesn't fix (and which the test in 3468 highlights), are arbitrary sends to #perform: withArguments: inSuperclass: (Ie. the compiler does not expand frame size of all senders, nor does the test run on a VM which does not error with many arguments) #perform:withArguments: just happend to be the most likely sender to run into it. Cheers, Henry
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On 1 February 2011 01:47, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Frankly, i had the opposite impression. For instance, Sets with nil already have more than year in Squeak, but still didn't found their way into Pharo. 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 i was proposed this fix for squeak and pharo both, months before, because NativeBoost were dependent on that to work correctly, because it was heavily exploiting #perform: primitive for retrying the same method after first invocation when there was no native code generated yet, and primitive failed because of that. But i weren't able to force it to be made into both forks.. because certainly i was busy with other stuff, so instead of pushing fix to both forks, i just made a changeset and put it into NB site. In that way i made sure, that no matter if fix is integrated or not, NB works :) 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. I think an upcoming Ring (yeah , to rule them all) or Torch? project will help addressing this issue. But i can't shed light details on it, because i don't know.. 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. I am one, who would certainly be happy too, to see a interchange between Pharo and Squeak to be easy. I can only say, that this is because two camps using different development process.. and not because of some intentionally political attitude. Nicolas, i encourage you (and others) to come up with initiative, to establish a process , or write down rules/guidelines, how to cherrypick the code between forks. This would help to both camps, so its worth to do. Nicolas -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On 1 February 2011 08:01, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: 2011/2/1 Marcus Denker marcus.den...@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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ This is probably because you must (Object recompile: #perform:withArguments:) there is no way to fix that without altering VM itself. This test actually shows that there is issue on VM side which needs to be adressed (but in Cog it works ok). Nicolas -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On 1 February 2011 08:05, Marcus Denker marcus.den...@inria.fr wrote: 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. +1 Strict rules work mostly for pedantic people.. Not many of us having this trait. And for impulsive people like me, who is chaotic pedant its not always good, because boring stuff drains my energy quite fast :) We are not perfect and so, we should embrace that :) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On Tue, 1 Feb 2011, Igor Stasenko wrote: On 1 February 2011 01:47, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Frankly, i had the opposite impression. For instance, Sets with nil already have more than year in Squeak, but still didn't found their way into Pharo. This not related to what Nicolas wrote. He wrote that a lot more patches go from Squeak to Pharo, than from Pharo to Squeak. The latter is close to zero, while the first is between 300 and 800 (based on the Pharo issue tracker. 400-900 including the non-closed issues). So I wonder why did you have the opposite impression. Levente snip
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On 1 February 2011 15:44, Levente Uzonyi le...@elte.hu wrote: On Tue, 1 Feb 2011, Igor Stasenko wrote: On 1 February 2011 01:47, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Frankly, i had the opposite impression. For instance, Sets with nil already have more than year in Squeak, but still didn't found their way into Pharo. This not related to what Nicolas wrote. He wrote that a lot more patches go from Squeak to Pharo, than from Pharo to Squeak. The latter is close to zero, while the first is between 300 and 800 (based on the Pharo issue tracker. 400-900 including the non-closed issues). So I wonder why did you have the opposite impression. I doubt that Squeak wants to integrate Etoys cleanup :). Squeak community are much more conservative towards major refactorings/changing APIs etc etc. And given that most major changes in Pharo are for either throwing out some old stuff or do complete rewrite, this gives an answer why you don't see changes flowing widely from Pharo to Squeak. As for minor level changes, or kernel/compiler changes - we are in sync .. because both camps paying attention in keeping core in healthy state. But you should know it yourself, because you are taking part in that. :) Levente snip -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On Tue, 1 Feb 2011, Igor Stasenko wrote: On 1 February 2011 15:44, Levente Uzonyi le...@elte.hu wrote: On Tue, 1 Feb 2011, Igor Stasenko wrote: On 1 February 2011 01:47, Nicolas Cellier nicolas.cellier.aka.n...@gmail.com wrote: The fact is that, while many patches find their way from Squeak to Pharo, very few take the other way. Frankly, i had the opposite impression. For instance, Sets with nil already have more than year in Squeak, but still didn't found their way into Pharo. This not related to what Nicolas wrote. He wrote that a lot more patches go from Squeak to Pharo, than from Pharo to Squeak. The latter is close to zero, while the first is between 300 and 800 (based on the Pharo issue tracker. 400-900 including the non-closed issues). So I wonder why did you have the opposite impression. I doubt that Squeak wants to integrate Etoys cleanup :). Squeak community are much more conservative towards major refactorings/changing APIs etc etc. And given that most major changes in Pharo are for either throwing out some old stuff or do complete rewrite, this gives an answer why you don't see changes flowing widely from Pharo to Squeak. This doesn't anwser at all why you had the impression that more Pharo changes are going to Squeak, than the other way. On the contrary it demonstrates why you think Pharo changes don't get integrated into Squeak. As for minor level changes, or kernel/compiler changes - we are in sync .. because both camps paying attention in keeping core in healthy state. But you should know it yourself, because you are taking part in that. :) No, we are not in sync and it's hard to tell all the differences. Just try to load a package developed for Pharo into Squeak and you'll see how much fixes you have to do to make it work. Or just try to maintain a package for both platforms. Levente Levente snip -- Best regards, Igor Stasenko AKA sig.
[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
2011/2/1 Marcus Denker marcus.den...@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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ This is probably because you must (Object recompile: #perform:withArguments:) Nicolas -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: 2011/2/1 Marcus Denker marcus.den...@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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ 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.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ This is probably because you must (Object recompile: #perform:withArguments:) Nicolas
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ This is probably because you must (Object recompile: #perform:withArguments:) Nicolas -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
2011/2/1 Stéphane Ducasse stephane.duca...@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
Re: [Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
2011/2/1 Marcus Denker marcus.den...@inria.fr: On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote: 2011/2/1 Marcus Denker marcus.den...@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/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/ 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
