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

R

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

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
 
G

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

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

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

Isaac Gouy

Jacob said:
Jacob said:
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" ?
 
J

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:

Jacob said:
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
 
N

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

Gene Tani

Rick said:
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
 

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

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top