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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

Re: [Vm-dev] 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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

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
|  
Report Content as Inappropriate

Re: [Vm-dev] 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jakob Reschke
In reply to this post by Eliot Miranda-2
Hi Vaidotas,

I cannot reproduce this. In my current trunk image where I
coincidentally try to get familiar with Environments to put them to
use, I can save morphs without a debugger appearing. Loading via drag
and drop works as well (though the option "load as morph" appears
twice in the dialog that prompts me for an action after the drop).

Does Morph saving depend on ImageSegments anyway?

Best regards,
Jakob

2016-09-23 16:10 GMT+02:00 Vaidotas Didžbalis <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

vaidasd
Hello Jacob,
ActiveWorld is morph also, and it cannot be stored to disk. I believed all morphs share the same storage mechanism, and that we are considering to remove that mechanism. Sorry for wrong claim. You are right, some morphs can be saved. Perhaps morphs I tried saving were dependent on the ActiveWorld.
regards,
Vaidotas

On Fri, Sep 23, 2016 at 5:36 PM, Jakob Reschke <[hidden email]> wrote:
Hi Vaidotas,

I cannot reproduce this. In my current trunk image where I
coincidentally try to get familiar with Environments to put them to
use, I can save morphs without a debugger appearing. Loading via drag
and drop works as well (though the option "load as morph" appears
twice in the dialog that prompts me for an action after the drop).

Does Morph saving depend on ImageSegments anyway?

Best regards,
Jakob

2016-09-23 16:10 GMT+02:00 Vaidotas Didžbalis <[hidden email]>:
> 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
>




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hannes Hirzel
In reply to this post by Jakob Reschke
Hello Jakob

On 9/23/16, Jakob Reschke <[hidden email]> wrote:
> Hi Vaidotas,
>
> I cannot reproduce this. In my current trunk image where I
> coincidentally try to get familiar with Environments to put them to
> use, I can save morphs without a debugger appearing.

This is indeed the case.
A test case for Squeak6.0alpha-16755?

1. In a project activate the 'objects' flap.
2. Choose the 'Multimedia' category
3. Drag out a bookmorph
4. In the control bar click on the top-right icon to get 'more controls'
5. Add some morphs to the page
6. Add another page by clicking on 'plus' and add more morphs
7. Bring up the 'halo' menu
8. Choose submenu 'debug' and then 'save morph in file'.
9. Delete the morph
10. Choose menu 'tools' / 'File list'
11. Identify the file of the saved bookmorph and click on it.
12. Choose 'Load as morph'

Result OK

Questions:
a) Since then is this working again?
b) Which underlying mechanism is used to do this?


--Hannes

> Loading via drag
> and drop works as well (though the option "load as morph" appears
> twice in the dialog that prompts me for an action after the drop).
>
> Does Morph saving depend on ImageSegments anyway?
>
> Best regards,
> Jakob
>
> 2016-09-23 16:10 GMT+02:00 Vaidotas Didžbalis <[hidden email]>:
>> 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
>>
>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hannes Hirzel
Just for clarity:

Please note that saving a project (menu 'project' / 'save project') is
not yet working.

It breaks in

MorphicProject>>exportSegmentWithChangeSet: aChangeSetOrNil fileName: aFileName
directory: aDirectory withoutInteraction: noInteraction

world cleanUpReferences.

(world is a PasteUpMorph)


On 9/23/16, H. Hirzel <[hidden email]> wrote:

> Hello Jakob
>
> On 9/23/16, Jakob Reschke <[hidden email]> wrote:
>> Hi Vaidotas,
>>
>> I cannot reproduce this. In my current trunk image where I
>> coincidentally try to get familiar with Environments to put them to
>> use, I can save morphs without a debugger appearing.
>
> This is indeed the case.
> A test case for Squeak6.0alpha-16755?
>
> 1. In a project activate the 'objects' flap.
> 2. Choose the 'Multimedia' category
> 3. Drag out a bookmorph
> 4. In the control bar click on the top-right icon to get 'more controls'
> 5. Add some morphs to the page
> 6. Add another page by clicking on 'plus' and add more morphs
> 7. Bring up the 'halo' menu
> 8. Choose submenu 'debug' and then 'save morph in file'.
> 9. Delete the morph
> 10. Choose menu 'tools' / 'File list'
> 11. Identify the file of the saved bookmorph and click on it.
> 12. Choose 'Load as morph'
>
> Result OK
>
> Questions:
> a) Since then is this working again?
> b) Which underlying mechanism is used to do this?
>
>
> --Hannes
>
>> Loading via drag
>> and drop works as well (though the option "load as morph" appears
>> twice in the dialog that prompts me for an action after the drop).
>>
>> Does Morph saving depend on ImageSegments anyway?
>>
>> Best regards,
>> Jakob
>>
>> 2016-09-23 16:10 GMT+02:00 Vaidotas Didžbalis <[hidden email]>:
>>> 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
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Frank Shearar-3
In reply to this post by vaidasd
On 23 September 2016 at 07:10, Vaidotas Didžbalis <[hidden email]> wrote:
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

It was pretty difficult for Colin Putney to perform the heart surgery necessary to get Environments into the image in the first place. The capabilities that Environments enable are pretty dang awesome, and it's a crying shame that people either don't see these capabilities (sandboxing, trivial resolution of class name clashes are the START of things) or (more likely) simply haven't had the time to build the _missing tooling support_ to make Environments work to their fullest.

I'm equally to blame here: I burned out a few years back, and have since been too busy doing other stuff to work on Environments (or Squeak at all).

But it would be tragic if we performed the equally painful surgery to remove Environments.

So instead of removing a super awesome half-implemented feature of Squeak, why don't we, I don't know, _fix the bug_. Raise a bug report. Give a patch. It will make Squeak better.

frank


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stéphane Rollandin
> It was pretty difficult for Colin Putney to perform the heart surgery
> necessary to get Environments into the image in the first place. The
> capabilities that Environments enable are pretty dang awesome, and it's
> a crying shame that people either don't see these capabilities
> (sandboxing, trivial resolution of class name clashes are the START of
> things) or (more likely) simply haven't had the time to build the
> _missing tooling support_ to make Environments work to their fullest.

Where is the canonical documentation for Environments, where I would
expect to find an exposition of its overall architecture, plus a
detailed tour of its most important classes and methods, along with a
couple of examples showing how to use it?

Stef


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Hannes Hirzel
In reply to this post by Frank Shearar-3
On 9/24/16, Frank Shearar <[hidden email]> wrote:
....

>
> It was pretty difficult for Colin Putney to perform the heart surgery
> necessary to get Environments into the image in the first place. The
> capabilities that Environments enable are pretty dang awesome, and it's a
> crying shame that people either don't see these capabilities (sandboxing,
> trivial resolution of class name clashes are the START of things) or (more
> likely) simply haven't had the time to build the _missing tooling support_
> to make Environments work to their fullest.
>
> I'm equally to blame here: I burned out a few years back, and have since
> been too busy doing other stuff to work on Environments (or Squeak at all).
>
> But it would be tragic if we performed the equally painful surgery to
> remove Environments.
>
> So instead of removing a super awesome half-implemented feature of Squeak,
> why don't we, I don't know, _fix the bug_. Raise a bug report. Give a
> patch. It will make Squeak better.

Yes, this is the way to go. And add notes on the Squeak wiki

And simple use cases first. Maybe entering a new environment when
entering a project and leaving it then leaving the environment is a
simple use case.

Subclassing MorphicProject is neat these days and with overriding a
few methods you can customize the project.

The question is what would be needed to set up a project specific environment.
Maybe a new thread should be started for this.

--Hannes

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Kjell Godo
In reply to this post by Stéphane Rollandin
Yay sandboxing 
     Yay trivial solve name clashing 
     Why hide it 

Vat good iss a Dooms Day device
     If You  Keep  It A  Zecret

     Vhy Didn't You Tell Ze VVorld HAH? <---[ Doctor strange love ]

in my opinion if you make a function in a software
     and don't tell anyone
     you might as well not have made the function
     nobody knows it's in there
in Smalltalk the code itself often tells anyone
     but in other languages not so much
     consequently they seem to have better documentation some or mostly
in Smalltalk if a function is dispersed or complex
     such that the code does not speak very well or is muted
     then not spending a few minutes to comment
          ( like Andy Bower used to do for Dolphin
               every single method with a 
               one line comment<---[ is priceless ][ no other help is needed ][ mostly ]
               most of the main classes big commented )
     the main Classes with design and or usage notes
     is a crime of wasted effort
in my opinion
look at the fact that Dolphin has always been so bullet proof
     with images going for months even years without a crash
     or a memory leak
     and all or most of it made by just one or two guys
     can it be attributed to the comments
          at all
          well i bet you a good big chunk of that success rate can be
     I know those comments contributed a good big chunk 
          of my not needing to ask for help with Dolphin
          ever
          such that i got a bad habit of never asking for help
          and was totally spoiled for anything that was not Dolphin

how about this idea
     a Class whose only job is to describe some subsystem
     where each of the Methods is just a comment
     or returns a String
     like a little book   right in the code
     ( use Pier Seaside Aida Iliad etc if you had a wild hair 
          to get fancy )<---[ not needed ]

so up with comments and up with Andy Bower
     is what I'm saying

and don't hand Google another brick in the wall of their world domination
     by hiding comments out on the internet

     unless you link to it from comments in the code

     in that case every single Class involved should contain such
          a link in its comment to its comment out on the web
          and Methods could have comment links to specific places
               in the web pages where it is commented
          or you hate the users 
               and you hate cheaply gotten Maybe wider Smalltalk usage
          in my opinion
     

On Saturday, September 24, 2016, Stéphane Rollandin <[hidden email]> wrote:
It was pretty difficult for Colin Putney to perform the heart surgery
necessary to get Environments into the image in the first place. The
capabilities that Environments enable are pretty dang awesome, and it's
a crying shame that people either don't see these capabilities
(sandboxing, trivial resolution of class name clashes are the START of
things) or (more likely) simply haven't had the time to build the
_missing tooling support_ to make Environments work to their fullest.

Where is the canonical documentation for Environments, where I would expect to find an exposition of its overall architecture, plus a detailed tour of its most important classes and methods, along with a couple of examples showing how to use it?

Stef




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bert Freudenberg
In reply to this post by Max Leske
Hi Max,

I'd be interested to learn how you are using ImageSegments. Is it using CodeLoader?

- Bert -

On Thu, Sep 22, 2016 at 9:08 PM, Max Leske <[hidden email]> wrote:
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
|  
Report Content as Inappropriate

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

Bert Freudenberg
In reply to this post by Frank Shearar-3
On Sat, Sep 24, 2016 at 7:10 AM, Frank Shearar <[hidden email]> wrote:
On 23 September 2016 at 07:10, Vaidotas Didžbalis <[hidden email]> wrote:
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

It was pretty difficult for Colin Putney to perform the heart surgery necessary to get Environments into the image in the first place. The capabilities that Environments enable are pretty dang awesome, and it's a crying shame that people either don't see these capabilities (sandboxing, trivial resolution of class name clashes are the START of things) or (more likely) simply haven't had the time to build the _missing tooling support_ to make Environments work to their fullest.

I'm equally to blame here: I burned out a few years back, and have since been too busy doing other stuff to work on Environments (or Squeak at all).

But it would be tragic if we performed the equally painful surgery to remove Environments.

So instead of removing a super awesome half-implemented feature of Squeak, why don't we, I don't know, _fix the bug_. Raise a bug report. Give a patch. It will make Squeak better.

+1

Don't worry, we're not removing environments. Project saving will work again some way or other pretty soon.

- Bert -


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eliot Miranda-2
In reply to this post by Frank Shearar-3


On Fri, Sep 23, 2016 at 10:10 PM, Frank Shearar <[hidden email]> wrote:
On 23 September 2016 at 07:10, Vaidotas Didžbalis <[hidden email]> wrote:
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

It was pretty difficult for Colin Putney to perform the heart surgery necessary to get Environments into the image in the first place. The capabilities that Environments enable are pretty dang awesome, and it's a crying shame that people either don't see these capabilities (sandboxing, trivial resolution of class name clashes are the START of things) or (more likely) simply haven't had the time to build the _missing tooling support_ to make Environments work to their fullest.

I'm equally to blame here: I burned out a few years back, and have since been too busy doing other stuff to work on Environments (or Squeak at all).

But it would be tragic if we performed the equally painful surgery to remove Environments.

So instead of removing a super awesome half-implemented feature of Squeak, why don't we, I don't know, _fix the bug_. Raise a bug report. Give a patch. It will make Squeak better.

+1000
 
frank
 
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

No, we use ImageSegment directly (we’ve subclassed ImageSegment). Here’s the short version:

1. we copy the roots:

self
copyFromRoots: (Array with: anObject)
sizeHint: self fileSize // 2
areUnique: true.

2. we write the segment onto a MutliByteFileStream (which we’ve subclassed):

NSSegmentStream
forceNewFileNamed: fileName
do: [ :stream | stream writeObject: self ].

where #writeObject: is implemented as:

writeObject: anObject
(SmartRefStream on: self) nextPutObjOnly: anObject


We load the segment back by:

1. opening a MultiByteFileStream and sending the installation message:

NSSegmentStream
readOnlyFileNamed: (aDirectory fullNameFor: filename)
do: [ :stream |
self
installSegmentFrom: stream
andDo: aBlock ]

2. #installSegmentFrom:andDo: basically sends #readObject to the file stream:

readObject
"This is a hack to allow for the old segments (mixed code and objects)
to be loaded without the #inform: in #nextAndClose opening a UI element."
^ self binary peek = ReferenceStream versionCode
ifTrue: [ (SmartRefStream on: self) nextAndClose ]
ifFalse: [
| object |
self
ascii;
fileIn.
object := SmartRefStream scannedObject.
SmartRefStream scannedObject: nil.
object ]

3. and once we have the segment we send #install to it


We’ve made some modifications here and there (e.g. to suppress UI elements) but the above is the gist of it. I can give you the full source if you need it.
It’s possible that this is all overkill or parallels functionality found in other places. I’ve inherited the code and haven’t spent the time exploring improvements in that area.

Cheers,
Max

On 26 Sep 2016, at 19:39, [hidden email] wrote:

Hi Max,

I'd be interested to learn how you are using ImageSegments. Is it
using CodeLoader?

- Bert -



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Stéphane Rollandin
In reply to this post by Stéphane Rollandin
 > Where is the canonical documentation for Environments, where I would
> expect to find an exposition of its overall architecture, plus a
> detailed tour of its most important classes and methods, along with a
> couple of examples showing how to use it?

So there is really no documentation ?

Stef


12
Loading...