Make ImageSegments import-only?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Make ImageSegments import-only?

Bert Freudenberg
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 -


Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

David T. Lewis
+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 -
>
>



Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Tobias Pape
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 -
>


Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Hannes Hirzel
+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 -
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Bert Freudenberg
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 -
>>
>
>
>




Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Chris Muller-3
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 -
>> >>
>> >
>> >
>> >
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

timrowledge

> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Bert Freudenberg
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:

> 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.






Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Robert Hirschfeld
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


Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

vaidasd
In reply to this post by Bert Freudenberg
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


Reply | Threaded
Open this post in threaded view
|

Re: Make ImageSegments import-only?

Hannes Hirzel
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
>