Ruboto on a watch (Ruboto IRB for WIMM One)
44 views
Skip to first unread message
Scott
Jan 11, 2012, 2:58:00 PM1/11/12
to Ruboto (JRuby on Android)
Over the holidays I started playing with the SDK for the WIMM One
(http://www.wimm.com/). I generated a ruboto app and made a slight
modification for the WIMM SDK (RubotoActivity inherits from WIMM's
LauncherActivity instead of Activity, and switch the build target to
WIMM). The default app loaded up without a problem. I then modified
the demo-irb-server script to make the app serve up an IRB browser
based experience. Everything runs (mostly...see below) well on the
emulator. I released Ruboto IRB for WIMM to their "Try Untested Alpha
Micro Apps" forum. I will check in a separate project to github for
anyone who wants to experiment.
Here's a few notes:
1) I'm still waiting to get confirmation that the app runs on a WIMM
device I only have an emulator). My first release failed. My guess is
that it was related to a wifi check that I couldn't test on the
emulator.
2) There is a bug in Android that this touches. Pre Gingerbread there
was a leak (file descriptor) in some of the socket code. The webrick
server I'm using triggers this problem and ends up spinning and
crashing after a period of use. The WIMM API is based on Android 7.
3) Start up is slow (40-60) as expected for a device with limited
resources. This means that Ruboto will be limited to a experimental
tool (learning, experimenting, testing) until the day when we can get
start up way down.
You need to register as a developer (free) to see the forum post:
http://support.wimm.com/entries/20845227-ruboto-irb-for-wimm
(http://www.wimm.com/). I generated a ruboto app and made a slight
modification for the WIMM SDK (RubotoActivity inherits from WIMM's
LauncherActivity instead of Activity, and switch the build target to
WIMM). The default app loaded up without a problem. I then modified
the demo-irb-server script to make the app serve up an IRB browser
based experience. Everything runs (mostly...see below) well on the
emulator. I released Ruboto IRB for WIMM to their "Try Untested Alpha
Micro Apps" forum. I will check in a separate project to github for
anyone who wants to experiment.
Here's a few notes:
1) I'm still waiting to get confirmation that the app runs on a WIMM
device I only have an emulator). My first release failed. My guess is
that it was related to a wifi check that I couldn't test on the
emulator.
2) There is a bug in Android that this touches. Pre Gingerbread there
was a leak (file descriptor) in some of the socket code. The webrick
server I'm using triggers this problem and ends up spinning and
crashing after a period of use. The WIMM API is based on Android 7.
3) Start up is slow (40-60) as expected for a device with limited
resources. This means that Ruboto will be limited to a experimental
tool (learning, experimenting, testing) until the day when we can get
start up way down.
You need to register as a developer (free) to see the forum post:
http://support.wimm.com/entries/20845227-ruboto-irb-for-wimm
Uwe Kubosch
Jan 11, 2012, 6:07:43 PM1/11/12
to rub...@googlegroups.com
Uwe Kubosch
Jan 11, 2012, 6:18:46 PM1/11/12
to rub...@googlegroups.com
On 2012-01-11, at 20:58, Scott wrote:
> 2) There is a bug in Android that this touches. Pre Gingerbread there
> was a leak (file descriptor) in some of the socket code. The webrick
> server I'm using triggers this problem and ends up spinning and
> crashing after a period of use. The WIMM API is based on Android 7.
Do you know why it is based on such an old version of Android? Will it be upgraded, do you think?
--
Uwe Kubosch
http://ruboto.org/
Scott Moyer
Jan 11, 2012, 11:15:40 PM1/11/12
to rub...@googlegroups.com
I think they just picked the version during development and it's easier to not upgrade it now. This is clearly a specialized device (no need for NFC or many of the newer features...yet). The I'm Watch is 1.6 based.
Hopefully WIMM witl patch some of the older OS bugs and then upgrade in the future. One issue is that the OS version seem to keep growing in the spec requirements. A watch is currently likely to have specs close to the first gen of handsets.
I was actually surprised how much of the OS they left in. I was thinking that the OpenGL library would have been pulled. But, I ran the demo-opengl script, and it worked without modification.
I was actually surprised how much of the OS they left in. I was thinking that the OpenGL library would have been pulled. But, I ran the demo-opengl script, and it worked without modification.
Scott
Feb 23, 2012, 2:50:49 AM2/23/12
to Ruboto (JRuby on Android)
It's been a long saga. After posting the app on the WIMM forum,
someone tried to get it working on their device, and it kept failing.
I posted a few updates based on guesses as to what was wrong. WIMM
recently sent me a device, so I can finally see for myself. It turns
out to be a heap limit. They have the per app heap limited to 16MB (G1
levels), while their emulator defaults to 48MB.
The first thing I did was swap out the 1.7.0-dev verion of JRuby for
1.5.6. This gave it enough space to run, but it still quickly ran out
of space (depending on what scripts I ran). I looked at a few heap
dumps and discovered that a huge amount of memory is taken up in hash
maps for keeping track of all the files in the jar. The ruby stdlib
has ~900 files and there are also a large number of timezone files
associated with joda. For now, I've done the following:
1) Put the stdlib in a zip file inside the jar. I then unpack it into
the files dir the first time the app runs, and set the load path to
handle things correctly.
2) Removed most of the joda timezone files from the core jar.
Those two changes gave me 2-3MB more room to work with. I've posted
the working version to WIMM's forums, and will check in some code to
github soon. There are still some issues:
1) We are leaking our Activities. We've known this for some time
(based on keeping references to the activities in globals). I
experimented with modifying ruboto and RubotoActivity to better clean
up the reference, but I haven't got it yet. It looks like it's still
held on to by the proxy that JRuby creates for it. I have to figure
out how to clean that up.
2) I'm not sure what problems I may cause by removing the joda
timezone files, but I can't imagine that it will have a big impact on
this particular device.
3) I'm not sure if there will be a way to get back to the latest JRuby
(or what I lose by dropping back to 1.5.6). The memory footprint of
JRuby continues to grow. I hope that WIMM expands their heap
allotment, but it may always be a struggle stuffing JRuby on to more
limited devices.
Anyway...it's an interesting experiment
someone tried to get it working on their device, and it kept failing.
I posted a few updates based on guesses as to what was wrong. WIMM
recently sent me a device, so I can finally see for myself. It turns
out to be a heap limit. They have the per app heap limited to 16MB (G1
levels), while their emulator defaults to 48MB.
The first thing I did was swap out the 1.7.0-dev verion of JRuby for
1.5.6. This gave it enough space to run, but it still quickly ran out
of space (depending on what scripts I ran). I looked at a few heap
dumps and discovered that a huge amount of memory is taken up in hash
maps for keeping track of all the files in the jar. The ruby stdlib
has ~900 files and there are also a large number of timezone files
associated with joda. For now, I've done the following:
1) Put the stdlib in a zip file inside the jar. I then unpack it into
the files dir the first time the app runs, and set the load path to
handle things correctly.
2) Removed most of the joda timezone files from the core jar.
Those two changes gave me 2-3MB more room to work with. I've posted
the working version to WIMM's forums, and will check in some code to
github soon. There are still some issues:
1) We are leaking our Activities. We've known this for some time
(based on keeping references to the activities in globals). I
experimented with modifying ruboto and RubotoActivity to better clean
up the reference, but I haven't got it yet. It looks like it's still
held on to by the proxy that JRuby creates for it. I have to figure
out how to clean that up.
2) I'm not sure what problems I may cause by removing the joda
timezone files, but I can't imagine that it will have a big impact on
this particular device.
3) I'm not sure if there will be a way to get back to the latest JRuby
(or what I lose by dropping back to 1.5.6). The memory footprint of
JRuby continues to grow. I hope that WIMM expands their heap
allotment, but it may always be a struggle stuffing JRuby on to more
limited devices.
Anyway...it's an interesting experiment
dcunited001
Mar 5, 2012, 6:53:40 PM3/5/12
to Ruboto (JRuby on Android)
I'm a ruby developer and I've got a Wimm dev device. I have some
experience with Java, but I'd like to use jruby.
Quick question - should I go with Ruboto for a Wimm project or is this
something I should wait for?
experience with Java, but I'd like to use jruby.
Quick question - should I go with Ruboto for a Wimm project or is this
something I should wait for?
Scott
Mar 5, 2012, 8:19:55 PM3/5/12
to rub...@googlegroups.com
The project is in a fairly good place at the moment. I'd recommend grabbing the 0.4 version from the WIMM forums and giving it a try. It is a good tool for learning the Android/WIMM APIs and prototyping some ideas. It is not a solution for shipping an app (due to the limitations of the device). You'll want to use adb for your connectivity to the device (or load it into an emulator). The WIMM device does not hold its wifi connection open long enough (even with repeated requests to keep it alive).
I'll post the code on github soon (need to finish up a few other activities).
Reply all
Reply to author
Forward
0 new messages