Sunday, February 21, 2010
Dammit, Nethack!
I have been a bit... distracted lately by a certain chaotic elven wizard with a penchant for Yendorian amulets. I'll be back into SecureSqueak shortly.
Tuesday, November 17, 2009
NewCompiler
I want to use the NewCompiler in SecureSqueak.
The main reason for this is that I want to use its IR ("intermediate representation") objects for moving code between images. The IR is effectively the bytecodes, but in object form, one object for one instruction, such that a final compilation step can be run on them to make CompiledMethods.
This is important in SecureSqueak as it makes implementing a "bytecode verifier" much easier. Instead of verifying the bytecodes for incorrect variable accesses, invalid jump destinations and so forth, we just get the kernel to run the last step of compilation itself. This makes it impossible (*ahem* less possible) for malicious bytecodes to be injected into SecureSqueak.
The rest of the compiler is completely optional. You merely need *something* that can generate the IR — it doesn't even need to be Smalltalk code.
The current NewCompiler maintainers use Pharo, so I'll be moving development over to that for now.
The main reason for this is that I want to use its IR ("intermediate representation") objects for moving code between images. The IR is effectively the bytecodes, but in object form, one object for one instruction, such that a final compilation step can be run on them to make CompiledMethods.
This is important in SecureSqueak as it makes implementing a "bytecode verifier" much easier. Instead of verifying the bytecodes for incorrect variable accesses, invalid jump destinations and so forth, we just get the kernel to run the last step of compilation itself. This makes it impossible (*ahem* less possible) for malicious bytecodes to be injected into SecureSqueak.
The rest of the compiler is completely optional. You merely need *something* that can generate the IR — it doesn't even need to be Smalltalk code.
The current NewCompiler maintainers use Pharo, so I'll be moving development over to that for now.
Tuesday, September 22, 2009
UGP / SecureSqueak 0.1 released
Download from here: http://sourceforge.net/projects/securesqueak/
Or watch the video: http://vimeo.com/6698843.
This is the first release of my "Unnamed Grand Project". It includes the SecureSqueak kernel (kind of), SiteBrowser, Subcanvas and the DPON object replication framework. Currently the "SecureSqueak kernel" is just the Squeak 3.10 kernel converted to use namespaces. Version 0.2 of UGP will start introducing security into it.
This release is for show and tell only; it barely works and isn't at all secure.
Or watch the video: http://vimeo.com/6698843.
This is the first release of my "Unnamed Grand Project". It includes the SecureSqueak kernel (kind of), SiteBrowser, Subcanvas and the DPON object replication framework. Currently the "SecureSqueak kernel" is just the Squeak 3.10 kernel converted to use namespaces. Version 0.2 of UGP will start introducing security into it.
This release is for show and tell only; it barely works and isn't at all secure.
Sunday, September 6, 2009
Subcanvas, with windows!
...and they actually work, too! The yellow parts are the borders; you can drag them around, and clicking on them brings them to the front.
The Subcanvas API is starting to prove that it really can work. The yellow bits are a subcanvas. Each of those contains a subcanvas with the window contents. The background is a subcanvas. The buttons (grey things with text) are subcanvases and will pop up a brand new window when you click on them.
Next up: choose better colours and make the test sites actually do something.
Tuesday, September 1, 2009
Subcanvas: Introducing Easels
Last night I started writing a real test for my Subcanvas graphics/events architecture: a trivial windowing system as the humble beginnings of a SiteBrowser [A SiteBrowser lets you browse "Sites" across the Internet, similar to navigating between Projects in Squeak]. The first problem I encountered was: from ordinary application code, how do I add a subcanvas? You aren't meant to hold references to canvases in your code, and the method to add a canvas is Canvas>>addCanvas. That would mean that you can only add a canvas from within an event handler. Oops. I needed to refactor the API to make it less brain-dead.
As a result, I introduce the Easel, an object which specifies the structure of Canvases and their children. An Easel is an object that your code should hold a reference to, and its API contains all the methods used to add, remove, move, resize, raise and lower subcanvases. I've also moved the canvas handler accessing methods to it, and added a method to cause a redraw event on a canvas.
I'll be updating http://gulik.pbwiki.com/Canvas soon.
As a result, I introduce the Easel, an object which specifies the structure of Canvases and their children. An Easel is an object that your code should hold a reference to, and its API contains all the methods used to add, remove, move, resize, raise and lower subcanvases. I've also moved the canvas handler accessing methods to it, and added a method to cause a redraw event on a canvas.
I'll be updating http://gulik.pbwiki.com/Canvas soon.
Saturday, August 1, 2009
Subcanvas with events
What is the picture of? It's a simple test for the Subcanvas graphics / events API. It's Squeak, but with Morphic temporarily disabled and a Subcanvas test running full-screen and reacting to keyboard and mouse events. The blue squares are from mouse move events (offset by a few mm). The big green rectangle is a subcanvas that draws little red squares rather than blue squares on mouse move events. All the other sized squares are from mouse click events. The text is from keyboard events; the little white lines above text are key press events and the white lines below are key release events.
Font rendering here is done very simply. It will be improved.
The performance of this implementation is currently usable with a single, small subcanvas, but the performance will suffer incredibly as subcanvases get bigger. This is because subcanvases are BitBltted in their entirety after each event; the implementation is currently naïve and there is a lot of room for optimisation.
I'm disappointed by Squeak's graphics performance. BitBlts on Forms are very slow. As a result, I'm not going to try to optimise this implementation of Subcanvas (based on Forms and BitBlt) and instead re-implement it in the future using either a raw X11 socket with XRender, XDamage etc, or use OpenGL in 2-D. Subcanvas at heart is an API, so any users of it should be unaffected. Currently I'm favouring reimplementing it to use X11 as most POSIX systems (Linux, Solaris, BSD, Apple with OS/X) have an accelerated X server, and I could bundle something like XMing with MS Windows. Forms, BitBLT and friends could then be completely purged from the VM leaving it headless.
Sunday, June 28, 2009
Keyboard events
Mouse events in Subcanvas now mostly work. A canvas's target now receives mouse movement events, mouse button press and release events and canvas enter and exit events. Now, I've moved my attention to keyboard events.
There are three types of keyboard events in Squeak: Key Press, Character and Key Release. Key Press and Key Release should give only the description of which physical key on the keyboard has been pressed or released, including modifier keys (shift, CTRL, etc). Currently the Squeak VM uses the "Mac-Roman" encoding to encode which key was pressed or released, which is less than ideal and still differs per platform. The Character event contains a Unicode character. A single Unicode character may have required multiple key presses and even some UI interaction to be composed.
There are three types of hardware keyboard in the world; the US one (104 keys), the European one (105 keys) and the East Asian one (109 keys). These are very similar to each other and based on the PS/2 keyboard. Almost every keyboard in the world is based on one of these hardware prototypes with different printed letters on it.
I've also found that the USB specification (made by Microsoft) has reasonably elegant "scan-codes" that specify the actual keys pressed with no regard for which character is printed on that key. I believe these codes would provide for a much more elegant way of specifying which keys were pressed in the "press" and "release" events than the Mac-Roman keys currently provided by the Squeak VM. Unfortunately, any notion of the original USB scan codes have long been forgotten by the OS by the time the character arrives at the Squeak VM, so the VM or the image will need to map OS-specific event IDs to the equivalent USB scan codes. It is a bit of a roundabout way to do it, but the end result is an OS-independent manner of doing raw keyboard events. Perhaps SqueakNOS can strip away the layers of abstraction and pass USB scan-codes through directly? :-)
The end result is that an application using Subcanvas can either use the character events, or it can use the key press and key release events to roll its own "Input Method Editor". This gives a good level of initial functionality for most languages in the world by using the Unicode character input directly from the VM, as well as a future growth path for implementing new "Input Method Editors" (or games) using the raw key press and release events.
On another chain of thought, I'm considering making Pango and Freetype "libraries" available in SecureSqueak / UGP. If they're provided as a resource such that Subcanvas does not have any architectural dependencies on them, they can be implemented as a "deprecated on birth" resource that will provide necessary text rendering functionality until pure Smalltalk-based solutions can be written. At this stage, I'm a bit wary of just how complex the rendering of multilingual text can be.
There are three types of keyboard events in Squeak: Key Press, Character and Key Release. Key Press and Key Release should give only the description of which physical key on the keyboard has been pressed or released, including modifier keys (shift, CTRL, etc). Currently the Squeak VM uses the "Mac-Roman" encoding to encode which key was pressed or released, which is less than ideal and still differs per platform. The Character event contains a Unicode character. A single Unicode character may have required multiple key presses and even some UI interaction to be composed.
There are three types of hardware keyboard in the world; the US one (104 keys), the European one (105 keys) and the East Asian one (109 keys). These are very similar to each other and based on the PS/2 keyboard. Almost every keyboard in the world is based on one of these hardware prototypes with different printed letters on it.
I've also found that the USB specification (made by Microsoft) has reasonably elegant "scan-codes" that specify the actual keys pressed with no regard for which character is printed on that key. I believe these codes would provide for a much more elegant way of specifying which keys were pressed in the "press" and "release" events than the Mac-Roman keys currently provided by the Squeak VM. Unfortunately, any notion of the original USB scan codes have long been forgotten by the OS by the time the character arrives at the Squeak VM, so the VM or the image will need to map OS-specific event IDs to the equivalent USB scan codes. It is a bit of a roundabout way to do it, but the end result is an OS-independent manner of doing raw keyboard events. Perhaps SqueakNOS can strip away the layers of abstraction and pass USB scan-codes through directly? :-)
The end result is that an application using Subcanvas can either use the character events, or it can use the key press and key release events to roll its own "Input Method Editor". This gives a good level of initial functionality for most languages in the world by using the Unicode character input directly from the VM, as well as a future growth path for implementing new "Input Method Editors" (or games) using the raw key press and release events.
On another chain of thought, I'm considering making Pango and Freetype "libraries" available in SecureSqueak / UGP. If they're provided as a resource such that Subcanvas does not have any architectural dependencies on them, they can be implemented as a "deprecated on birth" resource that will provide necessary text rendering functionality until pure Smalltalk-based solutions can be written. At this stage, I'm a bit wary of just how complex the rendering of multilingual text can be.
Subscribe to:
Posts (Atom)
