Running !Squeak and !Scratch

Greetings folks,
well I have RISC OS 5.24 Pi loaded up and running on a Pi 3. I have been copying across important utilities such as SideDiff and Reporter. I have been completely failing to get SunFish or Omni to talk to my network. Pointers to how to correct this appreciated. It used to work, long ago.

I loaded up the new DDE and after some issues with amu not finding timestamps was able to run a bunch of example makefiles with apparent success. I am *not * currently able to compile any new Squeak VM since I’ve run into some changes affecting the C libraries; specifically the appearance of the ‘Export.APCS-32’ stuff. Some googling last night didn’t illuminate it for me so a pointer to details would help. In particular since I use OSLib I need to understand how that might be affected – should it be installed nasally, or perhaps in the APCS-32 directory, or left in the plain Libraries directory or what? Similarly, I use ‘rink’ which always used to just be a sibling of CLib. Where should it go? Should I expect it to still work?

If we can sort things out quickly there is a good chance I will be able to get RISC OS up to a Squeak 5.1 level fairly soon. Moving on to a Cog VM with dynamic translation is a bigger job even though the translator already exists for Raspbian since there are places where we rely on gcc intrinsics that may not be easy to translate to RISC OS, and I’ll need to work out how to replicate a thread timer. There’s also Ben Avison’s amazing assembler BitBLT speedups to port across. The net result of all that would be a 5-20X speedup, depending on the benchmark of course.

I have been completely failing to get SunFish or Omni to talk to my network. Pointers to how to correct this appreciated.

I think that the GUI front-end to SunFish does not function completely correctly on new processors. I’m not certain of this because I rarely use it anyway. I generally set up NFS access from RISC OS by creating a Sunfish image file (filetype 1b6) and double-clicking that to open the remote folder. Here is an example file:

Protocol: NFS2
Server: 192.168.1.123
Export: /home/example
UID: 1002
GID: 100

So if you are trying to connect to a Linux machine, you just need the user and group IDs to use, the server IP address and the path. Plus you need to have set up the Linux machine to accept connections from the RISC OS machine. I usually find that that is the harder part.

I’ve had trouble connecting via NFS to a Raspberry Pi running Raspbian. Perhaps Sunfish does not support the version of NFS I have on Raspbian.

I have been completely failing to get SunFish or Omni to talk to my network.

Tim,

If you are using Windows then it may be SMB1 is turned off. Try the hints at the following site:

https://www.bapfish.org.uk/networking.htm

If you are using a Mac then this site may help though it is a little old.

http://www.riscos.org/networking/tiger.html

this thread may also help.

https://www.riscosopen.org/forum/forums/11/topics/9646

As to the DDE stuff then I’ll defer to someone who has more knowledge.

I am not currently able to compile any new Squeak VM since I’ve run into some changes affecting the C libraries; specifically the appearance of the ‘Export.APCS-32’ stuff. Some googling last night didn’t illuminate it for me so a pointer to details would help.

I’ve no idea what Export.APCS-32 contains. It’s there, but it hasn’t caused a problem for me.

In particular since I use OSLib I need to understand how that might be affected – should it be installed nasally, or perhaps in the APCS-32 directory, or left in the plain Libraries directory or what?

I don’t know whether this is conventional, but I have OSLib installed somewhere completely different, so I think you can choose where to put it. On our computer it’s in $.Programming.Libraries.OSLib.OSLib and in there is an Obey file called SetVars which sets OSLib$Dir to the current directory and sets up OSLib$Path so that you can use “OSLib:” in #include lines and the make file:

Set OSLib$Dir <Obey$Dir>
Set OSLib$Path <OSLib$Dir>.

Note the full stop on the end: it’s important. You need to make sure SetVars has been run before you start compiling anything that includes OSLib.

Not sure how it works: I do not use OSLib myself that much, but I have it in place to compile the RUfl library, and its source files include lines like:

#include "oslib/font.h"

In particular since I use OSLib I need to understand how that might be affected

The base libraries should be available, as always, by path (C: for instance).

I have placed DeskLib in Libraries because it was a pain in the ass finding where the normal C stuff was so I didn’t want to bury DeskLib that far. It is explicitly filer booted during system startup so DeskLib: paths work.
Likewise for OSLib, once it has been “seen”, surely OSLib: paths will just work? I got Zap’s Zed editor built by invoking OSLib directly from an archive!

If you’re having problems, check how you’re referring to directories. I’ve come across code that does stuff like #include ^.^.^.etc. Yuck!

I have no idea what rink is; though the first question I’d ask (given the failure of the older gcc) is – is it ARMv8 compatible? If it won’t run on the machine, everything else is moot.

Matthew – thanks, I’ll try that. I can likely extract the info that used to work from the disc image of the older RISC OS.

Doug – I even remember reading the Vigay/Tiger article years ago. I’ll try some of that too.

Matthew (again) – the reason the Export.APCS-32 comes up is that the DDE !SetVars carefully sets all my path variables to point to places within it, which was the source of my puzzlement. I don’t know if that indicates some change in APCS requirements, whether that infers I need to change cflags in my makefiles, if OSLib can still be used (I have v7, which appears to be most recent), and of course I can’t find ‘rink’ as a sibling of CLib when CLib now points to somewhere unexpected.

Rick – I never did understand why OSLib wasn’t more integrated into the DDE library setup. The !SetVars carefully sets paths for all the ‘normal’ libraries explicitly even though it seems it ought to be pretty simple to do the job for any and all subdirectories. ‘rink’ is ‘Runtime lINKer’ which makes it simple to have code modules install and link at runtime if and when needed. I use it for all the files you’d notice as ‘plugins’ insode the !Squeak directory. Since the VM does run I feel safe in assuming the rink runtime to be ok on a Pi 3 just as it was on a Pi 1. It’s the building part that worries me a little in light of the APCS32 stuff.

Just catching up on this thread and existing to here an update to 5.1 might be possible. I am starting to figure out a little more how to actually use !Squeak and wish I had discovered this years ago as I think it is a great playground for experimenting with code. It makes a change from my day job of C# and javascript.

Andrew, you might well find that a 5.1 image will run on the existing VM. I have to admit to not having tried it yet but generally we’ve always worked quite hard to make sure that images can run on newer VMs than the image’s own vintage. It’s not always successful and for the latest system we have a new and incompatible object format that requires a completely different VM. The benefit is a considerable speedup and easier conversion to 64bit stuff; the cost is some confusion and inconvenience for users of older systems. The ‘split line’ is at the 4.6 → 5.0 change. The 4.6 & 5.0 images are functionally the same with only the object format altered, so you should be ok running a 4.6 image on the current RISC OS !Squeak app.

You can grab a copy of the 4.6 system from http://files.squeak.org/4.6/Squeak4.6-15102.zip and you’ll needc the updated .sources file too from http://files.squeak.org/4.6/SqueakV46.sources.zip – stick the sources file in the application directory alongside the older one (SqueakV41.sources I think) and you should be able to just d-click on the Squeak4.6-15102.image file to run it.

I hope to get to make a v5+ VM sometime soon, though it will require a completely different build set up. And then comes the fun of getting the Cog dynamic translation working…

Some news –
Using the Sunfish obey files as recommended by Matthew worked straight away. A non-obviouls point was the way that the filename of the obey file is used as the effective name of the pseudo-directory that is ‘mounted’. It is kind of cool that access wirks even withing Squeak with no problems.

The VNCServ module seems to work pretty well, making it a whole lot easier to actually work on RISC OS, which is very nice. I was startled to find it isn’t an !app and has no meaningful hints about where to install it etc. I’m currently using a 16bpp HD-size screen with decent performance and rendering.

The 4.6 image I suggested works nicely for me; there are a couple of simple perfromance improvements that can be done to make things nicer pro tempore. I’ll try to upload a prepared version to make life simpler.

Problems – I don’t seem to be getting any command/control/etc key stuff, despite them working ok in StrongEd etc. Maybe this is an interaction (or more likely a failure of interaction) with DeepKeys? Anyone know how to improve that?