Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Access Underlying Squeak on Jessie

Wed Mar 23, 2016 6:36 pm

How can I set up a Pi menu item on Jessie to open Squeak which underlies Scratch? I want to program in Squeak and access the electronics, without the Scratch GUI.

I opened the Main Menu Editor and under Programming checked the Squeak entry. Squeak shows up with an icon, so I clicked it and the wait mouse pointer turned for a while then nothing. I also opened the Application Launch Bar to put Squeak up top but it was not listed under installed applications. What do I need to do?

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Access Underlying Squeak on Jessie

Wed Mar 23, 2016 7:42 pm

[Edit: Jan 22 2017 to update versions of Squeak on the relevant website]

Easy! I'm assuming you know about using Squeak or you probably wouldn't ask the question, but I'll also try to explain this so somebody with not much knowledge might be able to follow it so please don't feel I'm talking down to you.

There's two ways; one really trivial, one a tiny bit more complex.

The trivial way is to go to http://www.squeak.org/downloads find the Quick Download section and click on the link for the 'All-in-one 5.1' package. When you unzip that you will find two files and a directory tree - if you are in the relevant directory simply running ./squeak.sh should fire everything up ok. The somewhat odd directory tree is due to making this download something that can run on linux-X86/linux-ARM/Windows/OS X.

The downside of this is that you would have to open a terminal, cd to the directory and run the shell script every time. You could of course make a desktop file to deal with that.

The slightly more complex way to do things would be to do the download as above and extract the important files and put them in 'proper' places on your Pi. The Squeak Virtual Machine is already in place, obviously, since it is used to run Scratch. So is a shell script to start it up (/usr/bin/squeak in fact). So all we need are
a) the 5.0 sources file, which you'll find as 'Squeak-5.1-16548-32bit-All-inOne/Contents/Resources/SqueakV50.sources' (Note how the sources file is still the 5.0 version; we don't replace it for every minor release)
b) the 5.1 image file, Squeak-5.1-16548-32bit-All-inOne/Contents/Resources/Squeak5.1-16548-32bit.image'
c) the relevant .changes file, Squeak-5.1-16548-32bit-All-inOne/Contents/Resources/Squeak5.1-16548-32bit.changes'

You could also use the Linux(ARM) download; you'll find the image, changes and sources files in the 'shared' directory.

Copy them to wherever you want to run Squeak - I'd suggest just a directory under your normal home directory.

To run, just use

Code: Select all

squeak Squeak5.1-16548-32bit.image
Personally I'd advise changing the permissions on the .image file to read-only but that's up to you. My view is that the first thing you ought to do is start up the default image and save it under a new name so that the default is not mucked up. That's why I'd suggest setting it read-only. Obviously you'd then use

Code: Select all

squeak mychosenname.image
I have actually had emails from people forgetting that part.

Also you can make a desktop file to run it. And you can associate the squeak script with all .image files via the 'Open With...' dialogue in Raspbian.

One extra point - if you use xrdp for your display like I do (I have a dozen Pis and couldn't possibly have a monitor each) then you'll need to add a 'sudo' to the front of the command line since there is some weird permissions bug that xrdp exposes.
Latest versions of Raspbian remove the need to worry about that, at least mostly.

Aside from that, anyone not familiar with Squeak will really benefit from visiting the http://www.squeak.org site to subscribe to the mailing list and asking questions. I warn you, it's addictive; I've been doing it to make a living for 35 years now.
Last edited by timrowledge on Sun Jan 22, 2017 11:38 pm, edited 1 time in total.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Thu Mar 24, 2016 2:14 pm

Thank you! For the benefit of newer Smalltalkers using Squeak, let's continue discussing details.

If you are just learning Squeak writing tiny programs, a read-only image is fine and you can fileout and filein your code each session. If you are doing a larger project that will take many days or months, a write-able image is helpful to do programming that lasts between sessions so it is best to practice separating system and programmer until you are advanced enough to write a Smalltalk yourself. Keep a read-only image or the .zip file, use a copy, and delay damage by never altering supplied classes, always keep your work in your own categories and classes then fileout your code frequently so you don't lose your work, and back the fileouts up on a thumb drive or disk in case of power loss during an SD card write or other sources of damage.

One odd glitch is sometimes double clicking on the Squeak icon may produce an attempt to open two images, resulting in an error message - be careful not to save the one that gives that error. It's pest to right click and use the open menu item instead of double click and get two images by mistake. With these tips, Squeak should remain as secure as any language as you develop your code.

xrdp is new to me, I'm looking it up. I only have one Pi but I'm thinking of trying to run a robot using many Pi's for machine vision - maybe split up a frame into quadrants then contour, and identify the objects each in a Pi then bring them together to get a real time vision system. I'll use Squeak for most of it until I get code that works but must run faster, then down-translate it to say C.

> "I've been doing it to make a living for 35 years now."

Very interesting. I tried to sell a database for Digitalk Smalltalk/V but got less than 10 orders. How do you, or how can I make a living with Smalltalk? I am making a living in a non-tech field now, but as a hobby developing a new language and tools for my robot which doesn't pay until it works and sells.

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Access Underlying Squeak on Jessie

Thu Mar 24, 2016 5:46 pm

Kirk Fraser wrote:If you are just learning Squeak writing tiny programs, a read-only image is fine and you can fileout and filein your code each session. If you are doing a larger project that will take many days or months, a write-able image is helpful to do programming that lasts between sessions so it is best to practice separating system and programmer until you are advanced enough to write a Smalltalk yourself.
I'd disagree fairly strongly with that approach because it involves throwing away one of the most useful parts of a Smalltalk system - the persistence of environment. Being able to save your work and restart from exactly where you left off, even on a different machine (i.e I can do some work on my iMac, save it, copy the image file to a friend's PC, do some work on it, save that, copy to one of my Pis, work on it etc ad infinitum) is a massive advantage. That this works even when in the middle of a debugging session is fantastic.

My routine is start a release image, save it with a new name (and try to remember to make it a descriptive name so you will know in six months time what it was all about) and work away, saving reasonably frequently in case of the occasional total-screw-up-bug. The new code I write and code I edit is all saved in the .changes file as a transaction log which can be examined later if one has problems; tools can show you what you did in what order, compare versions saved etc. The normal code management tool in Squeak is 'Monticello' which can save chunks of code in packages in various ways, with assorted margin, comparing, tracking & versioning capabilities. It's way more sophisticated than the original Smalltalk changes tools, though those are still alive and usable if one prefers.

Kirk Fraser wrote:Keep a read-only image or the .zip file, use a copy, and delay damage by never altering supplied classes, always keep your work in your own categories and classes then fileout your code frequently so you don't lose your work, and back the fileouts up on a thumb drive or disk in case of power loss during an SD card write or other sources of damage.
I almost agree with that - if you save the image you don't need to keep worrying about filing out code anywhere near as much, and with the changes log you can recover it even if you manage to totally explode your machine. Unless you actually explode something and physically burn down your Pi/Sd card/house. So yes, definitely do the backup dance just like any other computer system. It's perfectly ok to edit the built-in system classes too; so what if you break something? The worst that can happen is that you have to start a new image, load your packages fro mMonticello and work out where you got stupid... I do it all the time because I do low-level system work so much.
Kirk Fraser wrote:One odd glitch is sometimes double clicking on the Squeak icon may produce an attempt to open two images, resulting in an error message - be careful not to save the one that gives that error. It's pest to right click and use the open menu item instead of double click and get two images by mistake. With these tips, Squeak should remain as secure as any language as you develop your code.
Well that's the linux UI at fault there and I accept no blame for how awful it is. People have been working hard for decades to make it that wrong. RISC OS should have won.
Kirk Fraser wrote:xrdp is new to me, I'm looking it up. I only have one Pi but I'm thinking of trying to run a robot using many Pi's for machine vision - maybe split up a frame into quadrants then contour, and identify the objects each in a Pi then bring them together to get a real time vision system. I'll use Squeak for most of it until I get code that works but must run faster, then down-translate it to say C.
xrdp or vnc or whatever; they're all usable to various degrees.
Image processing in Smalltalk can be surprisingly fast since we have all that clever BitBlt stuff ( especially on the PI where Ben Avison did a fantastic ARM-specific variant which hugely improved Scratch performance) and if you do find bits that are big loops of bit-flinging - which is not something that gets much advantage from a proper OOP system - then you can convert said loop(s) to C and make a plugin that can be called from Squeak. We do it all the time for file, socket, window, encryption, blab-blah-blah stuff.
Kirk Fraser wrote: > "I've been doing it to make a living for 35 years now."

Very interesting. I tried to sell a database for Digitalk Smalltalk/V but got less than 10 orders. How do you, or how can I make a living with Smalltalk? I am making a living in a non-tech field now, but as a hobby developing a new language and tools for my robot which doesn't pay until it works and sells.
Same as most things - get obsessed, get good, get known, get involved, get lucky. I got interested as a way of prototyping UIs for CAD systems back around 1981, then got involved when I was an IBM Research Fellow working on CAD UI at the Winchester UK Scientific Centre (remember, CAD was pretty much big mainframe and special terminal stuff back then) and just drifted into teaching and implementing Smalltalk systems after that. Worked on the Active Book, spent time in Silicon Valley as the manager of Smalltalk Development for ParcPlace (spun out of XEROX PARC to commercialise Smalltalk) and various other research labs; worked on making Smalltalks for assorted iPAD-like things decades before iPads. It just happens.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Fri Mar 25, 2016 3:59 am

Today after working on putting Squeak 5.0 on my Raspberry Pi I'm sure of one thing, Linux was not made for kids or beginners of any age, except in price. One thing I recommend every new Pi user do is create a text file "Sudo Code" to keep necessary Linux commands around after they expire from human memory. sudo chmod 777 /usr/lib/squeak/5.0 was needed to allow me to copy the changes, image, and sources files to that directory created using File Manager. I toiled nearly blindly until I happened to get the Squeak icon up on the menu bar and only one problem remains, it doesn't work.

So I next messed with trying to change the .sh file and copied what I guessed might be the squeak vm file for Linux to that directory - an executable named squeak from the Linux side 9f the all-in-one files. So now my .sh has only one line exec "squeak" "Squeak5.0-15113.imge". But that won't start Squeak either from that directory or another version with paths on the desktop, and the Application referenced by the Squeak icon doesn't work either. Further suggestions please!

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Fri Mar 25, 2016 6:27 pm

Run
squeak Squeak5.0-15113.image
does not work even after deleting my extra .sh files. Could the newest Raspbian requires something else? Na it's most likely the squeak command needs the path.
squeak /usr/lib/squeak/5.0/Squeak5.0-15113.image
That works!

So kids, the path is an important piece missing from the first code statement.. The exact path will vary based on where you put the three Smalltalk files. Now it should be easy to update the icon to run the correct statement.

Some parts of the above discussion on protecting files may be confusing. If it's your own Pi and nobody else will access it, there is no need to keep the working Smalltalk files read only which could prevent writing changes. The backup files may be protected or put on an external storage device.

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Sat Mar 26, 2016 2:42 am

timrowledge wrote:
Same as most things - get obsessed, get good, get known, get involved, get lucky. I got interested as a way of prototyping UIs for CAD systems back around 1981, then got involved when I was an IBM Research Fellow working on CAD UI at the Winchester UK Scientific Centre (remember, CAD was pretty much big mainframe and special terminal stuff back then) and just drifted into teaching and implementing Smalltalk systems after that. Worked on the Active Book, spent time in Silicon Valley as the manager of Smalltalk Development for ParcPlace (spun out of XEROX PARC to commercialise Smalltalk) and various other research labs; worked on making Smalltalks for assorted iPAD-like things decades before iPads. It just happens.
With CAD as your main focus, how did Smalltalk fall so far behind Autocad, Solidworks, etc.? I had access to Solidworks and it was amazing to see a color 3D model i made spin fast without a special graphics card. I wrote a Smalltalk graphics program to display the results of G-Code files when I was trying to etch a printed circuit board with a desktop CNC mill (a mistake). It does do graphics but not as photo realistic or fast as some of today's CAD and game programs.
mrowledge wrote:
I'd disagree fairly strongly with that approach because it involves throwing away one of the most useful parts of a Smalltalk system - the persistence of environment. Being able to save your work and restart from exactly where you left off, even on a different machine (i.e I can do some work on my iMac, save it, copy the image file to a friend's PC, do some work on it, save that, copy to one of my Pis, work on it etc ad infinitum) is a massive advantage. That this works even when in the middle of a debugging session is fantastic.
One of the nice things about the Model View Controller concept is to be able to view and use Smalltalk differently from the paradigm of image based programming. While it may not be noticeable on high end computers, if you bring your image to your friend's Pi, you'll have to wait longer to load it than you would to file in your source code. But in some cases showing a friend your exact debugging problem would help.
mrowledge wrote:
if you do find bits that are big loops of bit-flinging - which is not something that gets much advantage from a proper OOP system - then you can convert said loop(s) to C and make a plugin that can be called from Squeak. We do it all the time for file, socket, window, encryption, blab-blah-blah stuff.
Fantastic, now where is a tutorial on how to do that? How do I learn how to interact with a USB device in real time, with Squeak or in the case of a webcam, in C controlled by Smalltalk? I've tried to learn how to write the camera.dll that brings video into Squeak but can't find the source code, with even less clue about how to do it in Linux on a Pi.

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Access Underlying Squeak on Jessie

Sat Mar 26, 2016 6:32 pm

Kirk Fraser wrote:sudo chmod 777 /usr/lib/squeak/5.0 was needed to allow me to copy the changes, image, and sources files to that directory created using File Manager.
I'm not terribly sure why you wanted to put the image/changes/sources in /usr/lib ? I suppose there might be an argument for putting default copies of the image/changes in somewhere like /usr/share/blah and making the squeak shell script copy them to your working directory if no special path was provided...

The sources file can reasonably conveniently live in the same directory as the virtual machine (for example /usr/lib/squeak/5.0-3553 is current on my machine) but I'd say it's easier to just keep it in you working directory for Squeak related things. Any time you update the VM (which can be quite frequent if you take an active interest since we constantly improve it) you'd need to copy/move/link the sources file to the directory for the new vm - we're up to 5.0-37-something for the development vm right now.
Kirk Fraser wrote: I toiled nearly blindly until I happened to get the Squeak icon up on the menu bar and only one problem remains, it doesn't work./quote]
Well the making-a-desktop-file thing is a standard job that a linux-spirt can explain. Those files will be in some well-buried directory.
Kirk Fraser wrote: So I next messed with trying to change the .sh file and copied what I guessed might be the squeak vm file for Linux to that directory - an executable named squeak from the Linux side 9f the all-in-one files. So now my .sh has only one line exec "squeak" "Squeak5.0-15113.imge". But that won't start Squeak either from that directory or another version with paths on the desktop, and the Application referenced by the Squeak icon doesn't work either. Further suggestions please!
You don't need to do that. The relevant ARM Squeak vm is in /usr/lib/squeak/5.0-whatever and the squeak shell script is in /usr/bin - no need to mess with them at all so far as I can tell.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Access Underlying Squeak on Jessie

Sat Mar 26, 2016 6:49 pm

Kirk Fraser wrote:With CAD as your main focus, how did Smalltalk fall so far behind Autocad, Solidworks, etc.?
Smalltalk was never in the same market as actual CAD applications; I used it initially as a way to develop conceptual UIs for CAD. Sort of software magic markers and plasticine.
Kirk Fraser wrote:One of the nice things about the Model View Controller concept is to be able to view and use Smalltalk differently from the paradigm of image based programming. While it may not be noticeable on high end computers, if you bring your image to your friend's Pi, you'll have to wait longer to load it than you would to file in your source code. But in some cases showing a friend your exact debugging problem would help.
Uh? I'm baffled by this. MVC was the early ui paradigm - we use something called Morphic these days - and I don't seen any connection between that and the paradigm of image based computing...

Also, why do you think copying an image file from one machine to another would take a long time? The typical current development image is ~35Mb (largely the screen bitmap and font bitmaps and a load of code strings etc, something I constantly work to reduce) and takes a few seconds to copy from one Pi to another across the net. Filing out code, copying that and filing it in is likely to take much longer in my experience and copying an image has the advantage that you know *exactly* what state it is in. It's also worth noting that with the latest Cog/Spur version of Squeak the Pi is pretty damn fast. Like around one thousand times faster than the Smalltalk systems I used back then.
Kirk Fraser wrote:
timrowledge wrote:
if you do find bits that are big loops of bit-flinging - which is not something that gets much advantage from a proper OOP system - then you can convert said loop(s) to C and make a plugin that can be called from Squeak. We do it all the time for file, socket, window, encryption, blab-blah-blah stuff.
Fantastic, now where is a tutorial on how to do that?
You'll find all sorts of stuff on the squeak wiki ( wiki.squeak.org ) and more by joining the mailing list (http://lists.squeakfoundation.org/mailman/listinfo) and talking with the experts. I'd suggest the plain vanilla Squeak-dev list to start with.
Kirk Fraser wrote:How do I learn how to interact with a USB device in real time, with Squeak or in the case of a webcam, in C controlled by Smalltalk? I've tried to learn how to write the camera.dll that brings video into Squeak but can't find the source code, with even less clue about how to do it in Linux on a Pi.
USB usually seems to be just files in my experience - like most things in file obsessed linux - and things like cameras are generally very OS specific. In the case of the Pi and the Pi camera for example we have a CameraPlugin that is include in the default vm anyway, which works via video4Linux or v4l2 (I think). So any camera that works with that will be ok. 'Camera.dll' couldn't possibly work on a Pi since it is a Windows dll :-) As for the Smalltalk level code to drive that camera ... I'll have to look for that since I don't recall right now.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Mon Apr 04, 2016 12:38 pm

Kids, Note the instructions above do not put one into the Squeak underlying Scratch but install the latest version of Squeak without Scratch. By searching online I found Tim had helped another person on another forum access the camera code in Scratch by telling him to get it out of the Scratch changes file. This is a bit tedious as you have to copy out the latest version of each method of related classes - there may be older versions of the same methods you don't want.

The reason I chose to put my Squeak 5 in path /usr/lib/squeak/ is because the instructions said to put it anywhere I want and i found a squeak sub directory is already there, pre-installed for Scratch. There in another folder one finds the camera primitive accessed by the Squeak code.

My reason for using Squeak for camera work initially even though it is way too slow for real time is Squeak provides tools to inspect, explore, halt, and write things to transcript which make it possible to find and fix teeny little bugs and write code easier than in many other languages since you don't have to worry about memory management usually.

You may have to value your own code by file out and file in for backups since I once read the Package system doesn't work, and it's far easier than manually sifting through the changes file to find more than a method or two of lost code. I don't know if the packager has been fixed in a recent release. Try it and come to your own conclusion.

timrowledge
Posts: 1257
Joined: Mon Oct 29, 2012 8:12 pm
Location: Vancouver Island
Contact: Website

Re: Access Underlying Squeak on Jessie

Tue Apr 05, 2016 5:16 am

Kirk Fraser wrote:You may have to value your own code by file out and file in for backups since I once read the Package system doesn't work, and it's far easier than manually sifting through the changes file to find more than a method or two of lost code. I don't know if the packager has been fixed in a recent release. Try it and come to your own conclusion.
Monticello has been the production package manager for around a dozen years. It's reliable.
If you manage to crash the system (which you can, since it is quite permissible to fire around in the deepest roots of the image and change anything, which sometimes means the wrong thing) then all your changed code and recorded 'do its' are in the changelog and those can be browsed with normal tools provided for you. No manual digging in text files etc. We don't like dealing with mere text.
Making Smalltalk on ARM since 1986; making your Scratch better since 2012

Kirk Fraser
Posts: 50
Joined: Thu Feb 13, 2014 6:52 am

Re: Access Underlying Squeak on Jessie

Fri Apr 15, 2016 4:42 pm

Unanswered questions:
1) How does one access a USB peripheral from Squeak on RPi?
2) How does one access WiFi from Squeak on RPi?
3) How does Squeak handle multiple cores on RPi 3?
4) We have a way to access Scratch Smalltalk code for a Camera, how do we get the C++ code?

Juggling Forums - I posted on [squeak-dev] but only got this:
http://car.mines-douai.fr/category/software/pharos/
The important download links don't work and there is no forum there.

Another forum about a microconroller I want to use only shows Free Pascal,linking it and RPi, nothing in Squeak. Does anyone know how to learn the unknown when the trail of hints runs out?

Return to “Scratch”