[Pharo-project] about imageSegments
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
On Fri, Jan 22, 2010 at 12:35 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> 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?
David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support. When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable. The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches. 2¢ best Eliot
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 22, 2010, at 9:59 PM, Eliot Miranda wrote:
On Fri, Jan 22, 2010 at 12:35 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> 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?
David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support. When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable.
Thanks I read a lot the parcel paper roel wrote about the pickle format. I reviewed it several times. I'm found of the idea that you can spend time saving if you get really fast loading :) But the paper was never crystal clear to me and I was always sad about that. I remember the first time I loaded RB with the parcels (20 min vs a couple of seconds).
The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches.
Ok I see the idea.
2¢
best Eliot
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda wrote:
On Fri, Jan 22, 2010 at 12:35 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> 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?
David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support.
Parcels are wonderful things, but my impression is that ImageSegment and parcels are designed to do rather different things. Parcels are used for physical delivery of packages (primarily code), whereas ImageSegments are for arbitrary graphs of objects (primarily not code, although some folks have tried to use ImageSegments for code). If parcels are designed to be more general than package delivery, I'd like to hear about it. I suspect that the only VM support that ImageSegments really need are the mark-sweep primitives to discover what objects are in the ImageSegment. All other algorithms, file format, etc. can (and maybe should) be redesigned to be better, but using the GC to find the objects is the heart of what ImageSegment is.
When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable.
The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches.
I like that approach for a file format. It probably doesn't even make writing the file out much slower; the work has to be done in multiple passes, but each pass is simpler. And write speed is important: A parcel is typically written once and loaded many times, but one common pattern of ImageSegment use is write once, load once, discard, or even write once, load never. Regards, -Martin
On Fri, Jan 22, 2010 at 4:33 PM, Martin McClure <martin@hand2mouse.com>wrote:
Eliot Miranda wrote:
On Fri, Jan 22, 2010 at 12:35 PM, Stéphane Ducasse <stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>> 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?
David Leibs' work on parcels in VW demonstrated that high-performance packaging can be done with no VM support.
Parcels are wonderful things, but my impression is that ImageSegment and parcels are designed to do rather different things. Parcels are used for physical delivery of packages (primarily code), whereas ImageSegments are for arbitrary graphs of objects (primarily not code, although some folks have tried to use ImageSegments for code). If parcels are designed to be more general than package delivery, I'd like to hear about it.
You're talking abut parcels expression in VW not their underlying nature. Parcels' underlying nature is just efficient unpacking of object graphs. The code stuff is layered above that, so much so that it obscures the essentials. Parcels are at core another pickling format, but one that is very much faster than standard approaches. My comparisons of BOSS (VW's Binary Object Storage System, very similar to ReferenceStream et al) and Parcels showed parcels to be 4 times faster than BOSS. Basically you get out of a parcel what you put in, and in VW parcels get code put in them. But you can put arbitrary objects in parcels. Note that parts of the parcel marshalling code is used in Opentalk. I suspect that the only VM support that ImageSegments really need are
the mark-sweep primitives to discover what objects are in the ImageSegment. All other algorithms, file format, etc. can (and maybe should) be redesigned to be better, but using the GC to find the objects is the heart of what ImageSegment is.
The core problem is that an image segment is a raw binary snapshot of a part of the heap, so a particular VMs object header formats and tagging scheme is built-in to the segment. If I were to evolve the Squeak garbage collector and object representation to make Cog significantly faster, as I fully intend to do this year, image segments will at least break backward compatibility. They can only be exchanged between VMs running exactly the same object representation. Parcels can be loaded into very different systems; VW loads parcels into either 32-bit or 64-bit images without difficulty, and parcels written before immutability or ephemerons were added could be loaded after. So for me image segments are too low-level and constraining.
When you implement a binary format, carefully designed for unpacking performance, at the image level you get the freedom to add flexibility. I added shape change support to parcels (and some higher level features that aren't relevant here) after David had left. So I think the right approach is to reimplement image segments entirely in the image without special VM support and add metadata to the format (class shape information) and you'll probably end up with something that is nearly as performant but much more flexible and evolvable.
The two keys to the performance of David's design are the separation of objects from their references and the btching of object allocations. A parcel file starts with a number of allocations of well-known classes (e.g. this parcel contains 17 large integers of the following sizes, and 3 floats, and 17 symbols of the following sizes etc) followed by an arbitrary number of "N instances of class X". So the unpacker populates an object table with indices from 1 to N where N is the number of objects in the parcel, but it does so in batch, spinning in a loop creating N instances of each class in turn, instead of determining which object to create as it walks a (flattened) input graph. After the instance data comes the reference data, which slots refer to which objects. Again the unpacker can spin filling in slots from the reference data instead of determining whether to instantiate an object or dereference an object id as it walks the input graph. So loading is much faster than e.g. ReferenceStream-style approaches.
I like that approach for a file format. It probably doesn't even make writing the file out much slower; the work has to be done in multiple passes, but each pass is simpler. And write speed is important: A parcel is typically written once and loaded many times, but one common pattern of ImageSegment use is write once, load once, discard, or even write once, load never.
Right. Writing out needs to be fast, but IIRC image segments aren't written incrementally; writing happens after a full walk of the graph has been made. So all we're talking about is adding a sort phase that assigns object table ids in the graph which shouldn't be expensive.
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Eliot Miranda wrote:
Parcels are wonderful things, but my impression is that ImageSegment and parcels are designed to do rather different things. Parcels are used for physical delivery of packages (primarily code), whereas ImageSegments are for arbitrary graphs of objects (primarily not code, although some folks have tried to use ImageSegments for code). If parcels are designed to be more general than package delivery, I'd like to hear about it.
You're talking abut parcels expression in VW not their underlying nature. Parcels' underlying nature is just efficient unpacking of object graphs. The code stuff is layered above that, so much so that it obscures the essentials. Parcels are at core another pickling format, but one that is very much faster than standard approaches. My comparisons of BOSS (VW's Binary Object Storage System, very similar to ReferenceStream et al) and Parcels showed parcels to be 4 times faster than BOSS.
Basically you get out of a parcel what you put in, and in VW parcels get code put in them. But you can put arbitrary objects in parcels. Note that parts of the parcel marshalling code is used in Opentalk.
Thanks, that's good to know.
I suspect that the only VM support that ImageSegments really need are the mark-sweep primitives to discover what objects are in the ImageSegment. All other algorithms, file format, etc. can (and maybe should) be redesigned to be better, but using the GC to find the objects is the heart of what ImageSegment is.
The core problem is that an image segment is a raw binary snapshot of a part of the heap, so a particular VMs object header formats and tagging scheme is built-in to the segment. If I were to evolve the Squeak garbage collector and object representation to make Cog significantly faster, as I fully intend to do this year, image segments will at least break backward compatibility. They can only be exchanged between VMs running exactly the same object representation. Parcels can be loaded into very different systems; VW loads parcels into either 32-bit or 64-bit images without difficulty, and parcels written before immutability or ephemerons were added could be loaded after.
So for me image segments are too low-level and constraining.
Really? Wow. I haven't looked at the binary format; I had assumed from what little code I'd read that it was more machine-independent than that. And the format should be defined at the Smalltalk level, not in the VM. But, again, to me the defining quality of ImageSegment isn't what format is used, it's what you can do with it, especially how you define what objects are in the ImageSegment. Regards, -Martin
On Fri, Jan 22, 2010 at 5:51 PM, Martin McClure <martin@hand2mouse.com>wrote:
Eliot Miranda wrote:
Parcels are wonderful things, but my impression is that ImageSegment
and
parcels are designed to do rather different things. Parcels are used
for
physical delivery of packages (primarily code), whereas ImageSegments are for arbitrary graphs of objects (primarily not code, although
some
folks have tried to use ImageSegments for code). If parcels are
designed
to be more general than package delivery, I'd like to hear about it.
You're talking abut parcels expression in VW not their underlying nature. Parcels' underlying nature is just efficient unpacking of object graphs. The code stuff is layered above that, so much so that it obscures the essentials. Parcels are at core another pickling format, but one that is very much faster than standard approaches. My comparisons of BOSS (VW's Binary Object Storage System, very similar to ReferenceStream et al) and Parcels showed parcels to be 4 times faster than BOSS.
Basically you get out of a parcel what you put in, and in VW parcels get code put in them. But you can put arbitrary objects in parcels. Note that parts of the parcel marshalling code is used in Opentalk.
Thanks, that's good to know.
I suspect that the only VM support that ImageSegments really need are the mark-sweep primitives to discover what objects are in the ImageSegment. All other algorithms, file format, etc. can (and maybe should) be redesigned to be better, but using the GC to find the
objects
is the heart of what ImageSegment is.
The core problem is that an image segment is a raw binary snapshot of a part of the heap, so a particular VMs object header formats and tagging scheme is built-in to the segment. If I were to evolve the Squeak garbage collector and object representation to make Cog significantly faster, as I fully intend to do this year, image segments will at least break backward compatibility. They can only be exchanged between VMs running exactly the same object representation. Parcels can be loaded into very different systems; VW loads parcels into either 32-bit or 64-bit images without difficulty, and parcels written before immutability or ephemerons were added could be loaded after.
So for me image segments are too low-level and constraining.
Really?
Look at Interpreter>>primitiveLoadImageSegment and Interpreter>>primitiveStoreImageSegment in VMMaker. Wow. I haven't looked at the binary format; I had assumed from
what little code I'd read that it was more machine-independent than that. And the format should be defined at the Smalltalk level, not in the VM. But, again, to me the defining quality of ImageSegment isn't what format is used, it's what you can do with it, especially how you define what objects are in the ImageSegment.
Right! cheers Eliot
Regards,
-Martin
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Look at Interpreter>>primitiveLoadImageSegment and Interpreter>>primitiveStoreImageSegment in VMMaker.
Yeaph these ones! I think that this code can only break in the future or will take a lot of time to get fully understood and with too much VM knowledge so that a smart smalltalker can do it without been a smart vm guy. Stef
2010/1/23 Eliot Miranda <eliot.miranda@gmail.com>:
So for me image segments are too low-level and constraining.
Right. Every time we wanting to say 'let VM do it for us' , we should always consider implementing it in smalltalk. For reasons you described before. My own rule of thumb: - do not put 'clever' code into VM. VM should be dumb, leaving cleverness to language level. -- Best regards, Igor Stasenko AKA sig.
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.
ImageSegments currently have some problems, but are useful. Rather than remove them, I'd like to see them evolve to be better-implemented as people have energy to work on them. If necessary, put a "not for the faint of heart" sign on them in the meantime. Regards, -Martin
On Jan 23, 2010, at 1:13 AM, Martin McClure wrote:
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.
ImageSegments currently have some problems, but are useful.
Rather than remove them, I'd like to see them evolve to be better-implemented as people have energy to work on them. Me too this was the original plan.
If necessary, put a "not for the faint of heart" sign on them in the meantime.
clearly :) This is why mariano started to package them better (even if their influence is creeping in lot of dark corners). Now one of the difficult problem with imagesegment is that as soon as you have a out (of the root graph) pointer pointing in an object in the root graph then this subgraph will not be saved. This means that as soon as you have a closures, session, thread.... holding a ref to any subgrpah objects you can save half of your data. This is why netstyle fork and do brain surgery on the image then save and throw away the image after saving it. Stef
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. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi@netstyle.ch> 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 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 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. Another problem is that if we remove ImageSegment to an external package, will be soon outdated and nobody will maintain it. 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
So the plan would be - try to group as much as possible imageSegment related code in a package (without unloading it for now) - may be offer a simple ImageSlice (going in the direction of what nestyle did) - get ready to throw them away. Stef On Jan 25, 2010, at 9:57 AM, Mariano Martinez Peck wrote:
On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi@netstyle.ch> 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
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
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.
Another problem is that if we remove ImageSegment to an external package, will be soon outdated and nobody will maintain it.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote:
On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi@netstyle.ch> 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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/25 Adrian Lienhard <adi@netstyle.ch>:
On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote:
On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi@netstyle.ch> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On Jan 25, 2010, at 10:24 , Igor Stasenko wrote:
2010/1/25 Adrian Lienhard <adi@netstyle.ch>:
On Jan 25, 2010, at 09:57 , Mariano Martinez Peck wrote:
On Mon, Jan 25, 2010 at 9:02 AM, Adrian Lienhard <adi@netstyle.ch> 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?
Probably because it was easier that way ;). As far as I understand a lot of code deals with storing presenters (Etoys) and projects/morphs in clever ways. This is additional behavior that you don't need (anymore). I think if we remove this, we get a very small class that is much simpler to understand and use. Adrian
participants (6)
-
Adrian Lienhard -
Eliot Miranda -
Igor Stasenko -
Mariano Martinez Peck -
Martin McClure -
Stéphane Ducasse