2010/1/25 Adrian Lienhard <[email protected]>: > On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote: > >> On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <[email protected]> wrote: >> >>> Hi Stef >>> >>> We can move the few classes related to image segments into a separate >>> package in SqueakSource. The system (ideally) does not depend on them so it >>> should not be too hard to package them separately. >>> >>> >> There are several things I would like to say: >> >> - The ImageSegment code really suc.. and it is very difficult to understand, >> maintain and test. It is full of etoys, morphic, project and other stuff. >> - There are a lot of methods that do a lot of black magic >> - The code is VERY fragile and may be broke any time (if it is not already >> broken) >> >> However, >> >> - Some people use it >> - It is fast > > I think image segments is a very nice idea and it works very well if you know > how to use them. The core, which is used for basic store/load, is not that > complicated. But image segments have been hacked in ugly ways for project > persistency. Hence, there is a lot of complexity that is not needed. >
Just one question: Why it is an ImageSegments which been hacked, but not a Project themselves? >> If you ask if we should remove it form core, I would say: >> >> - It won't very VERY easy to completely remove them. There are some places >> where ImageSegment are inside the code and won't be easy to remove. Or at >> least, leave the code with Smalltalk at: #ImageSegment ifPresent: [blah..] >> Look for example, >> Behavior >> allInstancesEverywhereDo: >> ClassDescription >> updateInstancesFrom: >> All those doGently and isInMemory > > I don't think it is very hard. Methods such as allInstancesEverywhereDo: can > be deleted. They implement iterating over object in segments that may be > stored on disk. This is too much magic in my eyes. I would only keep the core > to do basic segment store/load. > >> So...remove then would be easy, but put them in a separate package, still >> working and without Smalltalk at: ifPresent I think it would be difficult. >> >> I have already clean, fix and test it as much as possible. I will let them >> in Pharo and as Martin said, getting it better when someone has time and is >> willing to do it. > > When I find some time I'll try to continue from your work and extract them > into a separate package. > >> Another problem is that if we remove ImageSegment to an external package, >> will be soon outdated and nobody will maintain it. > > I believe it may be even the other way round. If image segments (or any other > package) is external to the image, it is easier to commit changes. Even > though image segments have been around for 10 years inside Squeak they have > not been maintained, so it can only get better ;) > > Cheers, > Adrian > >> >> Cheers >> >> Mariano >> >> >> Adrian >>> >>> On Jan 22, 2010, at 21:35 , Stéphane Ducasse wrote: >>> >>>> hi guys >>>> >>>> the more I read about imageSegments the more I would like to remove them >>> (or to package them >>>> carefully - not sure that this is possible) and may be add a new class >>> to >>>> just have one simple way of invoking the save (but not swapping back in) >>>> >>>> I think that mariano diving into them is a great phd exercise but on the >>> long run >>>> I see it as a brittle mechanism. >>>> >>>> what do you think? >>>> >>>> Stef >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
