Göran Krampe wrote:
> But of course, a plugin ...not sure I get what that *is* in this lineup 
> - a C plugin? Or is it a piece of java code in the java "harness" you 
> have that we call using.... some kind of protocol?

I was thinking about a regular plain old plugin written in C that uses 
specific JNI calls to do its work. Basically Squeak -> plugin (C) -> JNI 
-> Java. It's more work but it works incrementally which is a huge 
advantage from my position.

> Anyway, we would love to take a look at your "messy code" and promise 
> that we will not harass you with questions about it :)

I've uploaded the current state to

   http://squeakvm.org/win32/experimental/androidvm.zip

Some comments on the setup:
- The VM itself is a shared library (libsqueakvm.so) the "app" is a 
wrapper written in Java.
- You'll need the Android NDK in order to compile the shared lib. Make 
sure you can compile hellojni or some of the others to ensure your tools 
are in place.
- Place the entire squeakvm directory in the NDK's apps/ directory (next 
to hellojni and friends)
- To compile the app you need Eclipse and the various SDK bits (see 
Android docs for that; it works pretty much as advertised)
- Apparently, Eclipse does not "see" the dependencies between the shared 
library and the app - you need to manually remake the shared lib if 
you've changed a .C file
- Make absolutely sure you how to work the debugger (ddms). It's pretty 
much your only source of debug info since it shows the android logs that 
you can write to by using either System.out or dprintf().

BTW, I'll say that more than half of my time on the weekend was spent 
with the issues like the above. The setup is lengthy and just drags on 
and on and on, no reason to get discouraged by that.

Some comments on the implementation:
- The image is broken into pieces since Android's AssetManager doesn't 
like assets larger than 1MB. There's probably a better way of doing that 
but here's the code I used to break up an image:

	infile := FileStream readOnlyFileNamed: 'android.image'.
	infile binary.
	count := 0.
	[infile atEnd] whileFalse:[
		outfile := FileStream newFileNamed: 'android.image.', (count := count+1).
		outfile binary.
		outfile nextPutAll: (infile next: 1024*1024).
		outfile close.
	].
- All the Android specific code is currently in one file 
project/jni/squeakvm.c for simplicity (this should be broken out to 
separate files as the project progresses).
- Since the image file is compressed, it's preloaded into the object 
memory, and then the sqImageFile* and sqAlloc* functions are stubbed out 
"just so" that they operate on the preloaded image in-memory. It's a 
really neat hack but you probably wouldn't get that from reading the 
code :-)
- I haven't been using "proper" JNI callbacks for implementing display 
updates; but then I don't *really* think that should be necessary (we 
should rather fix the Morphic update cycle not to leave bits behind). 
But if you want to start with something I'd say a good place is to 
implement the callbacks from Squeak to Java in ioForceToScreen and 
ioShowDisplay.

Good luck!

Cheers,
   - Andreas