[Vm-dev] one more thing which may be scratch, may be the vm....

[David Corking]

Bert Freudenberg  wrote:

> (we hope Linux packagers will hide the VM selection details behind a common squeakvm script that launches the right binary for the image)
>
>>>> I can test in a i386 VM if it helps. (Well, not the camera.)
>>> You could simply run the i386 version of Squeak in your 64 bit Linux. That
>>> should work perfectly fine.
>>
>> That's okay for me, but it's not okay for the Fedora Linux distribution I'm
>> working on packaging it for.
>>
>>> This might do the job of installing it (untested):
>>>      sudo yum install squeak-vm.i686
>>
>> We generally only have 32-bit versions of packages in x86_64 when they're
>> white-listed in for a specific reason.
>
>
> Having "working software" might be a good reason? ;)

I agree with Bert. Fedora allows us to install 32-bit packages. The
user needs to install all the dynamically linked 32 bit shared object
libraries too: which would be easier if the 32-bit dependencies were
listed in an RPM. But once this is done, Squeak works perfectly,
including the camera, as far as I know (I didn't try all the plugins
yet.) The alternative would be for a team of x86_64 enthusiasts to
discover and squash all the bugs introduced by selecting 64-bit
architecture options for the C compiler.

Thanks to Jaroslav's great work incorporating David Lewis's recent
x86_64 bug squashed code in the Fedora source RPM, Fedora 18 is in a
much better shape than earlier releases (
https://bugzilla.redhat.com/show_bug.cgi?id=879974 )

Where is the right place to influence the Fedora decision-making
process? I take it you (Matthew) and Jaroslav can't make the decision
to go 32-bit on your own.

One thing we could keep an eye out for, to avoid it happening again,
is when the Fedora buildbot reported x86_64 failed builds for F15(?)
onwards, and the automatic build process fell back to distributing an
old and broken 64-bit squeak vm in the six-monthly releases. The
Sugar-on-a-Stick community then automatically published x86_64 spins
of Fedora whose Etoys and Scratch didn't work! (In my own experience,
Squeak was one of several Sugar packages completely broken in Fedora
16 x86_64.)

I may be wrong, but I wonder if these concerns are also relevant for
the other 64-bit platforms that Fedora builds for. (Alpha, Sparc etc
still around? 64-bit ARM?)

On the same topic, will 32-bit ARM Squeak (Linux, Android, iOS,
Windows, or RiscOS) run on the new 64-bit ARM platforms?

Matthew wrote:

> the Help
> Screens function (which is supposed to launch a browser with HTML help) does
> not work. If I copy in the so.ScratchPlugin from the Scratch package,
> however, it works fine.
> (Code is 'ScratchPlugin primOpenURL: helpDir pathName, FileDirectory slash,
aFilename')

In 2011 there was a Pharo Scratch community, 'Scat', (links below)
that forked MIT's Smalltalk branch of Scratch, when MIT efforts
refocused on Actionscript Scratch. Perhaps there is functionality in
the current Squeak / Pharo that duplicates the functionality of the
OpenURL primitive. If I recall correctly, modern Squeak can launch a
browser on most common desktops without a special plugin. Anyway, it
might be worth suggesting to the Scat community or looking into more
deeply, if not for the short term gain of wroking around a bug, for
the long term benefits of Don't Repeat Yourself :)

Have fun! David

Scat links:
http://code.google.com/p/scat/
http://www.squeaksource.com/nscratch.html