For performance, write it in C - Part 3, Source code now available

[Rick DeNatale]

Oops. Sorry. Meant to type

-- 2.0 will support the same language as 1.9, but with a different
underlying implementation.


Bill

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Versions with even minor numbers are considered the stable "production" branch.
Versions with odd minor numbers are considered experimental where
features which might produce incompatibilities and breakage are added,
tried out, and perhaps removed before becoming part of the
specification if not the implementation of the next stable branch.

Or do I have it wrong?

 

[James Edward Gray II]

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Versions with even minor numbers are considered the stable
"production" branch.
Versions with odd minor numbers are considered experimental where
features which might produce incompatibilities and breakage are added,
tried out, and perhaps removed before becoming part of the
specification if not the implementation of the next stable branch.

Or do I have it wrong?

In general yes, although it seems Matz is considering a production
1.9 release.

James Edward Gray II

 

[Greg Donald]

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Linux 2.6 has always had 4 version parts. Linux 2.4 recently gained a
4th number as well:

http://kerneltrap.org/node/7009

I realize I'm not answering your question, but I thought the info was
useful nevertheless.

 

[Rick DeNatale]

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Versions with even minor numbers are considered the stable
"production" branch.
Versions with odd minor numbers are considered experimental where
features which might produce incompatibilities and breakage are added,
tried out, and perhaps removed before becoming part of the
specification if not the implementation of the next stable branch.

Or do I have it wrong?

In general yes, although it seems Matz is considering a production
1.9 release.

I thought that he was joking when he said that the version after 1.9.9
would be 1.9.a.

Now I wouldn't be surprised if 2.0 weren't just a tagged version of a
1.9.x release (which is what I meant above by "if not the
implementation of," but I would be surprised if there was a production
1.9.x release so-named.


--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

IPMS/USA Region 12 Coordinator
http://ipmsr12.denhaven2.com/

Visit the Project Mercury Wiki Site
http://www.mercuryspacecraft.com/

 

[Rick DeNatale]

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Linux 2.6 has always had 4 version parts. Linux 2.4 recently gained a
4th number as well:

http://kerneltrap.org/node/7009

I realize I'm not answering your question, but I thought the info was
useful nevertheless.

I realized that, but decided to simplify, I never did specify a
lexical convention for sub-version, (or Major, or Minor for that
matter)

 

[Isaac Gouy]

My assertion is correct. The fasta benchmark says:

Each program should:
[...]
* generate DNA sequences, by weighted random selection from the
alphabets (using the pseudo-random number generator from the random
benchmark)

And the implemenation:

http://shootout.alioth.debian.org/gp4/benchmark.php?
test=fasta&lang=ruby&id=0

Contains the random number generator from the random benchmark:

http://shootout.alioth.debian.org/old/benchmark.php?
test=random&lang=ruby&id=0

I did not see this test named 'random' when I looked through the
alioth site earlier today... and I still don't see any links to it
from that site. (I did find it by following your link, however.)

I notice that your second link contains the word 'old'. Perhaps this
benchmark has been withdrawn? If so, I submit that your criticism was
true in the past, but no longer is.

I agree that the presence of "/old/" (vs. "/gc4/") in the URL probably
indicates that the "random" benchmark has been removed from most
locations. There was an actual link to it, however, from the FASTA
benchmark description page. Specifically, on this page:

http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all

At the bottom, under "about the fasta benchmark", in the second bullet
point. That's the *current* page for the FASTA benchmark, so maybe
that page just needs to be updated to remove that constraint?

Jacob Fugal

There was and is an actual link to it from the FASTA benchmark
description
http://shootout.alioth.debian.org/gp4/benchmark.php?test=fasta&lang=all#about

Jacob, why would we want to remove that constraint?

Either remove or update to point to a current (not "/old/") benchmark.
I don't care either way...

Jacob Fugal

Jacob, why would we want to remove that constraint, and what problem
would be solved by "update to point to a current (not "/old/")
benchmark" ?

 

[Jacob Fugal]

Jacob, why would we want to remove that constraint, and what problem
would be solved by "update to point to a current (not "/old/")
benchmark" ?

Note this portion of the prior conversation:

My assertion is correct. The fasta benchmark says:

Each program should:
[...]
* generate DNA sequences, by weighted random selection from the
alphabets (using the pseudo-random number generator from the random
benchmark)

I did not see this test named 'random' when I looked through the
alioth site earlier today... and I still don't see any links to it
from that site. (I did find it by following your link, however.)

I notice that your second link contains the word 'old'. Perhaps this
benchmark has been withdrawn? If so, I submit that your criticism was
true in the past, but no longer is.

I agree that the presence of "/old/" (vs. "/gc4/") in the URL probably
indicates that the "random" benchmark has been removed from most
locations.

The problem I see is that the current incarnation of the FASTA
benchmark page makes reference to another benchmark that *appears* to
have been deprecated. This possible deprecation is manifest in the
presence of the word "old" in the URL combined with the assertion
(which I'll admit I haven't verified) that there is no other link to
the benchmark on the site. The reliance of the FASTA benchmark on the
Random benchmark, to me, is not an issue. The reliance of the FASTA
benchmark on a possibly *deprecated* Random benchmark is the issue.
This issue can be resolved by:

1) Removing the reliance
2) Updating the FASTA benchmark to reference a non-deprecated Random benchmark
3) Clarifying that the Random benchmark is not, in fact, deprecated
4) Something else I haven't considered (I'm not omniscient, and don't
pretend to dictate what the Shootout must do

[I had assumed previously that the deprecation of the Random benchmark
was certain in my previous posts, which is why I didn't previously
mention option 3. I didn't mention option 4, because I assumed it was
implied, but I state it here for completeness.]

Now, between those four options, I don't care which you do. You know
what the Random benchmark is and whether it's necessary and/or
deprecated a lot better than I do. I was just mentioning possible
options to resolve the issue that I noticed in the conversation above.
I'm fine with letting you choose which option to pursue.

Jacob Fugal

 

[nobu]

Hi,

At Tue, 22 Aug 2006 02:36:35 +0900,
Rick DeNatale wrote in [ruby-talk:209688]:

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

It had followed, but changed. Teeny of 0 means development
version now.

 

[Gene Tani]

Doesn't Ruby version numbering follow the same general scheme as the
Linux kernel?

Version Major.Minor[.sub-version]

Versions with even minor numbers are considered the stable
"production" branch.
Versions with odd minor numbers are considered experimental where
features which might produce incompatibilities and breakage are added,
tried out, and perhaps removed before becoming part of the
specification if not the implementation of the next stable branch.

Or do I have it wrong?

In general yes, although it seems Matz is considering a production
1.9 release.

I thought that he was joking when he said that the version after 1.9.9
would be 1.9.a.

Now I wouldn't be surprised if 2.0 weren't just a tagged version of a
1.9.x release (which is what I meant above by "if not the
implementation of," but I would be surprised if there was a production
1.9.x release so-named.

i think minor and teeny won't go over "9"

http://groups.google.com/group/comp.lang.ruby/browse_frm/thread/1fc37aafd77e131d?hl=en