would be nice to have a **new** and separate package with clean code for your scenario adrian.
Stef On Mar 30, 2010, at 8:48 AM, Adrian Lienhard wrote: > > On Mar 29, 2010, at 22:23 , Mariano Martinez Peck wrote: > >> On Mon, Mar 29, 2010 at 5:12 PM, Adrian Lienhard <[email protected]> wrote: >> >>> >>> On Mar 29, 2010, at 21:52 , Mariano Martinez Peck wrote: >>> >>>> 2010/3/29 John M McIntosh <[email protected]> >>>> >>>>> Also this week I will ship a 4.2.4b1 VM which is the result of some >>> Squeak >>>>> 4.0 base VM merge processing and contains the fix to enable the loading >>> of >>>>> old image segments used I guess by squeakmap? >>>>> >>>>> >>>> >>>> I am not sure. ImageSegment is a full of c...and maybe it will be even >>>> removed. It was not working since a lot of time and nobody says anything. >>> >>> Mariano, I know you know image segments, but I think this is may be >>> confusing for others. So I like to say something ;) >>> >>> Image segments work very well; both from a reliability and performance >>> point of view. We are using them for hundreds of customers. DabbleDB uses >>> images segments as well AFAIK. >>> >>> There are two parts, the primitives implemented by the VM in C and the >>> image-side code. The code in the image consists of support code to load and >>> store a segment and on top of this there is code for swapping in/out >>> classes, projects etc. Especially the latter is a mess and we already >>> started cleaning it. As images segments are not used by core code we also >>> consider moving it into a separate, external package (of course, the >>> primitives should stay in the VM). >>> >>> >> Thanks for the remark Adrian :) I know you know more for ImageSegments >> than all of us. >> >> As you said, it works pretty well for a piece of the domain. For example, in >> your case, you just export the segment, but did you try to swap them out >> (but letting the segment inside) and load it again ? it was broken. >> Exporting a segment, and bring them back again but where classes were >> modified or removed in the image, was broken also. If you load segments from >> older versions, it was broken too (this was what they fixed now). The >> symbols, you explained me that problem. In your case it works perfect >> because, as you say, almost only use the primitives, no more. But that's a >> very limited piece of ImageSegment. That piece, in that way, it works. > > Yes, exactly. And I think that's the most important piece and the one > valuable to maintain. We just create a segment, write it to disc, and read it > back from there into a fresh image. The only problem we had was with the > symbols you mentioned above. We do migrations with scripts inside the image > so that the segment's instances are always in sync with the code of the image > we load them into. > >> For big segments, I am not sure if it works well neither. The segment >> allocates more than 2 times what needed. In DabbleDB I read they had that >> problem. The segments were too big, that having to allocate 2 or 3 times, >> crash everything. > > Depends on what you think is big. Most of our segments are smaller than 50MB > but I have seen larger ones that worked too. > > Cheers, > Adrian > > >> Cheers >> >> Mariano >> >> >> >>>> We >>>> even started to remove part of it in Pharo. And SqueakMap was completely >>>> removed. >>> >>> Yes, SqueakMap is not relevant anymore for Pharo. Hence, this VM fix is not >>> critical for us. >>> >>> Cheers, >>> Adrian >>> _______________________________________________ >>> 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
