[Pharo-project] roadmap
Hi, Lukas and Stefan (Marr) both raised the topic of the roadmap. From Lukas:
This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs).
I think too that they have a point. Stef answered:
We should because we know where we want to go.
I think that at the very least it is a communication issue. From outside it is unclear in what order should the efforts be spent. We have a ton of wishes, but not an understanding of where we want to get and how. Please, let's discuss this roadmap. Not listing wishes, but actionable points. I start with some questions: - beside RB and Announcements, are there other things that could be problematic - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head? Cheers, Doru -- www.tudorgirba.com "Sometimes the best solution is not the best solution."
This is indeed important. I tried several times to use Pharo 1.4 but I could not really work with it unfortunately. I am stuck with 1.3
Please, let's discuss this roadmap. Not listing wishes, but actionable points.
I start with some questions: - beside RB and Announcements, are there other things that could be problematic - how do we approach the RB problem? Is it Ok to get it out of the image and have Jenkins build the Pharo distribution by loading the head?
I have probably read superficially the emails about those issues. Can you give a brief summary of the problem? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
- beside RB and Announcements, are there other things that could be problematic
Anything that is forked and changed, and that has existing could become a potential problem: - AST-*: No changes at the moment. - Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version. - Refactory-*: No big changes at the moment. - SUnit: Some problems in the past. - Shout: Some problems in the past. - ... Lukas -- Lukas Renggli www.lukas-renggli.ch
On Jan 2, 2012, at 6:24 PM, Lukas Renggli wrote:
- beside RB and Announcements, are there other things that could be problematic
Anything that is forked and changed, and that has existing could become a potential problem:
- AST-*: No changes at the moment.
We plan to change it. I asked camillo to discuss the changes in the mailing-list because we want pinocchio analysis to be applied on Pharo and for that we need some extensions. So what is the process?
- Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version.
How can the core of pharo work with FS if FS is not loaded in Pharo?
- Refactory-*: No big changes at the moment. - SUnit: Some problems in the past. - Shout: Some problems in the past. - ...
Lukas
-- Lukas Renggli www.lukas-renggli.ch
- beside RB and Announcements, are there other things that could be problematic
Anything that is forked and changed, and that has existing could become a potential problem:
- AST-*: No changes at the moment.
We plan to change it. I asked camillo to discuss the changes in the mailing-list because we want pinocchio analysis to be applied on Pharo and for that we need some extensions. So what is the process?
- Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version.
How can the core of pharo work with FS if FS is not loaded in Pharo?
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS? Lukas -- Lukas Renggli www.lukas-renggli.ch
On Jan 2, 2012, at 8:42 PM, Lukas Renggli wrote:
- beside RB and Announcements, are there other things that could be problematic
Anything that is forked and changed, and that has existing could become a potential problem:
- AST-*: No changes at the moment.
We plan to change it. I asked camillo to discuss the changes in the mailing-list because we want pinocchio analysis to be applied on Pharo and for that we need some extensions. So what is the process?
- Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version.
How can the core of pharo work with FS if FS is not loaded in Pharo?
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
Normally we talk and we reach a consensus. But it really looks that there is no possible discussion with you. Sadly. May be you should create your own smalltalk. Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On 02/01/12 2:58 PM, Stéphane Ducasse wrote:
On Jan 2, 2012, at 8:42 PM, Lukas Renggli wrote:
How can the core of pharo work with FS if FS is not loaded in Pharo?
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
Normally we talk and we reach a consensus.
The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point. Is it possible to maintain FS as a separate package, and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files. IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome.
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
Normally we talk and we reach a consensus.
The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point.
Apparently you did not browse enough the archive because it was mentioned and mentioned and mentioned and and mentioned again. We even stopped to fork it and published our changes to a common repository. instead of PharoTaskForces.
Is it possible to maintain FS as a separate package,
yes now what would be the key reason? Did you ever see a smalltalk without its own file system? The same question goes for the compiler. Can OPAL work without its own AST? Now if you read carefully my emails you will see that the door is always open but so far I did not hear anything about possible collaboration and as its latin root probably indicate to collaborate we should be two willing to do it. Let us take a concrete example: Pinocchio for example developed a large set of registry allocation for assembly generation and other analysis. Pinocchio people released the code under MIT and camillo spent time to make sure that their analyses work on our system. So should we throw away this effort because we cannot add nodes to AST? Frankly? What I asked is a discussion and so far I did not get anything concrete.
and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files.
Do you think that the system works without files?
IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome.
Did you check the FS repository recently to see the changes we are talking about? May be this is not 100% published in fs but this is easy to do it :) Why somebody does not merge in both way? We spent time commenting the code that we do not know because they was no serious comments. damien improved some part, camillo spent some time to fix some other problems. Now the code is there so what? Stef
Can we lower tension a bit? To me it sounds as you are pretty much in sync. Am 03.01.2012 um 09:09 schrieb Stéphane Ducasse:
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
Normally we talk and we reach a consensus.
The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point.
Apparently you did not browse enough the archive because it was mentioned and mentioned and mentioned and and mentioned again. We even stopped to fork it and published our changes to a common repository. instead of PharoTaskForces.
So if the FS in pharo is exactly the FS in the repository then there is no fork and no problem for others. And maybe you (Stef) could add that at a later time when the tiny kernel is present there would be only FS that is loaded as a module to the system, right? At this point I can see an agreement of all participating parties.
Is it possible to maintain FS as a separate package,
yes now what would be the key reason? Did you ever see a smalltalk without its own file system? The same question goes for the compiler. Can OPAL work without its own AST? Now if you read carefully my emails you will see that the door is always open but so far I did not hear anything about possible collaboration and as its latin root probably indicate to collaborate we should be two willing to do it.
Let us take a concrete example: Pinocchio for example developed a large set of registry allocation for assembly generation and other analysis. Pinocchio people released the code under MIT and camillo spent time to make sure that their analyses work on our system. So should we throw away this effort because we cannot add nodes to AST? Frankly? What I asked is a discussion and so far I did not get anything concrete.
Adding nodes means adding classes. That should be no problem at all. The question is if those changes are valuable for all. Then the extension nodes should go in the AST package. If the extra nodes are for special purpose than they should go in a extra package that is to be loaded in order to use OPAL. I can't see here a single problem except negotiation and communication. my 2 things, Norbert
and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files.
Do you think that the system works without files?
IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome.
Did you check the FS repository recently to see the changes we are talking about? May be this is not 100% published in fs but this is easy to do it :) Why somebody does not merge in both way? We spent time commenting the code that we do not know because they was no serious comments. damien improved some part, camillo spent some time to fix some other problems. Now the code is there so what?
Stef
+1 On Wed, Jan 4, 2012 at 1:45 PM, Norbert Hartl <norbert@hartl.name> wrote:
Can we lower tension a bit? To me it sounds as you are pretty much in sync.
Am 03.01.2012 um 09:09 schrieb Stéphane Ducasse:
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
Normally we talk and we reach a consensus.
The issue here is that FS was a separately maintained package that was (and apparently still is) loaded into different places. Adding the FS packages to Pharo amounts to a fork of FS. In hindsight, there should have been a discussion at that point.
Apparently you did not browse enough the archive because it was mentioned and mentioned and mentioned and and mentioned again. We even stopped to fork it and published our changes to a common repository. instead of PharoTaskForces.
So if the FS in pharo is exactly the FS in the repository then there is no fork and no problem for others. And maybe you (Stef) could add that at a later time when the tiny kernel is present there would be only FS that is loaded as a module to the system, right? At this point I can see an agreement of all participating parties.
Is it possible to maintain FS as a separate package,
yes now what would be the key reason? Did you ever see a smalltalk without its own file system? The same question goes for the compiler. Can OPAL work without its own AST? Now if you read carefully my emails you will see that the door is always open but so far I did not hear anything about possible collaboration and as its latin root probably indicate to collaborate we should be two willing to do it.
Let us take a concrete example: Â Pinocchio for example developed a large set of registry allocation for assembly generation and other analysis. Pinocchio people released the code under MIT and camillo spent time to make sure that their analyses work on our system. So should we throw away this effort because we cannot add nodes to AST? Frankly? What I asked is a discussion and so far I did not get anything concrete.
Adding nodes means adding classes. That should be no problem at all. The question is if those changes are valuable for all. Then the extension nodes should go in the AST package. If the extra nodes are for special purpose than they should go in a extra package that is to be loaded in order to use OPAL. I can't see here a single problem except negotiation and communication.
my 2 things,
Norbert
and use it for Pharo core? I think the answer is yes, because it is possible to run without .sources and .changes files.
Do you think that the system works without files?
IMHO, the right way forward is to make it a priority to build the "core" from PharoKernel, and the modularity everyone wants will be a natural outcome.
Did you check the FS repository recently to see the changes we are talking about? May be this is not 100% published in fs but this is easy to do it :) Why somebody does not merge in both way? We spent time commenting the code that we do not know because they was no serious comments. damien improved some part, camillo spent some time to fix some other problems. Now the code is there so what?
Stef
-- www.tudorgirba.com "Every thing has its own flow"
- Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version.
How can the core of pharo work with FS if FS is not loaded in Pharo?
Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS?
For your information we will use FS in the core and AST is used by OPAL. And OPAL should be our new compiler. Now I will stop replying to such emails because I should work too.
participants (6)
-
Alexandre Bergel -
Lukas Renggli -
Norbert Hartl -
Stéphane Ducasse -
Tudor Girba -
Yanni Chiu