Ruby on the mobile?


#1

Hi all,

I found this post interesting. Is Ruby ignoring the mobile market? Do
we need a “microruby” implementation?

From Berco Beute, commenting on GvR’s “Marketing Python - An Idea Whose
Time Has Come” Artima post at
http://www.artima.com/weblogs/viewpost.jsp?thread=150515

"Trying to market python is useless, it has to sell itself. Ruby isn’t
marketed as most in this forum seem to believe. It is has one great
vehicle: RoR. The ideas behind RoR were interesting enough to sell
itself. Ruby just piggybacks.

Fortunately for Python there is one giant opportunity right under its
nose: mobile devices. I won’t grow tired pointing out that the market of
mobile devices will be so much bigger than the PC market. With Nokia’s
open source implementation of a Python interpreter for their series 60
phones the first steps have been taken in the right direction. And it’s
a direction that the Ruby community completely ignores. I’ve been using
Ruby before Python and once explicitely asked the Ruby community, via
their main newsgroup, whether anybody was thinking about a Ruby
interpreter for mobile devices. No positive reactions.

So if you want Python to become more popular, grab the source of Nokia’s
implementation from here:

and port it every thinkable mobile device. Compelling applications will
follow, believe me, since the advantage of using python over e.g. java
microedition are enormous and many developers will be eager to switch."


#2

A number of people have approached the JRuby project, asking if there
could be a way to run JRuby within a Java ME or embedded Java
environment. Sadly, with the complexity of JRuby and its dependencies
on mainstream “standard” Java, we don’t have a good way to do this.
However, it again shows there’s interest in embedded Ruby.

I would also be very interested in a standard microruby that could be
embedded, mainly because devising such a standard would provide a
baseline we could use for a “micro” JRuby. If there were a core subset
of Ruby functionality that could be stuffed into a micro version, it
would probably be easier for both C Ruby and JRuby to create
miniaturized implementations. People really do want embedded/micro
Ruby…when will it be easy for them to find it?


#3

Hi,

In message “Re: Ruby on the mobile?”
on Sat, 4 Mar 2006 01:21:48 +0900, “Berger, Daniel”
removed_email_address@domain.invalid writes:

|I found this post interesting. Is Ruby ignoring the mobile market? Do
|we need a “microruby” implementation?

Hmm, Ruby is not originally designed for mobile devices, since it has
much bigger core than, say, Python, or Lua. But devices are getting
more and more powerful. I don’t think we need to wait for no longer
than 4 years, to see JRuby run on our cell phones.

For your information, Ruby does run on mobile devices, namely on Sharp
Linux Zaurus. Perhaps we could manage to compile it on Windows CE
Mobile as well.

						matz.

#4

Berger, Daniel wrote:

From Berco Beute, commenting on GvR’s “Marketing Python - An Idea Whose
Time Has Come” Artima post at
http://www.artima.com/weblogs/viewpost.jsp?thread=150515

"Trying to market python is useless, it has to sell itself. Ruby isn’t
marketed as most in this forum seem to believe. It is has one great
vehicle: RoR. The ideas behind RoR were interesting enough to sell
itself. Ruby just piggybacks.

That’s too funny. Where do people come up with these ideas? The
“Remedial Trolling” class?


#5

Berger, Daniel wrote:

Hi all,

I found this post interesting. Is Ruby ignoring the mobile market?
Do we need a “microruby” implementation?

I think a reworked runtime (maybe JVM?) which supports native threads is
more important. To me, mobile devices is just a hype - although it may
help from time to time; applets seem to have had a positive impact on
Java’s popularity. Having said that, let the Python camp have the
mobiles
all right - Ruby then will happily take over all servers… :slight_smile:

Just my 0.02 EUR

Kind regards

robert

#6

Hello Folks since I do program in mobile java let me clue you in…

While in J2ME MIDP we cannto do ruby as jruby on the J2EM JVMs…

…it might be possibl eot do JRuby on other ruby on the J2ME JVMs that
support PersonalJava ie the CDC mobile platform…

As PersonalJvaa is actually almost a complete full set of java1.1…it
may be possibl eto run JRuby on a mobile device supporting CDC such as
SonyEricsson recently reelased new pen based handsets…


#7

Oh yeah, I had forgotten PersonalJava. Actually almost all my with
with embedded Java has been on sub-CLDC profiles, so I rarely venture
out of the deepest embedded worlds.

That might be a good way to get Ruby on a mobile device, since a
subset of JRuby could be modified to work on PersonalJava…maybe
easily. My hope would be for a community-wide effort to define what a
“micro” Ruby should be able to do…so that we could define the “micro
edition” of Ruby the same way across all platforms. It would seem to
me that’s exactly what embedders need…a common “micro ruby” they can
write scripts for that will work correctly on all devices.

  • Charlie

#8

In article removed_email_address@domain.invalid,
gregarican removed_email_address@domain.invalid wrote:

implementations on more small devices platforms so there was no real
choice between the two.

So why does Python have more working implementations on small device
platforms
than Ruby does?

Phil


#9

Berger, Daniel wrote:

I found this post interesting. Is Ruby ignoring the mobile market? Do
we need a “microruby” implementation?

Good point. Personally as a language I like Ruby better than Python and
Ruby’s mindset matches mine better than Python’s. But for a project
where I was trying to port an app to various handheld devices I was
forced to abandon Ruby in favor of Python so that I had the ability to
offer the most flexible solution. Python currently has working
implementations on more small devices platforms so there was no real
choice between the two.


#10

Probably they have separated POSIX dependent functions into modules.
In contrast Ruby took all-in-one approach, so that some kind of POSIX
emulation layer is required on non POSIX platform (including mobile
devices). The Ruby approach is useful (no clumsy list of imports),
but not the best for small devices.

The idea of a stripped down ruby, which just depends on ANSI-C,
is quite appealing. Is it possible to compile an interpreter without
Dir, File, IO, Process and other system stuff or are there
too many internal dependencies on POSIX?


#11

Hi,

In message “Re: Ruby on the mobile?”
on Sat, 4 Mar 2006 05:28:49 +0900, removed_email_address@domain.invalid (Phil T.)
writes:

|So why does Python have more working implementations on small device platforms
|than Ruby does?

Probably they have separated POSIX dependent functions into modules.
In contrast Ruby took all-in-one approach, so that some kind of POSIX
emulation layer is required on non POSIX platform (including mobile
devices). The Ruby approach is useful (no clumsy list of imports),
but not the best for small devices.

						matz.

#12

Ruby’s Parser depends on File and IO, so that it’s bit hard to
separate them. Other system stuff can be separated rather easily,
I think.

This surprises me, as I cannot find anything related in parse.y or did
I look in the wrong place?


#13

Hi,

In message “Re: Ruby on the mobile?”
on Sat, 4 Mar 2006 18:18:38 +0900, “Matthias G.”
removed_email_address@domain.invalid writes:

|The idea of a stripped down ruby, which just depends on ANSI-C,
|is quite appealing. Is it possible to compile an interpreter without
|Dir, File, IO, Process and other system stuff or are there
|too many internal dependencies on POSIX?

Ruby’s Parser depends on File and IO, so that it’s bit hard to
separate them. Other system stuff can be separated rather easily,
I think.

						matz.

#14

“M” == Matthias G. removed_email_address@domain.invalid writes:

M> This surprises me, as I cannot find anything related in parse.y or
did
M> I look in the wrong place?

NODE*
rb_compile_file(f, file, start)
const char *f;
VALUE file;
int start;
{
lex_gets = rb_io_gets;
lex_input = file;
lex_pbeg = lex_p = lex_pend = 0;
ruby_sourceline = start - 1;

return yycompile(f, start);

}

See the VALUE file and rb_io_gets()

Guy Decoux


#15

Good point. Personally as a language I like Ruby better than Python and
Ruby’s mindset matches mine better than Python’s. But for a project
where I was trying to port an app to various handheld devices I was
forced to abandon Ruby in favor of Python so that I had the ability to
offer the most flexible solution. Python currently has working
implementations on more small devices platforms so there was no real
choice between the two.

Then port Ruby.

In my case, that was (a few years ago!) to linux-on-iPAQ, which made it
rather straightforward (dev environment remotely & publicly offered by
handhelds.org or cross-compilation toolkit provided by the same nice
ppl)

On limited CPUs in embedded environments, Ruby’s performance may matter.
Moore and YARV will help :slight_smile:

Bye,
Kero.


#16

On Mar 4, 2006, at 12:08 PM, ts wrote:

VALUE file;

See the VALUE file and rb_io_gets()

Guy Decoux

Wow, that’s kind of (if I may be permitted to use the term) badass. I
can just see someone (probably Matz.) sitting there coding ruby and
thinking “Hmm, I’ve written this neat stdlib with OO support for
files, and I need to read a file to parse it…might as well use it.”


#17

ts schrieb:

return yycompile(f, start);

}

See the VALUE file and rb_io_gets()

Guy Decoux

Thanks Guy!

Replacing rb_io_gets with something aquivalent shouldn’t be too hard.
Alternatively the interpreter has the opportunity to eval ruby strings,
which are loaded without the File class.


#18

Kero wrote:

Then port Ruby.

In my case, that was (a few years ago!) to linux-on-iPAQ, which made it
rather straightforward (dev environment remotely & publicly offered by
handhelds.org or cross-compilation toolkit provided by the same nice ppl)

True. I honestly lack the skill set to get that far under the hood I
suppose. I did work some using a Ruby port for the Sharp Zaurus that
was great. It was based on 1.8.0 I believe and I was able to bring in
some external libraries that made my app really effective. If I had the
talent to port Ruby to Palm OS or Windows Mobile I certainly would
undertake the task. It certainly couldn’t hurt Ruby’s exposure or
influence…