In preparation of making Etoys work on the recently announced OLPC tablet, I ported it to the iPad. Here is a videoread on below for some details:



This might look exciting, and it certainly is, but it feels actually a lot more clunky than it looks. You may have noticed the little target circles I added whenever a finger touches the screen. That's to know where exactly the finger hit. It's really hard to hit anything, took me a while of training to hit the colorful halo handle buttons on first try. We really need to redesign the user interface before giving this into the hands of kids ...

But for now, some technical details: John McIntosh ported the Squeak Virtual Machine to Apple's touch-based OS last year (source available at isqueak.org). I modified it slightly to enable multi-touch and keyboard input. Also, I rewrote his code to deal with touch events in Squeak, and added multi-touch handling to Morphic. Fortunately, Morphic was designed to handle multiple "hands" (pointing devices) from the beginning, so adding this was much easier than in a system that assumes there is only one mouse. That's why moving multiple objects at the same time, and painting with more than one finger, just works once the events are in the system.
So far this is just an early test. We should work on improving the Etoys touch UI in next year's release. The Sugar menu bar works fine, but everything else is way too small. At least we have the luxury of being able to test Etoys alreadygetting the rest of Sugar running on a touch device might take a while. Hopefully OLPC will have developer machines soonish. If this test has shown one thing, then that there is lots of work to do (and it may even be necessary to start over).

About three months ago, I joined Lockheed Martin STS as their Chief Innovation Officer. I have been wanting to pursue a project that was quite different from the direction that Teleplace has been going, and after about a year of discussion, it was clear that the direction I wanted to go and what Lockheed Martin was looking for fit extremely well.

It is too early to talk about what I will be doing, but if it works the way I think it should, it could have some very big results and may have an impact on everyone someday. I can tell you it is a very different world inside of a big company - there is still a requirement to be entrepreneurial and sell the ideas, but once a big company like this gets behind it, the resources available are simply amazing.

More to come for sure...

Tamarin-central, the stable source tree of open source VM used byAdobe Flash, wasupdated last December (Dec 22 2009) after relatively longblank. The newer tree has faster VM and includes updated ABCassembler and disassembler. Especially those ABC utilities are quiteuseful to a binary hacker of AVM2.Download latest Flex SDKI found that neither Flex SDK 3.5 nor 4.0 stable build can compileabcdump. You need to download later version from the DownloadFlex site. Flex 4-Beta 2 (4.0.0.10485) works well. I would set theFlex directory to environment variable FLEX.$ export FLEX=~/Downloads/flex_sdk_4.0.0.10485_mplDownload and build Tamarin-centralBuilding procedure is well documented in Tamarin_Build_Documentation. Onlymy additional suggestion is to add --enable-debugger, it makes errormessages easy to read, it helps you, really.$ hg clone http://hg.mozilla.org/tamarin-central/$ cd tamarin-central$ mkdir objdir-release$ cd objdir-release$ python ../configure.py --enable-shell --enable-debugger$ make$ ./shell/avmshell -Dversionshell 1.5 release-debugger build cyclonefeatures AVMSYSTEM_32BIT; ...Build abcdumpThere are various useful utilities in utils/ directory. Some utilizesare written in ActionScript, so you need to compile them touse. Abcdump, ABC disassembler, is one of such utilities.$ cd ..$ java -jar $FLEX/lib/asc.jar -import core/builtin.abc -import shell/shell_toplevel.abc utils/abcdump.ascore/builtin.abc and shell/shell_toplevel.abc are basic librariesprovided by tamarin, you can use them to try to see how abcdumpworks. Note that you need to separate abc file names with --,otherwise arguments are processed by avmshell instead of abcdump.$ ./objdir-release/shell/avmshell ./utils/abcdump.abc -- core/builtin.abc // magic 2e0010// Cpool numbers size 158 0 %...I recommend you to make a tiny shell script to ease such a complicated command line.#!/bin/sh~/tmp/tamarin-central/objdir-release/shell/avmshell ~/tmp/tamarin-central/utils/abcdump.abc -- $@How to use abcasmAbcasm is a ABC assembler. It is written in java and shell script, soyou don't need to compile to try it. utils/abcasm/test/ directoryincludes various interesting sample programs. You can test them easilyand quickly.$ cd utils/abcasm/$ ./abcasm.sh test/hello.abstest/hello.abs$ ../../objdir-release/shell/avmshell test/hello.abcHello, world

*UPDATED* New half adder video is released!

Milan just started a blog describing how to write activities in Squeak, see his first post. There are already a few of these, most notably the games by Robert Hirschfeld's students at the University of Potsdam, Germany. But so far the process is only documented in mailing list posts. Way to go, Milan!

I'm going to Osaka in the chiristmas season to join the exhibition. This is a kind of "college reunion show" and all of artists were students of Prof. Hitoshi Nomura. I'm very excited to see old friends of the sculpture course. Now I'm quite busy to build a new version of wooden half adder. This is my first exhibition since 1999 anyway. Time is running so fast.First Passage

ARTCOURT Gallery Tenmabashi 1-8-5, Kita-ku, Osaka 530-0042 Japan

Hitoshi Nomura, Koji Nishimatsu, Kawai+Okamura, Osamu Kokufu, Tamaki Nagatani, Takashi Yamamiya, Yui Ishiyama, Kohei Nawa, Yasutaka Yamada, Yoshihiko Maeda, Ichiro Okada, Takao Machiba, Kenta Ogaya, Takayuki Okamoto, SHINCHIKA, Yasuyoshi Uchiyama and Taro Okumura

• December 15 - 26, 2009
• Gallery Hours: 11:00 - 19:00 ( - 17:00 on Saturdays) Closed on Sundays

• Event : Artists Talk Show
• Saturday, Dec.19, 14:00 - 15:30 (*15:30 - 17:00 Reception)

Brandon Boyer at Boing Boing Offworld was kind enough to post a link to the Colony videos I made. You can see it here:

A Look Back At the Colony

The CITRIS Digital Gallery Builder is a collaborative virtual gallery system for the humanities.
The main idea is that it allows users to easily build 3-dimensional virtual galleries which contain various types of media, and which can then be viewed and modified collaboratively by multiple people at once over the internet. This allows both for the creation of group curated spaces and for the viewers to actively engage the source material.

"Digital Galleries" are fairly simple structures emulating real-life exhibitions and collections. Visitors find themselves in a virtual space composed of various rooms, with 2-dimensional and 3-dimensional artifacts presented in the space. The user is represented by an avatar which they can navigate through the 3D space.

The CITRIS software is built on top of the Croquet system, which allows for group collaboration and interaction within the space. That is, several people may have avatars present in the space at one time, can interact with each other, and further can interact with the gallery itself. Examples of interaction include discussion, annotation of artifacts, adding hyperlinks to artifacts, as well as introducing new items into the gallery and modifying the layout of the gallery and contents.

Currently supported media types are:
Images (JPG, PNG, BMP)
Video (MPG)
Audio (MP3)
3D Objects (ASE)

Support for additional media types, especially 3D file formats, is planned.

While the alpha version is not yet publicly available for download, CITRIS is looking
for interested users who may want to provide feedback on the initial prototype.

Documentation and screenshots are at http://www.citris-uc.org/hosted/projects/ith/gallery,
and links to the user group, Croquet, etc are at http://www.citris-uc.org/hosted/projects/ith/gallery/#Feedback.

David Smith just made my life my easier by modifying TSpace & TUserCamera so picking in an overlay just falls out naturally from building an overlay with a TUserCamera. It's a little frustration that David can solve a problem that has been plaguing me for weeks with a couple of deep tweeks...and now pretty much any mistake with an overlay results in the image freezing...but such is life on the cutting edge.

Having a working top-down overlay in the corner of the screen makes me want to be able to toggle the two views: have the top-down view be the dominant image and the front facing view be in the corner. This could get confusing - there is one TUserCamera that managers the other TUserCameras as overlays. It seems like TUserCamera was originally a kind of catch all for all the things they didn't want to put into the TeapotMorph & I bet it was intented to be a singleton. The main TUserCamera (activeCamera of the TeapotMorph) is resistant to tampering, but what about creating an additional overlay with the front view in it?

Yay, that works. I wonder if David would consider killing the main Camera render and just render it as an overlay. very flexable.

I have been converting our morphic popup menu's over to Tweak. Our needs have all been simple so far, so not a deep test, but so far so good. The code has been pretty clean and does what I would expect it to do. And I have been enjoying the "do something wrong, get an error message, fix it and keep going" experience that I have been told is the really excitement about squeak, but has never really worked for me in Croquet, where it has been more like "do something wrong, restart the image, search the recent changes log to recover your code, make a small change & repeat". But I am now seeing the fun.

We are working with Tweak 1.0, in the Jasmine image, which, I think, puts us two versions behind. The mailing list says they are now working on 1.2 for Squeak 3.8. Hopefully we will see grand unification sometime this summer, with a 3.8 version of Croquet bringing us into the Tweak mainstream.

Other big news around the office here is that I set up the Mantis bug tracker on our server for the digital gallery project. It's much easier to use that the wiki arrangement we were using before. And best of all, it makes Orion happy.

Not yet fully blessed by the powers-that-be, but it looks like we are going to push ahead with using Croquet as the technology behind our IT & Humanities project. It's been a tough choice (and one I know I still might live to regret), but Croquet wins out by: being open sources; having a vision that is closely aligned with ours; and seeming to be on the road to developing a vibrant user community. Fingers crossed.

First step is to get Orion up to speed on Squeak. The cursing you hear in the background is him learing the new keyboard combinations. Not that I am much farther along the learing curve than he is. Scott spent the summer teaching me to become one with Squeak, but my instincts are still java/perl/c++ based. Right now I am tweaking Scott's UI on the Gallery Builder to suit my more Window's flavored preferences.

The goal is to replace Torque in our demo by the end of the month, in time for our next meeting with the Stanford Humanity Labs folk.

Interesting things to try:

1. File-out'ing the Jasmine code and running it in the 3.7 image, with the Gallery Builder.
   
2. Putting the Gallery Builder into a project and openning it inside of Jasmine. This will be amazingly cool if it works.
   
3. Writing some SUnit tests.
   

Community Developements

1. Julian has a blog. Yay!
   
2. The Squeak guys at Georgia Tech have set up a Croquet wiki. I suspect this will become the defacto offical one.

More event passways. The last entry discribed how a pointerDown event makes it to a componant that the mouse is over. This path is the same for pointerUp and pointerMove, but pointerEnter & pointerLeave have their own thing going on.

Those events are generated in TRay >> resetSelected, which is called for the activeCamera's pointer in TUserCamera preRender. Remeber that any TRay in a scene will select an object that it is pointing at in the render loop. resetSelected examins the ray's current selectedObject and it's lastSelection object to generated appropriate calls to pointerEnter, pointerLeave & oh yeah, pointerOver (which is called continuously on the selected object for as long as the TRay points at it).

Notes:
1) The TRay only generates the pointerX events if it's doSelect is true, so the camera's downRay does not trigger events.
2) The TRay is handed to the componant with the event, so you could have an object that responds differently to being selected by different pointers.
3) I wondered why these events were render based & not based on mouse event until Orion reminded me that objects in the scene can move themselves in front of the pointer. The render bases select can succesfully select those moving obejcts.

I have been learning about the Croquet event processing loop, in my attempt to get a pickable overhead view.

1) It all starts with Squeak and Morphic. The TeapotMorph is just another morph as far as Squeak is concerned. By default it registers itself for the full compliment of mouse and keyboard events.

2) I haven't fully groked Squeaks focus handling. Sometimes it uses mouse-over, sometimes it is click-to-focus. Unfortunately, click-to-focus does not seem to work on the TeaportMorph and keystrokes continue to go to the last selected morph. You can force it by putting this in a mouse event:
ActiveHand keyboardFocus: teaportMorph.

3) The TeapotMorph's default behavior is to route all it's events to it's activeCamera, which is a TUserCamera. The interesting call for me is camera >> pointerXY: evt position. This takes the viewpoint coordinates of the mouse and updates the TPointer that is attached to the userCamera.

More important things about TPointers.

* They operate automatically (as do all TRays). Put one in the scene graph and it picks every render cycle.

* Once TPointer has selected an object, it will not test any other items unless they are closer that the currently selected object.

* There is something special about the TPointer attached to the TAvatar that allows it to actually interact with objects in the scene. This has to do with replicated vs non-replicated picking....need to know more about this.

Ok, I think I am getting a hang of the tweak way of thinking.
Lets say I have a CColorPicker & I want to use it in a dialog & do something with it. There are a couple of ways of doing this.
The color selected by the user updates the colorPicker's value. So I can:

1. In the dialog's initialize, call self startScript: #doSomething when: { colorPicker. #valueChanged}
2. in the doSomething method (which should prob be called onColorChanged), put . I think that just tells tweak to magically add the line above to the init for me.
3. I can call colorPicker player: ( self fieldNamed: #someField ) which puts a CFieldReference into the colorPicker as it's value. So the field in the dialog is updated in sync with the colorPicker's value. This has something to do with Tweak's virtual field mechanism, which I don't fully understand, but it seems very cool.
   

My last post mentioned Takashi Yamamiya's blog Squeak Everyday, which served as the final bit of motivation to get me to start blogging my Croquet experiences (which I wish I had been doing over the summer - I think if I had been expressing my problems a bit more publicly we would have resolved the communication issues much faster). Anyway, more important than inspiring me, Takashi's blog also inspired David Smith, Croquet's project lead, to start his blog Croqueteer. I think this is great way to communicate. It helps build up a sense of community, and I know that it is a real comfort to those of us building projects on top of Croquet, to have an idea of what the dev team is thinking about.

I found out about David's Blog on the page of Croquet links Julian Lombardi (U of Wisc) is putting together here. I have asked him to put a link to this blog up there too...which makes me nervous, but I figure if I expose my ignorance to the world I will learn the truth faster.

Well, my day two impressions are mixed. Jasmine has lots & lots of bugs. Seems like I cannot go for more than minute without doing something that pops up one of those cute debug dialogs. But, they are doing an amazing job of responding to bug reports and fixing things ("They" being David Smith, Andreas Raab & Mark McCahill). They fixed one of my bug reports within 12 hours. This is exactly why it was so important to me (and them too, I am sure), that they get out a public release. A small group just keeps repeating the same tests.

They could use some automated tests to help avoid regression thou. Takashi Yamamiya mentions in his blog entry that he got a Croquet Unit Test runner working with TeaTime (which then changed breaking his code) and that he has started porting all his work over to Jasmine. Very exciting.

I am told that Takashi (a core squeak developer) is working on a Croquet game project, Chain Reaction, with Yoshiki Ohshima (ditto re: squeak, out of U of Kyoto) & 3DSolve (a North Carolina simulation and learning software company). I should find out more about this project.

This one took hour or two to down. I wonder if I am abusing an idiom.

I wanted to create a dialog with custom behaviors so I did the following.

d := CFileSaveDialog new.
d costume: CCFileSaveDialogCostumeCITRIS new.
d openLabel: 'Test Custom Dialog'.

then in CCFileSaveDialogCostumeCITRIS>>initialize I added changed around parameters:

directoryList costume: CTreeWidgetCostumeCitris new. "works"
player sorter primarySort: #compareType:with:. "does NOT work"

The problem is the timing. initialize gets called at the end of the new, and before the costume: call, so player in initialize has not been set to d. Instead CPlayer has silently stuck in a default CFileDialog that gets modified and then immediately discarded.

If I move the player modifying line into onPlayerChanged, it is all good.

I managed to force Scott's Gallery Builder into the Jasmine image. It's a little bit crippled by my pattented "hack off any code that generates an error" approach, but it is still functional. Yay! Now to get it talking to Croquet. I had this working back in August, with Solar, so it should go pretty quick...but not probably not quick enough for our Citris Corporate Sponsors Day presentation on Tuesday. Ah well, one last chance to show off the cute Citris Alien from the Torque engine.

Looks like I was asking the wrong question last week when I asked about running Jasmine under the 3.7 VM. As everyone said, that is no problem, the Jasmine image runs just fine with the 3.7 VM. But Scott's code relies on infrastructure in the 3.7 image, not the VM. Infrastructure which does not exist in the Jasmine image. Oops. So, I spent today alternating between:

1. Failing to get Scott's code running in the Jasmine image. I was able to chop out most of the references to horizontal scrollbars, but ran into an unknown message that I cannot track down.
   
2. Failing to get Jasmine to run in Scott's 3.7 image. I thought doing a file out on all the Croquet catagories might work, but the Croquet image has changed some of the basic Squeak syntax rules to allow calls like gl glVertex(0.0, 0.0, 0.0), and I don't know how to get those changes into the 3.7 image. So I just get lots and lots of syntax errors.
   
3. Being really really surprised when I did the following: file-in one of Scott's .cs files, immediately file-out it, then close Squeak w/out saving, reopen Squeak, file-in my new .cs file and presto - a stream of errors. I don't know if this is a bug in Squeak, something really weird with Scott's change set, or, more likely, my mental model of how change sets work is completely wrong.