From ryand-ruby at zenspider.com Fri Jun 3 03:32:33 2005 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Fri Jun 3 03:25:35 2005 Subject: [Rubytests-devel] *Base files Message-ID: If there aren't any real solid objections, I'm going to get rid of StringBase, ArrayBase, and HashBase. They don't serve any pragmatic or even real purpose as far as I can tell. I'm hitting Hash next and it is only clouding things up. Less code is better code. From holmberg at iar.se Fri Jun 17 11:50:03 2005 From: holmberg at iar.se (Johan Holmberg) Date: Fri Jun 17 11:45:45 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <200506080226.j582QQcR006203@rubyforge.org> References: <200506080226.j582QQcR006203@rubyforge.org> Message-ID: <42B2F12B.200@iar.se> zenspider@rubyforge.org wrote in a CVS commit email: > > Modified Files: > rubicon_tests.rb > Log Message: [...] > Make assert_set_equal actually use Set [...] > # > def assert_set_equal(expected, actual) > ! expected_left = expected.dup > ! actual.each do |x| > ! if j = expected_left.index(x) > ! expected_left.slice!(j) > ! end > ! end > ! assert( expected.length == actual.length && expected_left.length == 0, > ! "Expected: #{expected.inspect}, Actual: #{actual.inspect}") > end > > --- 186,190 ---- > # > def assert_set_equal(expected, actual) > ! assert_equal(expected.to_set, actual.to_set) > end > I think this particular change should be reversed. The Set class "deals with a collection of unordered values with no duplicates". The previous definition of "assert_set_equal" was sensitive to duplicates, so for example assert_set_equal([1,1,1], [1]) would be FALSE, but is now TRUE. So the earlier definition of "assert_set_equal" was stricter, and I think it should stay that way. But I quess the name "assert_set_equal" should be changed to something better. What would be a better name? assert_array_equal_when_order_is_ignored :) assert_unordered_equal assert_bunch_equal ??? My English is too bad to know what would be a good name. Any suggestions? /Johan Holmberg From holmberg at iar.se Fri Jun 17 12:10:39 2005 From: holmberg at iar.se (Johan Holmberg) Date: Fri Jun 17 12:06:22 2005 Subject: [Rubytests-devel] rubicon rubicon_tests.rb In-Reply-To: <200506080226.j582QQcR006203@rubyforge.org> References: <200506080226.j582QQcR006203@rubyforge.org> Message-ID: <42B2F5FF.8030808@iar.se> zenspider@rubyforge.org wrote in a CVS commit email: > > Modified Files: > rubicon_tests.rb > Log Message: [...] > Nuked rubicon's TestRunner and TestSuite classes because they served > no purpose. > Switched handleTests to use test/unit's console test runner. > Switched BulkRunner to use test/unit's console TestRunner. [...] > Next step is to hack on test/unit so we can specify our own runner/reporter > and nuke nearly everything in here. > Nice to see that your are taking on the work to move more closely to Test::Unit. If this requires changes in Test::Unit, I think we should be aware of the fact that this may introduce a new dependency on a "new enough" version of Test::Unit that is newer than the Test::Unit found in historic versions of Ruby (e.g. 1.8.2). /Johan Holmberg From holmberg at iar.se Tue Jun 21 04:14:40 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 21 04:10:35 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <42B2F12B.200@iar.se> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> Message-ID: <42B7CC70.2070001@iar.se> Johan Holmberg wrote: > > But I quess the name "assert_set_equal" should be changed to something > better. What would be a better name? > > assert_array_equal_when_order_is_ignored :) > assert_unordered_equal > assert_bunch_equal > ??? > > My English is too bad to know what would be a good name. Any suggestions? > After some thought, I realize that the function compared "multisets" (as defined in mathematics & C++). So a good name ought to be "assert_multiset_equal". If noone has any objections I will make the changes indicated in my previous mail, and use this new name for the assertion. /Johan Holmberg From ryand-ruby at zenspider.com Tue Jun 21 11:52:15 2005 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue Jun 21 11:48:03 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <42B2F12B.200@iar.se> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> Message-ID: <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> On Jun 17, 2005, at 8:50 AM, Johan Holmberg wrote: > I think this particular change should be reversed. The Set class > "deals with a collection of unordered values with no duplicates". > The previous definition of "assert_set_equal" was sensitive to > duplicates, so for example > > assert_set_equal([1,1,1], [1]) > > would be FALSE, but is now TRUE. So the earlier definition of > "assert_set_equal" was stricter, and I think it should stay that way. > > But I quess the name "assert_set_equal" should be changed to > something better. What would be a better name? In smalltalk an unordered collection that it not sensitive to duplicates is called a bag. It is a great data-structure, esp for multithreaded coding (think rinda, it is just a distributed bag). I dislike the name "multiset" and given ruby's history wrt smalltalk, I think bag would be a good choice. I also dislike the previous implementation, as it is less than clear and far less than the simplest thing that works. If you don't mind, I'll clean this one up. From holmberg at iar.se Tue Jun 21 12:16:02 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 21 12:11:36 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> Message-ID: <42B83D42.3060501@iar.se> Ryan Davis wrote: > > In smalltalk an unordered collection that it not sensitive to > duplicates is called a bag. It is a great data-structure, esp for > multithreaded coding (think rinda, it is just a distributed bag). I > dislike the name "multiset" and given ruby's history wrt smalltalk, I > think bag would be a good choice. > Bag seems OK too (when I looked up "bag" in the Wikipedia it was just a link to the article about "multiset"). > I also dislike the previous implementation, as it is less than clear > and far less than the simplest thing that works. If you don't mind, > I'll clean this one up. > I don't mind, as long as you don't loose anything in the current implementation. I'm "guilty" of writing it in it's previous shape. I realize that it is not very clear, and was thinking about adding some comments explaining why it was written that way. Can you describe shortly in what way you were thinking of cleaning it up? /Johan Holmberg From hgs at dmu.ac.uk Tue Jun 21 12:33:36 2005 From: hgs at dmu.ac.uk (Hugh Sasse) Date: Tue Jun 21 12:29:07 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <42B83D42.3060501@iar.se> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> <42B83D42.3060501@iar.se> Message-ID: On Tue, 21 Jun 2005, Johan Holmberg wrote: > I don't mind, as long as you don't loose anything in the current > implementation. [...] would it be worth specifying what you want to keep in particular? Bag sounds good to me by the way. Reminds me of those probability questions: "If you have a bag containing 30 white balls and 20 red balls ... [can you work out which idiot mixed them up for you]?" :-) > > /Johan Holmberg Hugh From holmberg at iar.se Tue Jun 21 12:54:41 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 21 12:50:16 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> <42B83D42.3060501@iar.se> Message-ID: <42B84651.9050509@iar.se> Hugh Sasse wrote: > On Tue, 21 Jun 2005, Johan Holmberg wrote: > >> I don't mind, as long as you don't loose anything in the current >> implementation. [...] > > > would it be worth specifying what you want to keep in particular? > Of course. I avoided "sort" for example since I didn't want the method to depend on all objects in the arrays being "comparable". Otherwise a natural implementation would have been: x.sort == y.sort I wanted the method to just depend on "==" for the matching of elements (Array#index uses == internally). The general idea was remove pairs of equal objects (according to ==) from the two arrays, and see if we ended up with two empty arrays (in the implementation only one of the arrays needed to be emptied). /Johan Holmberg From ryand-ruby at zenspider.com Tue Jun 21 13:10:39 2005 From: ryand-ruby at zenspider.com (Ryan Davis) Date: Tue Jun 21 13:06:06 2005 Subject: [Rubytests-devel] rubicon rubicon_tests.rb In-Reply-To: <42B2F5FF.8030808@iar.se> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F5FF.8030808@iar.se> Message-ID: <9055B5FB-CB4E-4A75-AF9E-15A5317B2128@zenspider.com> On Jun 17, 2005, at 9:10 AM, Johan Holmberg wrote: > If this requires changes in Test::Unit, I think we should be aware > of the fact that this may introduce a new dependency on a "new > enough" version of Test::Unit that is newer than the Test::Unit > found in historic versions of Ruby (e.g. 1.8.2). *shrug* I don't think it is the goal of rubicon to be compatible with every version of every ruby implementation all at once. After all, part of the goal of rubicon is to get merged back in to ruby. If we require backwards compatibility (and I don't think we do, honestly), I suggest we branch. From holmberg at iar.se Tue Jun 21 13:47:55 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 21 13:43:28 2005 Subject: [Rubytests-devel] rubicon rubicon_tests.rb In-Reply-To: <9055B5FB-CB4E-4A75-AF9E-15A5317B2128@zenspider.com> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F5FF.8030808@iar.se> <9055B5FB-CB4E-4A75-AF9E-15A5317B2128@zenspider.com> Message-ID: <42B852CB.7060205@iar.se> Ryan Davis wrote: > > On Jun 17, 2005, at 9:10 AM, Johan Holmberg wrote: > >> If this requires changes in Test::Unit, I think we should be aware of >> the fact that this may introduce a new dependency on a "new enough" >> version of Test::Unit that is newer than the Test::Unit found in >> historic versions of Ruby (e.g. 1.8.2). > > > *shrug* > > I don't think it is the goal of rubicon to be compatible with every > version of every ruby implementation all at once. After all, part of > the goal of rubicon is to get merged back in to ruby. If we require > backwards compatibility (and I don't think we do, honestly), I suggest > we branch. > I really disagree on this. I think it is a valuable property to be able to run Rubicon on: - different versions of Ruby (e.g. to see the Ruby language evolution) - different Ruby implementations (e.g. JRuby) - different platforms I think it is worth some "trouble" to stay that way, and in the changes I have done I have tried to improve Rubicon in that direction. ( I don't mean "every version". Supporting really old versions of C-Ruby would be too much trouble. ) About branching: my view is that one of the reasons for the version-tests in Rubicon source is to *avoid* branching. This may complicate the code somewhat (not much), but it shows clearly what has changed between versions of Ruby. Don't you think that is worth keeping? Am I reading to much into what you wrote? Or do we have as opposite views as I fear? /Johan Holmberg From enebo at acm.org Tue Jun 21 13:52:07 2005 From: enebo at acm.org (Thomas E Enebo) Date: Tue Jun 21 13:47:31 2005 Subject: [Rubytests-devel] rubicon rubicon_tests.rb In-Reply-To: <9055B5FB-CB4E-4A75-AF9E-15A5317B2128@zenspider.com> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F5FF.8030808@iar.se> <9055B5FB-CB4E-4A75-AF9E-15A5317B2128@zenspider.com> Message-ID: <20050621175207.GO265@garnet.tc.umn.edu> On Tue, 21 Jun 2005, Ryan Davis defenestrated me: > On Jun 17, 2005, at 9:10 AM, Johan Holmberg wrote: > > >If this requires changes in Test::Unit, I think we should be aware > >of the fact that this may introduce a new dependency on a "new > >enough" version of Test::Unit that is newer than the Test::Unit > >found in historic versions of Ruby (e.g. 1.8.2). > > *shrug* > > I don't think it is the goal of rubicon to be compatible with every > version of every ruby implementation all at once. After all, part of > the goal of rubicon is to get merged back in to ruby. If we require > backwards compatibility (and I don't think we do, honestly), I > suggest we branch. JRuby is currently working towards 1.8.2 compatibility. We use rubicon all the time. Any solution you guys arrive at should take this into consideration. If you do use a newer version of Test::Unit, then hopefully it runs in 1.8.2 (I can add the newer version Test::Unit to JRuby or even port some 1.9 behavior in a newer Test::Unit back to 1.8.2 behavior). I really do not want to get stuck on a stale branch since not all newly added tests will be 1.9 behavioral tests. The other broader question about rubicon is its goal? If someone wants to start a new ruby port (like Rite), then they have to implement enough ruby support to run Test::Unit before they can get any test results (the same tests that would be useful in getting it to the point of running Test::Unit). From experience I can say getting Test::Unit to run is a pretty high bar. Now that I am past this point it is academic to me. Just something to consider. -Tom PS - We do plan on updating jruby to 1.9 compatibility but we have no time-table on it (hmmm, perhaps we should have one). -- + http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+ | Thomas E Enebo, Protagonist | "Luck favors the prepared | | | mind." -Louis Pasteur | From holmberg at iar.se Tue Jun 28 12:58:52 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 28 12:54:21 2005 Subject: [Rubytests-devel] Re: [Rubytests-commit] rubicon rubicon_tests.rb In-Reply-To: <42B83D42.3060501@iar.se> References: <200506080226.j582QQcR006203@rubyforge.org> <42B2F12B.200@iar.se> <587C5595-D47D-4F85-AC3B-861500358851@zenspider.com> <42B83D42.3060501@iar.se> Message-ID: <42C181CC.8070804@iar.se> Johan Holmberg wrote: > Ryan Davis wrote: > >> >> In smalltalk an unordered collection that it not sensitive to >> duplicates is called a bag. It is a great data-structure, esp for >> multithreaded coding (think rinda, it is just a distributed bag). I >> dislike the name "multiset" and given ruby's history wrt smalltalk, I >> think bag would be a good choice. >> > > Bag seems OK too (when I looked up "bag" in the Wikipedia it was just a > link to the article about "multiset"). > >> I also dislike the previous implementation, as it is less than clear >> and far less than the simplest thing that works. If you don't mind, >> I'll clean this one up. >> > > I don't mind, as long as you don't loose anything in the current > implementation. I'm "guilty" of writing it in it's previous shape. I > realize that it is not very clear, and was thinking about adding some > comments explaining why it was written that way. > I have just renamed the method to "assert_bag_equal", reverted to the old code, and added some comments explaining the code. But feel free to improve it further (I couldn't find out any clearly better code). /Johan Holmberg From holmberg at iar.se Tue Jun 28 13:34:48 2005 From: holmberg at iar.se (Johan Holmberg) Date: Tue Jun 28 13:30:08 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? Message-ID: <42C18A38.6060207@iar.se> Hi JRuby-developers! I tried to run Rubicon with JRuby on Windows a while ago. I noticed that I got errors having to do with "\" vs. "/" in pathnames. What is your approach to such platform issues? I also wonder if I should expect JRuby to work well (with Rubicon) in a native Windows environment (not Cygwin). Is it reasonable for me to try running Rubicon with the latest version of JRuby from your CVS archives? /Johan Holmberg From headius at gmail.com Tue Jun 28 15:24:23 2005 From: headius at gmail.com (Charles O Nutter) Date: Tue Jun 28 15:19:35 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <42C18A38.6060207@iar.se> References: <42C18A38.6060207@iar.se> Message-ID: There are still lingering issues with path separators in JRuby. The complication comes from the fact that Java tends to convert or generate path separators to the preference of the host platform...i.e. / for UNIX-like systems and \ for Windows. When paths are used in JRuby, especially those that are further manipulated by path-aware core Java APIs like java.io.File, the slashes can be altered from what you'd expect. Rubicon passes several paths into JRuby in unix format (using /) which is acceptable in normal Ruby. However, JRuby, because of baggage it carries from Java file IO, may alter the structure of those paths when they are returned. These issue are mostly cosmetic; the paths continue to work correctly, and most Java and Ruby code don't mind mixed separators. The problem comes up when code like Rubicon expects specific path characters to always be returned. We want to support the Ruby way as much as possible, and obviously this is still outstanding. Although there are still issues running Rubicon against JRuby, there are many, many tests that pass perfectly. It's coming along. - Charlie On 6/28/05, Johan Holmberg wrote: > > > Hi JRuby-developers! > > I tried to run Rubicon with JRuby on Windows a while ago. I noticed that > I got errors having to do with "\" vs. "/" in pathnames. What is your > approach to such platform issues? > > I also wonder if I should expect JRuby to work well (with Rubicon) in a > native Windows environment (not Cygwin). > > Is it reasonable for me to try running Rubicon with the latest version > of JRuby from your CVS archives? > > /Johan Holmberg > > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubytests-devel/attachments/20050628/ea9cb92d/attachment.htm From enebo at acm.org Tue Jun 28 20:10:29 2005 From: enebo at acm.org (Thomas E Enebo) Date: Tue Jun 28 20:05:52 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: References: <42C18A38.6060207@iar.se> Message-ID: <20050629001029.GF265@garnet.tc.umn.edu> I think for Java the platform for ruby (JRuby) we should always assume '/' and try and squash File.PATH_SEPERATOR. That would make our tests consistent with linux/unix ruby tests and at least consistently match a single line of os tests within rubicon. Plus I favor '/'. :) -Tom PS- I am assuming we can override the '\' seperator as default on windows somehow within Java. Sorry for briging this up on ruby-tests too :| On Tue, 28 Jun 2005, Charles O Nutter defenestrated me: > > There are still lingering issues with path separators in JRuby. The > complication comes from the fact that Java tends to convert or > generate path separators to the preference of the host platform...i.e. > / for UNIX-like systems and \ for Windows. When paths are used in > JRuby, especially those that are further manipulated by path-aware > core Java APIs like java.io.File, the slashes can be altered from what > you'd expect. > Rubicon passes several paths into JRuby in unix format (using /) which > is acceptable in normal Ruby. However, JRuby, because of baggage it > carries from Java file IO, may alter the structure of those paths when > they are returned. > These issue are mostly cosmetic; the paths continue to work correctly, > and most Java and Ruby code don't mind mixed separators. The problem > comes up when code like Rubicon expects specific path characters to > always be returned. > We want to support the Ruby way as much as possible, and obviously > this is still outstanding. Although there are still issues running > Rubicon against JRuby, there are many, many tests that pass perfectly. > It's coming along. > - Charlie > > On 6/28/05, Johan Holmberg <[1]holmberg@iar.se> wrote: > > Hi JRuby-developers! > I tried to run Rubicon with JRuby on Windows a while ago. I noticed > that > I got errors having to do with "\" vs. "/" in pathnames. What is > your > approach to such platform issues? > I also wonder if I should expect JRuby to work well (with Rubicon) > in a > native Windows environment (not Cygwin). > Is it reasonable for me to try running Rubicon with the latest > version > of JRuby from your CVS archives? > /Johan Holmberg > _______________________________________________ > Rubytests-devel mailing list > [2]Rubytests-devel@rubyforge.org > [3]http://rubyforge.org/mailman/listinfo/rubytests-devel > > References > > 1. mailto:holmberg@iar.se > 2. mailto:Rubytests-devel@rubyforge.org > 3. 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 | "Luck favors the prepared | | | mind." -Louis Pasteur | From headius at gmail.com Tue Jun 28 21:35:44 2005 From: headius at gmail.com (Charles O Nutter) Date: Tue Jun 28 21:30:56 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <20050629001029.GF265@garnet.tc.umn.edu> References: <42C18A38.6060207@iar.se> <20050629001029.GF265@garnet.tc.umn.edu> Message-ID: Cross-posting to jruby-devel... I looked into ways to squash FILE_SEPARATOR back when the problems with Glob showed up, but never found any good solution. It's complicated again by the fact that Ruby tries to preserve file separators, rather than converting everything to one or the other. java.io.File wants to put platform-specific file separators all over the place when expanding file paths and whatnot. Still, there's probably something I've overlooked. - Charlie On 6/28/05, Thomas E Enebo wrote: > > I think for Java the platform for ruby (JRuby) we should always assume > '/' and try and squash File.PATH_SEPERATOR. That would make our tests > consistent with linux/unix ruby tests and at least consistently match > a single line of os tests within rubicon. Plus I favor '/'. :) > > -Tom > > PS- I am assuming we can override the '\' seperator as default on windows > somehow within Java. Sorry for briging this up on ruby-tests too :| > > > On Tue, 28 Jun 2005, Charles O Nutter defenestrated me: > > > > There are still lingering issues with path separators in JRuby. The > > complication comes from the fact that Java tends to convert or > > generate path separators to the preference of the host platform...i.e. > > / for UNIX-like systems and \ for Windows. When paths are used in > > JRuby, especially those that are further manipulated by path-aware > > core Java APIs like java.io.File, the slashes can be altered from what > > you'd expect. > > Rubicon passes several paths into JRuby in unix format (using /) which > > is acceptable in normal Ruby. However, JRuby, because of baggage it > > carries from Java file IO, may alter the structure of those paths when > > they are returned. > > These issue are mostly cosmetic; the paths continue to work correctly, > > and most Java and Ruby code don't mind mixed separators. The problem > > comes up when code like Rubicon expects specific path characters to > > always be returned. > > We want to support the Ruby way as much as possible, and obviously > > this is still outstanding. Although there are still issues running > > Rubicon against JRuby, there are many, many tests that pass perfectly. > > It's coming along. > > - Charlie > > > > On 6/28/05, Johan Holmberg <[1]holmberg@iar.se > wrote: > > > > Hi JRuby-developers! > > I tried to run Rubicon with JRuby on Windows a while ago. I noticed > > that > > I got errors having to do with "\" vs. "/" in pathnames. What is > > your > > approach to such platform issues? > > I also wonder if I should expect JRuby to work well (with Rubicon) > > in a > > native Windows environment (not Cygwin). > > Is it reasonable for me to try running Rubicon with the latest > > version > > of JRuby from your CVS archives? > > /Johan Holmberg > > _______________________________________________ > > Rubytests-devel mailing list > > [2]Rubytests-devel@rubyforge.org > > [3]http://rubyforge.org/mailman/listinfo/rubytests-devel > > > > References > > > > 1. mailto:holmberg@iar.se > > 2. mailto:Rubytests-devel@rubyforge.org > > 3. 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 | "Luck favors the prepared | > | | mind." -Louis Pasteur | > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubytests-devel/attachments/20050628/f05aa39f/attachment.htm From drbrain at segment7.net Tue Jun 28 23:37:02 2005 From: drbrain at segment7.net (Eric Hodel) Date: Wed Jun 29 10:55:32 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <20050629001029.GF265@garnet.tc.umn.edu> References: <42C18A38.6060207@iar.se> <20050629001029.GF265@garnet.tc.umn.edu> Message-ID: <81F2A836-5917-4B13-961A-A302231E5D08@segment7.net> On 28 Jun 2005, at 17:10, Thomas E Enebo wrote: > On Tue, 28 Jun 2005, Charles O Nutter defenestrated me: > >> There are still lingering issues with path separators in JRuby. >> The >> complication comes from the fact that Java tends to convert or >> generate path separators to the preference of the host >> platform...i.e. >> / for UNIX-like systems and \ for Windows. When paths are used in >> JRuby, especially those that are further manipulated by path-aware >> core Java APIs like java.io.File, the slashes can be altered >> from what >> you'd expect. >> Rubicon passes several paths into JRuby in unix format >> (using /) which >> is acceptable in normal Ruby. However, JRuby, because of >> baggage it >> carries from Java file IO, may alter the structure of those >> paths when >> they are returned. > > I think for Java the platform for ruby (JRuby) we should always > assume > '/' and try and squash File.PATH_SEPERATOR. That would make our tests > consistent with linux/unix ruby tests and at least consistently match > a single line of os tests within rubicon. Plus I favor '/'. :) > > -Tom > > PS- I am assuming we can override the '\' seperator as default on > windows > somehow within Java. Sorry for briging this up on ruby-tests too :| No. The tests should always use File.join. -- Eric Hodel - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04 From holmberg at iar.se Wed Jun 29 11:29:51 2005 From: holmberg at iar.se (Johan Holmberg) Date: Wed Jun 29 11:25:14 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: References: <42C18A38.6060207@iar.se> Message-ID: <42C2BE6F.5090904@iar.se> Charles O Nutter wrote: > There are still lingering issues with path separators in JRuby. The > complication comes from the fact that Java tends to convert or generate > path separators to the preference of the host platform...i.e. / for > UNIX-like systems and \ for Windows. When paths are used in JRuby, > especially those that are further manipulated by path-aware core Java > APIs like java.io.File, the slashes can be altered from what you'd expect. > I realize that is a bit tricky for you, since JRuby is kind of running on two "platforms" at the same time (the real OS (e.g. Windows), and Java itself). Do you think you will solve these issues internally in JRuby, or would you like to see the Rubicon tests adapted to your situation? I haven't thought this through in detail, but would you for example be helped by a pathname specific assertion (e.g. "assert_filename_equal") that would be extra tolerant in the case of JRuby on Windows? Since we don't have a formal language spec for Ruby I think there is no 100% correct way of choosing how to do. But it would of course be easier (at least for Rubicon) if JRuby behaved like C-Ruby on all OS-platforms. /Johan Holmberg From headius at gmail.com Wed Jun 29 13:11:06 2005 From: headius at gmail.com (Charles O Nutter) Date: Wed Jun 29 13:06:19 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <42C2BE6F.5090904@iar.se> References: <42C18A38.6060207@iar.se> <42C2BE6F.5090904@iar.se> Message-ID: I think C-Ruby behavior is the gold standard right now, and we would plan to hack or replace any Java APIs that make that standard impossible. That said, there may be things we can't hack or replace, or things that are not worth the extra effort or the divergence from base Java APIs. I think we should hold off on any JRuby-specific rubicon changes for these kinds of issues until we've had a chance to revisit them in the JRuby world. We're comfortable allowing them to keep failing :) - Charlie On 6/29/05, Johan Holmberg wrote: > > Charles O Nutter wrote: > > There are still lingering issues with path separators in JRuby. The > > complication comes from the fact that Java tends to convert or generate > > path separators to the preference of the host platform...i.e. / for > > UNIX-like systems and \ for Windows. When paths are used in JRuby, > > especially those that are further manipulated by path-aware core Java > > APIs like java.io.File, the slashes can be altered from what you'd > expect. > > > > I realize that is a bit tricky for you, since JRuby is kind of running > on two "platforms" at the same time (the real OS (e.g. Windows), and > Java itself). > > Do you think you will solve these issues internally in JRuby, or would > you like to see the Rubicon tests adapted to your situation? I haven't > thought this through in detail, but would you for example be helped by > a pathname specific assertion (e.g. "assert_filename_equal") that would > be extra tolerant in the case of JRuby on Windows? > > Since we don't have a formal language spec for Ruby I think there is no > 100% correct way of choosing how to do. But it would of course be easier > (at least for Rubicon) if JRuby behaved like C-Ruby on all OS-platforms. > > /Johan Holmberg > > _______________________________________________ > Rubytests-devel mailing list > Rubytests-devel@rubyforge.org > http://rubyforge.org/mailman/listinfo/rubytests-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/rubytests-devel/attachments/20050629/b8a6870d/attachment.htm From enebo at acm.org Wed Jun 29 19:47:03 2005 From: enebo at acm.org (Thomas E Enebo) Date: Wed Jun 29 19:42:13 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <81F2A836-5917-4B13-961A-A302231E5D08@segment7.net> References: <42C18A38.6060207@iar.se> <20050629001029.GF265@garnet.tc.umn.edu> <81F2A836-5917-4B13-961A-A302231E5D08@segment7.net> Message-ID: <20050629234703.GH265@garnet.tc.umn.edu> On Tue, 28 Jun 2005, Eric Hodel defenestrated me: > On 28 Jun 2005, at 17:10, Thomas E Enebo wrote: > > >On Tue, 28 Jun 2005, Charles O Nutter defenestrated me: > > > >> There are still lingering issues with path separators in JRuby. > >>The > >> complication comes from the fact that Java tends to convert or > >> generate path separators to the preference of the host > >>platform...i.e. > >> / for UNIX-like systems and \ for Windows. When paths are used in > >> JRuby, especially those that are further manipulated by path-aware > >> core Java APIs like java.io.File, the slashes can be altered > >>from what > >> you'd expect. > >> Rubicon passes several paths into JRuby in unix format > >>(using /) which > >> is acceptable in normal Ruby. However, JRuby, because of > >>baggage it > >> carries from Java file IO, may alter the structure of those > >>paths when > >> they are returned. > > > > I think for Java the platform for ruby (JRuby) we should always > >assume > >'/' and try and squash File.PATH_SEPERATOR. That would make our tests > >consistent with linux/unix ruby tests and at least consistently match > >a single line of os tests within rubicon. Plus I favor '/'. :) > > > >-Tom > > > >PS- I am assuming we can override the '\' seperator as default on > >windows > >somehow within Java. Sorry for briging this up on ruby-tests too :| > > No. The tests should always use File.join. Sorry, I was talking about how we implement files internally to JRuby and not about changing anything within the tests. I shouldn't have responded to this list about our implementation. -Tom -- + http://www.tc.umn.edu/~enebo +---- mailto:enebo@acm.org ----+ | Thomas E Enebo, Protagonist | "Luck favors the prepared | | | mind." -Louis Pasteur | From holmberg at iar.se Thu Jun 30 11:15:06 2005 From: holmberg at iar.se (Johan Holmberg) Date: Thu Jun 30 11:10:24 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: References: <42C18A38.6060207@iar.se> <42C2BE6F.5090904@iar.se> Message-ID: <42C40C7A.2040801@iar.se> Charles O Nutter wrote: > I think C-Ruby behavior is the gold standard right now, and we would > plan to hack or replace any Java APIs that make that standard > impossible. That said, there may be things we can't hack or replace, or > things that are not worth the extra effort or the divergence from base > Java APIs. I think we should hold off on any JRuby-specific rubicon > changes for these kinds of issues until we've had a chance to revisit > them in the JRuby world. We're comfortable allowing them to keep failing :) > Sounds good. /Johan From holmberg at iar.se Thu Jun 30 12:31:59 2005 From: holmberg at iar.se (Johan Holmberg) Date: Thu Jun 30 12:27:16 2005 Subject: [Rubytests-devel] Core dump: ruby -e 'p [].max' Message-ID: <42C41E7F.9070609@iar.se> Hi! I just built the latest from CVS on the "ruby_1_8" branch, and get a core dump like this when I run the new binary: $ ruby -e 'p [].max' -e:1: [BUG] Segmentation fault ruby 1.8.3 (2005-06-30) [i386-freebsd5.3] Abort (core dumped) I get the core on both FreeBSD & Linux. /Johan Holmberg From holmberg at iar.se Thu Jun 30 12:45:05 2005 From: holmberg at iar.se (Johan Holmberg) Date: Thu Jun 30 12:40:22 2005 Subject: [Rubytests-devel] Re: Core dump: ruby -e 'p [].max' In-Reply-To: <42C41E7F.9070609@iar.se> References: <42C41E7F.9070609@iar.se> Message-ID: <42C42191.5000000@iar.se> Sorry, this was meant for "cuby-core". I was typing too fast :) /Johan Holmberg Johan Holmberg wrote: > Hi! > > I just built the latest from CVS on the "ruby_1_8" branch, and get a > core dump like this when I run the new binary: > > $ ruby -e 'p [].max' > -e:1: [BUG] Segmentation fault > ruby 1.8.3 (2005-06-30) [i386-freebsd5.3] > > Abort (core dumped) > > I get the core on both FreeBSD & Linux. > > /Johan Holmberg > > From drbrain at segment7.net Thu Jun 30 14:42:59 2005 From: drbrain at segment7.net (Eric Hodel) Date: Thu Jun 30 14:38:11 2005 Subject: [Rubytests-devel] Testing JRuby on Windows? In-Reply-To: <20050629234703.GH265@garnet.tc.umn.edu> References: <42C18A38.6060207@iar.se> <20050629001029.GF265@garnet.tc.umn.edu> <81F2A836-5917-4B13-961A-A302231E5D08@segment7.net> <20050629234703.GH265@garnet.tc.umn.edu> Message-ID: <5EA0620D-702C-4356-A0DB-F84F38B97022@segment7.net> On 29 Jun 2005, at 16:47, Thomas E Enebo wrote: > On Tue, 28 Jun 2005, Eric Hodel defenestrated me: > > >> On 28 Jun 2005, at 17:10, Thomas E Enebo wrote: >> >> >>> On Tue, 28 Jun 2005, Charles O Nutter defenestrated me: >>> >>> >>>> There are still lingering issues with path separators in JRuby. >>>> The >>>> complication comes from the fact that Java tends to convert or >>>> generate path separators to the preference of the host >>>> platform...i.e. >>>> / for UNIX-like systems and \ for Windows. When paths are used in >>>> JRuby, especially those that are further manipulated by path- >>>> aware >>>> core Java APIs like java.io.File, the slashes can be altered >>>> from what >>>> you'd expect. >>>> Rubicon passes several paths into JRuby in unix format >>>> (using /) which >>>> is acceptable in normal Ruby. However, JRuby, because of >>>> baggage it >>>> carries from Java file IO, may alter the structure of those >>>> paths when >>>> they are returned. >>>> >>> >>> I think for Java the platform for ruby (JRuby) we should always >>> assume >>> '/' and try and squash File.PATH_SEPERATOR. That would make our >>> tests >>> consistent with linux/unix ruby tests and at least consistently >>> match >>> a single line of os tests within rubicon. Plus I favor '/'. :) >>> >>> -Tom >>> >>> PS- I am assuming we can override the '\' seperator as default on >>> windows >>> somehow within Java. Sorry for briging this up on ruby-tests too :| >>> >> >> No. The tests should always use File.join. >> > > Sorry, I was talking about how we implement files internally to > JRuby > and not about changing anything within the tests. I shouldn't have > responded to this list about our implementation. -- Eric Hodel - drbrain@segment7.net - http://segment7.net FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04