Smalltalk › Squeak › Squeak - Dev

Condensing sources for a new release

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

38 messages Options

K K Subbu

Re: Letting the VM run multiple image formats

On 08/02/20 1:59 AM, David T. Lewis wrote:
> To say it another way, if I have Cog installed on my Linux box, and
> then I install 32-bit Spur, it overwrites the /usr/local/bin/squeak
> file. And if I then isntall 64-bit Spur, it overwrites the one for
> 32-bit Spur. They also conflict with the original /usr/local/bin/squeak.

+1 for fixing this.

Currently, I am using a hack to support different squeak VMs on a single
(non-root) session. I install all products in /opt/share/squeak but
create a symlink based on the image format number. My directory looks
like something like this (edited for brevity) :

/opt/share/squeak$ ls -n 6*
lrwxrwxrwx ... 6502 -> sqtrunklinux
lrwxrwxrwx ... 6504 -> sqcoglinuxht
lrwxrwxrwx ... 6505 -> sqcoglinuxht
lrwxrwxrwx ... 6521 -> sqcogspurlinuxht
lrwxrwxrwx ... 68019 -> sqcogspur64linuxht
lrwxrwxrwx ... 68021 -> sqcogspur64linuxht

I use the attached run script (installed in /opt/share/bin/run and
included in $PATH) to launch any given image. The script extracts the
image format from the given image and then picks up the right VM through
these symlinks.

I propose two changes to the official VM download :

* Squeak VM is a personal app, so it need not use the conventional
/usr/local path. The Official VM unix build can set its prefix to a
non-root directory, so that Linux/Unix downloads don't need root
permission to install. Package maintainers do their own builds, so they
can override the prefix path to suit their distros.

* Include the image format in the binary path so that we don't overwrite
binaries that handle other format numbers. e.g. $HOME/.squeak/68019/....
We could insert an conf/ini/plist file inside this directory for the
name (e.g. cog, spur, sista etc.), word size (32, 64) or optional features.

Regards .. Subbu

run.sh (1K) Download Attachment

timrowledge

Re: Letting the VM run multiple image formats

I suggest that what we would like to achieve is a way to run either 32 or 64 bit images on all our platforms with minimal fiddling. I mean sure, fiddling is fun but that isn't the sort of fun fiddling we like to have fun with, right?

David has long had a unix script that uses his imageformat program to test the image file format and work out the right vm to use and then launch the image with that vm. I'm not sure right now if it also checks for the latest version of the relevant vm (a loosely equivalent script we use for the Pi NuScratch system makes use of some trickery -
`
# find the latest vm
VM=`ls /usr/lib/squeak/5.0-20*/squeak|sort -r | head -1`
# and thus its directory
BIN=`/usr/bin/dirname $VM`

- to find the most recently date-named vm and I assume we could do the same.

We could of course go full-nutter and make use of the amazing trick discussed around 6 May 2019 in some fascinating messages from Subbu
(subject: [squeak-dev] Running Squeak fro ma unix shell script file with #! squeak...)
to put the vm name to use in the image header like a shebangbinbash. I guess we would make that refer to a script that still did the latest-vm-lookup trick.

For other platforms we might have to use a different approach, though I suspect Mac OS could just use the same unix ideas if not actual scripts. Windows ... no idea and probably something annoying but it must be able to do sometihng equivalent. The only thing we have to be careful about is not deciding on an option that makes it hard to use other platforms in the future.

For deployment/downloads we'd likely want to just bundle both 32&64 bit vms in a package set up to use the script(s) -after all the executables are not particularly large.

Err, it's too late at night for me to care about looking it up, but are we also going to get problems from wanting to run 32 bit images on a 64 bit OS where the OS insists on 64 form executables? Of course we are, silly question...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Exact estimate

Eliot Miranda-2

Re: Letting the VM run multiple image formats (was: Condensing sources for a new release)

In reply to this post by Tobias Pape

Hi Tobias,

On Sat, Feb 8, 2020 at 10:22 AM Tobias Pape <[hidden email]> wrote:

> On 07.02.2020, at 20:36, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Fri, Feb 7, 2020 at 11:33 AM Eliot Miranda <[hidden email]> wrote:
> Tobias,
>
> On Fri, Feb 7, 2020 at 11:21 AM Tobias Pape <[hidden email]> wrote:
>
> > On 07.02.2020, at 20:07, David T. Lewis <[hidden email]> wrote:
> >
> > Technically,
> > it would be hard to do this from a single compiled VM executable, but
> > fortunately that is not needed.
>
> It's possible, tho. RSqueak at one point happily read 64bit and 32bit images all the same…
>
> Of course it's possible. But it makes no sense to me. One only needs to convert once so why complicate the Vm including an extremely rarely used action that is slooow? If we include this facility soon enough people will complain that launching a 32-bit image takes ages. It is *much better engineering* to require people to convert once using a separate tool than complicating the existing production VM with a facility that is hardly ever used.
>
> And if *you* want the facility, why don't *you* write it and test it, instead of expecting me to add it as yet another task to my high list of completely unfunded things to do for the VM?
>

Eliot, I did by no means imply that this be your duty.
Not at all.
In fact, if a VM gains this ability, I think it ought to be done that all conversion is (a) obvious to the user and (b) transparent to everything after interpret().
And I acknowledge that these kind of features are not the ones you should think about :)

OK, cool. Sorry, I was triggered. Right now only Nicolas is putting in significant effort alongside me. I'm angry with the "PharoiVM" gang and their extremely unethical behaviour. So I'm a bit touchy.

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

best, Eliot

Eliot Miranda-2

Re: Letting the VM run multiple image formats

In reply to this post by K K Subbu

> On Feb 8, 2020, at 4:28 AM, K K Subbu <[hidden email]> wrote:
>
> On 08/02/20 12:37 AM, David T. Lewis wrote:
>> As long as each flavor of VM is installed in a distict directory under
>> /usr/local/lib/squeak, and as long as the run scripts that point to
>> those directories have distinct names in /usr/local/bin, then the
>> selection of a correct VM executable for any given image format is
>> handled from a single shell script. I call it /usr/local/bin/run on
>> my PC, hence "$ run squeak.image" for any flavor of squeak.image.
>
> The default prefix path should be changed to something like $HOME/.squeak or $HOME/.config/squeak so that default installations will not require root permission.

+1000. But this is not really the prefix path, but the default
installation. Can’t we easily compute the correct prefix path in the
squeak launch script based on its path (i.e. from a combination of $0
and $PATH ?). See

>
> Package maintainers can always override this default to distro-specific paths while building system-wide installable packages.
>
> Regards .. Subbu
>

Eliot Miranda-2

Re: Condensing sources for a new release

In reply to this post by David T. Lewis

Hi David, Hi Release Manager, Hi All,

On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:

On Thu, Feb 06, 2020 at 05:02:36PM -0800, Eliot Miranda wrote:
> Hi Tim,
>
> > On Feb 6, 2020, at 1:05 PM, tim Rowledge <[hidden email]> wrote:
> >
> > ???At yesterday's board meeting we discussed the possibility of condensing the sources file for the new release; we don't do this often, and usually for major releases but it after all five years since the last time and the changes file has got quite large.
> >
> > So as an experiment we thought of
> > - take a 5.2-19299 image (ie just the start of post-5.2)
> > - condense the sources
> > - update to latest (19335)
> > ... hopefully resulting in a small changes file of everything changed from 5.2 to now.
> >
> > Happily this process worked without any hitches on my iMac and I now have:
> > image -> 44.4MB
> > changes -> 144KB
> > sources -> 50MB
> >
> > The sources file has grown rather a lot from 35.2 to 50MB. I had thought that might be due to adding the EToys stuff but that was there in the 5.0 release anyway. The image has also grown from 5.0 (35.6MB) to 44.4. That's quite a lot.
> >
> > Now an interesting question is the most effective way to make a 32bit image release to use the same source file. Let's see if condensing sources & updating a 18229-32bit image results in an image that can use the same sources file...
>
> The ???right??? way, until we have written a 64-bit to 32-bit image converter, is to do the release in a 32-bit image and then run it through the 32-bit yo 64-bit converter yo derive the 64-bit pre-release image, which should be started up and snapshotted before being used as a release image.
>

Yes that is the right way to do it. And if it is a lot of work and/or
confusion, then the best thing for 5.3 is don't worry about condensing
the sources for this release. It's definitely a "nice to have" and not
a requirement for Squeak 5.3.

> Another way is to do a release on the 32-bit image and then just slam in the right source pointers. Dumping the source pointers from the 64-bit image is a trivial undertaking. Reading in the dumped source pointers and applying them should be only slightly less trivial.
>
> But given that soon macs that run 32-bit images (on spur vms) won???t be available I guess I really should try and write the converter 64-bit to 32-bit converter.
>

A 64-bit to 32-bit image converter would be a very good thing to have
in our toolkit :-)

I got this working this morning. See Cog-eem.398. So to use,
- clone or update an opensmalltalk-vm repository
- cd to the image directory and create a VMMaker image via either buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
- run a converter, e.g.
Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. (produces trunk6-64.image & trunk6-64.changes)
Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. (produces trunk6-64-32.image & trunk6-64-32.changes)

Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on my 2.9GHz Core i9 MacBook Pro

So let's try releasing by converting the 64-bit image into a 32-bit one.

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

best, Eliot

David T. Lewis

Re: [Vm-dev] Condensing sources for a new release

Update - I resolved my library problem, and can run the traced image.
However, it opens with an empty black window (but no VM crash or error
messages).

The image that I converted was Squeak5.3beta-19335-64bit.image. I'll
try some others later.

Meanwhile if anyone else can give this a try, please do :-)

Dave

On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote:

> I need some help on this, can someone please test the converted 32-bit
> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
> (I think) and I don't have any time to follow up on it today. Thanks!
>
> The actual image conversion seems to work fine, and it's fast. But I
> don't have a 32-bit VM at the moment, probably due to Linux runtime
> library issues that I don't have time to sort out this morning.
>
> Thanks!
> Dave
>
> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
> > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
> > >
> > > Hi David, Hi Release Manager, Hi All,
> > >
> > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
> > > >
> > > > A 64-bit to 32-bit image converter would be a very good thing to have
> > > > in our toolkit :-)
> > >
> > > I got this working this morning. See Cog-eem.398. So to use,
> > > - clone or update an opensmalltalk-vm repository
> > > - cd to the image directory and create a VMMaker image via either
> > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
> > > - run a converter, e.g.
> > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
> > > (produces trunk6-64.image & trunk6-64.changes)
> > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
> > > (produces trunk6-64-32.image & trunk6-64-32.changes)
> > >
> > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
> > > my 2.9GHz Core i9 MacBook Pro
> > >
> > >
> > > So let's try releasing by converting the 64-bit image into a 32-bit one.
> > >
> >
> > Bravo! I am away now but will try doing an image conversion as soon as
> > I can tomorrow.
> >
> > Thanks Eliot,
> >
>
>
>
>
>
>
>

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by timrowledge

Hi David,

> On Feb 11, 2020, at 6:09 AM, David T. Lewis <[hidden email]> wrote:
>
> I need some help on this, can someone please test the converted 32-bit
> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
> (I think) and I don't have any time to follow up on it today. Thanks!

You don’t need to test on multiple platforms. It is in the nature of the beast that if the 32-bit result of a conversion starts up at all then it is correct and will function on all platforms.

The image conversion does not do anything special which could possibly affect cross-platform behaviour. Its effects are entirely below that level, simply changing the width of all pointers and mapping out-of-range immediate into their boxed equivalents (SmallFloat64 => BoxedFloat64, SmallInteger=>LargePositiveInteger & LargeNegaitiveInteger). Just as the 64-bit product goes the other way. Nothing else is changed.

>
> The actual image conversion seems to work fine, and it's fast. But I
> don't have a 32-bit VM at the moment, probably due to Linux runtime
> library issues that I don't have time to sort out this morning.
>
> Thanks!
> Dave
>
>> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
>>> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
>>>
>>> Hi David, Hi Release Manager, Hi All,
>>>
>>> On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
>>>>
>>>> A 64-bit to 32-bit image converter would be a very good thing to have
>>>> in our toolkit :-)
>>>
>>> I got this working this morning. See Cog-eem.398. So to use,
>>> - clone or update an opensmalltalk-vm repository
>>> - cd to the image directory and create a VMMaker image via either
>>> buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
>>> - run a converter, e.g.
>>> Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
>>> (produces trunk6-64.image & trunk6-64.changes)
>>> Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
>>> (produces trunk6-64-32.image & trunk6-64-32.changes)
>>>
>>> Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
>>> my 2.9GHz Core i9 MacBook Pro
>>>
>>>
>>> So let's try releasing by converting the 64-bit image into a 32-bit one.
>>>
>>
>> Bravo! I am away now but will try doing an image conversion as soon as
>> I can tomorrow.
>>
>> Thanks Eliot,
>>
>
>
>
>
>
>
>

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by David T. Lewis

> On Feb 11, 2020, at 6:48 AM, David T. Lewis <[hidden email]> wrote:
>
> Update - I resolved my library problem, and can run the traced image.
> However, it opens with an empty black window (but no VM crash or error
> messages).
>
> The image that I converted was Squeak5.3beta-19335-64bit.image. I'll
> try some others later.

And the 64-bit image opens correctly?

>
> Meanwhile if anyone else can give this a try, please do :-)

Shall do.

>
> Dave
>
>
>> On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote:
>> I need some help on this, can someone please test the converted 32-bit
>> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
>> (I think) and I don't have any time to follow up on it today. Thanks!
>>
>> The actual image conversion seems to work fine, and it's fast. But I
>> don't have a 32-bit VM at the moment, probably due to Linux runtime
>> library issues that I don't have time to sort out this morning.
>>
>> Thanks!
>> Dave
>>
>>> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
>>> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
>>>>
>>>> Hi David, Hi Release Manager, Hi All,
>>>>
>>>> On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
>>>>>
>>>>> A 64-bit to 32-bit image converter would be a very good thing to have
>>>>> in our toolkit :-)
>>>>
>>>> I got this working this morning. See Cog-eem.398. So to use,
>>>> - clone or update an opensmalltalk-vm repository
>>>> - cd to the image directory and create a VMMaker image via either
>>>> buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
>>>> - run a converter, e.g.
>>>> Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
>>>> (produces trunk6-64.image & trunk6-64.changes)
>>>> Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
>>>> (produces trunk6-64-32.image & trunk6-64-32.changes)
>>>>
>>>> Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
>>>> my 2.9GHz Core i9 MacBook Pro
>>>>
>>>>
>>>> So let's try releasing by converting the 64-bit image into a 32-bit one.
>>>>
>>>
>>> Bravo! I am away now but will try doing an image conversion as soon as
>>> I can tomorrow.
>>>
>>> Thanks Eliot,
>>>
>>
>>
>>
>>
>>
>>
>>
>

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by David T. Lewis

Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script),

On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote:

Update - I resolved my library problem, and can run the traced image.
However, it opens with an empty black window (but no VM crash or error
messages).

This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message:

Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6

Please check you have write permission for this file.

You won't be able to save this image correctly until you fix this.

So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions:

$ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/

total 191096

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle

drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle

-rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle

-rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes

-rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image

-rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle

-rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns

-rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns

-rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns

-rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle

-rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns

-rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns

-rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources

drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle

drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale

drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes

The image that I converted was Squeak5.3beta-19335-64bit.image. I'll
try some others later.

Meanwhile if anyone else can give this a try, please do :-)

Dave

On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote:
> I need some help on this, can someone please test the converted 32-bit
> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
> (I think) and I don't have any time to follow up on it today. Thanks!
>
> The actual image conversion seems to work fine, and it's fast. But I
> don't have a 32-bit VM at the moment, probably due to Linux runtime
> library issues that I don't have time to sort out this morning.
>
> Thanks!
> Dave
>
> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
> > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
> > >
> > > Hi David, Hi Release Manager, Hi All,
> > >
> > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
> > > >
> > > > A 64-bit to 32-bit image converter would be a very good thing to have
> > > > in our toolkit :-)
> > >
> > > I got this working this morning. See Cog-eem.398. So to use,
> > > - clone or update an opensmalltalk-vm repository
> > > - cd to the image directory and create a VMMaker image via either
> > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
> > > - run a converter, e.g.
> > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
> > > (produces trunk6-64.image & trunk6-64.changes)
> > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
> > > (produces trunk6-64-32.image & trunk6-64-32.changes)
> > >
> > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
> > > my 2.9GHz Core i9 MacBook Pro
> > >
> > >
> > > So let's try releasing by converting the 64-bit image into a 32-bit one.
> > >
> >
> > Bravo! I am away now but will try doing an image conversion as soon as
> > I can tomorrow.
> >
> > Thanks Eliot,
> >
>
>
>
>
>
>
>

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

best, Eliot

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by David T. Lewis

Hi David,

On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote:

Update - I resolved my library pro> blem, and can run the traced image.
> However, it opens with an empty black window (but no VM crash or error
> messages).

"This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message:"

I spoke too soon. So there are two problems, one Mac specific, and one to do with my image conversion. When I start up the converted 32-bit image it does indeed crap out with an "Unwind error during termination" error when installing the lowSpaceWatcher. Here's the stack:

UndefinedObject(Object)>>doesNotUnderstand: #resume

Context>>return:

SmalltalkImage>>lowSpaceWatcher

[] in SmalltalkImage>>installLowSpaceWatcher

I do apologize for my premature response. I'm taking a look now. There are assert failures long before the error so I should b able to fix the issue quickly.

>
>
> The image that I converted was Squeak5.3beta-19335-64bit.image. I'll
> try some others later.
>
> Meanwhile if anyone else can give this a try, pleasedo :-)

Dave

On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote:
> I need some help on this, can someone please test the converted 32-bit
> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
> (I think) and I don't have any time to follow up on it today. Thanks!
>
> The actual image conversion seems to work fine, and it's fast. But I
> don't have a 32-bit VM at the moment, probably due to Linux runtime
> library issues that I don't have time to sort out this morning.
>
> Thanks!
> Dave
>
> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
> > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
> > >
> > > Hi David, Hi Release Manager, Hi All,
> > >
> > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
> > > >
> > > > A 64-bit to 32-bit image converter would be a very good thing to have
> > > > in our toolkit :-)
> > >
> > > I got this working this morning. See Cog-eem.398. So to use,
> > > - clone or update an opensmalltalk-vm repository
> > > - cd to the image directory and create a VMMaker image via either
> > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
> > > - run a converter, e.g.
> > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
> > > (produces trunk6-64.image & trunk6-64.changes)
> > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
> > > (produces trunk6-64-32.image & trunk6-64-32.changes)
> > >
> > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
> > > my 2.9GHz Core i9 MacBook Pro
> > >
> > >
> > > So let's try releasing by converting the 64-bit image into a 32-bit one.
> > >
> >
> > Bravo! I am away now but will try doing an image conversion as soon as
> > I can tomorrow.
> >
> > Thanks Eliot,
> >
>
>
>
>
>
>
>

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

best, Eliot

K K Subbu

Re: Letting the VM run multiple image formats

In reply to this post by Eliot Miranda-2

On 10/02/20 10:09 PM, Eliot Miranda wrote:
>> The default prefix path should be changed to something like
>> $HOME/.squeak or $HOME/.config/squeak so that default installations
>> will not require root permission.
> +1000. But this is not really the prefix path, but the default
> installation. Can’t we easily compute the correct prefix path in
> the squeak launch script based on its path (i.e. from a combination
> of $0 and $PATH ?).

The prefix path gets recorded in the build directory Makefile, so the
install step in http://wiki.squeak.org/squeak/6177

$ make install

will fail because it requires a sudo. My proposal is to change the
default so that install will proceed smoothly for non-root users.
Package maintainers for distros can override this prefix in the
configure step.

Once installed, the squeakvm does compute the correct path for plugins
etc. from its installed location.

Regards .. Subbu

timrowledge

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by Eliot Miranda-2

> On 2020-02-11, at 9:12 AM, Eliot Miranda <[hidden email]> wrote:
>
> Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6
>
> Please check you have write permission for this file.

It's been my belief for a long while that what we should be doing in the all-in-one and other packages is to copy the default image/changes out of the package bundle to the enclosing directory (on the grounds that it's pretty close to certain to be a user's directory to do what they want with) and then run those copies. The supplied default image/changes should never be over written.

This is in line with a fairly common trope of starting any sort of editor program and getting a suitable 'blank' file. Obviously firing up a particular image via UI clicks etc would simply start the right image.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Oxymorons: Exact estimate

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by David T. Lewis

Hi David,

On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote:

Update - I resolved my library problem, and can run the traced image.
However, it opens with an empty black window (but no VM crash or error
messages).

Oops. My image converter correctly voids Smalltalk classPool at: #WordSize iff the image is 32-bit. If the image is 32-bit it does not void and so process terminate is broken because attempts to compute initialPCs are incorrect <blush>. The fix will be in in a few minutes.

The image that I converted was Squeak5.3beta-19335-64bit.image. I'll
try some others later.

Meanwhile if anyone else can give this a try, please do :-)

Dave

On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote:
> I need some help on this, can someone please test the converted 32-bit
> image on Linux and/or Windows? I'm have problems with my 32-bit libraries
> (I think) and I don't have any time to follow up on it today. Thanks!
>
> The actual image conversion seems to work fine, and it's fast. But I
> don't have a 32-bit VM at the moment, probably due to Linux runtime
> library issues that I don't have time to sort out this morning.
>
> Thanks!
> Dave
>
> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
> > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
> > >
> > > Hi David, Hi Release Manager, Hi All,
> > >
> > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
> > > >
> > > > A 64-bit to 32-bit image converter would be a very good thing to have
> > > > in our toolkit :-)
> > >
> > > I got this working this morning. See Cog-eem.398. So to use,
> > > - clone or update an opensmalltalk-vm repository
> > > - cd to the image directory and create a VMMaker image via either
> > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
> > > - run a converter, e.g.
> > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
> > > (produces trunk6-64.image & trunk6-64.changes)
> > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
> > > (produces trunk6-64-32.image & trunk6-64-32.changes)
> > >
> > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
> > > my 2.9GHz Core i9 MacBook Pro
> > >
> > >
> > > So let's try releasing by converting the 64-bit image into a 32-bit one.
> > >
> >
> > Bravo! I am away now but will try doing an image conversion as soon as
> > I can tomorrow.
> >
> > Thanks Eliot,
> >
>
>
>
>
>
>
>

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

best, Eliot

Eliot Miranda-2

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by Eliot Miranda-2

Hi David,

On Tue, Feb 11, 2020 at 6:09 AM David T. Lewis <[hidden email]> wrote:

I need some help on this, can someone please test the converted 32-bit
image on Linux and/or Windows? I'm have problems with my 32-bit libraries
(I think) and I don't have any time to follow up on it today. Thanks!

The actual image conversion seems to work fine, and it's fast. But I
don't have a 32-bit VM at the moment, probably due to Linux runtime
library issues that I don't have time to sort out this morning.

I can confirm that using Cog-eem.400 to convert the 64-bit to 32-bit image results in a functional result.

Thanks!
Dave

On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote:
> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote:
> >
> > Hi David, Hi Release Manager, Hi All,
> >
> > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote:
> > >
> > > A 64-bit to 32-bit image converter would be a very good thing to have
> > > in our toolkit :-)
> >
> > I got this working this morning. See Cog-eem.398. So to use,
> > - clone or update an opensmalltalk-vm repository
> > - cd to the image directory and create a VMMaker image via either
> > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh
> > - run a converter, e.g.
> > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'.
> > (produces trunk6-64.image & trunk6-64.changes)
> > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'.
> > (produces trunk6-64-32.image & trunk6-64-32.changes)
> >
> > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on
> > my 2.9GHz Core i9 MacBook Pro
> >
> >
> > So let's try releasing by converting the 64-bit image into a 32-bit one.
> >
>
> Bravo! I am away now but will try doing an image conversion as soon as
> I can tomorrow.
>
> Thanks Eliot,
>

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

best, Eliot

Eliot Miranda-2

Re: Letting the VM run multiple image formats

In reply to this post by K K Subbu

On Tue, Feb 11, 2020 at 9:32 AM K K Subbu <[hidden email]> wrote:

On 10/02/20 10:09 PM, Eliot Miranda wrote:
>> The default prefix path should be changed to something like
>> $HOME/.squeak or $HOME/.config/squeak so that default installations
>> will not require root permission.
> +1000. But this is not really the prefix path, but the default
> installation. Can’t we easily compute the correct prefix path in
> the squeak launch script based on its path (i.e. from a combination
> of $0 and $PATH ?).

The prefix path gets recorded in the build directory Makefile, so the
install step in http://wiki.squeak.org/squeak/6177

Ugh. This does not describe the standard VM build :-(

$ make install

will fail because it requires a sudo. My proposal is to change the
default so that install will proceed smoothly for non-root users.
Package maintainers for distros can override this prefix in the
configure step.

Once installed, the squeakvm does compute the correct path for plugins
etc. from its installed location.

The Cog VM build scripts install to a local directory, opensmalltalk-vm.git.products

So there's no issue with the standard VM, AFAIA

Regards .. Subbu

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

best, Eliot

Squeak - Dev mailing list

Re: Condensing sources for a new release

In reply to this post by Eliot Miranda-2

Holy shit, on such a slow machine! What would it take on a machine for mere mortals?My MacBook Pro is only 2.4gHz. Cant really test it out since MacOS Catalina is 64 bit only, and I ‘upgraded’ all my Macs because a flaw was supposed to be fixed in Catalina.

/————————————————————/

For encrypted mail use [hidden email]

Get a free account at ProtonMail.com

Web: https://objectnets.net and https://objectnets.org

https://datascilv.com https://datascilv.org

On Feb 10, 2020, at 08:49, Eliot Miranda <[hidden email]> wrote:

Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on my 2.9GHz Core i9 MacBook Pro

David T. Lewis

Re: Condensing sources for a new release

When I ran it, it took about ten seconds.

Time millisecondsToRun: [converter bootstrapImage: 'Squeak5.3beta-19335-64bit.image'] "==> 10031"

This is on a fairly old Linux laptop PC with "Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz" CPU.

Converting a full image from one image format to another is not a frequent
operation. I would be more than happy if it could be done in about a minute,
so seeing it completed in ten seconds looks pretty darn good to me.

Maybe somebody can report results on a Raspberry Pi :-)

Dave

On Tue, Feb 11, 2020 at 05:17:54PM -0800, John Pfersich via Squeak-dev wrote:

> Holy shit, on such a slow machine! What would it take on a machine for mere mortals?My MacBook Pro is only 2.4gHz. Cant really test it out since MacOS Catalina is 64 bit only, and I ???upgraded??? all my Macs because a flaw was supposed to be fixed in Catalina.
>
> /????????????????????????????????????????????????????????????/
> For encrypted mail use [hidden email]
> Get a free account at ProtonMail.com
> Web: https://objectnets.net and https://objectnets.org
> https://datascilv.com https://datascilv.org
>
>
> >> On Feb 10, 2020, at 08:49, Eliot Miranda <[hidden email]> wrote:
> > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on my 2.9GHz Core i9 MacBook Pro

Tobias Pape

Re: [Vm-dev] Condensing sources for a new release

In reply to this post by Eliot Miranda-2

> On 13.02.2020, at 01:32, Ronie Salgado <[hidden email]> wrote:
>
> There is a way to untranslocate an application an access to content outside the read-only mount: https://objective-see.com/blog/blog_0x15.html

This part looks promising:

> › creating a signed DMG
> Apple tells us that App translocation does not apply to disk images (DMGs) that are signed. So instead of using a ZIP archive to distribute the application, I looked into using a signed DMG. To create a signed DMG I used the following make file (kindly provided by one of Objective-See's users -mahalo Clayton!!):
> VERSION="1.5.0"
> PROJECT="TaskExplorer"
> CODESIGN_IDENTITY="Developer ID Application: Objective-See, LLC (VBG97UB4TA)"
>
>> ## dmg
>> dmg:
>> rm -f ./${PROJECT}*.dmg
>> rm -rf /tmp/${PROJECT}-build
>> mkdir -p /tmp/${PROJECT}-build/
>> cp -R ./TaskExplorer.app /tmp/${PROJECT}-build
>> hdiutil create -srcfolder /tmp/${PROJECT}-build -volname "${PROJECT}" -format UDZO
>> -o ${PROJECT}-${VERSION}.dmg
>>
>> xattr -rc ${PROJECT}-${VERSION}.dmg
>> codesign -s ${CODESIGN_IDENTITY} -v ${PROJECT}-${VERSION}.dmg
>> rm -rf /tmp/${PROJECT}-build

The untranslocate part relies on Apple Private APIs. We should not do that.

Best regards
-Tobias