----- Original Message ----- | From: "Mariano Martinez Peck" <[email protected]> | To: "Seaside - general discussion" <[email protected]> | Cc: [email protected], [email protected] | Sent: Saturday, August 4, 2012 2:21:27 AM | Subject: Re: [Pharo-project] [Seaside] Re: [Metacello] What is the plan with Pharo changes? | | 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 :)
Deferring the removal of FileDirectory would buy me time for getting a more portable solution in place. | 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. The solution for SystemChangeNotifier is for me to add a message to the MetacelloPlatform class (my Grease layer) and use the currently correct method for Pharo-2.0. | 3) as Janko said, what about improving/using Grease/Sport for this | purpose? do they provide something for this? could this be added? The right answer for FileTree is to re-architect the implementation. The code is currently liberally sprinkled with FileDirectoryisms as FileTree does a lot of directory traversal ... Cami made a pass at replacing the FileDirectory calls with Filesystem calls[1] so I have a good blueprint for building an implementation neutral directory structure traversal class that can isolate the FileDirectory/Filesystem calls into a manageable location (right now there are just too many places that are different) ... So given time (and as I mentioned elsewhere I have to start preparing my ESUG talk because that's a hard deadline) I can get a handle on this. Eventually I plan to port Filesystem to GemStone, so moving away from FileDirectory is in my future plans as well, it's just the timing that is an issue, not the direction. I think that Sport should eventually end up with a port to Pharo-2.0, but for FileTree I don't think I want to require Sport. The FileTree implementation will benefit by the removal of the FileDiretoryisms, so that's the route I will take. [1] https://github.com/dh83/filetree/commit/4232898d4dbdd9712f4276f69c9404e14a6f1c49 | 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. If you decide to stick with your decision to drop FileDirectory, then a fork or Metacello will be a good choice for the near term ... you can freely make the most efficient changes to Metacello to keep it running and focus your energies on making Pharo-2.0 better ... I can take my time to port FileTree. If you rename FileDirectory or decide to keep it for a while longer, then I will be able to start immediate work on getting the Metacello Preview running on top of Pharo-2.0 (which shouldn't take too much work)... | | | Thanks for considering this a friendly and positive thread. | It was good that you made a point of focussing on the technical solutions to the problem. Leaving the politics for another thread, if any. | | 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 | |
