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.
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.
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:
–
_ _
__ __ | | ___ _ __ ___ __ _ _ __
'_ \ /| __/ __| '__ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
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
Hi,
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.
In message “Re: matz thoughts on Rite ?” on 03/07/22, “Simon Strandgaard” 0bz63fz3m1qt3001@sneakemail.com writes:
Chris Thomas chris@m-audio.com wrote in message news:F7E99B1E-BBA7-11D7-85C1-000393942016@m-audio.com…
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++.
Ruby’s extension & embedding API means that its GC also needs to
support C (and C++) - I think it has the same constraints as Boehm.
Any non-conservative GC scheme for Ruby would surely complicate the
API and the implementation.
– George
Hi,
It has one problem that a lot of GC algorithms have:
fragmentation. But with a language like ruby it should be possible to
write a separate memory compaction algorithm that uses some heuristics
on the “Memory Allocated / Memory Used” quotient and call the
compaction if absolute necessary, but this would make memory mangement
of C extensions really hard to write.
But this is independent of the used GC algorithm/library.
I don’t care much about fragmentation.
Have you thought about a user selectable (compile time) GC ?
I’m not sure what you mean by “user selectable (compile time)”.
The only problematic way with this is when using finalizeres.
Eiffel is going the Java way here, which is “never trust that a finalizer is
called”. GC is only used for pure memory resources and nothing else
(file handles etc.)
Current Ruby depends heavily upon finalizers. That is a problem.
matz.
In message “Re: matz thoughts on Rite ?” on 03/07/22, Lothar Scholz mailinglists@scriptolutions.com writes:
Chris Thomas chris@m-audio.com wrote in message news:F7E99B1E-BBA7-11D7-85C1-000393942016@m-audio.com…
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++.Ruby’s extension & embedding API means that its GC also needs to
support C (and C++) - I think it has the same constraints as Boehm.
Ruby’s current GC is not “general purpose” as Boehm: it only looks
in the stack for VALUEs, not for arbitrary pointers (it doesn’t have
to verify if there’s anything pointing to somewhere inside a memory
block). Extensions still allocate memory using malloc(), Ruby doesn’t
mess with that; ie. Ruby manages no memory arenas, only VALUE heaps. If
an extension malloc()s memory and doesn’t free it later Ruby won’t know
about it.
Any non-conservative GC scheme for Ruby would surely complicate the
API and the implementation.
matz already stated the GC will be generational and conservative.
On Tue, Jul 22, 2003 at 05:11:42PM +0900, George Marrows wrote:
–
_ _
__ __ | | ___ _ __ ___ __ _ _ __
'_ \ /| __/ __| '__ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
MS-DOS, you can’t live with it, you can live without it.
– from Lars Wirzenius’ .sig
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.
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.
Hi,
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.
In message “Re: matz thoughts on Rite ?” on 03/07/22, Lothar Scholz mailinglists@scriptolutions.com writes:
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
Oh, right - you mean at the Ruby interpreter compile time - I
thought you meant during compilation of the ruby code -
which is obviously a bit confusing…
–
The goal of Computer Science is to build something that will last at
least until we’ve finished building it.
Rasputin :: Jack of All Trades - Master of Nuns