Make ImageSegments import-only?
Locked
Make ImageSegments import-only?
 
|
Hi all,
I think there is no current usage of image segments. Project storing has been broken for a while and that's the only current use I am aware of. What about this idea: We keep ImageSegment but remove all support for writing. It would only be used for importing old projects. It would not use the VM primitives (because they are incompatible anyways). The number of methods in ImageSegment would shrink from more than 80 to 15. My SegmentLoader has 25 methods, it replaces the VM primitive. Cog appears to be fast enough to not cause a significant slowdown in loading. With this, old projects can still be imported, but writing projects would have to use some other serialization mechanism (which we discussed before). It would remove quite a bit of unused code, making the remaining code more easily understandable. Sounds good? - Bert - |
Re: Make ImageSegments import-only?
|
|
+1
Dave > Hi all, > > I think there is no current usage of image segments. Project storing has > been broken for a while and that's the only current use I am aware of. > > What about this idea: > > We keep ImageSegment but remove all support for writing. It would only be > used for importing old projects. It would not use the VM primitives > (because they are incompatible anyways). > > The number of methods in ImageSegment would shrink from more than 80 to > 15. > My SegmentLoader has 25 methods, it replaces the VM primitive. Cog appears > to be fast enough to not cause a significant slowdown in loading. > > With this, old projects can still be imported, but writing projects would > have to use some other serialization mechanism (which we discussed > before). > It would remove quite a bit of unused code, making the remaining code more > easily understandable. > > Sounds good? > > - Bert - > > |
Re: Make ImageSegments import-only?
|
|
In reply to this post by Bert Freudenberg
+1
On 13.09.2016, at 22:09, Bert Freudenberg <[hidden email]> wrote: > Hi all, > > I think there is no current usage of image segments. Project storing has been broken for a while and that's the only current use I am aware of. > > What about this idea: > > We keep ImageSegment but remove all support for writing. It would only be used for importing old projects. It would not use the VM primitives (because they are incompatible anyways). > > The number of methods in ImageSegment would shrink from more than 80 to 15. My SegmentLoader has 25 methods, it replaces the VM primitive. Cog appears to be fast enough to not cause a significant slowdown in loading. > > With this, old projects can still be imported, but writing projects would have to use some other serialization mechanism (which we discussed before). It would remove quite a bit of unused code, making the remaining code more easily understandable. > > Sounds good? > > - Bert - > |
Re: Make ImageSegments import-only?
|
|
+1
On 9/13/16, Tobias Pape <[hidden email]> wrote: > +1 > On 13.09.2016, at 22:09, Bert Freudenberg <[hidden email]> wrote: > >> Hi all, >> >> I think there is no current usage of image segments. Project storing has >> been broken for a while and that's the only current use I am aware of. >> >> What about this idea: >> >> We keep ImageSegment but remove all support for writing. It would only be >> used for importing old projects. It would not use the VM primitives >> (because they are incompatible anyways). >> >> The number of methods in ImageSegment would shrink from more than 80 to >> 15. My SegmentLoader has 25 methods, it replaces the VM primitive. Cog >> appears to be fast enough to not cause a significant slowdown in loading. >> >> With this, old projects can still be imported, but writing projects would >> have to use some other serialization mechanism (which we discussed >> before). It would remove quite a bit of unused code, making the remaining >> code more easily understandable. >> >> Sounds good? >> >> - Bert - >> > > > |
Re: Make ImageSegments import-only?
|
|
Okay, I've put it in the inbox as System-bf.916.
Are we sure about removing the ability to store? I just noticed that Eliot claimed to have fixed ImageSegments in System-eem.758. OTOH if nobody intends to use them it's better to get rid of the dead code. - Bert - On Wed, Sep 14, 2016 at 5:48 AM, H. Hirzel <[hidden email]> wrote: +1 |
Re: Make ImageSegments import-only?
|
|
The original purpose of ImageSegments was to leverage the
garbage-collector in order to have a performant serialization mechanism, is that right? Now with Cog/Spur, its performance is probably not as advantageous, and so the relative cost of its magical implementation, code size, number of serializers confusion, seems unlikely it will be used by any new code. On Wed, Sep 14, 2016 at 8:50 AM, Bert Freudenberg <[hidden email]> wrote: > Okay, I've put it in the inbox as System-bf.916. > > Are we sure about removing the ability to store? I just noticed that Eliot > claimed to have fixed ImageSegments in System-eem.758. OTOH if nobody > intends to use them it's better to get rid of the dead code. > > - Bert - > > On Wed, Sep 14, 2016 at 5:48 AM, H. Hirzel <[hidden email]> wrote: >> >> +1 >> >> On 9/13/16, Tobias Pape <[hidden email]> wrote: >> > +1 >> > On 13.09.2016, at 22:09, Bert Freudenberg <[hidden email]> wrote: >> > >> >> Hi all, >> >> >> >> I think there is no current usage of image segments. Project storing >> >> has >> >> been broken for a while and that's the only current use I am aware of. >> >> >> >> What about this idea: >> >> >> >> We keep ImageSegment but remove all support for writing. It would only >> >> be >> >> used for importing old projects. It would not use the VM primitives >> >> (because they are incompatible anyways). >> >> >> >> The number of methods in ImageSegment would shrink from more than 80 to >> >> 15. My SegmentLoader has 25 methods, it replaces the VM primitive. Cog >> >> appears to be fast enough to not cause a significant slowdown in >> >> loading. >> >> >> >> With this, old projects can still be imported, but writing projects >> >> would >> >> have to use some other serialization mechanism (which we discussed >> >> before). It would remove quite a bit of unused code, making the >> >> remaining >> >> code more easily understandable. >> >> >> >> Sounds good? >> >> >> >> - Bert - >> >> >> > >> > >> > >> > > > > |
Re: Make ImageSegments import-only?
|
|
> On 14-09-2016, at 12:56 PM, Chris Muller <[hidden email]> wrote: > > The original purpose of ImageSegments was to leverage the > garbage-collector in order to have a performant serialization > mechanism, is that right? > > Now with Cog/Spur, its performance is probably not as advantageous, > and so the relative cost of its magical implementation, code size, > number of serializers confusion, seems unlikely it will be used by any > new code. Given that Spur is somewhat different memory model I doubt that using the original idea of the image segment is of any real advantage. And given that the detail of the memory model is different we’d have to do assorted fiddling in both directions. Seems like a bit of a loser to me. Being able to stop keeping compatibility code working in the vm would save some hassles. I say ‘just dolt' tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Brain fried; core dumped. |
Re: Make ImageSegments import-only?
|
|
Okay. I moved it to trunk.
With this, we should be able to load most old Etoys projects. If something doesn't work, speak up :) - Bert - On Thu, Sep 15, 2016 at 3:40 AM, tim Rowledge <[hidden email]> wrote:
|
Re: Make ImageSegments import-only?
|
|
In reply to this post by Bert Freudenberg
Until we have an alternative implementation, it would be nice to have full image segment support to for example revive Croquet's islands. (We did that for Squeak v4, but stopped working on it with v5...)
Best, Robert > On 14 Sep 2016, at 15:50, Bert Freudenberg <[hidden email]> wrote: > > Okay, I've put it in the inbox as System-bf.916. > > Are we sure about removing the ability to store? I just noticed that Eliot claimed to have fixed ImageSegments in System-eem.758. OTOH if nobody intends to use them it's better to get rid of the dead code. > > - Bert - > > On Wed, Sep 14, 2016 at 5:48 AM, H. Hirzel <[hidden email]> wrote: > +1 > > On 9/13/16, Tobias Pape <[hidden email]> wrote: > > +1 > > On 13.09.2016, at 22:09, Bert Freudenberg <[hidden email]> wrote: > > > >> Hi all, > >> > >> I think there is no current usage of image segments. Project storing has > >> been broken for a while and that's the only current use I am aware of. > >> > >> What about this idea: > >> > >> We keep ImageSegment but remove all support for writing. It would only be > >> used for importing old projects. It would not use the VM primitives > >> (because they are incompatible anyways). > >> > >> The number of methods in ImageSegment would shrink from more than 80 to > >> 15. My SegmentLoader has 25 methods, it replaces the VM primitive. Cog > >> appears to be fast enough to not cause a significant slowdown in loading. > >> > >> With this, old projects can still be imported, but writing projects would > >> have to use some other serialization mechanism (which we discussed > >> before). It would remove quite a bit of unused code, making the remaining > >> code more easily understandable. > >> > >> Sounds good? > >> > >> - Bert - > >> > > > > > > > > > -- Robert Hirschfeld [hidden email] www.hirschfeld.org |
|
|
In reply to this post by Bert Freudenberg
Hello list, VaidotasWe use project-saving feature. Users maintains a set of projects with connectors based diagrams in them and project saving allows to share them among different user images. It's nice to be able to save any morph to disk and resurrect it in other image. We use Squeak 4.4. |
Re: Make ImageSegments import-only?
|
|
Yes, sharing projects through save and load in another project is a
need. The question is just which serialization format should be used in the future. We are currently looking for a replacement for ImageSegments. But to do so it means that reading Image Segments is necessary in a current version. --Hannes On 9/19/16, Vaidotas Didžbalis <[hidden email]> wrote: > Hello list, > We use project-saving feature. Users maintains a set of projects with > connectors based diagrams in them and project saving allows to share them > among different user images. It's nice to be able to save any morph to disk > and resurrect it in other image. We use Squeak 4.4. > Vaidotas > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |