lack of reaction to latest ruby implementations

[Alexander Kellett]

working on alternatives for the ruby runtime has
to be about the most difficult tasks one could take
on, and on top of that, the community interest doesn't
really help.

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

come on guys and gals, surely these projects are worth
way more than that? what with being a possible future
to ruby, it seems natural that people would express
much more interest!

even if you don't want to or don't think you could help
out directly then at least get involved!, give feedback!
i'm sure the developers would love it!

Alex

 

[Daniel Berger]

working on alternatives for the ruby runtime has
to be about the most difficult tasks one could take
on, and on top of that, the community interest doesn't
really help.

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

come on guys and gals, surely these projects are worth
way more than that? what with being a possible future
to ruby, it seems natural that people would express
much more interest!

even if you don't want to or don't think you could help
out directly then at least get involved!, give feedback!
i'm sure the developers would love it!

Alex

Well, Alex, I kinda feel like a caveman who's just been given a wrench.
You're screaming "Look! Look! Look at this awesome tool we've
invented! And it's all yours!". I'm staring at the shiny new metal
thing, and deep down I get the feeling it's pretty important, but I
just don't know what to do with it.

Know what I mean?

Regards,

Dan

 

[Lyle Johnson]

working on alternatives for the ruby runtime has
to be about the most difficult tasks one could take
on, and on top of that, the community interest doesn't
really help.

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

come on guys and gals, surely these projects are worth
way more than that? what with being a possible future
to ruby, it seems natural that people would express
much more interest!

even if you don't want to or don't think you could help
out directly then at least get involved!, give feedback!
i'm sure the developers would love it!

I don't think the (perceived) lack of response indicates a lack of
interest. To be fair, Ruby2C was only announced two days ago and I
suspect that most people (including myself) just haven't had the time
to download and try it out.

 

[Navindra Umanee]

maybe its just me but i expected *many* more emails in
reply to the yarv and ruby2c releases!!!!!

I'm not sure what you're talking about.

Where is the YARV announcement/release on this list? I certainly
haven't seen it. I saw a yarv/db thread but that was it. YARV looks
and sounds very interesting though. I just don't have a project to
run on it yet... when I do I'll make noise.

ruby2c seems a very specialised thing. I mean sure, it's nearly 1.0.0
but nobody seems really sure what to do with it given the limitations
which are apparently by design.

Anyway, as a newcomer, I'm sure I don't know what to make of all this.
What about the official Ruby release and VM? Seems to be a lot of
forking going on.

Cheers,
Navin.

 

[Bill Atkins]

I think you're misunderstanding the idea of YARV and ruby2c. They
aren't forks of Ruby. YARV is a VM for Ruby which is likely to become
part of Ruby 2.0. YARV works with your existing Ruby code (except for
unimplemented features, like continuations), and ruby2c is simply a
program that converts Ruby code into C. There's no forking going on,
and Matz's Ruby is still the one and only Ruby implementation.

Bill

 

[jm]

Anyway, as a newcomer, I'm sure I don't know what to make of all this.
What about the official Ruby release and VM? Seems to be a lot of
forking going on.

I prefer to think of it as active experimentation.

Jeff.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: lack of reaction to latest ruby implementations"

|Matz's Ruby is still the one and only Ruby implementation.

You have JRuby as well.

matz.

 

[Joe Van Dyk]

Well, Alex, I kinda feel like a caveman who's just been given a wrench.
You're screaming "Look! Look! Look at this awesome tool we've
invented! And it's all yours!". I'm staring at the shiny new metal
thing, and deep down I get the feeling it's pretty important, but I
just don't know what to do with it.

Know what I mean?

Regards,

Dan

Sums up my thoughts perfectly.

Joe

 

[Aredridel]

I think it's a case of bated excitement. We dare not speak, for fear of
disturbing progress.

It's mostly for me, a combination of having work to get done at the
moment and no time to help -- I can only watch from afar, and hope for
the best.

 

[Nicholas Van Weerdenburg]

Maybe it sounded to good to be true, and occupied the same mindspace
as Parrot and other dynamic VMs. That's sortof how my brain processed
it. It sortof hurts to think about VMs- it's like the beautiful girl
that is unattainable, so better not to get your hopes up .

That said, my reaction was "wow, cool".

Nick

 

[yakumo9275]

Id be way more interested in YARV if it wasnt so convoluted
to do. I have to download yarv (a given!), get a patch to
the ruby CVS... then get ruby from cvs. patch ruby. try and build.

i would rather have a tarball i could just download where its all
done.. then I have to try and not clobber any of my existing ruby
install (an easy given).

i usually break things when I try applying patches.

but then what? where from there? what next? how do I give feedback? how
do I help? I think YARV is a very important next step for ruby, but
what needs to be done to leap the chasm of just compiling it to being
helpful and providing back?

-stu

 

[Alexander Kellett]

Where is the YARV announcement/release on this list? I certainly
haven't seen it. I saw a yarv/db thread but that was it. YARV looks
and sounds very interesting though. I just don't have a project to
run on it yet... when I do I'll make noise.

the yarv announcement was a while ago, but i was just
surprised by the lack of interest in the two projects.
i hear so frequently "ruby is too slow" when in most
cases its just plain Fast Enough and in the few cases
when its not, projects like yarv and ruby2c attempt
to help and yet receive little feedback

maybe there is much feedback on the yarv-jp mailing list?

ruby2c seems a very specialised thing. I mean sure, it's nearly 1.0.0
but nobody seems really sure what to do with it given the limitations
which are apparently by design.

see my reply to dan.

Anyway, as a newcomer, I'm sure I don't know what to make of all this.
What about the official Ruby release and VM? Seems to be a lot of
forking going on.

there is no official ruby vm... yet.
and these aren't forks, they are built
on top of the current ruby interpreter.

Alex

 

[Alexander Kellett]

Well, Alex, I kinda feel like a caveman who's just been given a wrench.
You're screaming "Look! Look! Look at this awesome tool we've
invented! And it's all yours!". I'm staring at the shiny new metal
thing, and deep down I get the feeling it's pretty important, but I
just don't know what to do with it.

Know what I mean?

hehe. oh. ah!. funny comparison

well usage wise, i agree its not like you
can jump on board and replace your ruby
interpreter with either yarv or ruby2c/metaruby.
however, i would have expected that more people
were interested in a) helping out, b) giving
feedback, c) at least cheering the guys on

as far as i understand, with ruby2c it would
be possible to write ruby extensions in a subset
so rather than having to write extensions in c
in order to fix a specific speed problem that
a better algorithm just doesn't exist for,
ruby2c could be used, no static typing, just
easy to write ruby! okay sure, there are many
limitations but i'd rather use a limited ruby
than have to worry about static typing
definitions in c!

and then on to metaruby, which is just plain
cool imagine a ruby implementation written
in the language itself! rather than needing to
understand *yet another language* just to make
a minor change (for example to see how an rcr
would look in real life) wouldn't you love to be
able to extend and toy around with the interpreter
you're oh so fond of?

and YARV, well, just look at the benchmarks!
sure there are a few minor missing features, but
on the whole, other than bugs (which ko1 would
more than glad to know about i guess its
certainly not something to ignore

anyways. at least i know now that its not because
of lack of interest. seems like a set of
misunderstandings

so just to check, people are actually interested
in a faster ruby right? interested in a ruby 2.0
which would not only be faster in the general case!,
but due to the those speed improvements, would also
have some of the features that in the past were
cast off due to possible speed problems?. a ruby
implementation in which RCR's can be implemented
at a whim and extra extensions added in an easy
to use ruby subset?

thanks for the replies everyone
Alex

 

[Alexander Kellett]

i've seen very little from parrot directly with regards
to ruby, there is no maintained ruby/mono implementation,
and cardinal ain't seen a commit in quite a while. not sure
if somethings happening off in the background, but i've not
seen anything public.

yarv and ruby2c are both projects based around a community
need, and have no large external dependancies. what with yarv
being a possible implementation of the future ruby 2.0, aka
rite, i was very surprised that its not talked of much more.

any japanese speakers know if such things are spoken of
on the jp mailing lists?

/me ponders writing a book
- 'the loneliness of a ruby re-implementor'

Alex

 

[gabriele renzi]

Alexander Kellett ha scritto:

i hear so frequently "ruby is too slow" when in most
cases its just plain Fast Enough and in the few cases
when its not, projects like yarv and ruby2c attempt
to help and yet receive little feedback

maybe there is much feedback on the yarv-jp mailing list?

there is more traffic than on the english one.
I guess this relates to the subject being somewhat exotic, or hard,
still in development, and to some papers published in japanese

As for ruby2c.. it's just been released too little time ago

 

[gabriele renzi]

(e-mail address removed) ha scritto:

Id be way more interested in YARV if it wasnt so convoluted
to do. I have to download yarv (a given!), get a patch to
the ruby CVS... then get ruby from cvs. patch ruby. try and build.

i would rather have a tarball i could just download where its all
done.. then I have to try and not clobber any of my existing ruby
install (an easy given).

i usually break things when I try applying patches.

write yourself a simple script to automate the task, and just have a
little care to configure the ruby build with something like
--program-suffix=19forYARVexperimentation

but then what? where from there? what next? how do I give feedback? how
do I help? I think YARV is a very important next step for ruby, but
what needs to be done to leap the chasm of just compiling it to being
helpful and providing back?

I agree on this, and I think it is also valid for ruby2c, rubydium and
maybe ruby itself (but you have the ruby hacker's guide, there).

My 2c:
a great example of how to handle the newbie-developer-barrier is the
Kernel Janitor project for linux (and IIRC there is something similar in
freebsd-land).
Provide some tiny goals for newbie developers which are simple enough to
be done for them and that basically annoy you
I.e. fix some of the thousand warnings that ruby and yarv spit out when
compiled with various warning flags.

This allows to get a feeling on the internals, produces a useful result,
and lowers the gap beetween "user" and "developer".

 

[Phil Tomson]

i've seen very little from parrot directly with regards
to ruby, there is no maintained ruby/mono implementation,
and cardinal ain't seen a commit in quite a while. not sure
if somethings happening off in the background, but i've not
seen anything public.

Yeah, Cardinal has been pretty quiet for a while now. I wish I had more
time to work on it. We actually had a plan to go the other direction from
Ruby2C: We wanted to convert RubyC to Ruby so we could automatically
convert the built-in classes like array.c, hash.c, etc to Ruby code. If
we could do something like that it would be useful for metaruby as well, I
suspect. Basically, we need a C parser in Racc - that's the first step
anyway. There are plenty of C grammars out there, so that shouldn't be
too, too hard, but then again...

.....ah, but our ambitious plans haven't led to much action, unfortuneatly.
I haven't had any time to commit to Cardinal since last summer.


Phil

 

[Alexander Kellett]

Yeah, Cardinal has been pretty quiet for a while now. I wish I had
more
time to work on it. We actually had a plan to go the other direction
from
Ruby2C: We wanted to convert RubyC to Ruby so we could automatically
convert the built-in classes like array.c, hash.c, etc to Ruby code.
If
we could do something like that it would be useful for metaruby as
well, I
suspect. Basically, we need a C parser in Racc - that's the first step
anyway. There are plenty of C grammars out there, so that shouldn't be
too, too hard, but then again...

google pyggy. it includes a ansi c parser.
modify it to generate ruby eval-able structures
and load them into ruby. later on port it to ruby,
i'll help, i'm planning to do so anyways at some
point.

would you really want to convert the c anyway?
its a hell of a job and doesn't really provide
much anyway. the point in a ruby core lib written
in ruby itself is to have a well coded basis and
doing it in idiomatic c would thusly seem like
a much better idea, or am i missing something?
from the slant of correctness, yes i'd agree its
a nice aim. but i think it would be such a huge
investment that you may as well spend the time
writing testcases and idiomatic ruby...

.....ah, but our ambitious plans haven't led to much action,
unfortuneatly.
I haven't had any time to commit to Cardinal since last summer.

how about the other developers? i thought
there were a few working on it? maybe i was
mistaken, seems like a shame. how fast are
the python / perl6 implementations written
on top of parrot now?

Alex

 

[Phil Tomson]

google pyggy. it includes a ansi c parser.
modify it to generate ruby eval-able structures
and load them into ruby. later on port it to ruby,
i'll help, i'm planning to do so anyways at some
point.

would you really want to convert the c anyway?
its a hell of a job and doesn't really provide
much anyway. the point in a ruby core lib written
in ruby itself is to have a well coded basis and
doing it in idiomatic c would thusly seem like
a much better idea, or am i missing something?
from the slant of correctness, yes i'd agree its
a nice aim. but i think it would be such a huge
investment that you may as well spend the time
writing testcases and idiomatic ruby...

we need the ruby core libs implemented in ruby (or in Parrot's
IMCC, we wanted to make it so that you could taraget either IMCC or
Ruby, for Cardinal we would first target IMCC).
Perhaps now the aim should be to support the subset of Ruby that Ruby2C
supports so we can go full circle (C -> Ruby -> (Ruby2C) -> C).

Being able to automate the C-> Ruby (or C->IMCC) process would be a big
boon for both Cardinal and metaruby (the ability to keep class
libraries up-to-date when changes/additions occur would a great help).
But again, it's a big task, perhaps a bit too ambitious.

how about the other developers? i thought
there were a few working on it?

Dunno. There are others on the list. I'm not sure what everyone has been
up to.

Check out the cardinal page here:

http://cardinal.rubyforge.org/wiki/wiki.pl

maybe i was
mistaken, seems like a shame. how fast are
the python / perl6 implementations written
on top of parrot now?

I'm not sure how far along those are.

Phil

 

[mark]

google pyggy. it includes a ansi c parser.
modify it to generate ruby eval-able structures
and load them into ruby. later on port it to ruby,
i'll help, i'm planning to do so anyways at some
point.

After a quick look at the PyGgy site,
http://www.lava.net/~newsham/pyggy/, it seems to be a parser generator
written in Python. In which case it might be better to use either Racc
or Rockit.

Though I'll look more closely to see if I'm missing something.

would you really want to convert the c anyway?
its a hell of a job and doesn't really provide
much anyway. the point in a ruby core lib written
in ruby itself is to have a well coded basis and
doing it in idiomatic c would thusly seem like
a much better idea, or am i missing something?
from the slant of correctness, yes i'd agree its
a nice aim. but i think it would be such a huge
investment that you may as well spend the time
writing testcases and idiomatic ruby...

Well the problem was interfacing Parrot with the core lib. The first
solution we tried was using Parrot's native call interface to directly
acces rubylib, but that didn't work.

The next best solution seemed to be to produce a converter which could
translate the c code in to Parrot InterMediate Code. This project didn't
really get past the planning stage so I don't know how much work it
would be or if it would be a feasible goal.

how about the other developers?

Like Phil Thomson I haven't had time to focus on Cardinal for a while now.

i thought
there were a few working on it? maybe i was
mistaken, seems like a shame. how fast are
the python / perl6 implementations written
on top of parrot now?

AFAIK the perl6 implementation is still in the early stages. They have a
working parser engine and are working on the perl 6 grammar.

I don't know how far along the the python implementation has gotten.