Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

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

Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Eliot Miranda-2
 
Hi Bert, Hi All,

On Thu, Sep 15, 2016 at 2:55 PM, <[hidden email]> wrote:
[snip]
http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

What do others think?

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Max Leske
 

On 22 Sep 2016, at 20:28, Eliot Miranda <[hidden email]> wrote:

Hi Bert, Hi All,

On Thu, Sep 15, 2016 at 2:55 PM, <[hidden email]> wrote:
[snip]
http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

What do others think?

As long as you don’t remove it from the Cog VM’s until I no longer need it I’m fine with that.

Max


_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Eliot Miranda-2
 
Hi Max,

On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <[hidden email]> wrote:
 

On 22 Sep 2016, at 20:28, Eliot Miranda <[hidden email]> wrote:

Hi Bert, Hi All,

On Thu, Sep 15, 2016 at 2:55 PM, <[hidden email]> wrote:
[snip]
http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

What do others think?

As long as you don’t remove it from the Cog VM’s until I no longer need it I’m fine with that.

And when would that be?  Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works?
 

Max


_,,,^..^,,,_
best, Eliot





--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

RE: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Ron Teitelbaum
 

Hi All,

 

Sorry I’m joining this conversation late. 

 

We are using ImageSegment for transferring croquet island state.  Is this something covered in the changes from Bert or are we talking about dropping ImageSegment altogether? 

 

All the best,

 

Ron Teitelbaum

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Thursday, September 22, 2016 2:47 PM
To: Squeak Virtual Machine Development Discussion
Cc: Pharo Development List; The general-purpose Squeak developers list
Subject: Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

 

Hi Max,

 

On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <[hidden email]> wrote:

 

 

On 22 Sep 2016, at 20:28, Eliot Miranda <[hidden email]> wrote:

 

Hi Bert, Hi All,

 

On Thu, Sep 15, 2016 at 2:55 PM, <[hidden email]> wrote:

[snip]

http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

 

What do others think?

 

As long as you don’t remove it from the Cog VM’s until I no longer need it I’m fine with that.

 

And when would that be?  Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works?

 

 

Max



 

_,,,^..^,,,_

best, Eliot

 

 



 

--

_,,,^..^,,,_

best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Eliot Miranda-2
 
Hi Ron, Hi All,

On Thu, Sep 22, 2016 at 11:58 AM, Ron Teitelbaum <[hidden email]> wrote:

Hi All,

 

Sorry I’m joining this conversation late. 

 

We are using ImageSegment for transferring croquet island state.  Is this something covered in the changes from Bert or are we talking about dropping ImageSegment altogether? 


I suppose I should explain.  At ESUG Bert and others announced support for Toys in Squeak 5.1.  As part of this work, ImageSegment loading and saving was moved from the VM up into pure Smalltalk code.  This allows Squeak 5.1 (Spur) to load image segments saved on pre-Spur VMs.  Consequent;ly we no longer need VM support for ImageSegment.  Instead we can use the pure image-level code Bert has kindly written.  The question is then at what point can we nuke the Spur VM support, since it is now superfluous.

Bert, am I jumping the gun?  Do we still need to write image-level support for writing image segments?  If this is the case, Igor Stasenko described a primitive for collecting the set of objects to be written out.  It is the initial part of the segment-writing primitive that collects the transitive closure of objects reachable only from those root objects.
 

 

All the best,

 

Ron Teitelbaum

 

From: Pharo-dev [mailto:[hidden email]] On Behalf Of Eliot Miranda
Sent: Thursday, September 22, 2016 2:47 PM
To: Squeak Virtual Machine Development Discussion
Cc: Pharo Development List; The general-purpose Squeak developers list
Subject: Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

 

Hi Max,

 

On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <[hidden email]> wrote:

 

 

On 22 Sep 2016, at 20:28, Eliot Miranda <[hidden email]> wrote:

 

Hi Bert, Hi All,

 

On Thu, Sep 15, 2016 at 2:55 PM, <[hidden email]> wrote:

[snip]

http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

 

What do others think?

 

As long as you don’t remove it from the Cog VM’s until I no longer need it I’m fine with that.

 

And when would that be?  Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works?

 

 

Max



 

_,,,^..^,,,_

best, Eliot

 

 



 

--

_,,,^..^,,,_

best, Eliot







--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [Vm-dev] Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

Max Leske
In reply to this post by Eliot Miranda-2
 
Hi Eliot,

On 22 Sep 2016, at 20:46, Eliot Miranda <[hidden email]> wrote:

Hi Max,

On Thu, Sep 22, 2016 at 11:42 AM, Max Leske <[hidden email]> wrote:
 

On 22 Sep 2016, at 20:28, Eliot Miranda <[hidden email]> wrote:

Hi Bert, Hi All,

On Thu, Sep 15, 2016 at 2:55 PM,  <[hidden email]> wrote:
[snip]
http://lists.squeakfoundation.org/pipermail/packages/2016-September/068930.html

Name: System-bf.916
Ancestors: System-bf.915

Replace VM-level ImageSegment loading with a Smalltalk implementation for old (interpreter-era) projects.

Also removes support for writing segments.

This overrides the Spur support introduced in System-eem.758.

 So one question is should we delete VM support for ImageSegment from the Spur VM?  There's at least 1.5k of generated source for the Spur ImageSegment load and save support, some 2% of the interpreter/primitives source code.  That's a lot, and the code is complex and ugly.  If it never really worked before IMO we should nuke it asap.  If it worked in some fashion perhaps we can schedule its demise for the 6.0 release's VM.

What do others think?

As long as you don’t remove it from the Cog VM’s until I no longer need it I’m fine with that.

And when would that be?

Can’t really say but I'm hoping to get rid of ImageSegment within the next 2 years (very rough estimate).

  Do you mean that you use it in ways not covered by Bert's modifications (which render the VM support superfluous), or do you mean that you use ImageSegment as a naive consumer and are happy just so long as it works?

Speed is important to me, as I use ImageSegment to create snapshots of our applications (and hence I need write support, which Bert apparently removed). Those snapshots can exceed 90 MB and the graphs include thousands of objects. I fear that a pure Smalltalk implementation would not be fast enough.


On the other hand, we would simply not move to a VM version without ImageSegment support, so that case may give me the boost I need to get rid of ImageSegment :) Currently we’re preparing to move to our first Cog VM in production. If you can give me 2 or 3 months, so that I know the version we use works for us, you could then remove ImageSegment support and we would start replacing ImageSegment with something else so we could keep updating our VM.

Cheers,
Max

 

Max


_,,,^..^,,,_
best, Eliot





-- 
_,,,^..^,,,_
best, Eliot

Reply | Threaded
Open this post in threaded view
|

Re: Nuking VM ImageSegment support (was Re: [squeak-dev] Daily Commit Log; System-bf.916)

vaidasd
In reply to this post by Eliot Miranda-2
 
Hello all,
To save morph and restore it is a basic behavior which is broken since Squeak 4.5. This is a bug. Beginning from 4.5 new Squeak user will get a debugger window open in a few clicks. This bug happened as a side effect of pushing Environments package into the Squeak image beginning from Squeak 4.5. No one uses Environments; there are significant use for morph saving. Squeak needs this ability. Maybe it is easier to remove Environments from stock Image and to fix the bug introduced by that package.
Introduction of new packages need not to break useful things...
regards,
Vaidotas