Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

23 messages Options

Eliot Miranda-2

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

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

Max Leske

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

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

Eliot Miranda-2

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

Ron Teitelbaum

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

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.

Max

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

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

best, Eliot

Eliot Miranda-2

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

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

Max Leske

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

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

vaidasd

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

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

Jakob Reschke-2

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

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
>

vaidasd

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

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
>

Hannes Hirzel

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

In reply to this post by Jakob Reschke-2

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

Hannes Hirzel

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

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

Frank Shearar-3

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

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

Stéphane Rollandin

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

> 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

Hannes Hirzel

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

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

Kjell Godo

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

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

Bert Freudenberg

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

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

Bert Freudenberg

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

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.

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

- Bert -

Eliot Miranda-2

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

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

Max Leske

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

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 -

Stéphane Rollandin

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

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