Hi

On 5. Sep 2021, at 19:31, David T. Lewis lewis@mail.msen.com wrote:

I think that the 32-bit / 64-bit spur installation conflict is resolved in branch dtl/distinct-VERSION_TAG, although it could use a second set of eyes before I'd feel comfortable merging it.

is that the bit-ness of the image the binary understand or the bit-ness of the binary itself? -t

Dave

On Sat, Sep 04, 2021 at 03:59:34PM -0400, David T. Lewis wrote:

...

One caveat on this update - There is a remaining name space collision between 32-bit spur and 64-bit spur64 (same ./lib/squeak/<version> directory) when the two VMs are built from the same code base. You can install 32-bit V3 cog with 64-bit spur64 on the same machine without issue though. I'm not sure if this conflict is worth worrying about, but if so an additional update would be needed to provide distinct directory names for the 32 and 64 bit spur VMs.

A simple workaround is to install the 32-bit and 64-bit spur VMs from different git commit levels (i.e. just install a 32-bit VM that was built a week or so ago).

Dave

On Sat, Sep 04, 2021 at 12:16:51PM -0700, David T Lewis wrote:

...

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: a385f5b69e7bda720e980dd61e683a0bf4810cd7 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a385f5b69e7bda720e9... Author: David T. Lewis lewis@mail.msen.com Date: 2021-09-04 (Sat, 04 Sep 2021)

Changed paths: M platforms/unix/config/Makefile.install M platforms/unix/config/configure M platforms/unix/config/make.cfg.in

Log Message:

Add a configure option to specify name of the installed squeak run script. When running configure from a ./mvm script, the following command line option is now available:

--scriptname=SCRIPT run script name installed in PREFIX [squeak]

This allows the various mvm scripts to specify scriptname such that sudo make install will install /usr/local/bin/spur64 for a 64-bit spur VM, /usr/local/bin/cog for a 32-bit cog VM, and so forth. Does not affect naming of squeak.sh, which may be subject to similar name space conflicts. A corresponding update has been made to the cmake/configure installation for the classic interpreter VM (squeakvm.org SVN repository).

On 5. Sep 2021, at 22:43, David T. Lewis lewis@mail.msen.com wrote:

On Sun, Sep 05, 2021 at 08:51:44PM +0200, Tobias Pape wrote:

...

Hi

...

On 5. Sep 2021, at 19:31, David T. Lewis lewis@mail.msen.com wrote:

I think that the 32-bit / 64-bit spur installation conflict is resolved in branch dtl/distinct-VERSION_TAG, although it could use a second set of eyes before I'd feel comfortable merging it.

is that the bit-ness of the image the binary understand or the bit-ness of the binary itself? -t

It's the bit-ness of the binary itself.

For the opensmalltalk-vm VMs, this amounts to the same thing, although in theory the image word size could be independent of host word size. But in any scenario, you don't want to mix 32-bit and 64-bit executable files in the same /usr/local/lib/squeak/<foo> directory, so the simple check for sizeof(void *) should serve for the forseeable future.

As an aside, in the interpreter VM a similar installation naming convention is used, but in that case it refers strictly to image word size regardless of host word size. Thus the naming conventions are similar, but they actually mean different things on opensmalltalk-vm compared to squeakvm.org interpreter VM. But for now that difference does not matter.

ACK. -t

On Tue, Sep 07, 2021 at 09:15:50PM -0500, Chris Muller wrote:

Hi Dave,

This is something I've wanted for a long time, thank you!

As an aside, in the interpreter VM a similar installation naming

...

convention is used, but in that case it refers strictly to image word size regardless of host word size. Thus the naming conventions are similar, but they actually mean different things on opensmalltalk-vm compared to squeakvm.org interpreter VM. But for now that difference does not matter.

Just to clarify, is each flavor now producing a fully unique name, or is there still a potential naming conflict with interpreter VM's?

Hi Chris,

The short answer is yes, the name spaces are unique and the naming conflict is (or will be) eliminated.

There are several moving parts in play here, so for background:

1) Pull request PR 585 is part of Phil's work to update the Debian squeak-vm package to include opensmalltalk-vm along with classic interpreter VMs in the package. Until now, only the older interpreter VMs were provided, so this will be an important step forward.

2) Pull requests PR 590 and PR 591 are my attempt to support Phil's efforts by enabling distinctly named /usr/lib/squeak/<foo> installation directories and distinctly named /usr/bin/<foo> start scripts when VMs are installed in standard Unix directories.

3) Subversion update r3810 (squeakvm.org SVN repository) complements PR 590 and PR 590 by providing similar distinct naming for the interpreter VM (e.g. the ability to install /usr/bin/squeakvm instead of /usr/bin/squeak to avoid name space collision with the heavily overloaded /usr/bin/squeak script name).

Taken as a whole, these updates enable the full range of Squeak VMs to be installed on a single Unix (Linux) system in the standard Unix/Linux directory conventions. The changes do not (I hope) cause any problems or conflicts for the VMs that are normally built in the ./products directory for opensmalltalk-vm VMs.

I should emphasize here that from my point of view I think that Phil's work to produce a solid Debian package is the primary goal, and the updates that I have added are intended to support this (although I suspect that I have inadvertently complicated his efforts by throwing some new PRs into the mix, sorry about that).

The PRs still need a few more eyeballs, but once integrated we should be in a better position to supporting Debian, and therefore also to support the large community of Raspberry Pi users who get their Squeak/Slack/Etoys through Debian.

Dave