From holmberg at iar.se Wed Dec 1 13:56:47 2004 From: holmberg at iar.se (Johan Holmberg) Date: Wed Dec 1 13:56:06 2004 Subject: [Rubytests-devel] Known problems ... In-Reply-To: References: Message-ID: Thanks for the well-written reply. I can agree with most of what you said. Some further thoughts: In C-Ruby I found a function "rb_notimplement". I assume that it is intended for cases like the "ino" method we talked about. On Windows we already have: $ ruby -e 'File.lchmod("foo")' -e:1:in `lchmod': The lchmod() function is unimplemented on \ this machine (NotImplementedError) from -e:1 $ ruby -e 'Dir.chroot("foo")' -e:1:in `chroot': The chroot() function is unimplemented on \ this machine (NotImplementedError) from -e:1 Throwing the same exception for the File::Stat#ino method would seems natural to me (I'll try to ask about that on "ruby-core"). Wouldn't this be the right thing for the methods you mentioned as missing in JRuby too ? You wrote: > As far as testing, I think we should write tests according to how a > function is *supposed* to work (expected to work, documented to work, > common sense, etc), rather than testing that *how* it works is > correct. Test-driven development, and etc...write your tests [...] I _would like_ to fully agree, but I can see some minor "problems": The Rubicon tests can be used in at least two different ways: A) to verify an implementation against a specification (how it is supposed to work), and B) to track changes to the language. I guess that you are most interested in A). For me it has been B) that has been in the foreground. I think it would be nice if Rubicon could accommodate both "use cases". So, when I run Rubicon I would like to have these inputs: - a Ruby interpreter to test - a language version to consider correct. A problem here is that there is no formal specification of Ruby. The only thing we have are different versions of C-Ruby that implicitly defines the language at different times. As output I would like to have: - a list of cases where the interpreter under test doesn't follow the specified language version If this list gets long, there is a risk that one error _shadows_ another error. Currently most of Rubicon have _one_ test-method for each method tested. If some test-method have many "asserts", and we get an error, all we can say is that it has _at least_ one case where it doesn't behave as expected. But I would often like to know if there are _one_ or lets say _five_ errors in the method. It makes a difference in the B) use case above. I have been trying to figure out a way to handle both the A) and B) use cases, but I don't have any solution yet. One thought I've had, is to use the "known_problem" method for all unresolved cases, but make it work in two different ways: 1) do *nothing special* by default. The enclosed code should work as if "known_problem" wasn't there at all, i.e. a failed "assert" will lead to a real failure of the testcase. 2) make "known_problem" sensitive to an environment variable (or perhaps command line option), and if it is set reclassify the error to a "known problem" (as it is done today). This would avoid missing errors by default (since all tests are really executed). But it would still make it possible to "accept" that some tests fail, and still go on an find further errors. Another thought I've had is to split test-methods that have problems. Maybe one test-method for each method tested is a _too big_ unit. I've felt uncomfortable with slitting testcase, since I've felt the splitting would be governed by accidental circumstances. But now that I'm thinking about it again, maybe this is the right way to go. It would probably make it easier to handle language changes (some _test methods_ would be allowed/expected to fail for a particular language version). Am I thinking in the wrong direction ? It's not easy sort all things out at the same time .... My approach so far has been to take one step at a time, and fix easy things first. I have been hoping that some good solution to the trickier issues would pop-up later ... /Johan Holmberg From headius at gmail.com Wed Dec 1 14:54:15 2004 From: headius at gmail.com (Charles O Nutter) Date: Wed Dec 1 14:53:28 2004 Subject: [Rubytests-devel] Known problems ... In-Reply-To: References: Message-ID: First, the easy one: Raising NotImplementedError makes sense for these platform-specific cases, and would work well in JRuby's implementation also. Currently I think we just don't implement methods that we haven't implemented yet (rather than implementing them with NotImplementedError), but in cases where we *know* we'll never be able to implement (e.g. file stat stuff, etc) we could easily put a NotImplemented stub in place. Now we just need to convince Matz&Co that throwing NotImplementedError is better than returning bogus results. Replies to the rest are below... > I guess that you are most interested in A). For me it has been B) > that has been in the foreground. I think it would be nice if Rubicon > could accommodate both "use cases". > > So, when I run Rubicon I would like to have these inputs: > > - a Ruby interpreter to test > - a language version to consider correct. I agree that would be ideal. Specify what to test and what "specification" to test against. > A problem here is that there is no formal specification of Ruby. The > only thing we have are different versions of C-Ruby that implicitly > defines the language at different times. Maybe this should be raised to Matz&Co as well...there is a formal grammar, but no formal specification. Such things are both important to have...we on the JRuby team have to rely on empirical tests and Pickaxe to determine how something should be implemented. Pickaxe is good, but it's not a formal specification. Even a specification created after-the-fact is better than none at all. Right now the only complete specification is the one implicitly defined within the Rubicon. > As output I would like to have: > > - a list of cases where the interpreter under test doesn't > follow the specified language version Yes, I agree. If there were a formal specification, the test failures would also be able to note what part of the specification had been violated, a la the JCK and similar tools. > If this list gets long, there is a risk that one error _shadows_ > another error. Currently most of Rubicon have _one_ test-method for > each method tested. If some test-method have many "asserts", and we > get an error, all we can say is that it has _at least_ one case > where it doesn't behave as expected. But I would often like to know > if there are _one_ or lets say _five_ errors in the method. It makes > a difference in the B) use case above. So you're saying that a failure early on in a test will mask failures later in the test, rather than showing all failures for a given test. I agree, that's a problem. > One thought I've had, is to use the "known_problem" method for all > unresolved cases, but make it work in two different > ways: I'd say what we're really switching on is "strict" compliance with the "specification". Strict compliance would require that the known problem be fixed in some version; since that requires a Rubyperson to resolve, we may need to destrictify the test in cases where we don't care. Known problem should perhaps be switchable...however, I think your later suggestion makes the most sense... > Another thought I've had is to split test-methods that have > problems. Maybe one test-method for each method tested is a > _too big_ unit. I've felt uncomfortable with slitting testcase, > since I've felt the splitting would be governed by accidental > circumstances. But now that I'm thinking about it again, maybe this > is the right way to go. It would probably make it easier to handle > language changes (some _test methods_ would be allowed/expected to > fail for a particular language version). I think this is exactly what we need to do. Individual tests should test specific aspects of Ruby--individual behavioral and functional items from the "specification"--even down to the level of how a method behaves with specific params in specific cases. Finer-grained tests would allow us to tie failures back to individual items in the "specification", and would allow more tests to run in cases where there are known issues or breakages under very specific circumstances. Ideally "known_problem" would tag a failure as being "soft"; known problems would be tested in their own tests and would show up as failures...then the failure report could be filtered to exclude those issues. "known problem" failures would equate to "soft" or "expected" failures, and may or may not be of interest to the person running tests. - Charlie From enebo at acm.org Wed Dec 1 15:21:08 2004 From: enebo at acm.org (Thomas E Enebo) Date: Wed Dec 1 15:20:26 2004 Subject: [Rubytests-devel] Known problems ... In-Reply-To: References: Message-ID: <20041201202108.GA16936@garnet.tc.umn.edu> On Wed, 01 Dec 2004, Charles O Nutter defenestrated me: > First, the easy one: > > Raising NotImplementedError makes sense for these platform-specific > cases, and would work well in JRuby's implementation also. Currently I > think we just don't implement methods that we haven't implemented yet > (rather than implementing them with NotImplementedError), but in cases > where we *know* we'll never be able to implement (e.g. file stat > stuff, etc) we could easily put a NotImplemented stub in place. Now we > just need to convince Matz&Co that throwing NotImplementedError is > better than returning bogus results. Just to interject a perhaps not-too-well-thought-out idea.... If rubicon could just recognize that if it saw a NotImplementedError to not report that as an error, then a lot of platform checks could be removed from the tests. Perhaps an additional column could give a tally of how many tests did not finish because of unimplemented behavior (though I am not sure there would normally be a need for such a count). The idea that if you mark something as NotImplemented in your implementation, you do not care about any tests involving it (kind of inverting the responsibility from rubicon to the ruby implementation -- though NotImplemented would have a useful second meaning for script authors). Or if I haven't been reading this closely enough, is this your idea as well? -Tom -- + http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+ | Thomas E Enebo, Protagonist | "A word is worth a thousand | | | pictures" -Bruce Tognazzini | From headius at gmail.com Wed Dec 1 15:43:00 2004 From: headius at gmail.com (Charles O Nutter) Date: Wed Dec 1 15:42:12 2004 Subject: [Rubytests-devel] Known problems ... In-Reply-To: <20041201202108.GA16936@garnet.tc.umn.edu> References: <20041201202108.GA16936@garnet.tc.umn.edu> Message-ID: That's a good option also. I think we still need to break down the tests in cases where we don't want a failure (in this case, a raised NotImplementedErorr) at step A to prevent testing step B. This might also allow us to keep the tests mostly platform-neutral, rather than having special cases for the NotImplemented methods on each platform. - Charlie On Wed, 1 Dec 2004 14:21:08 -0600, Thomas E Enebo wrote: > On Wed, 01 Dec 2004, Charles O Nutter defenestrated me: > > > > > First, the easy one: > > > > Raising NotImplementedError makes sense for these platform-specific > > cases, and would work well in JRuby's implementation also. Currently I > > think we just don't implement methods that we haven't implemented yet > > (rather than implementing them with NotImplementedError), but in cases > > where we *know* we'll never be able to implement (e.g. file stat > > stuff, etc) we could easily put a NotImplemented stub in place. Now we > > just need to convince Matz&Co that throwing NotImplementedError is > > better than returning bogus results. > > Just to interject a perhaps not-too-well-thought-out idea.... > > If rubicon could just recognize that if it saw a NotImplementedError > to not report that as an error, then a lot of platform checks could > be removed from the tests. Perhaps an additional column could give > a tally of how many tests did not finish because of unimplemented behavior > (though I am not sure there would normally be a need for such a count). > The idea that if you mark something as NotImplemented in your implementation, > you do not care about any tests involving it (kind of inverting the > responsibility from rubicon to the ruby implementation -- though > NotImplemented would have a useful second meaning for script authors). Or > if I haven't been reading this closely enough, is this your idea as well? > > -Tom > > -- > + http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+ > | Thomas E Enebo, Protagonist | "A word is worth a thousand | > | | pictures" -Bruce Tognazzini | > From headius at gmail.com Sat Dec 11 01:02:06 2004 From: headius at gmail.com (Charles O Nutter) Date: Sat Dec 11 01:00:58 2004 Subject: [Rubytests-devel] Fix to TestTime.rb for JRuby Message-ID: JRuby also needed the conditional for the epoch date string, since it zero-pads the day of month. I cleaned up a bunch of assert_equal param ordering that I saw too. Index: TestTime.rb =================================================================== RCS file: /var/cvs/rubytests/rubicon/builtin/TestTime.rb,v retrieving revision 1.3 diff -u -r1.3 TestTime.rb --- TestTime.rb 13 Feb 2004 23:46:50 -0000 1.3 +++ TestTime.rb 11 Dec 2004 05:40:36 -0000 @@ -145,12 +145,12 @@ def test__dump end def os_specific_epoch - $os == MsWin32 ? "Thu Jan 01 00:00:00 1970" : "Thu Jan 1 00:00:00 1970" + $os == MsWin32 or $os == JRuby ? "Thu Jan 01 00:00:00 1970" : "Thu Jan 1 00:00:00 1970" end def test_asctime expected = os_specific_epoch - assert_equal(Time.at(0).gmtime.asctime, expected) + assert_equal(expected, Time.at(0).gmtime.asctime) end def test_clone @@ -171,7 +171,7 @@ def test_ctime expected = os_specific_epoch - assert_equal(Time.at(0).gmtime.ctime, expected) + assert_equal(expected, Time.at(0).gmtime.ctime) end def test_day @@ -338,36 +338,36 @@ def test_to_f t = Time.at(10000,1066) - assert_equal(t.to_f,10000.001066) + assert_equal(10000.001066, t.to_f) end def test_to_i t = Time.at(0) - assert_equal(t.to_i,0) + assert_equal(0, t.to_i) t = Time.at(10000) - assert_equal(t.to_i,10000) + assert_equal(10000, t.to_i) end def test_to_s t = Time.now - assert_equal(t.to_s,t.strftime("%a %b %d %H:%M:%S %Z %Y")) + assert_equal(t.strftime("%a %b %d %H:%M:%S %Z %Y"),t.to_s) end def test_tv_sec t = Time.at(0) - assert_equal(t.tv_sec,0) + assert_equal(0,t.tv_sec) t = Time.at(10000) - assert_equal(t.tv_sec,10000) + assert_equal(10000,t.tv_sec) end def test_tv_usec t = Time.at(10000,1066) - assert_equal(t.tv_usec,1066) + assert_equal(1066,t.tv_usec) end def test_usec t = Time.at(10000,1066) - assert_equal(t.usec,1066) + assert_equal(1066,t.usec) end def test_wday From headius at gmail.com Wed Dec 22 16:09:42 2004 From: headius at gmail.com (Charles O Nutter) Date: Wed Dec 22 16:08:07 2004 Subject: [Rubytests-devel] Release? Message-ID: Some new developers are getting involved in JRuby (and some old ones are coming back) and we have to keep telling them to use Rubicon HEAD instead of the latest release. Perhaps now would be a good time to put out a release of the tests? We've done a lot of cleanup the past couple months, and things have settled down quite a bit recently. Thoughts? - Charlie From holmberg at iar.se Thu Dec 23 04:52:09 2004 From: holmberg at iar.se (Johan Holmberg) Date: Thu Dec 23 04:50:39 2004 Subject: [Rubytests-devel] Release? In-Reply-To: References: Message-ID: On Wed, 22 Dec 2004, Charles O Nutter wrote: > > Some new developers are getting involved in JRuby (and some old ones > are coming back) and we have to keep telling them to use Rubicon HEAD > instead of the latest release. Perhaps now would be a good time to put > out a release of the tests? We've done a lot of cleanup the past > couple months, and things have settled down quite a bit recently. > > Thoughts? > > - Charlie > What would be the benefits of a release? - is it to get a "well defined" version? - do you want all JRuby developers to use the same version ? (even if it soon will become non-HEAD) - would it be easier to "download" compared to doing a CVS checkout? If we made a release of the current state of the project, wouldn't it still be just a "snapshot"? I'm not opposed to making a release; just curious about the reasoning behind it. ( Lastly I have to say: I have no idea how a realease is made at Rubyforge. Can Chad or Simon tell ??? ) /Johan Holmberg From holmberg at iar.se Thu Dec 23 05:20:14 2004 From: holmberg at iar.se (Johan Holmberg) Date: Thu Dec 23 05:18:44 2004 Subject: [Rubytests-devel] Known problems ... In-Reply-To: References: Message-ID: Hi ! Sorry that I haven't answered before. I haven't had much time thinking about the subject of the earlier mails in the thread. On Wed, 1 Dec 2004, Charles O Nutter wrote: > >> A problem here is that there is no formal specification of Ruby. The >> only thing we have are different versions of C-Ruby that implicitly >> defines the language at different times. > > Maybe this should be raised to Matz&Co as well...there is a formal > grammar, but no formal specification. Such things are both important > to have...we on the JRuby team have to rely on empirical tests and > Pickaxe to determine how something should be implemented. Pickaxe is > good, but it's not a formal specification. Even a specification > created after-the-fact is better than none at all. Right now the only > complete specification is the one implicitly defined within the > Rubicon. > I don't think there will be anything better in a foreseeable future. I'm hoping that Rubicon will be able to track the development of the Ruby language as close as possible. It *should* be a successively easier job, the more complete the tests are. About the other things we discussed: When I'm trying summarise the problems I was thinking about before, I think it is: - I want to avoid the current errors "shadowing" other tests - I want a way to "document in the Rubicon code" the differences in Ruby: 1) between Ruby versions. 2) on different platforms I have some unfinished ideas how the Rubicon code could be improved in this regard. My current idea is to show some "working code" here on the list as soon as I have something to show. /Johan Holmberg From chad at chadfowler.com Thu Dec 23 18:11:12 2004 From: chad at chadfowler.com (Chad Fowler) Date: Thu Dec 23 18:10:03 2004 Subject: [Rubytests-devel] Release? In-Reply-To: References: Message-ID: On 23-Dec-04, at 4:52 AM, Johan Holmberg wrote: > > On Wed, 22 Dec 2004, Charles O Nutter wrote: >> Some new developers are getting involved in JRuby (and some old ones >> are coming back) and we have to keep telling them to use Rubicon HEAD >> instead of the latest release. Perhaps now would be a good time to put >> out a release of the tests? We've done a lot of cleanup the past >> couple months, and things have settled down quite a bit recently. >> >> Thoughts? >> >> - Charlie >> > > What would be the benefits of a release? > A nice benefit would be able to say: ruby version 1.8.2 [2004-12-25] with rubicon 1.1 fails N number of tests, etc. A release is a great way to get people to start using Rubicon, too. > - is it to get a "well defined" version? > > - do you want all JRuby developers to use the same version ? > (even if it soon will become non-HEAD) > > - would it be easier to "download" compared to doing a CVS checkout? All of the above, I think. And most importantly, it helps people communicate about what they're using. > > If we made a release of the current state of the project, wouldn't it > still be just a "snapshot"? > Yes, but it would be a labeled snapshot. > I'm not opposed to making a release; just curious about the reasoning > behind it. > > ( Lastly I have to say: I have no idea how a realease is made at > Rubyforge. Can Chad or Simon tell ??? ) > You just go into the file manager and upload the files and descriptions. Pretty simple. I wonder if we could also make a rubicon rubygem. That would be interesting. Chad From headius at gmail.com Fri Dec 24 02:36:43 2004 From: headius at gmail.com (Charles O Nutter) Date: Fri Dec 24 02:35:04 2004 Subject: [Rubytests-devel] Commit mailing list? Message-ID: Is there a way to set up a commit mailing list? I've gotten hooked on having commits mailed to me for JRuby, and would like to see something similar for rubytests. I just like to see what's new, so I can re-run things against JRuby. Possible? - Charlie From holmberg at iar.se Mon Dec 27 14:42:36 2004 From: holmberg at iar.se (Johan Holmberg) Date: Mon Dec 27 14:40:57 2004 Subject: [Rubytests-devel] Commit mailing list? In-Reply-To: References: Message-ID: On Fri, 24 Dec 2004, Charles O Nutter wrote: > > Is there a way to set up a commit mailing list? I've gotten hooked on > having commits mailed to me for JRuby, and would like to see something > similar for rubytests. I just like to see what's new, so I can re-run > things against JRuby. > > Possible? > > - Charlie > I've thought about this too before, but then I didn't do anything about it. Now I asked Tom Copeland, and he returned a link to item #5 on the page: http://rubyforge.org/docman/view.php/5/16/new_project_admin_checklist.html I followed the instructions, and have received commit emails for myself. I think you can do the same procedure to add yourself (or I can do it, if you give me your preferred address). I guess automatically sending all commit-emails to this list is *not* a good idea (some subscribers may not want these emails). Maybe the right thing is to create a "rubytests-commit" list on Rubyforge. Then each person can decide for himself if he wants to get the commit emails. Or does anyone have some better suggestion ??? /Johan Holmberg From holmberg at iar.se Mon Dec 27 14:54:36 2004 From: holmberg at iar.se (Johan Holmberg) Date: Mon Dec 27 14:52:56 2004 Subject: [Rubytests-devel] Release? In-Reply-To: References: Message-ID: If we should make a release now after 1.8.2 have been released, what do you think remains to be fixed before such a release ? I have some minor changes I want to do, so the tests run better on Solaris. It would also be nice to look through the "known problems" to see if they really should be classified that way. /Johan Holmberg From holmberg at iar.se Mon Dec 27 14:57:21 2004 From: holmberg at iar.se (Johan Holmberg) Date: Mon Dec 27 14:55:40 2004 Subject: [Rubytests-devel] Commit mailing list? In-Reply-To: References: Message-ID: On Mon, 27 Dec 2004, Johan Holmberg wrote: > > Maybe the right thing is to create a "rubytests-commit" list on Rubyforge. > Then each person can decide for himself if he wants to > get the commit emails. > Simon or Chad, can you create such a list? I guess one has to be "admin" for rubytests to be able to do that. /Johan Holmberg From headius at gmail.com Mon Dec 27 18:14:30 2004 From: headius at gmail.com (Charles O Nutter) Date: Mon Dec 27 18:12:45 2004 Subject: [Rubytests-devel] Release? In-Reply-To: References: Message-ID: One that's come up in the JRuby team a few times is the use of "S" in the test results. We don't show those "S"s consistently, and really we probably don't show enough in the in-process listing of test results: TestArray: S TestBignum: TestBinding: TestClass: TestComparable: TestContinuation: I'd love to see ..... or something for tests that pass, so that at least it's obvious there's work being done. Other than that I think it's probably fair to make a release now, with the caveat that we know the tests are far from complete. It's hard to say what's in a given release when we really haven't quantified where we want to go. I say make a release now as a "it's been a long time and there's a lot of cleanup and other changes" and use this as a baseline for roadmap discussions. - Charlie On Mon, 27 Dec 2004 20:54:36 +0100 (MET), Johan Holmberg wrote: > > > If we should make a release now after 1.8.2 have been released, > what do you think remains to be fixed before such a release ? > > I have some minor changes I want to do, so the tests run better on > Solaris. It would also be nice to look through the "known problems" > to see if they really should be classified that way. > > /Johan Holmberg > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel > From headius at gmail.com Mon Dec 27 18:16:36 2004 From: headius at gmail.com (Charles O Nutter) Date: Mon Dec 27 18:14:52 2004 Subject: [Rubytests-devel] Commit mailing list? In-Reply-To: References: Message-ID: A mailing list is how SF does it. I'll add myself manually for now, but I'd like the mailing list way (so I can filter them more easily). I'll wait to hear from Chad or Simon...perhaps one of us should be an admin also, since we're a bit more active on development these days? - Charlie On Mon, 27 Dec 2004 20:57:21 +0100 (MET), Johan Holmberg wrote: > > On Mon, 27 Dec 2004, Johan Holmberg wrote: > > > > Maybe the right thing is to create a "rubytests-commit" list on Rubyforge. > > Then each person can decide for himself if he wants to > > get the commit emails. > > > > Simon or Chad, can you create such a list? > I guess one has to be "admin" for rubytests to be able to do that. > > /Johan Holmberg > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel > From enebo at acm.org Mon Dec 27 18:31:55 2004 From: enebo at acm.org (Thomas E Enebo) Date: Mon Dec 27 18:30:15 2004 Subject: [Rubytests-devel] Commit mailing list? In-Reply-To: References: Message-ID: <20041227233155.GA17879@garnet.tc.umn.edu> Just for reference...The script for commit diffs we use on jruby is called 'syncmail'. We turned it on in our project about a month ago and I think everyone likes the ability to see context diffs of commits. Here is a link to the sourceforge docs on it (I am not sure if rubyforge has this): https://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#scriptsyncmail -Tom On Mon, 27 Dec 2004, Charles O Nutter defenestrated me: > A mailing list is how SF does it. I'll add myself manually for now, > but I'd like the mailing list way (so I can filter them more easily). > > I'll wait to hear from Chad or Simon...perhaps one of us should be an > admin also, since we're a bit more active on development these days? > > - Charlie > > > On Mon, 27 Dec 2004 20:57:21 +0100 (MET), Johan Holmberg > wrote: > > > > On Mon, 27 Dec 2004, Johan Holmberg wrote: > > > > > > Maybe the right thing is to create a "rubytests-commit" list on Rubyforge. > > > Then each person can decide for himself if he wants to > > > get the commit emails. > > > > > > > Simon or Chad, can you create such a list? > > I guess one has to be "admin" for rubytests to be able to do that. > > > > /Johan Holmberg > > > > _______________________________________________ > > Rubytests-devel mailing list > > Rubytests-devel@rubyforge.org > > http://rubyforge.org/mailman/listinfo/rubytests-devel > > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel -- + http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+ | Thomas E Enebo, Protagonist | "A word is worth a thousand | | | pictures" -Bruce Tognazzini | From holmberg at iar.se Tue Dec 28 04:25:54 2004 From: holmberg at iar.se (Johan Holmberg) Date: Tue Dec 28 04:24:13 2004 Subject: [Rubytests-devel] Commit mailing list? In-Reply-To: <20041227233155.GA17879@garnet.tc.umn.edu> References: <20041227233155.GA17879@garnet.tc.umn.edu> Message-ID: On Mon, 27 Dec 2004, Thomas E Enebo wrote: > > Just for reference...The script for commit diffs we use on jruby is > called 'syncmail'. We turned it on in our project about a month ago > and I think everyone likes the ability to see context diffs of commits. > Here is a link to the sourceforge docs on it (I am not sure if rubyforge has > this): > > https://sourceforge.net/docman/display_doc.php?docid=772&group_id=1#scriptsyncmail > > -Tom > "syncmail" seem to be the script used at Rubyforge too. The line in "loginfo" now is: DEFAULT /usr/local/bin/syncmail %s holmberg@iar.se headius@headius.com As soon as we get a separate commit-list, we can change the line to point to the list instead. /Johan From holmberg at iar.se Wed Dec 29 06:53:53 2004 From: holmberg at iar.se (Johan Holmberg) Date: Wed Dec 29 06:52:09 2004 Subject: [Rubytests-devel] builtin/TestIO.rb : test_s_select ? Message-ID: Hi ! I'm trying to understand why this test fails on Solaris and Windows. The problem is the returned descriptors with an "error condition" in the case of a file-descriptor for a regular file. Solaris (and Windows) seem to behave different from for example FreeBSD and Linux. I have found the following in the select(3c) man-page on Solaris: File descriptors associated with regular files always select true for ready to read, ready to write, and error condi- tions. I haven't found any similar documenation for Windows, but I guess the same is applicable there. So my assumption is that the current test is wrong on Solaris and Windows. If noone thinks differently, I'll change the test to let the way Solaris/Windows works "pass" the Rubicon tests. /Johan Holmberg From headius at gmail.com Wed Dec 29 10:22:56 2004 From: headius at gmail.com (Charles O Nutter) Date: Wed Dec 29 10:21:07 2004 Subject: [Rubytests-devel] builtin/TestIO.rb : test_s_select ? In-Reply-To: References: Message-ID: I have no objections. I'm not familiar with how "select" is implemented under Windows, so I can't comment on that. I would imagine it's closer to SVR4 than to Linux or the BSDs, though, which would match your thinking. - Charlie On Wed, 29 Dec 2004 12:53:53 +0100 (MET), Johan Holmberg wrote: > > Hi ! > > I'm trying to understand why this test fails on Solaris and Windows. > The problem is the returned descriptors with an "error condition" > in the case of a file-descriptor for a regular file. > > Solaris (and Windows) seem to behave different from for example > FreeBSD and Linux. > > I have found the following in the select(3c) man-page on Solaris: > > File descriptors associated with regular files always select > true for ready to read, ready to write, and error condi- > tions. > > I haven't found any similar documenation for Windows, but I guess > the same is applicable there. > > So my assumption is that the current test is wrong on Solaris > and Windows. If noone thinks differently, I'll change the test to > let the way Solaris/Windows works "pass" the Rubicon tests. > > /Johan Holmberg > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel >