I wrote a new website for Black Page Digital, my consultancy in Amsterdam and San Francisco. It features a running Squeak Smalltalk that you can use for livecoding. Please check it out, pass it on, and let me know what you think!
Episode 8 of Smalltalk Reflections is out. The topic is “garbage collection”.
"Test the WebSocket API with an echo server." | report websocket | Transcript clear. report := [:label :data | Transcript cr; nextPutAll: label; print: data; endEntry]. websocket := ( (JS Object new) at: #newWebSocket put: (JS Function new: 'return new WebSocket("ws://echo.websocket.org");'); newWebSocket). websocket at: #onopen put: [:event | report value: 'opened: ' value: event. websocket send: 'hey there']; at: #onclose put: [:event | report value: 'closed: ' value: event]; at: #onmessage put: [:event | report value: 'data: ' value: event data. websocket close]; at: #onerror put: [:event | report value: 'error: ' value: event data]
Context is the umbrella project for Naiad (a distributed module system for all Smalltalks), Spoon (a minimal object memory that provides the starting point for Naiad), and Lightning (a remote-messaging framework which performs live serialization, used by Naiad for moving methods and other objects between systems). I intend for it to be a future release of Squeak, and a launcher and module system for all the other Smalltalks. I’m writing Context apps for cloud computing, web services, and distributed computation.
Commits b7676ba2cc and later of the Context git repo have:
- Support for installable object memories as git submodule repos.
- Submodule repos for memories for each of the known Smalltalk dialects, with Naiad support pre-loaded. I’m currently working on the submodules for Squeak and Pharo.
- A web-browser-based console for launching and managing object memories.
- A WebDAV-based virtual filesystem that enables Smalltalk to appear as a network-attached storage device, and mappings of the system to that filesystem that make Smalltalk accessible from external text editors (e.g., for editing code, managing processes and object memories).
- Remote code and process browsers.
Thanks for checking it out!
Episode 7 of Smalltalk Reflections is out. The topic is “minimalism”.
When you start the Context app, you start a webserver that provides a “console”. Viewed through a host web browser, the console describes what Context is, and enables control of the memories it knows about. The webserver also provides an active filesystem via WebDAV. This lets you interact with the console from a host terminal or text editor, in a manner reminiscent of a Unix procfs (content is generated live-on-read). Here’s a typical filesystem layout, and what you can do with it:
/ README.html memories 3EAD9A45-F65F-445F-89C1-4CA0A9D5C2F8 session state performance classes Object metaclass (etc.) methods at: (etc.) slots all (etc.) inherited (etc.) local (etc.) subclasses (etc.) processes the idle process ProcessorScheduler class>>idleProcess source variables thisContext self (etc.)  in ProcessorScheduler class>>resume (etc.) (etc.) workspaces hello world source result 7
The README.html file is what the console displays initially. It has a directory sibling memories, containing a subdirectory for each memory the console knows about. Each memory is named by its UUID. In the session directory, there are files which give information about a memory. The state file looks like this:
# This memory is running. You can send it one of the following # commands: snapshot, suspend, or stop. To do so, write this file with # the desired command as the first word after this comment. Subsequent # comments give other information about this memory, like host # resource usage and virtual machine plugins loaded. (type command here) # host resource usage # # bytes used: 437,598 # bytes available: 1,328,467 # virtual machine plugins loaded # # FlowPlugin
In this way, a file in the active filesystem provides access to a read-eval-print loop (REPL). The user gives input to the console by writing the file; the console gives feedback to the user (including documentation) by generating appropriate content when the file is read.
The performance file looks like this:
# instructions per second: 382,184,269 # messages per second: 12,355,810
This gives general profiling information about the virtual machine.
The subdirectories of the classes directory correspond to the memory’s classes. Each one has subdirectories for its methods, subclasses, and metaclass. The methods directory has a file for each method of the class. This provides the ability to browse and change source code in the memory from a host text editor.
The processes directory has a subdirectory for each running process in the memory. Each process directory has a subdirectory for each context of that process. Each context directory has a REPL file for the source code of the context’s method, and a subdirectory for the context’s variables (including the context itself), each of which is an inspector in the form of a REPL file. In this way, much of the functionality of the traditional Smalltalk debugger is accessible from a host text editor.
Finally, the workspaces directory has subdirectories for multiple “workspaces”, where one may evaluate expressions and interact with their result objects. Each workspace has a source file, another REPL file which contains instructions, the expression to evaluate, and, on the next read after write, the textual form of the result. In addition, in a result directory, is a file named for the textual form of the result, containing a REPL inspector for that result object.
These tools are useful both for newcomers to live object systems who are more comfortable with a text editor than the Smalltalk GUI, and for those accessing systems running in the cloud, for which traditional GUI access might be awkward or prohibitive.