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 <bert at freudenbergs.de> 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 <hannes.hirzel at gmail.com> wrote:
>>
>> +1
>>
>> On 9/13/16, Tobias Pape <Das.Linux at gmx.de> wrote:
>> > +1
>> > On 13.09.2016, at 22:09, Bert Freudenberg <bert at freudenbergs.de> 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 -
>> >>
>> >
>> >
>> >
>>
>
>
>
>