squeak-smalltalk / squeak-app Goto Github PK

Apparently, our repository does no longer exists on <travis-ci.com> (504 Gateway Timeout). As a consequence, the latest build in http://files.squeak.org/trunk/ is from 2021-07-06.

We should either fix the Travis configuration or migrate to GitHub Actions.

squeak.sh should come with a version number and a modification date (Source)

Currently, all new builds are uploaded to our file server and all old builds are kept. This requires quite some disk space that we could free, if we only keep the last X builds.

• Squeak.def
• Squeak.exp
• Squeak.lib
• Squeak.res
• SqueakConsoleUnstripped.exe
• SqueakUnstripped.exe

This here is not working right now:

./squeak.sh -- --doit '2 + 3'

2
SyntaxErrorNotification: "Nothing more expected ->"+
3

I've already sketched a simple solution in my working copy that uses an array rather than string concatenation in the shell script. Will commit it soon!

looks like there are some quotes missing here, which leads to problems when having spaces in the path

this vm-version seems to address a similar problem :)

See title.

squeak.bat is currently unable to pass any arguments to the VM.

Originally posted in #25

Both squeak.sh scripts (1, 2) don't allow to pass arguments in, for example -nodisplay.

All recent bundles with a unified binary for macOS (i.e., both x64 and ARMv8) are not usable, such as:

• Squeak6.1alpha-22943-64bit-202312181441-macOS.dmg
• Squeak6.1alpha-22943-64bit-All-in-One.zip

Meaning, the ones with the newer OSVM 2023.12. This is because the folder structure is different between x64 and ARMv8:

• files.squeak.org/base/Squeak64-trunk/vm-macos.zip/Squeak.app/Contents/Resources/English.lproj/MainMenu.nib (! folder !)
  • keyedobjects.nib
  • keyedobjects-101300.nib
• files.squeak.org/base/Squeak64-trunk/vm-macos-arm.zip/Squeak.app/Contents/Resources/English.lproj/MainMenu.nib

We build x64 for macOS 10.9 and later. We build ARMv8 for macOS 11.0 and later.

We had to switch GitHub Actions runner from macos-10.15 to macos-11. With it, we seem to use XCode 13.2.1. Through that, the usr/bin/ibtool seems to produce an output that is now different to ensure compatibility for macOS 10.9 and later, which results in MainMenu.nib being a folder (or bundle) with two different .nib files.

More interestingly, none of those keyedobjects* files matches the MainMenu.nib from the ARMv8 build, which has compatibility for macOS 11.0 and later.

Thus, our code for creating the unified binary is broken. The .nib files do not match anymore.

All other bundles are not affected. macOS users should download dedicated x64 or ARMv8 bundles for now. The all-in-one is thus not working for macOS.

Hi,

is my assumption wrong or should Bintray include builds for Win32, too? Is there something broken?

If you open a fresh trunk bundle, the height is not 768 but less.

The situation occurs when using the Linux bundle and when there is a hidden folder in the shared/ folder which contains a .image file (for example a .git repository which contains a .image file somehwere).

The problematic line seems to be the find call in ensure_image which finds all *.image files under shared/ and seems to sort differently on Mint so that the .image file in the hidden folder appears first.

Observed by @ekrebs5

Reference.

Maybe add a check/helper to the squeak.sh launcher.

There are two versions of the squeak.sh script for the linux-only release and the AiO bundle. Deduplicate both (perhaps write a tiny script to copy them over) so that both versions benefit from new changes, such as audio server detection.

Originally posted by @LinqLover in #17 (comment)

Should we have some simple acceptance tests for this wouldn't this be worth the effort at the current stage?

Maybe also open an issue for this.

Originally posted by @marceltaeumel in #25 (comment)

Currently the System package in the latest trunk image http://files.squeak.org/6.0alpha/Squeak6.0alpha-16852-32bit/Squeak6.0alpha-16852-32bit.zip is dirty.

OpenSmalltalk-VMs do not ship with this SqueakSSL version. The plugin that ships with them appears to cause problems at least on Linux.