matz thoughts on Rite ?

[Simon Strandgaard]

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


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


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

--
Simon Strandgaard

[Simon Strandgaard]

On Tue, 22 Jul 2003 00:09:21 +0900, Yukihiro Matsumoto wrote:

> In message "matz thoughts on Rite ?"
> on 03/07/21, "Simon Strandgaard" <0bz63fz3m1qt3001@sneakemail.com> writes:
>
> |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 ?


--
Simon Strandgaard

[Luc Heinrich]

Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

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

--
Luc Heinrich - [email]lucsky@mac.com[/email]

[Yukihiro Matsumoto]

Hi,

In message "Re: matz thoughts on Rite ?"
on 03/07/22, Luc Heinrich <lucsky@mac.com> writes:

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

[Yukihiro Matsumoto]

Hi,

In message "Re: matz thoughts on Rite ?"
on 03/07/22, "Simon Strandgaard" <0bz63fz3m1qt3001@sneakemail.com> writes:

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

[Chris Thomas]

On Monday, July 21, 2003, at 11:06 AM, Lothar Scholz wrote:

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

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

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

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

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

[Dan Sugalski]

At 3:37 AM +0900 7/22/03, Daniel Berger wrote:

>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
[email]dan@sidhe.org[/email] have teddy bears and even
teddy bears get drunk

[Yukihiro Matsumoto]

Hi,

In message "Re: matz thoughts on Rite ?"
on 03/07/22, Daniel Berger <djberge@qwest.com> writes:

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

[Lothar Scholz]

> His final thoughts were "C++ was a mistake" :) It might be worth

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

[Michael Campbell]

> > His final thoughts were "C++ was a mistake" :) It might be worth

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

Wise words, not only from him in this context, but in general.

[Michael Campbell]

> |Have you thought about a user selectable (compile time) GC ?

>
> I'm not sure what you mean by "user selectable (compile time)".

I'm guessing here, but I think he means, when compiling Ruby, to be able to
select which (of several possible) GC's to have Ruby use.

[Mauricio Fernández]

On Tue, Jul 22, 2003 at 03:20:03AM +0900, Yukihiro Matsumoto wrote:

> |* 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
-- [email]ksh@cis.ufl.edu[/email] put this on Tshirts in '93

[Dan Sugalski]

At 9:16 PM +0200 7/21/03, Lothar Scholz wrote:

> > His final thoughts were "C++ was a mistake" :) It might be worth

>
>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
[email]dan@sidhe.org[/email] have teddy bears and even
teddy bears get drunk

[Yukihiro Matsumoto]

Hi,

In message "[OT] Re: matz thoughts on Rite ?"
on 03/07/22, Mauricio Fernández <batsman.geo@yahoo.com> writes:

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

[Luc Heinrich]

Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

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

You rule.

--
Luc Heinrich - [email]lucsky@mac.com[/email]

[Simon Strandgaard]

On Tue, 22 Jul 2003 04:20:03 +0900, Yukihiro Matsumoto wrote:

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

--
Simon Strandgaard

[Mauricio Fernández]

On Tue, Jul 22, 2003 at 05:26:16AM +0900, Simon Strandgaard wrote:

> On Tue, 22 Jul 2003 04:20:03 +0900, Yukihiro Matsumoto wrote:

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

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

[Yukihiro Matsumoto]

Hi,

In message "Re: matz thoughts on Rite ?"
on 03/07/22, Lothar Scholz <mailinglists@scriptolutions.com> writes:

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