On 2010-01-18, at 7:36 PM, Andreas Raab wrote:

John M McIntosh wrote:

...

A dull iPhone 2nd generation gives 21,548,821 bytecode/sec; and 564,465 sends/sec a shinny newish iPhone 3G S gives: 42,xxxx,xxx bytescodes/sec; and 1,1xx,xxx sends/sec.

Interesting! I think that means I need to play with optimizations a bit more - from what I see it looks like the 3GS runs a 600MHz ARM where the Nexus runs a 1GHz. Did you apply any optimizations i.e., gnuify, or any ARM specific stuff?

Well yes, I'm sure there has to be a beer in here somewhere, don't see it tho...

No ARM specific stuff unless you consider it might have more registers than an i386...

-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

In

MCHttpRepository location: 'http://www.squeaksource.com/iPhone' user: '' password: ''

Name: iPhone-VMMaker-Only-JMM.1

I had some changes to handle:

(a) readImageFromFile: f HeapSize: desiredHeapSize StartingAt: imageOffset This was to handle mmap allocation, but it's obsoleted and replaced a year back with the macros we talked about earlier on image reading

(b) primitiveGetNextEvent

I have a change here where eventTypeIs == 6 if so that's a complex event and you'll find a description of that in the sq.h that I submitted in my microsecond clock changes last week or so. One of the issues is that the event type coming up is assumed to be an integers. However I change slot 4 to point to an oops. What is in the oops is platform dependent. I did have some constants I added for iphone touchs, and the generic location, acceleration data.

The ioGetNextEvent then is responsible for population slot 4 with smalltalk object. Althought the engineers at Apple tell me there *might* be touch area & pressure data, it's not accessible so you get the four types of events, the object is a set containing one or more items to enable the handling of 4 fingers down... 2 fingers up... with twist rotation on the other two fingers. Then in EventSensor(whatever) I deal with the interpretation of the complex object type. So no decision is done in the VM.

typedef struct sqComplexEvent { int type; /* type of event; EventTypeComplex */ unsigned int timeStamp; /* time stamp */ /* the interpretation of the following fields depend on the type of the event */ int action; /* one of ComplexEventXXX (see below) */ usqInt objectPointer; /* used to point to object */ int unused1; /* */ int unused2; /* */ int unused3; /* */ int windowIndex; /* host window structure */ } sqComplexEvent;

#define ComplexEventTypeTouchsDown 1 /* */ #define ComplexEventTypeTouchsUp 2 /* */ #define ComplexEventTypeTouchsMoved 3 /* */ #define ComplexEventTypeTouchsStationary 4 /* */ #define ComplexEventTypeTouchsCancelled 5 /* */ #define ComplexEventTypeAccelerationData 6 /* */ #define ComplexEventTypeLocationData 7 /* */ #define ComplexEventTypeApplicationData 8 /* */

On 2010-01-18, at 11:30 PM, Andreas Raab wrote:

BTW, one of the things I'm considering is to change the event type for touch events. That's mostly because it seems like on Android you actually get a coverage for a touch event, i.e., how many pixels were covered by your fatty fingers. And what I'm thinking here is that interaction could be *greatly* improved if the dispatch of such events would take coverage of the target area into account. That means that even if a click doesn't land "on" a relatively small button that the button will get the click if it's the ui element with the largest coverage in the region. I could see this working very well for relatively small UI elements. However, that does require extra information (pressure, coverage) and I'm wondering if it's worthwhile to package and dispatch those events separately. How does this level of stuff work on the iPhone? Are you dispatching touch events ore are you dispatching mouse events? Any additional parameters you're passing along?

Cheers,

• Andreas

-- =========================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Hi folks!

Igor Stasenko wrote:

Great news! I know at least one person who is interested in that - Goran :)

2010/1/18 Andreas Raab andreas.raab@gmx.de:

...

Folks -

Sorry for being quiet over the weekend but I was busy with my new toy - a shiny new unlocked Nexus One which arrived last week fresh from the Google store.

Andreas, I *love* you! :) This made my day.

I was myself toying with different approaches and will definitely take a look if you can share the code - github is nice... :)

Mikael Kindborg has been doing lots of cool fun stuff on Android by remote controlling a Rhinoscript engine using HTTP from an extended Workspace within Squeak with stuff like "do it in Android" etc.

We are focusing hard on Android here at MSC and having Squeak on it is extremely interesting.

Now, the absolutely coolest thing would be if we somehow can "tap into" all that java code. Have you given that any though? I even looked at the Dalvik source code to play with the thought of merging a Squeak VM with a Dalvik VM...

regards, Göran

Andreas Raab wrote:

1. Write generic bridge to Java (using JNI). That's a sizable chunk of

initial work, but once it's done you will be able to interact seamlessly between Squeak and Java.

And now that I've been thinking about it, it actually even seems more reasonable because you can leverage the FFI to do it. What I'd do is to add a new calling convention called 'java' and then use the FFI to spec it along the lines of:

JAssetManager>>open: fileName "public final InputStream open (String fileName)" <java: JInputStream 'android.content.res.AssetManager.open' (JString)>

(see http://developer.android.com/reference/android/content/res/AssetManager.html...)

and then provide the necessary level of primitive coercion via having the FFI recognize the java: calling convention and dispatch to a JNIPlugin which implements the necessary glue code. Being able to ride on top of the FFI really simplifies implementing all of the type manipulation so you can concentrate on the glue code itself. I'd say this cuts down on the required time significantly (to the point where I might even spend another weekend looking at it).

Cheers, - andreas

On Tue, Jan 19, 2010 at 11:14:19AM +0100, gaelli@emergent.de wrote:

...

There are two approaches here, with different tradeoffs:

1. Write generic bridge to Java (using JNI). That's a sizable chunk of

initial work, but once it's done you will be able to interact seamlessly between Squeak and Java. I've built a similar bridge (to Python) and it works extremely well.

You are aware of http://jniport.wikispaces.com/ aren't you?

Cheers

Markus

There is also JavaConnect:

http://news.squeak.org/2008/04/30/using-smalltalk-with-java-javaconnect-and-... http://www.info.ucl.ac.be/~jbrichau/javaconnect.html

Dave

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

On 19.01.2010, at 04:57, Göran Krampe wrote:

Hi!

Andreas Raab wrote:

...

Göran Krampe wrote:

...

Andreas, I *love* you! :) This made my day.

Heh, heh, you're welcome. It's still a long way to go though.

Of course, but it's a start!

...

...

We are focusing hard on Android here at MSC and having Squeak on it is extremely interesting.

Great! Think you can spare some resources to move things forward? :)

Might be able to.

...

...

Now, the absolutely coolest thing would be if we somehow can "tap into" all that java code. Have you given that any though? I even looked at the Dalvik source code to play with the thought of merging a Squeak VM with a Dalvik VM...

There are two approaches here, with different tradeoffs:

1. Write generic bridge to Java (using JNI). That's a sizable chunk of initial work, but once it's done you will be able to interact seamlessly between Squeak and Java. I've built a similar bridge (to Python) and it works extremely well.

Yeah, and yes, I read your other ride-on-FFI-post. Also, the JNIPort someone mentioned looked quite interesting too, and with a reasonable license it seems.

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?

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

regards, Göran

Just came across this article via my linux-squeak trigger:

http://www.infoq.com/news/2010/01/new-python-gil-squeak-on-android

It suggests to use Android Scripting Environment (ASE) for calling into Android:

http://code.google.com/p/android-scripting/

- Bert -

Folks -

I finally set up a project at Google to have a place people can more easily contribute to:

http://code.google.com/p/squeak-android-vm/

The code that's checked in is still the same that I put up earlier (didn't have much time to play with things) but hopefully I'll find a few hours soon to improve things.

If you'd like to be added as developer, please send me your Google Account email address so that I can add you to the project.

Cheers, - Andreas