Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly
Hi! Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of): self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error I have to shut down the method #validateShouldntException: Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion. On 2013-10-21, at 23:42, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
I have to shut down the method #validateShouldntException:
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Instead of using shouldnt:raise:, you can simply remove the assertion, as in: -=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-= || V -=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-= With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure. I read your post and I kind of agree. I will fix my tests then. Alexandre On Oct 22, 2013, at 12:08 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
On 2013-10-21, at 23:42, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
I have to shut down the method #validateShouldntException:
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 2013-10-22, at 00:20, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-=
|| V
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-=
With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed. Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else.
I read your post and I kind of agree. I will fix my tests then.
nice :)
In Seaside, there are a couple of tests that now fail because of this change. Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho. I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause. Johan On 22 Oct 2013, at 00:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 00:20, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-=
|| V
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-=
With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed.
Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else.
I read your post and I kind of agree. I will fix my tests then.
nice :)
On 2013-10-22, at 09:46, Johan Brichau <johan@inceptive.be> wrote:
In Seaside, there are a couple of tests that now fail because of this change.
Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho.
That's not true, that is the default behavior that you test for not Errors. I mean every code that is run must work and testing that it does not raise and Error is duplicated efforts. As I said, checking for any other error makes somehow sense, but not for Error itself. Because that basically means that you ignore what the test does since you are not specific at all. The test framework takes already care of that part, if you have an error the test fails. I think that is the goal. I do not understand why you would have to explain this to the user of the tests, since for him the result does not change. Yes it is red instead of yellow, but does that matter? I mean you just transformed at will an error into an assertion failure, to me this sounds very bogus. Just because you transform the error to an assertion, you did not anticipated anything, since you cannot be sure at all where the error happened, since you do not test for an explicit error. On the other hand if you call a method that is very small to check if it really works, you know which errors are signaled and you test explicitly for those. I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error to a refactored version that even includes a comment.
I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause.
But if you just use the expression directly, the debugger pops up in the place where the error was signaled. Not somewhere in deep in the assertion framework. Furthermore if you run the test under jenkins you will get no reasonable feedback (yes this should be changed as well). Just try to debug the following statement in a test: self shouldnt: [ 0/0 ] raise: Error vs. 0/0. Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error.
Johan
On 22 Oct 2013, at 00:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 00:20, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Instead of using shouldnt:raise:, you can simply remove the assertion, as in:
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-=
|| V
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-=
With the second version of the test, the test may be listed as an error in case of an exception, whereas the first version it can only be listed as a failure.
Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed.
Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else.
I read your post and I kind of agree. I will fix my tests then.
nice :)
On 22 October 2013 10:02, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 09:46, Johan Brichau <johan@inceptive.be> wrote:
In Seaside, there are a couple of tests that now fail because of this change.
Although I agree it's good practice to use specific error classes in such assertions, the tests that are failing in Seaside use the Error class because they are written to be cross-platform. Different subclasses of Error will be thrown on different platforms. Moreover, the use of the assertion specifically documents that this test is testing for any errors being thrown. Removing the assertion means we need to write it down in comments, which is less explicit imho.
That's not true, that is the default behavior that you test for not Errors. I mean every code that is run must work and testing that it does not raise and Error is duplicated efforts.
+1 'shouldn't raise' is bogus and as you said, it is default expectation for any code you run that it doesn't throws any errors. (that's why exceptions called so and that's why error is exception). i can understand why i would want to use 'should raise' to check that my code throws appropriate error when i using wrong data etc.. but not this one.
As I said, checking for any other error makes somehow sense, but not for Error itself. Because that basically means that you ignore what the test does since you are not specific at all. The test framework takes already care of that part, if you have an error the test fails. I think that is the goal. I do not understand why you would have to explain this to the user of the tests, since for him the result does not change. Yes it is red instead of yellow, but does that matter? I mean you just transformed at will an error into an assertion failure, to me this sounds very bogus. Just because you transform the error to an assertion, you did not anticipated anything, since you cannot be sure at all where the error happened, since you do not test for an explicit error. On the other hand if you call a method that is very small to check if it really works, you know which errors are signaled and you test explicitly for those.
I think I can come up with a tree transformation rule to go from #shouldnt:raise:Error to a refactored version that even includes a comment.
I'm not in favour of enforcing best practices this way. It just yields more workarounds in the end. I also do not understand the problem with debugging the test. If the test fails, you step through it and will discover the cause.
But if you just use the expression directly, the debugger pops up in the place where the error was signaled. Not somewhere in deep in the assertion framework. Furthermore if you run the test under jenkins you will get no reasonable feedback (yes this should be changed as well). Just try to debug the following statement in a test:
self shouldnt: [ 0/0 ] raise: Error
vs. 0/0.
Of course we can change it back at some point, but I haven't heard a solid reason in favor of shouldnt:raise:Error.
Johan
On 22 Oct 2013, at 00:26, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-10-22, at 00:20, Alexandre Bergel <alexandre.bergel@me.com>
wrote:
Instead of using shouldnt:raise:, you can simply remove the assertion,
as in:
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error -=-=-=-=-=-=-=-=-=
|| V
-=-=-=-=-=-=-=-=-= testNoErrorWhenDrawing view raw drawOn: tracingCanvas -=-=-=-=-=-=-=-=-=
With the second version of the test, the test may be listed as an
error in case of an exception, whereas the first version it can only be listed as a failure.
Right, but that doesn't make any difference IMO, using `shouldnt: [...] raise: Error` to not have errors does not make much sense. It makes a little bit more sense when using a specific Error, and it makes sense when testing for Notifications, which would go otherwise unnoticed.
Which is the reason that `#shouldnt:raise:` no longer accepts `Error` as an argument, but still lets you use anything else.
I read your post and I kind of agree. I will fix my tests then.
nice :)
-- Best regards, Igor Stasenko.
I will add a discussion to the SUnit Chapter about this point. Stef On Oct 22, 2013, at 12:08 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
On 2013-10-21, at 23:42, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
Just to share some thought. I am now playing with Pharo 3. I have seen TestCase has some additional checks for assertion with exception. I perfectly understand the idea behind this, however, on the other hand, I see nothing suspect with the following assertion (which Roassal's tests are full of):
self shouldnt: [ view raw drawOn: tracingCanvas ] raise: Error
I have to shut down the method #validateShouldntException:
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way. This only adds code who's sole purpose is to break people's existing code. If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule. Cheers Philippe
While I agree that we shouldnât unnecessary make life more difficult for external frameworks/libraries when that can be avoided, we do have to reserve the right to be able to make changes that break things. Like with #includesSubstring: the actual intention of the change is valid and sound, but the process could have been smoother. Issue 11876 does have a point and it does simplify the system, IMHO. On 24 Oct 2013, at 08:17, Philippe Marschall <philippe.marschall@netcetera.ch> wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Cheers Philippe
On 24 October 2013 08:17, Philippe Marschall < philippe.marschall@netcetera.ch> wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/** default.asp?11876#87218<https://pharo.fogbugz.com/default.asp?11876#87218> it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Running SLint over tests? I could agree the working code should be checked for rules.. but tests? Useful, to some pedantic souls i guess , but not me :) But anyways, i agree with you, we should not dictate what is 'best' rules and 'how you should do the coding', we shall let people discover own and let them shoot into their own foot, if they insisting to.
Cheers Philippe
-- Best regards, Igor Stasenko.
On 24.10.13 15:24, Igor Stasenko wrote:
On 24 October 2013 08:17, Philippe Marschall <philippe.marschall@netcetera.ch <mailto:philippe.marschall@netcetera.ch>> wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/__default.asp?11876#87218 <https://pharo.fogbugz.com/default.asp?11876#87218> it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Running SLint over tests? I could agree the working code should be checked for rules.. but tests?
Yes. Test should have the same quality standards as the rest of the code because you'll have to maintain them just the same. Our tests have to be portable like the rest of our code. Cheers Philippe
On 24 October 2013 15:40, Philippe Marschall < philippe.marschall@netcetera.ch> wrote:
On 24.10.13 15:24, Igor Stasenko wrote:
On 24 October 2013 08:17, Philippe Marschall <philippe.marschall@netcetera.**ch <philippe.marschall@netcetera.ch> <mailto:philippe.marschall@**netcetera.ch<philippe.marschall@netcetera.ch>>> wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/__**default.asp?11876#87218<https://pharo.fogbugz.com/__default.asp?11876#87218>
it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Running SLint over tests? I could agree the working code should be checked for rules.. but tests?
Yes. Test should have the same quality standards as the rest of the code because you'll have to maintain them just the same. Our tests have to be portable like the rest of our code.
Well, if you putting such high quality standards on Seaside, then logically i would expect more understanding from your side that people here also want to have quality standards for Pharo as well. And this issue with #shouldn't lies exactly in this plane. Because rephrasing you, running SLint on tests << doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain.>> :) Cheers
Philippe
-- Best regards, Igor Stasenko.
On Thu, 24 Oct 2013, Philippe Marschall wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
<rant> It's part of the Pharo manifesto: "Not backward compatible" </rant> Levente
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Cheers Philippe
On 24 Oct 2013, at 18:32, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 24 Oct 2013, Philippe Marschall wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
<rant> It's part of the Pharo manifesto: "Not backward compatible" </rant>
And I still think that this was the best decision we ever took. It will allow us to have a future. Marcus
On 24 Oct 2013, at 18:32, Levente Uzonyi <leves@elte.hu> wrote:
On Thu, 24 Oct 2013, Philippe Marschall wrote:
On 22.10.13 00:08, Camillo Bruni wrote:
see my long explanation here https://pharo.fogbugz.com/default.asp?11876#87218 it looks unsuspicous until the moment you try understand such a failing assertion.
This isn't moving Pharo foward. This doesn't make the system any more flexible, adaptable, modular or malleable. This doesn't make the system any easier to maintain. This doesn't make the system any smaller, faster, scalable or secure. This doesn't make the system any easier to maintain. This doesn't make life easier for anybody developing Pharo or using Pharo. This doesn't improve Pharo in any way.
This only adds code who's sole purpose is to break people's existing code.
<rant> It's part of the Pharo manifesto: "Not backward compatible" </rant>
<annoyed> Please go write those kind of comments on squeak-dev, nobody from Pharo ever does this on squeak-dev, ever. </annoyed>
Levente
If you disagree with such a way of writing tests then the right solution IMHO is to write a SLint rule.
Cheers Philippe
<rant> It's part of the Pharo manifesto: "Not backward compatible" </rant>
Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious If I can laugh from them this is that I should be quite strong no? We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. It is not easy but people like marcus, sven, esteban, igor, camillo and many many others are dedicated to that goal. All the rest does not matter :) I'm just sad that other smart people do not understand that we want to create a future to everybody not just a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it and I thank them for that. Stef
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:
<rant> It's part of the Pharo manifesto: "Not backward compatible" </rant>
Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious If I can laugh from them this is that I should be quite strong no?
I'm sorry if you guys didn't get my message, but it was as serious as it could be. I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. As I see, people need various levels of backwards compatibility. Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects. As time passes, and the number of users increases, you'll have to give in, and provide it some way.
We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view. Levente
It is not easy but people like marcus, sven, esteban, igor, camillo and many many others are dedicated to that goal. All the rest does not matter :)
I'm just sad that other smart people do not understand that we want to create a future to everybody not just a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it and I thank them for that.
Stef
I'm sorry if you guys didn't get my message, but it was as serious as it could be.
Ok fair :)
I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. As I see, people need various levels of backwards compatibility.
Indeed but the right level is important ;) I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW)
Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects.
there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in a system slowly improving. I can control when I want to migrate my apps.
As time passes, and the number of users increases, you'll have to give in, and provide it some way.
What I was thinking for example (and I will build it) is an automatic stub creation to support the loading of package where a class is missing in the existing system. I also love the evolution analysis made by andre that generates rules to check migration we should add automatic code transformation. I would like to keep refactoring that we can apply when people want to migrate. And we will get there because we start to have a good infrastructure. So once the infrastructure does not suck all our time then we will build the next generation tools. And this is starting :)
We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. You will complain about the fogbuz stuff and we will answer that we hate that google forced us to move. And this is like that.
I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view.
It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http server and many more is enough. And in addition the consortium means that slowly we will give an autonomous live to Pharo not based on free time of people. Stef
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:
I'm sorry if you guys didn't get my message, but it was as serious as it could be.
Ok fair :)
I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. As I see, people need various levels of backwards compatibility.
Indeed but the right level is important ;) I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW)
That's nice, but AFAIK Moose is Pharo-only, so you only have to follow your own changes.
Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects.
there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in a system slowly improving. I can control when I want to migrate my apps.
This is where the level of backwards compatibility comes into the picture. For example the official release of Seaside is still based on Pharo 1.3, and the reason for that is the frequent changes of core functionality.
As time passes, and the number of users increases, you'll have to give in, and provide it some way.
What I was thinking for example (and I will build it) is an automatic stub creation to support the loading of package where a class is missing in the existing system.
I don't see how this is benefical, or how it addresses the increasing demand for backwards compatibility.
I also love the evolution analysis made by andre that generates rules to check migration we should add automatic code transformation. I would like to keep refactoring that we can apply when people want to migrate. And we will get there because we start to have a good infrastructure. So once the infrastructure does not suck all our time then we will build the next generation tools. And this is starting :)
We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste. You will complain about the fogbuz stuff and we will answer that we hate that google forced us to move. And this is like that.
Well, fogbugz is just part of it, and somewhat less important than actual code changes. There are two kind of diffs posted to this mailing list. One for the changes on smalltalkhub, and the other is from github. The latter is totally useless, because it contains no code, just the name of the methods in the changed packages. The former is totally broken, because smalltalkhub can't create the diff, if the direct ancestor of the package is missing, and in 90%+ of the cases, you jump more than one mcz versions.
I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view.
It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http server and many more is enough. And in addition the consortium means that slowly we will give an autonomous live to Pharo not based on free time of people.
I can only repeat myself; these changes are great, but it's not a breakthrough. Levente
Stef
We should not continue this old discussion. We've already debated this ad naseum. Thank you Pharo guys for exploring what can be done when all constraints are removed! Thank you Squeak guys for advancing in a way that caters to legacy applications. On Fri, Oct 25, 2013 at 1:25 PM, Levente Uzonyi <leves@elte.hu> wrote:
On Fri, 25 Oct 2013, Stéphane Ducasse wrote:
I'm sorry if you guys didn't get my message, but it was as serious as it could be.
Ok fair :)
I understand that you don't what to be backwards compatible, because it makes it easier to change stuff. As I see, people need various levels of backwards compatibility.
Indeed but the right level is important ;) I help maintaining Moose and its several couple of tenth of packages as well as the pharoExtras packages so I think that I'm exposed to API changes. Just today I fixed the PharoSound package (full of ugly code BTW)
That's nice, but AFAIK Moose is Pharo-only, so you only have to follow your own changes.
Currently the package maintainers are the most affected, who would like to provide the same codebase for various versions of Pharo, and/or other Smalltalk dialects.
there is a bit of utopia there but why not. I prefer to see a system getting better than my code just loading in a system slowly improving. I can control when I want to migrate my apps.
This is where the level of backwards compatibility comes into the picture. For example the official release of Seaside is still based on Pharo 1.3, and the reason for that is the frequent changes of core functionality.
As time passes, and the number of users increases, you'll have to give in, and provide it some way.
What I was thinking for example (and I will build it) is an automatic stub creation to support the loading of package where a class is missing in the existing system.
I don't see how this is benefical, or how it addresses the increasing demand for backwards compatibility.
I also love the evolution analysis made by andre that generates rules to check migration we should add automatic code transformation. I would like to keep refactoring that we can apply when people want to migrate. And we will get there because we start to have a good infrastructure. So once the infrastructure does not suck all our time then we will build the next generation tools. And this is starting :)
We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE.
I'm not following the developement of Pharo closely anymore, mainly because it's not transparent enough for my taste.
You will complain about the fogbuz stuff and we will answer that we hate that google forced us to move. And this is like that.
Well, fogbugz is just part of it, and somewhat less important than actual code changes. There are two kind of diffs posted to this mailing list. One for the changes on smalltalkhub, and the other is from github. The latter is totally useless, because it contains no code, just the name of the methods in the changed packages. The former is totally broken, because smalltalkhub can't create the diff, if the direct ancestor of the package is missing, and in 90%+ of the cases, you jump more than one mcz versions.
I see that you're making big changes, but I still haven't seen the breakthrough: I don't see the advantage of using Pharo over another open source Smalltalk dialect, from business point of view.
It is just a question of view. For me a new compiler, debugger, inspector, filesystem, http server and many more is enough. And in addition the consortium means that slowly we will give an autonomous live to Pharo not based on free time of people.
I can only repeat myself; these changes are great, but it's not a breakthrough.
Levente
Stef
I am using Pharo business wise. And making money out of it. It is using Seaside 3 and a ton of packages. They all work fine. What's your point really? If you want to go Pharo, you go Pharo and you don't look back. Or you haven't made your mind. In which case the complaints are useless. Phil
Phil I can tell you that we will do our best to help you. We deeply want that other people can build successes for Pharo. We could be better and the systsme could be better but we are focused on improving it while at the same time making sure that business can grow. So do not hesitate to let us know if we fail so that we can fix things. Stef
I am using Pharo business wise.
And making money out of it.
It is using Seaside 3 and a ton of packages. They all work fine.
What's your point really? If you want to go Pharo, you go Pharo and you don't look back. Or you haven't made your mind. In which case the complaints are useless.
Phil
participants (11)
-
Alexandre Bergel -
Camillo Bruni -
Chris Muller -
Igor Stasenko -
Johan Brichau -
Levente Uzonyi -
Marcus Denker -
phil＠highoctane.be -
Philippe Marschall -
Stéphane Ducasse -
Sven Van Caekenberghe