There are a number of RubyVM machine projects some just starting, some
'almost' there, some very active and some dormant. See
http://www.rubygarden.org/ruby?VirtualMachineOptions
I am wondering if this is one area of Ruby that requires some form of
coordination. I appreciate that this isn't the way that Ruby projects are
handled in general but perhaps this can be an exception, at least until we
get one VM project through the gate.
Just a thought.
Cheers
Mark
Mark Wassell wrote:
There are a number of RubyVM machine projects some just starting, some
'almost' there, some very active and some dormant. See
http://www.rubygarden.org/ruby?VirtualMachineOptionsI am wondering if this is one area of Ruby that requires some form of
coordination. I appreciate that this isn't the way that Ruby projects are
handled in general but perhaps this can be an exception, at least until we
get one VM project through the gate.Just a thought.
Cheers
Mark
Not to sound mean, but its more of a phase people(community) go through. Just like the Ruby Text editor phase we had 6 months ago. I guess its time for a new fad,VM creation.
--dross
Mark Wassell wrote:
There are a number of RubyVM machine projects some just starting, some
'almost' there, some very active and some dormant. See
http://www.rubygarden.org/ruby?VirtualMachineOptionsI am wondering if this is one area of Ruby that requires some form of
coordination. I appreciate that this isn't the way that Ruby projects are
handled in general but perhaps this can be an exception, at least until we
get one VM project through the gate.
I sympathize with what you're saying, but there are problems with it.
- There is no one philosophy of how a VM ought to be done. Thus there is
a strong tendency for people to say, "I don't like that approach, I'll
make my own."
- Matz wants to use "his own" VM, which may or may not be YARV or some
existing project, but *will* be tailored specifically to Ruby.
- Matz, of course, has many subprojects and is very busy.
- Some projects target other VMs: Parrot, JVM, LLVM?, .NET, and so on. Even
when Matz writes/picks the One True VM, these other projects won't go away
or be invalidated.
Having said that: Synergy is a great thing. If people can somehow cooperate
and focus their efforts, that's great. Ultimately Matz's call I guess.
Hal
Mark Wassell ha scritto:
There are a number of RubyVM machine projects some just starting, some
'almost' there, some very active and some dormant. See
http://www.rubygarden.org/ruby?VirtualMachineOptionsI am wondering if this is one area of Ruby that requires some form of
coordination. I appreciate that this isn't the way that Ruby projects are
handled in general but perhaps this can be an exception, at least until we
get one VM project through the gate.Just a thought.
some points to think about:
- some things on that page are hust suggestions so the list gets smaller
- some are old things already abandonware
- some things are actually shared (i.e. I guess they're not rewriting the parser by themselve)
- maybe there is interaction 
At least you can find koichi sasada from yarv and alexander kellet from rubydium on #ruby-lang 
(and I think some other )
anyway, if there was a comp.lang.ruby.raving.about.new.vms with all those hackers I'd love to subscribe
just based on my own experience and my own development model /
architecture. there is no way on earth that i could work together
with someone else at this stage of development. the core is just
plain tiny, and it would be extremely difficult to coordinate a
team of people to work on it, i'm not certain it would be a good
thing in any case as i don't really believe that it requires a
team in any case... admittedly in a few months the core library
layer will be finished and the String / Interger / Array classes
will all need to be written (in ruby of course :)), i guess this
work could be done by a team.
in any case, as hal and gabriele pointed out, the main reason
for the variety of projects is that they just don't overlap
cheers,
Alex
On Sun, Oct 10, 2004 at 05:54:41AM +0900, Mark Wassell wrote:
There are a number of RubyVM machine projects some just starting, some
'almost' there, some very active and some dormant. See
http://www.rubygarden.org/ruby?VirtualMachineOptionsI am wondering if this is one area of Ruby that requires some form of
coordination. I appreciate that this isn't the way that Ruby projects are
handled in general but perhaps this can be an exception, at least until we
get one VM project through the gate.
No, people want the son-shi award.
PGP.sig (186 Bytes)
On Oct 9, 2004, at 2:06 PM, David Ross wrote:
Not to sound mean, but its more of a phase people(community) go through. Just like the Ruby Text editor phase we had 6 months ago. I guess its time for a new fad,VM creation.
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
some points to think about:
- some things are actually shared (i.e. I guess they're not rewriting
the parser by themselve)
nod. i'm re-using robert feldt's ruth parser for example.
and robert feldt's later project ripper is used by cardinal
from what i remember (though i'd love to be whacked with a
cluebat if i'm wrong here i didn't really look enough at
the code base yet)
writing parser frameworks sure is interesting but its a
heck of a tangent and there are other people i know that
are far better than me at it anyway
anyway, if there was a comp.lang.ruby.raving.about.new.vms with all
those hackers I'd love to subscribe
hehe
i'm not a news:/ sort of person unfortunately so if
its ever created, i hope there's a bi-di gateway 
mvg,
Alex
On Sun, Oct 10, 2004 at 10:09:51AM +0900, gabriele renzi wrote:
Eric Hodel wrote:
Not to sound mean, but its more of a phase people(community) go through. Just like the Ruby Text editor phase we had 6 months ago. I guess its time for a new fad,VM creation.
No, people want the son-shi award.
I seriously don't see why people are wanting to recreate the wheel, its not even being recreated in C. I was looking at all the VMs people were working on, which most are being built on top of another VM. This is very wasteful. I can see if they were creating a project because of the license, or perhaps the code was really bad. These projects are getting to be really halarious to me.
--dross
On Oct 9, 2004, at 2:06 PM, David Ross wrote:
Alexander Kellett wrote:
On Sun, Oct 10, 2004 at 10:09:51AM +0900, gabriele renzi wrote:
some points to think about:
- some things are actually shared (i.e. I guess they're not rewriting the parser by themselve)nod. i'm re-using robert feldt's ruth parser for example.
and robert feldt's later project ripper is used by cardinal
from what i remember (though i'd love to be whacked with a cluebat if i'm wrong here i didn't really look enough at the code base yet)
You're right that Cardinal uses Ripper as it's parsing component, but it was written by Minero Aoki, rather than Robert Feldt.
--
Mark Sparshatt
well neither of the two projects that appear
to be making the most progress fast are based
on a preexisting vm - yarv and my own project
of course
not sure i understand what you mean by recreate
the wheel. there is no overlap between the current
set of ruby vm projects that i can see.
some target .net for interoperability reasons,
one parrot for the same reasons (i hope / think),
and the remaining two that i know of (not sure how
bytecoderuby is going admittedly?) are two *very*
different approaches.
sorry, but i just don't see any wheel thats being
recreated, however, i do see recreation on a
wheel that is in dire need of being spun...
cheers,
Alex
On Sun, Oct 10, 2004 at 07:56:54AM +0900, David Ross wrote:
I seriously don't see why people are wanting to recreate the wheel, its
not even being recreated in C. I was looking at all the VMs people were
working on, which most are being built on top of another VM. This is
very wasteful. I can see if they were creating a project because of the
license, or perhaps the code was really bad. These projects are getting
to be really halarious to me.
Eric Hodel wrote:
>
>>Not to sound mean, but its more of a phase people(community) go
>>through. Just like the Ruby Text editor phase we had 6 months ago. I
>>guess its time for a new fad,VM creation.
>
>
>No, people want the son-shi award.
>
I seriously don't see why people are wanting to recreate the wheel,
The wheel is broken. matz says so, and if you look at eval.c, you'll
see why. Ruby needs a new interpreter.
its not even being recreated in C.
There are few compelling reasons to use C. There are few non-Japanese
speaking Ruby interpreter hackers (I mean eval.c) because it is very
difficult to get over the language barrier. I believe matz has said
that eval.c contains "black magic".
I was looking at all the VMs people were working on, which most are
being built on top of another VM. This is very wasteful.
I don't see how this is wasteful. Writing a VM takes a lot of work, to
be fast, and there are plenty of fast VMs out there. Furthermore, its
not very fun.
Writing an interpreter in Ruby that can output to
#{VM_or_language_of_choice} is much better for everybody because it
lowers the barrier to entry for future interpreter hackers/tweakers/etc.
I can see if they were creating a project because of the license, or
perhaps the code was really bad. These projects are getting to be
really halarious to me.
People are writing interpreters because it is a Hard Thing To Do.
(Count up all the nodes types in Ruby's AST, you'll see why its hard.)
This difficulty makes it fun (very, very fun, I know from experience).
Look at how many web frameworks Ruby has of varying complexity, or how
many template tools. Look at any other scripting language to see how
many different tools to do whatever you want there are. Many are of
equal quality and similar licenses, but nobody's knocking them for
duplicate effort.
PS: If you don't have anything nice to say...
David Ross (dross@code-exec.net) wrote:
>On Oct 9, 2004, at 2:06 PM, David Ross wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
oops. thanks mark. sorry minero 
Alex
On Sun, Oct 10, 2004 at 05:37:09PM +0900, mark sparshatt wrote:
You're right that Cardinal uses Ripper as it's parsing component, but it
was written by Minero Aoki, rather than Robert Feldt.
Hi,
In message "Re: Ruby VM Projects" on Sun, 10 Oct 2004 16:04:13 +0900, Eric Hodel <drbrain@segment7.net> writes:
The wheel is broken. matz says so, and if you look at eval.c, you'll
see why. Ruby needs a new interpreter.
It's not broken. It's just creaking. I agree with rest of your
words.
matz.
Eric Hodel wrote:
Eric Hodel wrote:
Not to sound mean, but its more of a phase people(community) go through. Just like the Ruby Text editor phase we had 6 months ago. I guess its time for a new fad,VM creation.
No, people want the son-shi award.
I seriously don't see why people are wanting to recreate the wheel,
The wheel is broken. matz says so, and if you look at eval.c, you'll
see why. Ruby needs a new interpreter.its not even being recreated in C.
There are few compelling reasons to use C. There are few non-Japanese
speaking Ruby interpreter hackers (I mean eval.c) because it is very
difficult to get over the language barrier. I believe matz has said
that eval.c contains "black magic".
Use C for speed. Yes, eval.c is not so great, and a syntax error which isnt very specific as what is wrong is bad.
I was looking at all the VMs people were working on, which most are
being built on top of another VM. This is very wasteful.
I don't see how this is wasteful. Writing a VM takes a lot of work, to
be fast, and there are plenty of fast VMs out there. Furthermore, its
not very fun.Writing an interpreter in Ruby that can output to
#{VM_or_language_of_choice} is much better for everybody because it
lowers the barrier to entry for future interpreter hackers/tweakers/etc.
My argument isn't to stop the efforts, its to get efforts organized instead of 1) wasting time 2) wasting people 3) creating several small projects which will go nowhere.
why 3? If only one person works on the project, or even just two. You will end up with code which might not look completely right. No one will want to fix it. Project dead. Getting more people in projects will allow thought in implementation.
I can see if they were creating a project because of the license, or
perhaps the code was really bad. These projects are getting to be
really halarious to me.
People are writing interpreters because it is a Hard Thing To Do.
(Count up all the nodes types in Ruby's AST, you'll see why its hard.)
This difficulty makes it fun (very, very fun, I know from experience).Look at how many web frameworks Ruby has of varying complexity, or how
many template tools. Look at any other scripting language to see how
many different tools to do whatever you want there are. Many are of
equal quality and similar licenses, but nobody's knocking them for
duplicate effort.
A better result would be to get many people and coordinate those efforts to accomplish a single task. Instead, we have 30 VM projects on the rise. A waste of man-power. I guess if they shed thier light you can also see some as "don't do in future". aka. Failures and Learning Exp. Which can be a good thing.
/me wonders back to broken conversatoin with the Japanese on WideStudio (*never ever send unnatural Japanese, *ouch*)
--dross
David Ross (dross@code-exec.net) wrote:
On Oct 9, 2004, at 2:06 PM, David Ross wrote:
David Ross wrote:
A better result would be to get many people and coordinate those efforts
to accomplish a single task. Instead, we have 30 VM projects on the
rise. A waste of man-power. I guess if they shed thier light you can
also see some as "don't do in future". aka. Failures and Learning Exp.
Which can be a good thing.
We don't need extra 'Managerial super-heroes' to help co-ordinate limited
resources. The people who are doing this stuff are not normal programmers
at all, and your ideas about a 'waste of man-power' are just plain wrong.
When dealing with these guys - the rules are completely different. Great
Hackers are most certainly not 'resources to be managed' as you seem to
think.
We need extra Hackers (aka Scientific researchers) who do stuff and
coordinate via peer review. I see nothing wrong with Alex or Koichi trying
out jit techniques or VM things while others try out Ruby/Parrot
integration.
-- Richard
Hello David,
A better result would be to get many people and coordinate those efforts
to accomplish a single task. Instead, we have 30 VM projects on the
rise. A waste of man-power. I guess if they shed thier light you can
What makes you think that there are a lot of people working on it ?
If no time is spend there can't be a waste of human power.
And if they are research projects to get a Ph.D. you simply can't do
collaborate work (some universities have a few relaxed rules but
it is still very hard to get this accepted).
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
Just remember, it doesn't have to be round to roll.
-- Matt
It's not what I know that counts, it's what I can remember in time to use.
On Sun, 10 Oct 2004, Yukihiro Matsumoto wrote:
It's not broken. It's just creaking. I agree with rest of your
words.
Eric Hodel wrote:
>>its not even being recreated in C.
>
>There are few compelling reasons to use C. There are few non-Japanese
>speaking Ruby interpreter hackers (I mean eval.c) because it is very
>difficult to get over the language barrier. I believe matz has said
>that eval.c contains "black magic".Use C for speed.
There is no need to use C to be fast. Read the Squeak paper.
In a matter of months (18?) the Squeak team had an implementation of
Smalltalk written in Smalltalk that was reasonably comparable in speed
to commercial Smaltalk implementations *before JIT*. This included
things like a multimedia library that was capable of synthesizing
multiple channels in real-time and a full GUI layer.
The Squeakers used two key components to get this advantage. They used
a Smalltalk subset that could be compiled to C, and they inlined
everything they could.
(The Squeakers had several advantages over Ruby, I'll have to write
about them sometime.)
I must note the story of a JIT on the HPPA architecture that was
faster than the compiled version because the JIT was good enough to
optimize for actual usage.
A combination of these approaches allows you to be fast and easy to
hack.
I prefer writing Ruby over writing C, and if I have to use C at all, I'd
rather have it generated for me so I don't have to think about it.
Yes, eval.c is not so great, and a syntax error which isnt very
specific as what is wrong is bad.
Syntax errors are found during parsing, not interpreting.
David Ross (dross@code-exec.net) wrote:
--
Eric Hodel - drbrain@segment7.net - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
David Ross wrote:
There are few compelling reasons to use C. There are few non-Japanese
speaking Ruby interpreter hackers (I mean eval.c) because it is very
difficult to get over the language barrier. I believe matz has said
that eval.c contains "black magic".Use C for speed. Yes, eval.c is not so great, and a syntax error which isnt very specific as what is wrong is bad.
Use C, ah yes. And spend 10x more time coding the same amount of code. Thanks, but no thanks. (Actually, I will use C, but only after everything else has been tried).
Wouldn't you like if Ruby could run 50%-300% faster than the current implementation (because it really could, the current implementation is not really efficient)? Me, I'd kill for that
--
dave
Richard Dale wrote:
David Ross wrote:
A better result would be to get many people and coordinate those efforts
to accomplish a single task. Instead, we have 30 VM projects on the
rise. A waste of man-power. I guess if they shed thier light you can
also see some as "don't do in future". aka. Failures and Learning Exp.
Which can be a good thing.We don't need extra 'Managerial super-heroes' to help co-ordinate limited
resources. The people who are doing this stuff are not normal programmers
at all, and your ideas about a 'waste of man-power' are just plain wrong.
When dealing with these guys - the rules are completely different. Great
Hackers are most certainly not 'resources to be managed' as you seem to
think.
Many hackers are coordinated. There are many projects which have a team and have specific areas to focus on. Management of OSS projects if a plus. There are big projects, and even small projects which have mangement. FreeBSD team is one of the larger projects. Then there are projects like DragonFlyBSD Installer project which is even smaller than what a VM team should have yet they *DO HAVE* management to who works on what area. Management is a must to make the project move faster.
We need extra Hackers (aka Scientific researchers) who do stuff and
coordinate via peer review. I see nothing wrong with Alex or Koichi trying
out jit techniques or VM things while others try out Ruby/Parrot
integration.
We need management and collaborated efforts!
--dross