matz thoughts on Rite ?

S

Simon Strandgaard

I don't know much about Rite, therefore I ask.


I would like to fill in some more info on this page:
http://www.rubygarden.org/ruby?Rite


What is long term goals for Rite ?
Will it be backward-compatible with Ruby-1.9 ?
Will there be real threading support ?
How about unicode ?
Can people contribute to create Rite (matz helpers/slaves) ?


Tell me what you know about Rite :)
 
S

Simon Strandgaard

In message "matz thoughts on Rite ?"

|What is long term goals for Rite ?
|Will it be backward-compatible with Ruby-1.9 ?
|Will there be real threading support ?
|How about unicode ?
|Can people contribute to create Rite (matz helpers/slaves) ?

Its goal is faster, smaller, more portable.

It will

* have native thread support.
* unicode aware (along with other encoding schemes)

We don't have any code yet to work on. I cannot spare time for Rite
now, so that Rite will be complete vaporware for a while. Perhaps
until 1.8.0 is out.


matz.

Some more Rite questions if its OK :)

* will Rite be developed publicly.. Or will you keep it souce secret ?
* still use Ruby license scheme ?
* do you need help? Say what we should do and we will do it :)
* will it be like Ruby.. Or will there be minor/major differences ?
* will Rite use Mark&Sweep GC or something else ?
 
L

Luc Heinrich

Yukihiro Matsumoto said:
Perhaps until 1.8.0 is out.

And that would be when approximately ? :)

(sorry to bother you with that, but the Python folks will ship a 2.3
release sooner than expected just to be able to integrate it with the
next release of MacOSX. I would personnally love to see a Ruby 1.8 in
Panther in place of the current 1.6.8... :) )
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: matz thoughts on Rite ?"

|> Perhaps until 1.8.0 is out.
|
|And that would be when approximately ? :)

By the end of July. We also want Ruby to be integrated in Panther.

matz.
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: matz thoughts on Rite ?"

|Some more Rite questions if its OK :)

For this time only. ;-)

|* will Rite be developed publicly.. Or will you keep it souce secret ?

From my experience and observation, an open source software needs to
have running code before the ball rolling to success. I think I need
to work alone until the first running version.

|* still use Ruby license scheme ?

It will be open source software for sure. License terms may be
changed.

|* do you need help? Say what we should do and we will do it :)

This is very important. Listen carefully.

From the reason I stated above, I feel like I will work alone.
But if someone shows his talent, and comes up with his own _good_
implementation of new Ruby earlier than me, and if he is willing to
contribute his code, and if he allows me to hack and chop his code to
make it "Rite", I will name it "Rite". And he will be honored for
ever.

|* will it be like Ruby.. Or will there be minor/major differences ?

There will be some incompatibility. This is a big chance to fix what
I've done wrong. For example, block parameters will be local to the
block. But these changes will be implemented in 1.9 first for
migration purpose.

|* will Rite use Mark&Sweep GC or something else ?

It will use generational mark and sweep.

matz.
 
C

Chris Thomas

I hope that it will use Boehm GC for garbage collection instead of its
own solution that must be tested and developed separate.

I'm using Boehm GC in my eiffel programs and it is much better then
the proprietary (but clever) GC implementation that SmartEiffel is
using. And the new versions use all capabilities of multi processor
machines. Something import in the future.

I'm willing to volunteer with the GC integration if it will ever leave
the vapourware phase. But remember that the GC decision must be done
very early.

There's been talk about a generational garbage collector customized for
Ruby in the past. Boehm is mostly a conservative mark&sweep, IIRC. In
any case, it should be possible to do better than Boehm, which largely
lives within the restraints imposed by supporting C and C++.

Chris
 
D

Daniel Berger

Just curious - is using C++ for the source instead of C an option?

/me ducks rotten vegetables being hurled at him by the crowd.

No, seriously. Once upon a time Chip Salzenburg, one of the core Perl
developers, was working on a complete rewrite of the Perl internals
using C++. He had nicknamed the project "Topaz" and even presented the
topic at TPC 3 (I believe). At one point thise was going to be Perl6 if
it had come to fruition. Here's a link to the story.

http://www.perl.com/pub/a/1999/09/topaz.html

Chip makes some interesting arguments, discussing why you might choose
C++ over C (macros), Ada, Eiffel and Objective C. Might at least be
worth contacting him to see what his "final thoughts" on the project
were.

Any thoughts?

Regards,

Dan
 
D

Dan Sugalski

Chip makes some interesting arguments, discussing why you might choose
C++ over C (macros), Ada, Eiffel and Objective C. Might at least be
worth contacting him to see what his "final thoughts" on the project
were.

Any thoughts?

His final thoughts were "C++ was a mistake" :) It might be worth
grabbing him and getting the details, as I'll only be able to pass
them on secondhand.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
(e-mail address removed) have teddy bears and even
teddy bears get drunk
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: matz thoughts on Rite ?"

|Just curious - is using C++ for the source instead of C an option?

No. Two object systems are source of confusion. I will not use
object-oriented language to implement my object-oriented language.

|Chip makes some interesting arguments, discussing why you might choose
|C++ over C (macros), Ada, Eiffel and Objective C. Might at least be
|worth contacting him to see what his "final thoughts" on the project
|were.

I'm still interesting in hearing from him.

matz.
 
M

Mauricio Fernández

|* do you need help? Say what we should do and we will do it :)

This is very important. Listen carefully.

From the reason I stated above, I feel like I will work alone.
But if someone shows his talent, and comes up with his own _good_
implementation of new Ruby earlier than me, and if he is willing to
contribute his code, and if he allows me to hack and chop his code to
make it "Rite", I will name it "Rite". And he will be honored for
ever.

Is there any kind of suffix in Japanese to indicate "first implementer"? ;-))
Blah-sensei == professor Blah
Blah-XXX == "Implementor of Rite" Blah ??? ;)



--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

Linux: the choice of a GNU generation
-- (e-mail address removed) put this on Tshirts in '93
 
D

Dan Sugalski

But his most final thought was "Optimization to early was a mistake"

Not the last words I got, but I talked to him after that article was written.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
(e-mail address removed) have teddy bears and even
teddy bears get drunk
 
Y

Yukihiro Matsumoto

Hi,

In message "[OT] Re: matz thoughts on Rite ?"

|Is there any kind of suffix in Japanese to indicate "first implementer"? ;-))
|Blah-sensei == professor Blah
|Blah-XXX == "Implementor of Rite" Blah ??? ;)

No, but I would call him "son-shi" (guru).

matz.
 
S

Simon Strandgaard

For this time only. ;-)
[snip Q&A]

A few more questions:

What is you thoughts about Ruby-to-bytecode, eg: jruby, netruby, parrot?
Is this the way to go for ruby ?

Making Rite faster than Ruby, how ? jit? gc? other?

Is 'Rite' just a codename.. Or should the 'Ruby' name be abandoned?
 
M

Mauricio Fernández

For this time only. ;-)
[snip Q&A]

A few more questions:

What is you thoughts about Ruby-to-bytecode, eg: jruby, netruby, parrot?

He said before it'd be bytecode, too lazy to lookup the references but
they're easy to find.
Is this the way to go for ruby ?

Making Rite faster than Ruby, how ? jit? gc? other?

bytecode + generational GC to begin with
Is 'Rite' just a codename.. Or should the 'Ruby' name be abandoned?

Rite is the name of the implementation. The name of the language doesn't change.

--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

<rm_-rf_> The real value of KDE is that they inspired and push the
development of GNOME :)
-- #Debian
 
L

Lothar Scholz

Hello matz,
I don't care much about fragmentation.

Hmm and what about long running ruby applications. With real threads
an web application server could make sense. But on the other hand Java
did not compact for years (don't now if Java > 1.3 has extended the
operator in this way).
|Have you thought about a user selectable (compile time) GC ?
I'm not sure what you mean by "user selectable (compile time)".

./configure --with_boehm_gc
make
make install

Current Ruby depends heavily upon finalizers. That is a problem.

Finalizers are supported by Boehm but you need some time to figure out
how to set them up. Like all open source projects there is a lack of
documentation.

But i will look into this at the end of year because my eiffel
development could also benefit from it.
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: matz thoughts on Rite ?"

|> I don't care much about fragmentation.
|
|Hmm and what about long running ruby applications.

If I understand right, memory fragmentation would not be critical
unless under the memory starving environment, although compaction may
improve performance significantly.

|> Current Ruby depends heavily upon finalizers. That is a problem.
|
|Finalizers are supported by Boehm but you need some time to figure out
|how to set them up. Like all open source projects there is a lack of
|documentation.

Last time I read the Boehm documentation about a year ago, its
finalizer was not sufficient to support the current Ruby behavior.
Finalizers may or may not be called. Ruby now calls every finalizers
before termination.

matz.
 
Y

Yukihiro Matsumoto

Hi,

In message "Re: matz thoughts on Rite ?"

|What is you thoughts about Ruby-to-bytecode, eg: jruby, netruby, parrot?
|Is this the way to go for ruby ?

Rite will not depend on Java nor .NET, although it's OK for the
interpreters on those platforms.

Parrot is an interesting project. But I need the core in my hand to
play with. Ruby on Parrot may become more popular than my interpreter
in the future. In that case, mine will be a reference implementation.

|Making Rite faster than Ruby, how ? jit? gc? other?

The current interpreter is very inefficient. The engine can be two or
three times faster just by reimplementing.

|Is 'Rite' just a codename.. Or should the 'Ruby' name be abandoned?

Rite is a code name for the new interpreter. Ruby remains to be the
language name.

matz.
 
A

Aredridel

Hi,

In message "Re: matz thoughts on Rite ?"

|Just curious - is using C++ for the source instead of C an option?

No. Two object systems are source of confusion. I will not use
object-oriented language to implement my object-oriented language.

That's wise, I think.

I think, often, in my spare time about interfacing C++ with Objective-C
with Ruby with Java, and every time, I find differences in object model
make me want to make an ugly hack that won't work. However, when I see
projects written in C, I see them used with all object models, because
the idea of a magic bridge is given up: instead, one wraps the C
functions and all is well.

Ari
 

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,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top