+1 On Wed, Jan 4, 2012 at 1:45 PM, Norbert Hartl <norb...@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"
