> > SystemChangeNotifier is a complete different situation than FileDirectory, > and we removed it because the effort of keeping the system working having two > different notification centers was eating all our time for make improvements. > So, we (I myself) decided to unload it and stop waisting time on try to make > the synchronization work... if you see the "before" and "after" (once we > finish, that is not done yet) you will notice the clarity and simplicity > gained. So... SystemChangeNotification is not going to go back, but an > approach like Mariano proposed would work fine, since Metacello just uses the > #doSilently stuff. > Btw... this is internal from Pharo, and 99.99% of the packages around > shouldn't even notice the difference. Of course, Metacello is in the 0.01% > remaining :) > >> 3) as Janko said, what about improving/using Grease/Sport for this purpose? >> do they provide something for this? could this be added? > > I'm strongly against this option, because I think Metacello (base) should be > part of Pharo Core (in fact I was planning to introduce it next days). If I > need to load grease or sport, I certainly will banish Metacello from core... > and I don't want to. Again, I prefer to spend time fixing Metacello to load > on Pharo (and I maintain my offer of spending it, he).
Yes I'm against adding layers of layers of layers. > >> 4) Should we integrate Metacello in the image with our changes until you >> have time and find a good solution that works everywhere? Maybe if we do 1) i >> t is not very necessary. > > I want Metacello in core, so... this is probably a good idea. A shrink down version then. > > best, > Esteban > >> >> Thanks for considering this a friendly and positive thread. >> >> On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <[email protected]> wrote: >> Hi Dale, >> >> Dne 04. 08. 2012 07:31, piše Dale Henrichs: >> >> > The bigger problem is that I have to have a code base that runs on >> > multiple platforms while being maintainable, so a "port" to Pharo-2.0 is >> > only a starting point. In the case of FileTree, which is the real >> > bottleneck there's a lot code that is written against the FileDirectory >> > API, so there will need to be significant work to find a way to keep a >> > common code base .... a much tougher problem, than "just getting it >> > working", it can be solved with time, but I didn't budget time for an >> > emergency rewrite of FileTree ... today. >> >> Just FYI, there is a Sport portability library and by using Sport's >> SpFilename you have an instantly portable file support over quite a >> dozen Smalltalks. So, if someone adapt Sport to a new Pharo 2.0 >> filesystem first .. >> >> Best regards >> Janko >> >> >> -- >> Janko Mivšek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> _______________________________________________ >> seaside mailing list >> [email protected] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >
