[Pharo-project] Fwd: Workspace API
Begin forwarded message:
From: Keith Hodges <keith_hodges@yahoo.co.uk> Date: February 12, 2009 2:38:41 PM CEST To: Alexandre Bergel <alexandre@bergel.eu>, stephane ducasse <stephane.ducasse@free.fr
Subject: Re: [Pharo-project] Workspace API
Alexandre Bergel wrote:
Hi Keith,
I am close enough to Stef to affirm you that he respects your work and he is really willing to have a look at your code. As I do. I said that I would look at your SUnit extension a long while ago. However Stef and I are extremely busy. We are leading a group of 8 people, which suck up all our time. Really.
Regards, Alexandre Why do you need to look at my code? I am not speaking up because you are not gathering up my meagre useless coding crumbs.
The argument is not about code its about perspective and philosophy.
MC1.5 is a loadable tool it either works or it doesn't. If it doesn't then the way forward is to consider contributing to the MC1.5 effort to make it work. That is the philosophy choice, inclusive or exclusive.
Will you make the philosophy choice to treat MC as a community project or your project, which is it to be? That choice takes no time at all to make. You make the choice and then you can put your time and effort into working with the consequences.
I am concerned because your philosophy leads you to continue to fork stuff that doesn't need to be forked and should not be forked for the good of the community.
Another trivial example: Workspace is another tool, it could be loadable, it need not be part of the kernel. Variants of Workspace could be available. Whatever is done it could be loadable and work in all images. There is no reason at all why my old production image that is still in 3.8 cant load a newer implementation of Workspace (since ScriptManager loads successfully)
SUnit is a loadable framework it is something that should be managed as a resource for everyone. Why does the pharo team insist on controlling it and forking. I am not asking you to "look at my code" in SUnit. In fact I doubt that the filters are actually working at the moment. Some of my code in SUnit was really rubbish until recent improvements.
I am asking you to adopt a philosophy of seeing MC/SUnit/Workspace/Compiler/Collections etc as a community resource, with a repository squeaksource/Testing that the community maintains. Not something that pharo does its own thing on.
If you dont, then I cant write a package that loads into Squeak and Pharo (because MC wont necessarily be compatible) or Tests run in squeak and Pharo (because SUnit will be incompatible). Why don't you see this level of compatibility as important?
So again I am not complaining about the fact that you haven't looked at this or that bit of code. Your response of "we havent had time to look at that " winds me up, because I hear it as "we havent had time to audit your potentially inferior code that might be below us to use." and that very attitude misses the point completely.
All of Stef objections, demonstrate that this is how he sees it.
I am complaining that you see the issue as a bunch of "potentially inferior" code contributions to your cause, rather than "we have something to contribute to the community of SUnit and MC users, because MC and SUnit are frameworks that everyone uses and depends on."
regards
Keith
On Thu, Feb 12, 2009 at 3:51 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So again I am not complaining about the fact that you haven't looked at this or that bit of code. Your response of "we havent had time to look at that " winds me up, because I hear it as "we havent had time to audit your potentially inferior code that might be below us to use." and that very attitude misses the point completely.
All of Stef objections, demonstrate that this is how he sees it.
I am complaining that you see the issue as a bunch of "potentially inferior" code contributions to your cause, rather than "we have something to contribute to the community of SUnit and MC users, because MC and SUnit are frameworks that everyone uses and depends on."
We believe your work (MC, SUnit, Sake and Packages) is important enough for an integration into Pharo. We don't want to consider it as an external package. But for that, Pharo's maintainers must have a look at the code and decide if it is safe to include. Your code is not of lower quality. Have a nice day and please continue working on these tools -- Damien Cassou http://damiencassou.seasidehosting.st
We believe your work (MC, SUnit, Sake and Packages) is important enough for an integration into Pharo. We don't want to consider it as an external package.
I think that you should consider it as an external package, because it IS an external package. And it is used by code that is not Pharo code. I think in an open source environment where everyone is short on time and energy it is rude not to. Those who fixed it before, invested their time and energy contributing to a solution and to an ideal, knowing that others would fix it in future and do the same, and it would continue to be useful. I consider the fact that Pharo team ignored Edgars contribution to squeak as extremely rude for the same reason. When I took up the role of maintaining MC1.5, I did so with the express purpose of integrating all of the MC forks for the benefit of the whole community. If I had known that this idea was conceptually a waste of time then I wouldn't have bothered. I did it because I wanted overrides to actually work, and because I thought people would be enthusiastic for it to actually work. How on earth do you do anything practical with MC1? It drove me nuts. There should be one stream of development for MC, any more makes no sense. Again this is a philosophical choice, you either see the sense in it or you don't. The fact that you will not adopt the choice of treating MC as an external package for the benefit of all, and you continue to develop MC1 within pharo is in by book extremely insulting to the amount of effort that has been made on your behalf. I say again it is an external package, and the repo is OPEN, so use it, and if you find it isnt up to scratch (the tests arent), then join in and fix it. Instead you appear to be cocking a snook at everyones contributions, and going your own way. Perhaps you guys are still not understanding what LPF is for. If you want to change something to make it integrate well with Pharo but this would make it incompatible with other squeak, then we have a mechanism for backporting compatibility to older users. That mechanism is LPF, and S/P, thats what it is there for. If you maintain it as an external package.
But for that, Pharo's maintainers must have a look at the code and decide if it is safe to include. Why? As I said its not their package, its an external package. Your code is not of lower quality.
Thanks, my code quality really depends on sleep, there must be a correlation there.
Have a nice day and please continue working on these tools
I am just speaking up because I found code in Pier that was not compatible with Squeak, so I worry where this is all going. Keith
When I took up the role of maintaining MC1.5, I did so with the express purpose of integrating all of the MC forks for the benefit of the whole community. If I had known that this idea was conceptually a waste of time then I wouldn't have bothered. I did it because I wanted overrides to actually work, and because I thought people would be enthusiastic for it to actually work. How on earth do you do anything practical with MC1? It drove me nuts.
I have a hard time to trust a system that references 6 undefined variables and that sends twice as many undefined messages (see attached screenshot).
Perhaps you guys are still not understanding what LPF is for.
I honestly do not understand what LPF means. It is probably because I am not a native speaker.
I am just speaking up because I found code in Pier that was not compatible with Squeak, so I worry where this is all going.
I still don't know what kind of problem you encountered with Pier? Please file a bug at <http://code.google.com/p/pier/>. I exclusively use Pharo for the development and deployment of Pier, Seaside and my other public and commercial projects. I know and trust the people that are behind Pharo, they push forward in the right direction. They maintain a good balance between clean-up, new features and building a trustworthy stable system. It obvious that external packages will break sooner or later and that framework developers have to pay attention to portability. At some point there will probably be no way around a Squeak specific platform class, if people want to use Seaside in Squeak? Lukas -- Lukas Renggli http://www.lukas-renggli.ch
I honestly do not understand what LPF means. It is probably because I am not a native speaker.
Lukas Renggli wrote:
When I took up the role of maintaining MC1.5, I did so with the express purpose of integrating all of the MC forks for the benefit of the whole community. If I had known that this idea was conceptually a waste of time then I wouldn't have bothered. I did it because I wanted overrides to actually work, and because I thought people would be enthusiastic for it to actually work. How on earth do you do anything practical with MC1? It drove me nuts.
I have a hard time to trust a system that references 6 undefined variables and that sends twice as many undefined messages (see attached screenshot).
Well spotted, I wouldn't know about that, because I don't use Lint. Unfortunately I don't have time to fix it until April 7th. Keith
On Thursday 12 February 2009 15:51:14 Stéphane Ducasse wrote:
Begin forwarded message:
From: Keith Hodges <keith_hodges@yahoo.co.uk> Date: February 12, 2009 2:38:41 PM CEST To: Alexandre Bergel <alexandre@bergel.eu>, stephane ducasse <stephane.ducasse@free.fr
Subject: Re: [Pharo-project] Workspace API
Alexandre Bergel wrote:
Hi Keith,
I am close enough to Stef to affirm you that he respects your work and he is really willing to have a look at your code. As I do. I said that I would look at your SUnit extension a long while ago. However Stef and I are extremely busy. We are leading a group of 8 people, which suck up all our time. Really.
One of the guy that suck up all your time thanks you .... Cheers, Gwenael
Regards, Alexandre
Why do you need to look at my code? I am not speaking up because you are not gathering up my meagre useless coding crumbs.
The argument is not about code its about perspective and philosophy.
MC1.5 is a loadable tool it either works or it doesn't. If it doesn't then the way forward is to consider contributing to the MC1.5 effort to make it work. That is the philosophy choice, inclusive or exclusive.
Will you make the philosophy choice to treat MC as a community project or your project, which is it to be? That choice takes no time at all to make. You make the choice and then you can put your time and effort into working with the consequences.
I am concerned because your philosophy leads you to continue to fork stuff that doesn't need to be forked and should not be forked for the good of the community.
Another trivial example: Workspace is another tool, it could be loadable, it need not be part of the kernel. Variants of Workspace could be available. Whatever is done it could be loadable and work in all images. There is no reason at all why my old production image that is still in 3.8 cant load a newer implementation of Workspace (since ScriptManager loads successfully)
SUnit is a loadable framework it is something that should be managed as a resource for everyone. Why does the pharo team insist on controlling it and forking. I am not asking you to "look at my code" in SUnit. In fact I doubt that the filters are actually working at the moment. Some of my code in SUnit was really rubbish until recent improvements.
I am asking you to adopt a philosophy of seeing MC/SUnit/Workspace/Compiler/Collections etc as a community resource, with a repository squeaksource/Testing that the community maintains. Not something that pharo does its own thing on.
If you dont, then I cant write a package that loads into Squeak and Pharo (because MC wont necessarily be compatible) or Tests run in squeak and Pharo (because SUnit will be incompatible). Why don't you see this level of compatibility as important?
So again I am not complaining about the fact that you haven't looked at this or that bit of code. Your response of "we havent had time to look at that " winds me up, because I hear it as "we havent had time to audit your potentially inferior code that might be below us to use." and that very attitude misses the point completely.
All of Stef objections, demonstrate that this is how he sees it.
I am complaining that you see the issue as a bunch of "potentially inferior" code contributions to your cause, rather than "we have something to contribute to the community of SUnit and MC users, because MC and SUnit are frameworks that everyone uses and depends on."
regards
Keith
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I am close enough to Stef to affirm you that he respects your work and he is really willing to have a look at your code. As I do. I said that I would look at your SUnit extension a long while ago. However Stef and I are extremely busy. We are leading a group of 8 people, which suck up all our time. Really.
One of the guy that suck up all your time thanks you ....
Gweanael, come on. You know what alex meant. And yes I'm really busy with the group. I can show you what it means to organize WCRE, ESUG, budgeting things and writing postdoc, phd, doing presentations .... Stef
participants (5)
-
Damien Cassou -
Gwenael Casaccio -
Keith Hodges -
Lukas Renggli -
Stéphane Ducasse