[Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?

Sat Aug 4 16:33:16 UTC 2012

Esteban ... I agree with all of your points

----- Original Message -----
| From: "Esteban Lorenzano" <estebanlm at gmail.com>
| To: metacello at googlegroups.com
| Cc: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>, Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, August 4, 2012 3:04:02 AM
| Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?
| 
| Hi,
| 
| 
| 
| On Aug 4, 2012, at 11:21 AM, Mariano Martinez Peck <
| marianopeck at gmail.com > wrote:
| 
| 
| Hi all. I am answering to all together:
| 
| 
| Stef: Yes, I imported and loaded the Pier of DBX website in Pharo 2.0
| with seaside and magritte. With 5 minutes of opening debuggers and
| change things I was able to correctly make it work (at least, my
| app, I didn't run all tests to see).
| 
| 
| Dale: We don't want to just help you with "hacks", that why I send
| this email and several others, to see what others think so that can
| find better and non-hacky solutions. So, let's try to find good
| solutions:
| 
| 
| 1) does it help if we put back FildeDirectory and we remove it later
| ? so that you have time to update Metacello and that we can still
| use Metacello :)
| 
| 
| Ok, we could do as Dale proposed, reload the package adding prefix
| Obsolete... that will work just for a while, and I certainly prefer
| to help on the adaptation than reintroduce it... of course, maybe we
| should do that in the first instance and in this case it was
| possible (se below), but well... we already screw it, so, I prefer
| to do step forwards than backward (if possible).
| 
| 
| 
| 
| 
| 2) for the SystemChangeNotifier does it make sense to delegate to the
| closures? [ xx ] valueWithoutSystemNotifications. Or we add a
| #doSilently: and we add a MetacelloPharo20Platform that overrides
| the behavior.
| 
| 
| 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).
| 
| 
| 
| 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.
| 
| 
| best,
| Esteban
| 
| 
| 
| 
| 
| Thanks for considering this a friendly and positive thread.
| 
| 
| On Sat, Aug 4, 2012 at 9:16 AM, Janko Mivšek <
| janko.mivsek at eranova.si > 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
| seaside at lists.squeakfoundation.org
| http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
| 
| 
| 
| 
| --
| Mariano
| http://marianopeck.wordpress.com
| 
| 
| 