Index

Show enters and exits. Hide enters and exits.

01:57:37couthmm.
01:58:27evanfinally got alias workig.
01:58:30evanthat was fun.
02:00:11evanthough, i might have found a super cache bug.
02:00:22evani'm thinking I might have to just turn off all inline caching for super
02:00:46evanor improve the caching check
02:00:47evanooh..
02:00:48evani wonder..
02:03:11boyscoutSpeed up Array#pack, String#unpack, and String#rpartition - 26c73d4 - Ivan Samsonov
02:03:11boyscoutAdd spec for super/alias_method interaction - a93958e - Evan Phoenix
02:03:11boyscoutFix the super/alias interaction problem - 7e7fcdd - Evan Phoenix
02:12:17boyscoutCI: rubinius: 7e7fcdd successful: 3041 files, 11843 examples, 36124 expectations, 0 failures, 0 errors
02:26:19brixenargh, encodings are frustrating!
02:26:42brixencode that works in 1.9 on the cmd line with -e fails in a file
04:04:52rueThink there was some chatter on -core about file-related encoding stuff just recently
05:20:28leavengoodJust a quick note: you may want to update http://rubini.us/ to reflect the recent Tweet about implementing some of the ObjectSpace methods
05:20:50leavengoodin particular the bottom part about compatibility
05:21:20rueThis is all very hush-hush ;)
05:23:36leavengoodhush-hush?
05:23:41leavengoodThen don't tweet ;)
05:24:41rueProtocol error :P
05:26:17leavengoodany good areas for a some new to Rubinius to jump in?
05:26:25leavengoods/some/someone
05:26:50leavengoodhold on, I see stuff on the web-site
05:27:02leavengoodthough if you have any suggestions
05:31:19leavengoodbroken link from the FAQ (at the bottom): http://rubini.us/about/contributing
05:33:28leavengoodI guess that link should be http://rubini.us/about/contribute
06:51:23rueYup
06:51:44rueFixing broken specs or running your own code and fixing what breaks are popular
08:21:13dbussinkevan: did you run your fiber stuff against the specs for 1.9?
08:40:35rueDid you? :)
08:48:49dbussinkrue: nope, not yet ;)
08:49:03dbussinkrue: problem is that we should devise a better way to run specs for stuff that we already support from 1.9
08:49:29dbussinkthere are a few other things that were added, like source_location and method parameters
17:22:09evanrad.
17:22:44evanrubinius, for a trivial invocation benchmark, is the same speed as unoptimized, all virtual C++
17:23:23rueNewt
17:23:30kronos_vanocool!
17:23:50evaninteresting side note
17:23:59evani guess there are cases where g++ will eliminate a virtual call
17:24:11rueIt will, yes.
17:24:23evandemote it to non-virtual, then optimize
17:24:53rueMight need O3 for it to trigger
17:24:55evanso writing a trivial benchmark, all virtual benchmark it's easy to have g++ make it into a constant
17:25:02evanO2 seemed to do it
17:25:07evanif i split the code between 2 .o files
17:25:10evani'll bet i can fool it.
17:27:10evanack!
17:27:13evaneven at -O0
17:27:20evang++ has eliminate the virtual call
17:27:34evanand put in a raw, static call.
17:28:03evanso rbx is as fast as unoptimized NON-virtual g++ in this case.
17:30:04Zoxchaving fun?
17:30:51rueThat is somewhat odd, actually.
17:31:20evanrue: http://gist.github.com/294899
17:31:29evanrunning g++ -O0 -g -S -o benchmark/raw/invoke_cpp_virt.s benchmark/raw/invoke_cpp_virt.cpp
17:31:33evancheck out the .s file
17:31:44evanyou'll see that the places where more and call are called
17:31:50evanthey're normal function calls, not virtual
17:36:01rueWeird...though I suppose the reasoning could be that the virtual resolution is not a debuggable step
17:37:12evanperhaps
17:37:16rueWish you could do prefix commas in Ruby too, so much nicer for multiple arguments
17:40:25evanrue: looks like it's a class hierarchy optimization
17:40:42evancombined with creating a C++ object on the stack
17:41:12evanactually
17:41:17evani think it's JUST creating it on the stack.
17:41:38evanthe justification being that the compiler knows the exact type of that object
17:41:44evanbecause it's got full control over it
17:41:46rueYef
17:41:55evanrather than just seeing a pointer returned from something
17:47:02evanbtw
17:47:06evanif you want to REALLY know whats going on
17:47:13evanyou have to use "otool -t -v <file>"
17:47:23evanie, don't even trust g++ -S output
18:22:39brixendbussink: just fyi, I have a facility for running specs like those for Fiber on other version
18:22:54brixendbussink: I'm fixing up rubyspec now and then I'll sync
18:47:03dbussinkbrixen: ah, cool, that's available in mspec?
18:47:16dbussinkbrixen: would be nice if we can include stuff into ci
18:48:48brixenit will be in mspec
18:49:00brixenand yes, we can include stuff in ci
18:49:07brixenthat'd be the point of having specs ;)
19:49:20brixenarg, misfired a git reset --hard
19:49:38brixen*and* reloaded my vim buffer
19:49:46brixen<- dork
20:01:03VVSizbrixen: whooops! and 'git reflog' is probably not going to help...
20:04:32brixenit wasn't too bad, I just rewrote it
20:23:10evansweet
20:23:13evangot another llvm patch in
20:23:25evan2.7 is going to give us some nice things
20:23:49ZoxcARM JIT? :D
20:24:31evani think so
20:24:34evanyes
20:24:59brixennice
20:25:53scottwoh, nice
20:33:06dbussinkevan: that definitely needs prebuilt arm files ;)
20:34:31brixenwe just need to get an arm farm going in the cloud :)
20:35:06evanhehe
20:35:07evanarm farm
20:35:09evanok, lunch time.
20:35:15dbussinkevan: did you already take a look at #179?
20:35:21evanno
20:35:42brixenactually, arch specific build farms as a service sounds awesome
20:36:03brixentype rake in rbx and it farms it out for your platform and downloads the files
20:36:06evandbussink: i'll take a look after lunch
20:36:31evanbrixen: code in the cloud!
20:36:36brixenheh
20:40:00dbussinkbrixen: might be too specific to make a lot of money off though
20:47:18brixendbussink: hrm dunno, could be great for dev-on-the-go with an ipad or iee-like netbook
20:47:46brixenI'll leave that do the bizdev folks to market research :)
20:48:10boyscoutReally use llvm-config flags when building with system LLVM - 5531a56 - Dmitriy Timokhin
20:48:45brixendbussink: also, maybe just a matter of time, we we're talking about vmware "clouds" in late '90s
20:48:59brixen-'
20:49:17dbussinkbrixen: true, although build farms are quite a different beast
20:49:39brixendifferent beasts just need different automation
20:49:40mahargsourceforge used to have a build farm like that
20:49:45mahargI guess they shut it down
20:50:59brixenI think the way we manually build or cross-compile is < ideal
20:51:13brixenbut, that could be the low blood sugar talking!
20:51:15brixenlunches!
20:51:41dbussinkoh definitely yeah, the question is more whether the problem annoys people enough so they want to fork over money
20:52:30boyscoutCI: rubinius: 5531a56 successful: 3041 files, 11843 examples, 36124 expectations, 0 failures, 0 errors
21:18:46tenderloveHI!
21:19:01evanhola.
21:19:06tenderlovebroooooo
21:19:12tenderlovecan I pick your brain about rubyspec?
21:19:27evancourse
21:19:55tenderlovewhy does rubyspec have tests for stdlib?
21:20:08tenderloveshouldn't those be checked in to ruby's svn?
21:20:32evanwell, there was that discussion
21:20:41evanfor the vast majority
21:20:44evanthere were no tests even.
21:20:59evanand since the stdlib is basically part of an implementation
21:21:01evanwe put them into rubyspec.
21:21:12tenderlovehrm
21:21:43evanyou could make the same argument for all of rubyspec
21:21:51evanthat it should be within ruby-core svn
21:22:19tenderloveThe "language spec" part of it makes sense to me
21:22:20evanbut ruby-core has never seemed terribly interested
21:22:37tenderlovebut stuff like "yaml" isn't really part of the ruby language
21:22:48evanbut it's part of an implementation
21:23:01tenderlovehmmm
21:23:03tenderloveI guess so
21:23:09evanif, say, maglev didn't provide any of the stdlib
21:23:18evanno one could/would use it
21:23:21tenderloveright
21:23:30tenderloveokay, other topic
21:23:30evanthe fact that you have to require them is beside the point
21:23:41evanevery developer expects them to be there and to behave in a certain way
21:23:41tenderloveso, syck is going away
21:23:48evanright, i've heard.
21:23:54tenderlovewell, I want it to go away
21:24:02tenderlovebut I don't want to support the same api that syck provides
21:24:21evanug.
21:24:21tenderlovesome of it is the same
21:24:23evanthats..
21:24:25evannot going to work.
21:24:42evanunless you figure out which parts of the public API and which parts are the private API
21:24:52evanand then tell people "sorry, all these things are broken now"
21:25:07tenderloveright
21:26:06evanbut you're likely not going to be able to change much "just because"
21:26:12evanas it will break a lot of things
21:26:48tenderloveI can change some things
21:26:59tenderlovethe thing is though, nobody wants to maintain syck
21:27:27tenderlovefrom what I can tell, it's either remove syck, or replace it
21:27:31evanoh, I understand that
21:27:37evanthey don't want to maintain the C code
21:27:38evani'm assuming.
21:27:57tenderlovenot sure. there was no differentiation between the C and the ruby code
21:28:14evank.
21:28:16evanwell...
21:28:25evanimho, yaml should be unbundled from stdlib all together.
21:28:30evanand syck moved into a gem
21:28:46evanand your new yaml code should be a gem called yaml or somethnig
21:28:57tenderloveimho, all of stdlib should be gems
21:29:01evanto allow people to choose
21:29:57evanthis is going into 1.9.2?
21:30:01tenderloveI think so
21:30:17tenderloveI was going to ask about how this would muck with rubyspec
21:30:34tenderlovebut my initial inspection leads me to believe that I support all the tests that are here
21:30:36evanrubyspec will run the specs
21:30:39evanand they will pass or fail.
21:30:57rueSpecs for some arbitrary gem?
21:31:24tenderloveevan: I'm not sure why rubyspec is testing this though: http://github.com/rubyspec/rubyspec/blob/master/library/yaml/tagurize_spec.rb
21:31:45tenderlovedoesn't seem like a public api thing
21:31:51evanwell
21:31:57evandon't take whats in rubyspec as the public API
21:32:05evanwe have no clue what the public API is most of the time
21:32:13evanand so we let people spec the shit out of stuff
21:32:26evanand worry about it removing stuff later.
21:32:36evantagurize is a public method
21:32:44evanso i'm assuming it's thought to be in the public API
21:32:50evanwelcome to rubyspec
21:32:53tenderloveBut it's not useful
21:33:08tenderloveI don't want rubyspec to bind me to methods that are useless
21:33:14tenderloveor to force my implementation
21:33:18rueEach individual gem can certainly co-opt the specs, but if YAML is not a part of the standard distribution, its specs have no place in RubySpec
21:33:30rueProffers he as his opinion
21:33:31tenderloverue: it is part of the standard distro
21:33:31evantenderlove: how do you know it's not useful?
21:33:39evanthat seems like your opinion
21:33:42ruetenderlove: But it is a gem?
21:33:54tenderlovetags are arbitrary strings. what would you use this for?
21:33:58evanwhat matters is if your opinion is authorative
21:34:06evantenderlove: check google code search
21:34:10evanagain
21:34:18evanwe have no way to know what is public and what is not.
21:34:28evanif you want to push back on things
21:34:31evanthats fine
21:34:34evanwe'll discuss them.
21:34:46evanesp. if you,re becoming the yaml maintainer.
21:34:51evanas the yaml maintainer
21:34:59evanwe're HAPPY HAPPY HAPPY to have you say "thats not public"
21:35:09evanwe can't get verification of 90% of things
21:35:16evanso someone telling us is awesome.
21:35:29tenderloveaccording to this: http://redmine.ruby-lang.org/wiki/ruby/Maintainers
21:35:32tenderloveI am the maintainer :-)
21:35:39imajesw000t!
21:35:59ruetenderlove: How does the standardness manifest?
21:36:03evanwonderful!
21:36:13evantenderlove: we're happy to add guards for things that you're deprecating in 1.9 then.
21:36:27tenderlovegreat! that is what I'm here to find out about
21:36:28evanand happy to sort out how you want to continue forward with the testing strategy.
21:36:50tenderlove^5
21:36:50evanrubyspec is amatuers filling a vacuum
21:36:56evanif a pro wants to fill the vacuum
21:37:01evanwe're happy to give up the space.
21:37:03tenderlovehaha
21:37:03imajeshah
21:37:09imajeswhat a kiss ass
21:37:10imajes:P
21:37:16evanit's my nature.
21:37:33tenderloveI just wanted to find out how "in-stone" the ruby specs are
21:37:45tenderlovealso, how much of them are based on actual use
21:37:51imajesevan: you are sweet
21:37:58tenderloveI'm doing my best to support the syck api
21:38:04tenderlovebut some if it just doesn't make sense
21:38:11evantenderlove: it used to be based on usage
21:38:16rueI just do not see how it will be different from any other arbitrary gem out there that people can optionally use
21:38:17evanbut usage is subjective
21:38:21evanso we don't hold back
21:38:30evanif people want to read yaml.rb and write specs for every method
21:38:32evanwe're fine with that
21:38:41tenderloverue: It ships with ruby, that's what's different
21:38:41evanBECAUSE there was no yaml maintainer to tell us otherwise
21:39:01tenderlovecool
21:39:29tenderlovewhat is your opinion on merging these tests in to the yaml test suite?
21:39:39evani'm fine with that
21:39:49evani'm against the idea of rewriting them all though.
21:40:18tenderlovehrm....
21:40:30rueWhat is the gain from shipping a .gem rather than the library?
21:40:34tenderloveI wonder if merging *my* specs to ruby spec is getter
21:40:35tenderlovebetter
21:40:51tenderloverue: gems can be updated. stdlib cannot
21:40:57evantenderlove: possibly
21:41:19tenderloveevan: the reason I'm thinking that is because I think you're right
21:41:24tenderlovewrt implementations
21:41:43tenderlovebut I hate the idea of having duplicate codes
21:42:05evanagreed, thats less than ideal
21:42:20evanuniformity in rubyspec is a huge deal.
21:43:00tenderloveugh
21:43:14tenderlovestdlib seems to blur the line of what rubyspec should test
21:43:20evanyep.
21:43:31tenderloveIf stdlib were all gems, this wouldn't be an issue
21:43:32tenderlove:-/
21:43:39evanyep.
21:44:04evanall the big libs in stdlib should be unbundled
21:44:09evanleaving stuff like thread, etc in stdlib.
21:44:19evanthough, i think even thread has moved into the core in 1.9
21:44:24evanMutex, etc.
21:44:33rueIt is not "unbundled" though, if it is just a .gem file instead
21:45:06evanrue: you mean so that they can be upgraded via gem
21:45:08evanright.
21:45:50rueSo the gem-ness is sort of a distinction without difference. What matters is whether the code comes with Ruby, or if it lives on gemcutter or wherever
21:46:04rueThe former should be specced, the latter not
21:46:36evansure
21:46:42evanbut rubyspec will still and always fill a vacuum
21:47:04evanif there are gems that everyone uses everyday and there are no tests/specs for it, and we're expected to implement it
21:47:10evanthen we're going to write specs and put them in rubyspec.
21:47:21evanthe critical part of that equation is "and we're expected to implement it"
21:47:33evanevery impl. pretty much has their own yaml library at this point.
21:47:55evanrubinius uses syck only because I finally got enough of capi implemented to run it.
21:48:59tenderloveevan: ^5
21:49:39evantenderlove: one thing to consider, btw, is that all the other yaml implementations pass the yaml rubyspecs (i'd expect)
21:49:53evanso the java one jruby uses, the smalltalk one maglev uses, etc.
21:50:02tenderloveI'm looking through them now
21:50:07tenderloveI need to take a closer look
21:50:11evanyou could consider your new one just another form of this equation
21:50:12tenderlovebut they seem to just test the basic stuff
21:50:24evanBUT the difference is that you'd also like to increment the version number
21:50:30evanand deprecated/clarify a number of existing APIs
21:50:39evanas the yaml maintainer, you're free to do so.
21:50:53evanan envyable position.
21:51:14evanthe rest of us have to suck it up and make it bug-to-bug compatible.
21:51:22evanyes, bug-to-bug.
21:51:55tenderlovehah
21:52:05tenderlovehopefully that will be easy
21:52:09tenderlovesince I'm just using libyaml
21:52:19tenderloveactually, I think all of my codes will run on rubinius now
21:52:36evanwonderful!
21:53:03evantenderlove: seems like you should just say "ok guys, yaml has been upgraded to 2.0. it's now based on libyaml and a number of APIs have been removed and deprecated"
21:53:15evanie, tried it as a new major version of a library we know and love.
21:53:19evans/tried/treated/
21:53:21tenderloveyes
21:53:21evaner.
21:53:23evans/tried/treat/
21:53:34tenderloveI *think* the plan is to ship 1.9.2 with both syck and psych
21:53:48tenderlovein order to let people migrate
21:54:02tenderlovethough I'm just going to cut a gem release
21:54:47evansomething you should try and work out NOW
21:54:57evanis how code changes are going to make there way from the gem into MRI
21:55:08evanie, if you release a version 2.0.2 of the gem
21:55:18evandoes MRI need to do a new release to get that?
21:56:31tenderloveI don't think so
21:56:43tenderloveI'm going to try to get this extension such that you can use it from stdlib or gems
21:56:44evanyou should figure it out now
21:56:46evanand write it down
21:56:50tenderlovesort of like rdoc
21:56:50evanso people know what to expect
21:56:57evanthis has been a HUGE problem for the bundled libs up to now
21:57:05evanwell, rdoc is the worst example
21:57:11tenderlovesoap4r
21:57:14evanthe version change has been HUGE
21:57:16evansame with soap4r
21:57:26evanthe version in MRI is totally different than the gem
21:57:33evanit lagged by YEARS
21:57:35evanin MRI.
21:57:36evanyears.
21:57:40tenderloveI know
21:57:41tenderlove;-)
21:57:56evanso if you mean use soap4r as an example of what NOT to do, sure.
21:58:01tenderlovehahaha
22:00:28rueMRI would be bundling a specific version of these libraries, which is what we would have to target
22:01:57rueIt seems to me that completely severing them would be better overall.
22:02:31evanagreed, but that doesn't seem to be in the cards.
22:03:08tenderlove*sigh*
22:03:09tenderloveya
22:03:16rueThe thing is, if the libraries are supposed to be viable as gems, they ought to provide their own specs
22:03:39evandouble agree.
22:04:06evanthats why i hope tenderlove and I figure out how to keep the testing/specing of his new yaml library sane.
22:04:09evanand happy
22:04:43rueSo, conceptually, rather than writing "rubyspecs" for them, the situation would be that the set of specs from whichever version is bundled gets pulled in instead
22:05:02evanthat would be best
22:05:05tenderloveyes
22:05:10evanbecause the the library maintainer would be writing the specs.
22:05:27evanthe flip side of that is that rubyspecs contains specs but no implementation
22:05:38evanso either they'd be unbundled from rubyspec entirely
22:05:42tenderlovethe problem though, is that if it ships as a stdlib, all implementations need to provide it. :-(
22:05:48evanor we'd have to figure out what version of the specs should be in rubyspec
22:05:57evantenderlove: exactly
22:06:10evannot only that, they have to provide it BUT don't have to use your implementation.
22:06:29tenderlovedo you expect other implementations to pass all tests that ship with mri?
22:06:48rueIn short, yes
22:07:02evantenderlove: typically, yes.
22:07:13tenderloveif that's true, then I could safely pull all yaml specs in to ruby svn
22:07:19evanthe tests that ship with MRI leave something to be desired at present.
22:08:23ruePull them into the YAML gem and then "freeze" them thence to SVN. Maybe
22:08:41tenderloveIf I were to move the rubyspec yaml tests to MRI, would they be removed from rubyspec?
22:09:10evantenderlove: brixen would have more of an opinion
22:09:16evanbut i'd put that largely up to you, the yaml maintainer.
22:09:23tenderloveI'm just curious
22:09:25rueI think conceptually, yes
22:09:28evanso long as you understand the requirements
22:09:41tenderloveit seems to me that rubyspec is like one giant patch that should be applied to MRI's tests
22:09:44evanthat the yaml specs exist to allow people to write yaml libraries that have a certain API
22:10:01evantenderlove: sure, like I said, it's filling a vacuum
22:10:17evantenderlove: MRIs test not really useful for implementers though
22:10:25evanbecause they don't actually indicate anything about the behavior being tested
22:10:26rueFor any given Ruby version, the YAML specs would become "externals" in the RubySpec repository
22:10:40tenderloverue: yes
22:10:48tenderloveevan: interesting....
22:10:56tenderlovethey /should/ though
22:11:06evantenderlove: additionally, MRI-core has only recently shown themselves to pay much attention to rubyspec
22:11:30evanso them having some level of ownership of them would be nice, but they haven't given much indication that they're interested at this point.
22:11:38rueIn reality, they probably do need to be in the repo because other implementations will rely on them. And, obviously, you may end up with eighteen billion different "externals" that way.
22:11:44evanthey're focused on the NEXT ruby version
22:11:52evanrubyspec is interested in a number of ruby versions.
22:11:59evan1.8.6, 18.7, etc.
22:12:32tenderloverue: right. it seems like one repo should be an "external" for the other repo
22:12:34boyscoutSupport early exit from #find_object. Fixes #179. - d94820f - Evan Phoenix
22:12:40tenderlovebut which is which confuses me
22:12:56rueRubySpec is the umbrella
22:13:27evanyes, rubyspec is a umbrella vacuum.
22:13:48tenderloveevan: that sounds like new logo opportunities
22:13:54evanfuck yeah.
22:14:15evanthings that fill that vacuum are core specs, language specs, stdlib specs
22:14:29evanstdlib specs have always been the most nebulous
22:14:33rueI do not think there is any real merit to the half-bundled-half-not mode of distribution
22:14:35evanfor exactly the reasons we've been discussing.
22:15:08tenderloverue: I agree, but duplication seems crazy
22:15:17evantenderlove: one thing I should note is that the yaml specs can't just be the current/next yaml version
22:15:27evanthey need to be for the a few past versions too.
22:15:38tenderlovehah
22:15:40tenderlovethat's funny
22:15:48tenderlovethe yaml specs are so bad
22:15:49evanit's true.
22:15:58ruetenderlove: Duplication? If they are wholly severed, then it works just like any other gem
22:16:34tenderloverue: I mean, rubyspec tests YAML.dump, and so do the syck tests. I don't like having it in two places
22:17:01boyscoutCI: rubinius: d94820f successful: 3041 files, 11843 examples, 36124 expectations, 0 failures, 0 errors
22:17:05rueIf yaml is only distributed as a gem, then RubySpec would have no yaml specs
22:17:14tenderlovebut it isn't
22:17:17tenderlove:-)
22:17:28evanyaml is, at present, just an API
22:17:44evanit WAS an implementation, but it's now an API with many implementations.
22:18:03evanjust like the ruby core libraries.
22:18:27rueMy argument was that the model where it is both a gem and bundled is unviable; completely severing it to a gem is the better solution - and does not involve duplication
22:18:28evanrubyspec provides an implementer the ability to know if their implementation satisfies the yaml API requirements.
22:19:18tenderloveevan: yes, but does that mean I should remove the tests I wrote that test the same thing rubyspec tests?
22:19:26evanthe idea for that has always been that rubyspec provides a suite of tests for knowing if one implementation could be dropped in place of another without disrupting anything
22:19:32rueAh, OK, you mean the existing specs for the Ruby versions that do have it bundled
22:19:43brixenatw, we're talking about 349 lines of code in the yaml specs in rubyspec
22:19:47evantenderlove: perhaps
22:19:51brixenatm rather
22:19:58evanoh really?
22:19:59tenderlovebrixen: that's for putting that in perspective ;-)
22:20:00evani should have looked.
22:20:02tenderloveerr thanks
22:20:04evanyou know
22:20:04brixenhalf of those are require spec_helper
22:20:06evannevermind.
22:20:11evantenderlove: you've got full control.
22:20:15tenderlove^5
22:20:16evanwe'll do whatever you need.
22:20:18tenderlovewild west!
22:20:21tenderloveyee haw
22:20:22rueIt is not just yaml, though.
22:20:24tenderlovehaha
22:20:31evantenderlove: i trust you to do the right thing
22:20:54evanmy only request is this: rubyspec needs to remain conservative and consise.
22:20:55tenderloverue: I agree. I'm glad to hear the rubyspec perspective
22:21:11evanand it must be able to test multiple versions.
22:21:36tenderlovecan you mark particular tests as only working on a particular version?
22:21:43evansure
22:21:47tenderlovecool
22:21:52evanit's versions of ruby though, not yaml.
22:22:03tenderloveyes
22:22:29ruetenderlove: In the hypothetical case of a severed, standalone gem, the specs would be with the gem. They could be pulled into RubySpec to cover the legacy bundled version as appropriate
22:22:34brixentenderlove: do you need a rubyspec tutorial?
22:22:41brixentenderlove: in all seriousness
22:22:45tenderlovebrixen: I think that I do
22:22:49tenderlovewhere should I read up?
22:22:54brixenok, let's move to #rubyspec
22:23:08rueBut the two are independent