Archive for virtual filesystem

Caffeine: live web debugging with SqueakJS

Posted in Appsterdam, consulting, Context, Naiad, Smalltalk, Spoon with tags , , , , , , , , , , , , , , , , , , , , on 26 October 2016 by Craig Latta

In February 2015 I spoke about Bert Freudenberg’s SqueakJS at FOSDEM. We were all intrigued with the potential of this system to change both Smalltalk and web programming. This year I’ve had some time to pursue that potential, and the results so far are pretty exciting.

SqueakJS is a Squeak virtual machine implemented with pure JavaScript. It runs in all the web browsers, and features a bi-directional JavaScript bridge. You can invoke JavaScript functions from Smalltalk code, and pass Smalltalk blocks for JavaScript code to invoke as callbacks. This lets Smalltalk programmers take advantage of the myriad JavaScript frameworks available, as well as the extensive APIs exposed by the browsers themselves.

The most familiar built-in browser behavior is for manipulating the structure of rendered webpages (the Document Object Model, or “DOM”). Equally important is behavior for manipulating the operation of the browser itself. The Chrome Debugging Protocol is a set of JavaScript APIs for controlling every aspect of a web browser, over a WebSocket. The developer tools built into the Chrome browser are implemented using these APIs, and it’s likely that other browsers will follow.

Using the JavaScript bridge and the Chrome Debugging Protocol, I have SqueakJS controlling the web browser running it. SqueakJS can get a list of all the browser’s tabs, and control the execution of each tab, just like the built-in devtools can. Now we can use Squeak’s user interface for debugging and building webpages. We can have persistent inspectors on particular DOM elements, rather than having only the REPL console of the built-in tools. We can build DOM structures as Smalltalk object graphs, complete with scripted behavior.

I am also integrating my previous WebDAV work, so that webpages are manifested as virtual filesystems, and can be manipulated with traditional text editors and other file-oriented tools. I call this a metaphorical filesystem. It extends the livecoding ability of Smalltalk and JavaScript to the proverbial “favorite text editor”.

This all comes together in a project I call Caffeine. had fun demoing it at ESUG 2016 in Prague. Video to come…

2 Comments »

current design for Context’s virtual filesystem

Posted in consulting, Context, Naiad, Smalltalk, Spoon with tags , , , , , on 13 January 2014 by Craig Latta

I’m writing Context’s virtual filesystem support now. The directory structure looks like this:

--
root
   classes
      <each class>
         methods
            all
               <each method>
                  literals
                     <literal objects>
                  source
                  version
            inherited
               <inherited methods>
            local
               <locally-defined methods>
         slots
            all
               <each slot>
                  <instances ordered by slot>
                     references
                        <referring objects>
                     slots
                        <etc>
            inherited
               <etc>
            local
               <etc>
   processes
      <each process' suspended context>
         method
            instructions
            literals
               <literal objects>
         sender
            <etc>
   README.html
--

What do you think?

3 Comments »

What services should the initial Context filesystem provide?

Posted in Context, Naiad, Smalltalk, Spoon with tags , , , , , , , , on 19 December 2013 by Craig Latta

The Context app is now mountable as a virtual (WebDAV) filesystem. What should it do? It has a file at the top level called “README.html”, which is obvious enough. What should the README describe? What would you want a newcomer to be able to do from their favorite text editor (or their favorite file-aware programming language)? Browse classes and methods? Resume and suspend object memories? Add and remove code modules? Please share your thoughts, keeping in mind that this is meant to be a minimal system (one can always add code modules to it later).

Image

2 Comments »

%d bloggers like this: