[Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?
dhenrich at vmware.com
Sat Aug 4 20:37:47 CEST 2012
Cami provided a port of FileTree to Pharo-2.0 within an hour...
Getting FileTree to run is not the issue ... for me ... FileTree was written to be very _dependent_ on FileDirectory and needs to be rewritten...
I think the Pharo folks are correct that most applications will not be hit nearly as hard by the removal of FileDirectory.
----- Original Message -----
| From: "Philippe Marschall" <philippe.marschall at gmail.com>
| To: "Seaside - general discussion" <seaside at lists.squeakfoundation.org>
| Cc: Pharo-project at lists.gforge.inria.fr
| Sent: Saturday, August 4, 2012 10:27:42 AM
| Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes?
| On Sat, 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
| > :)
| > 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.
| > 3) as Janko said, what about improving/using Grease/Sport for this
| > purpose?
| > do they provide something for this? could this be added?
| > 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)
| > it is not very necessary.
| > Thanks for considering this a friendly and positive thread.
| So instead of lamenting the state of the world I went ahead and wrote
| some code. To find out what breaks in Seaside I created new packages
| for every Pharo package that didn't work. So I ended up with:
| - Grease-Pharo20-Core
| - Grease-Tests-Pharo20-Core
| - Seaside-Pharo20-Core
| - Seaside-Tests-Pharo20-Core
| You can find them in the Seaside 3.1 repository . I'm not really
| sure this was a clever idea but it sounded better than writing a long
| Things I ran into:
| - file system (obviously)
| - SystemAnnouncer
| - BlockContext is gone
| - extension methods are now present on String
| - different Float number printing
| File system and SystemAnnouncer are only used by file library.
| Right now two tests fail because the GRPackage dependencies are
| inconsistent due to a mix of Pharo and Pharo20 packages. The rest
| seems to work, also functionally.
| Things I didn't test or even load:
| - OB tooling
| - Slime/SLint tooling
|  http://www.squeaksource.com/Seaside31
| seaside mailing list
| seaside at lists.squeakfoundation.org
More information about the Pharo-project