Ruby on the mobile?
Berger, Daniel
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:
http://sourceforge.net/projects/pys60
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."
gregarican
> 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.
James Britt
..
>
>>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?
--
James Britt
Robert Klemme
> 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... :-)
Just my 0.02 EUR
Kind regards
robert
Fred Grott
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..
--
Posted via http://www.ruby-forum.com/.
Charles O Nutter
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
On 3/3/06, Fred Grott <fred....@gmail.com> wrote:
> 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..
>
>
>
> --
> Posted via http://www.ruby-forum.com/.
>
>
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
Phil Tomson
So why does Python have more working implementations on small device platforms
than Ruby does?
Phil
Yukihiro Matsumoto
In message "Re: Ruby on the mobile?"
on Sat, 4 Mar 2006 05:28:49 +0900, pt...@aracnet.com (Phil Tomson) 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.
Matthias Georgi
>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?
Yukihiro Matsumoto
In message "Re: Ruby on the mobile?"
on Sat, 4 Mar 2006 18:18:38 +0900, "Matthias Georgi" <matti....@gmail.com> 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.
Matthias Georgi
>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?
Kero
> 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 :)
Bye,
Kero.
ts
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
Logan Capaldo
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."
Matthias Georgi
> 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
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.
gregarican
> 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...