+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"