Ruby VM Projects

M

Mark Wassell

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
 
D

David Ross

Mark said:
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
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
 
H

Hal Fulton

Mark said:
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.

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
 
E

Eric Hodel

--Apple-Mail-4-943443563
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; format=flowed

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.

--
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--Apple-Mail-4-943443563
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFBaGtJMypVHHlsnwQRAsuZAJwNGCf0t12WVem+/7ZqzHdL3sJaTACg84pU
2JO2M9HLkOY/Y8Pdvs77+GU=
=HPTg
-----END PGP SIGNATURE-----

--Apple-Mail-4-943443563--
 
D

David Ross

Eric said:
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
 
G

gabriele renzi

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?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.

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 :)
 
A

Alexander Kellett

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.

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 :p

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
 
A

Alexander Kellett

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 sort of person unfortunately so if
its ever created, i hope there's a bi-di gateway :p

mvg,
Alex
 
A

Alexander Kellett

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 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
 
E

Eric Hodel

--mPOSj6iWmtyhwOMz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Eric Hodel wrote:
=20
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...

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--mPOSj6iWmtyhwOMz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFBaN7qMypVHHlsnwQRAlZJAJwNNvTFridu92J24XR6iLMj8f3BcQCgghnI
R+yTpLQApERPHfAg+McgI14=
=mW58
-----END PGP SIGNATURE-----

--mPOSj6iWmtyhwOMz--
 
M

mark sparshatt

Alexander said:
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.
 
A

Alexander Kellett

You're right that Cardinal uses Ripper as it's parsing component, but it
was written by Minero Aoki, rather than Robert Feldt.

oops. thanks mark. sorry minero :(

Alex
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: Ruby VM Projects"

|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.
 
D

David Ross

Eric said:
David Ross ([email protected]) wrote:




The wheel is broken. matz says so, and if you look at eval.c, you'll
see why. Ruby needs a new interpreter.




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 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.
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
:p (*never ever send unnatural Japanese, *ouch*)

--dross
 
R

Richard Dale

David said:
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
 
D

David Ross

Richard said:
David Ross wrote:



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
 
L

Lothar Scholz

Hello David,

DR> A better result would be to get many people and coordinate those efforts
DR> to accomplish a single task. Instead, we have 30 VM projects on the
DR> 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).
 
M

Matt Lawrence

It's not broken. It's just creaking. I agree with rest of your
words.

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.
 
E

Eric Hodel

--B9BE8dkJ1pIKavwa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Eric Hodel wrote:
=20

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.

--=20
Eric Hodel - (e-mail address removed) - http://segment7.net
All messages signed with fingerprint:
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04


--B9BE8dkJ1pIKavwa
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQFBaZNlMypVHHlsnwQRAgmlAKDQ6EuCH18Wnoa67TahIPkqtOzsJQCfRuM+
enuS8i1vJJCpT7BKXwvMaYY=
=EeaT
-----END PGP SIGNATURE-----

--B9BE8dkJ1pIKavwa--
 
G

gabriele renzi

Matt Lawrence ha scritto:
Just remember, it doesn't have to be round to roll.

-- Matt

and actually, on a road made of half circles a squared wheel goes way
better than a round one :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top