MacOS Context application created
I’ve created the first of the platform-specific launching mechanisms for the Context 3 release on 20 March, a MacOS application. On each platform, launching an application starts the minimal subject and history memories, and opens a website served by the subject memory using your default web browser. You can then control the subject memory from that website (load modules, quit, etc.).
For MacOS, I wrote an Automator workflow which opens the memories with Finder commands from an AppleScript, and opens the website after that. I saved the workflow as an application, and put the processor (AKA “virtual machine”) and memories in its Resources. This was my first serious application of Automator or AppleScript; I’m impressed!
I’m also writing applications for Ubuntu Linux and Microsoft Windows. I’d appreciate any suggestions about mechanisms to use on those platforms. I’d also love contributions of prettier iconography. :)
thisContext 
28 January 2011 at 9:24 pm
What about two bent spoons forming an S for the logo?
It would still be an S, but also it will consist of two spoons.
LikeLike
28 January 2011 at 11:27 pm
That would be cool! Care to sketch something?
LikeLike
28 January 2011 at 9:27 pm
You have subject and history memories. Subject would be analogous to a regular image. History would be a changes file. They would both be memories, because you want to avoid the translation back and forth to strings of text. You are taken with the purity of pure memory. Correct?
Where do I fit in here? I don’t see how I hack this. I could use the site created by the subject memory; OK.
Would I need to prune the way you do with your imaging tools to code anything?
What if I had a program that I wrote in Squeak and wanted to deploy in Spoon? I don’t imagine that’s possible.
So, how would I build anything?
I’m getting a “This is a whole new language” vibe here.
LikeLike
28 January 2011 at 11:42 pm
Well, it’s not just an aesthetic thing… When you have the original live objects communicating with a target system via messages, you have no ambiguity about what you mean to convey. When you try to use a textual representation of those objects outside their original environment, you introduce ambiguities that lead to inaccuracy and conflict. Then you get countermeasures which are sometimes more painful than the original symptoms (e.g., namespaces :). I’ve had enough of that. :) I’ve also had enough of stripping (really knot-untying). This project includes the strip to end all strips, so no one ever has to do it again.
The website provided by the subject memory is just a last-resort control console. It’s also listening for connections from other memories that speak its remote-messaging wire protocol. You’ll be able to browse the subject memory and make changes, from the browsers in a traditional Squeak system (or Pharo, or VisualWorks, or any other Smalltalk). Or, through the subject memory’s website, you’ll be able to load modules (served by other memories I’m setting up on EC2) that add display access, development tools, etc. You’ll be able to create those modules in any other Smalltalk.
So, no, this is not a whole new language. This is Smalltalk reduced to its essence, then taking the opportunity to introduce some much-needed concepts of system organization and deployment before things get bloated again. :)
LikeLike
29 January 2011 at 4:44 am
Craig,
This is great! Smalltalk hasn’t been so small since Smalltalk/V fit on a floppy disk. :-)
Now all we need is for Vassili to port the Newspeak native widgets to Squeak!
LikeLike
14 June 2011 at 2:56 pm
[…] created Windows and Linux apps to go along with the Mac app I made for starting Spoon. Now I’m sorting all the classes and methods of the minimal object […]
LikeLike