Index

Show enters and exits. Hide enters and exits.

00:04:54brixenyou know, why do we go to all this trouble to make Ruby wonderful?
00:05:00brixeneffen lazy_array
00:05:06brixenguess what it does....
00:05:17brixenit defines method_missing, for one
00:05:30brixenand guess where __class__ and #copy_object end up?
00:05:34brixenjust guess...
00:05:44brixenand guess what #copy_object does in rbx
00:05:49evanug.
00:05:49evanyeah
00:05:52evani recall hitting that
00:05:53brixenseriously, just a wild guess
00:05:55evanand not fixing it.
00:06:06evanlazy_array redefines __class__ ?
00:06:10evanthats bad news.
00:06:11evanmega
00:06:25evanit shouldn't touch any __ methods.
00:07:34brixenhttp://gist.github.com/230474
00:07:46brixenso, of course our copy object prim will fail with a type error
00:07:52evanyeah
00:07:55brixenyou tried to copy and Object into an Array
00:07:56evanwe've had that happen before
00:08:04evancopy_object is thankfully doing the right thing by failing loudly
00:08:14brixenyes
00:08:27evanthat kind of code is exactly why we can't have nice things
00:08:29brixenunfortunately it cannot also nuke LazyArray
00:08:32brixen... from orbit!
00:08:42evanreadys the orbital weapons platform
00:08:48brixengo!
00:09:09evanlaunches the nukes.
00:10:00brixenat this point, I think a full RubyConf talk should be dedicated to educating and instructing people on what it means to have a *real* Ruby implementation
00:10:14evanyeah
00:10:20brixen"don't act like you're the only person in the room"
00:10:25brixenYOU'RE NOT
00:13:14ddubsilly question perhaps, but does Object#hash use the memory address as the basis of the hash key?
00:13:26evanno
00:15:03dduboh interesting
00:15:50ddub(I was misreading code before and asking to double-check, as using the memory address would be unfortunate in conjunction with a relocating GC)
00:16:33evanyeah
00:16:39evanpretty much not possible.
00:18:53evanGAH
00:19:08ddubGAH!
00:19:09evanIO#reopen(other_io) raise an exception if the reciever is closed
00:19:11evanbut
00:19:16evanIO#reopen(path, mode) does not.
00:22:24brixenwell that's...
00:22:30brixenok, I'm without words
00:22:39brixen4:22!
00:22:41brixendammit
00:22:43brixenlate again
00:22:51brixenand too many wtf's today
00:23:10evanthere is always tomorrow.
00:23:19brixenheh
00:23:25brixenthe day is young!
00:24:27slavasup boys
00:26:01slavaddub: what you can do is use the address as the hash until the object is relocated, and after it is relocated, add a new ivar to the object with the old address and use that as the hash
00:31:38evanslava: surely you're joking.
00:31:56slavano, its a legitimate technique
00:32:08slavait saves one word per object unless you actually take its identity hashcode (which is rare)
00:32:38slavaI'm not telling ddub to implement this, just answering his question about using the address as a hash -vs- compacting GC
00:32:42evanso you fixup all objects
00:32:59slavano, only those that have had their id hash already taken
00:33:02evanthat can't work if something (a hash table) saves the hash value
00:33:05evanyou can't fix that up.
00:33:24slavathe hash doesn't change
00:33:24evanbecause you can't identify the hash value in the heap
00:33:27evanit's just a random number.
00:33:35slavawhen you promote the object, you store its old address in the hash field in the header
00:33:35evani thought you're saying you change it everytime
00:33:37slavano
00:33:51slavaalthough some GCs do use the current address as the hash, and rehash identity hashtables on every GC, but that's a different technique
00:35:27slavathis is easy too -- when yo udo a GC, you set a flag in the hashtable's header and check the flag on every access; if it is set you rehash
00:35:29ddubobviously
00:35:36ddubyou should just make the default hash return 0
00:37:21ddubthinks he is quite clever
00:37:45evansweet
00:37:49evangot argf basically rewritten
00:37:54slavaevan: I haven't even added identity hashing yet but when I do I'm going to use unused space in the header (only 4 bits are occupied)
00:38:00evanand it now passes all the specs but the inplace edit ones.
00:38:35evanright
00:38:50evani'm considering shifting a few things around to get at least 16 bits free
00:38:56evanand putting a hash code in there
00:39:02slavawhat's in your header?
00:39:15evanso that blah.hash doesn't require an object_id to be setup
00:39:20slavamine just stores the built-in type number, and if the type is a tuple then a second header field stores a class pointer
00:39:56evantype number, mark bits, gc zone number
00:40:01evanand a couple other flags
00:40:07slavacan't you determine the gc zone from the address?
00:40:15slavaand store mark bits in a bitmap off to the side?
00:40:23evani can, but it's nice to have it right there in the header
00:40:26evanit's a great sanity check.
00:40:54evanthere are 2 mark bits, i could store them off to the side
00:40:59evani'm considering that.
00:41:04slavawhy 2? something to do with weak pointers?
00:41:11evannah.
00:41:21evanit was originally a debugging mechanism
00:41:34evanto detect objects that missed one mark/sweep
00:41:38evanbut were caught in the next one
00:41:51evanbut i'm going to reuse it now to eliminate the unmarking phase entirely
00:42:10evanby flip-floping the mark number between collections
00:42:20slavaoh I see
00:42:27slavaotherwise you'd have to clear the mark bits after a GC
00:42:45evanyep
00:43:30slavaI guess a mark bitmap only makes sense with a contiguous heap
00:44:38evanype
00:44:48slavaor a block structured heap
01:27:32evanwhat
01:27:32evanthe
01:27:34evanfuck
01:27:37evansuddenly now
01:27:46evanthe CI specs are forking bombing
02:17:53evanARG
02:17:59evanthere is an ARGF spec that closes STDIN
02:18:07evanand thusly breaks a bunch of other stuff
02:25:59evanbrixen: you still around?
02:28:21brixenyep
02:28:22brixensup?
02:28:33evani'm going to quaratine a spec
02:28:36brixenk
02:28:50evanspecificly, the one that tests that ARGF, when taking -, closes STDIN
02:28:55brixenbe sure to add ! so it knows you mean it :)
02:29:09evanrunning that now that ARGF is actually doing what it should means that it actually closes STDIN
02:29:17evanand that easily destabalizes the rest of the spec run
02:29:23evanspecificly, it destabalizes IO.popen
02:29:28brixenyeah, it's a wacky behavior
02:29:33brixenI mean, seriously
02:29:35evanbecause it uses STDIN.reopen to rotate IOs
02:29:50evanand you can't use IO#reopen(other_io) on a closed stream
02:30:05brixenyou can add not_compliant_on :rubinius too
02:30:08evanok, well, it took all day
02:30:13brixen:(
02:30:16evanbut ARGF is 99% complaint.
02:30:22brixenahh sweet!
02:30:29evanonly thing missing is the in-place operations.
02:30:50brixenawesome
02:30:54evancaught a comple of other bugs
02:31:01evanmainly because ARGF is built some much on IO
02:31:11evanand the specs do some twisty IO things
02:32:24brixenI do wish we could get Amy and Seth to do a Seriously? Ruby edition
02:32:24evanthe ARGF specs are wierd
02:32:27evanmainly because ARGF is wierd
02:32:32brixenyeah
02:32:35evanlike there is a spec that reopens the thing it just closed
02:32:39evanno comment or anything
02:32:43brixenheh
02:32:45evani deleted the line
02:32:49evanand most of the ARGF specs broke.
02:33:03evanso it's cleanup code basically
02:33:09evanbecause you can't isolate ARGF
02:33:18evanin rbx we can, but not MRI.
02:33:29boyscoutAdd 2 missing IO#reopen specs - 2785899 - Evan Phoenix
02:33:29boyscoutHave mspec print out a backtrace when it's interrupt in debug - d79a685 - Evan Phoenix
02:33:29boyscoutFix IO#reopen(path, mode) for closed streams - 80978c8 - Evan Phoenix
02:33:29boyscoutRework ARGF entirely - 0dc2945 - Evan Phoenix
02:33:29boyscoutUpdate tags for ARGF - 4161576 - Evan Phoenix
02:33:29boyscoutQuarantine bad ARGF spec - 973ceb1 - Evan Phoenix
02:33:31boyscoutAdd extra checks for using ARGF is stdin only mode - 17983f3 - Evan Phoenix
02:33:33boyscoutMove the flush/closed checks around in IO#reopen - d05de3d - Evan Phoenix
02:33:57evanmaybe i'll get past a tomorrow!
02:34:05brixenhah
02:35:21boyscoutCI: d05de3d success. 3002 files, 11363 examples, 35372 expectations, 0 failures, 0 errors
02:36:38brixenok, I see the spec
02:36:50brixenwe should be able to run that using ruby_exe
02:36:52brixenI'll look at it
03:34:07benschwarzevan:
15:04:51ddubgood morning
15:31:04rueMorning
15:50:17rueWas there a decision on the kernel special forms/double-underscore matter?
16:08:30darixis the rake install step already there?
16:44:39helozjiskyhi all, i got a error while building melbourne for MRI, any idea ?
16:48:24helozjiskyi forgot ruby-dev
16:58:25evanrue: what was the question?
17:04:38brixenhelozjisky: can you give me a gist of your error?
17:05:50brixenevan: http://github.com/jvoorhis/ruby-llvm/blob/master/samples/factorial.rb
17:06:17brixenI used to work with jeremy
17:06:18evanhuh.
17:06:23evancool.
17:06:30brixenI talked to him last night about getting it running in rbx
17:06:39brixenI think he uses AutoPointer
17:06:52brixenbut I'm sure he'd be ok with doing it a better way
17:07:10brixenanyway, yeah cool
17:07:23evanis it using FFI?
17:07:24brixensince I wanted to write ffi bindings to llvm but he beat me to it! :)
17:07:26brixenyep
17:07:28evancool!
17:07:31brixenyeah!
17:07:34helozjiskybrixen: just missed ruby-dev
17:07:38evanyeah, poor AutoPointer
17:07:43evanfinalizers ftl.
17:07:51brixenhelozjisky: I don't know what ruby-dev is
17:07:56brixenevan: yep
17:08:13brixenevan: extension compiler coming along very nicely
17:08:22brixenjust a few rake rules and some helper methods
17:08:23evanawesome
17:08:53brixenI'll test it directly on elle before I push :)
17:09:58helozjiskybrixen: an ubuntu package, sudo apt-get install ruby-dev
17:10:14brixenhelozjisky: ahh ok
17:10:57evanyes, i forgot that package on my new ubuntu VM too
17:11:00evanoriginally
17:12:18evani'm reading the thesis about implementing a GHC backend in LLVM
17:12:33helozjiskyyou need getting_started.txt on a new system
17:12:43brixenevan: neat
17:12:44brixenlink?
17:12:55evanhttp://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf
17:13:54brixencool
17:14:07brixenhot off the presses
17:14:25ddubthis worries me
17:14:34ddubnow I fear llvm might become Parrot
17:14:55brixennot much chance of that
17:15:01brixenllvm is used for real projects
17:15:08brixenzing
17:17:09evanchris has a pretty good technique for guiding
17:17:15evanbasically, he's got the ability to say "no."
17:17:25evanwhich is not a quality it seems the parrot devs have
17:20:47ddubyeah, that is somewhat essential
17:21:02ddubkinda like how linus has the ability to say "no, and you are an imbecile"
17:21:58evanyeah, i'm not sure the second part of that is necessary
17:22:16evanbut then again, linux deals with a much bigger crowd than either chris or I
17:22:39evansomething I think thats amazing is that linux hasn't been forked really
17:23:20brixenwell, it's not exactly a trivial project
17:23:27brixenthe US hasn't been forked either
17:26:02evanhah
17:26:06evanwell, there was one time
17:26:13evanbut the fork was forcibly merged back in.
17:26:17brixenheh
17:26:18brixenyeah
17:49:51boyscoutFix Kernel#methods for immediate values - 93f67c0 - Evan Phoenix
17:51:42boyscoutCI: 93f67c0 success. 3002 files, 11363 examples, 35372 expectations, 0 failures, 0 errors
18:25:05ddubthis week kinda snuck up on me, I don't think I'm going to have time to finish the mini-project I wanted to before rc
18:43:07boyscoutAdd Rubinius::Unsafe.set_class, use with caution! - 7b2902b - Evan Phoenix
18:43:07boyscoutAdd Peter Bevin's class-becomes-frozen patch - 3a1b04b - Evan Phoenix
18:43:07boyscoutUpdate Array tags - 017242f - Evan Phoenix
18:44:17brixenbadaboom
18:45:44evanpretty painless
18:45:54evanUnsafe.set_class has a few restrictions
18:46:34brixen1. get a note from your mother, 2. ...
18:50:43boyscoutCI: 017242f success. 3002 files, 11389 examples, 35400 expectations, 0 failures, 0 errors
18:51:02evanpretty much.
18:51:12evanthe restrictions are mainly type safety
18:51:18evanso that you can't create an invalid object
18:51:29evanie, an object layout that is a mismatch to the class
18:51:53brixenmakes perfect sense
18:52:19evanbrixen: could you check out array/hash_spec.rb:25
18:52:34brixenyeah
18:52:48evani always forget how a ruby_bug works
18:52:52evanthats saying what?
18:53:00evanbecause that behavior isn't true on 1.8.7
18:53:09evana recursive array on 1.8.7 has a different hash value
18:53:10brixenit's a bug in less than 1.9.1
18:53:12brixenyeah
18:53:28brixenthat's a bunch of work marcandre did and I think it's all in 1.9
18:53:29evanruby_bug is only conditional on MRI though
18:53:30evanright
18:53:33brixenright
18:53:38evank
18:53:51evanso idealy we wouldn't have the same bug
18:53:52brixenyou can put a ruby_version_is "1.9" around it
18:53:59brixenideally we would not
18:54:02brixenin any version
18:54:05evanok
18:54:08evani'll poke at this
18:54:11brixenk
18:54:12evansee if i can implement it easily.
18:55:14evanhm, 1.9.1p129 still has this bug
18:55:53brixenit's probably fixed in 1.9.2 or trunk
19:01:50evanmarcandr_: poke?
19:02:04evan<= confused
19:02:43evanohh
19:02:48evanthats... WIERD.
19:03:50evanno wait.
19:03:54evanthis doesn't make sense.
19:04:07brixenwassup?
19:04:30evani don't see how the code in 1.9 would result in a consistent hash value for a recursive array
19:04:37evanit uses the size
19:04:58evanoh
19:05:01evani guess i see
19:05:06evanbut it's a silly edge case.
19:05:11evanit's only true for
19:05:12evana = []
19:05:13evana << a
19:05:28evanany single recursion will yield the same hash value
19:05:41evanbecause the depth is 1
19:05:51brixenahh yeah
19:07:18evanmm, i think i see.
19:07:25evani'm using xor to mix the hash value of elements in
19:07:33evanbut i'm getting 1 ^ 1
19:07:52evanin one case, then 1 ^ 0
19:07:53evanso
19:07:56evana = []
19:07:57evana << a
19:08:03evana.hash # => 0
19:08:05evanbut then
19:08:08evan[a].hash # => 1
19:08:12evanthis test is silly.
19:08:15evansilly silly silly.
19:08:30evanwhy the heck is it using a NON recursive array to test?
19:08:51evanthats a side effect of whatever you use to mix the hash values
19:08:56evani think this is just a bad spec.
19:10:20brixenhmm, why would [rec].hash == rec.hash ?
19:10:26evanit wouldn't.
19:10:34brixenthat doesn't make sense to me either
19:10:36evanit's a coincindence that it is in 1.9
19:10:41evani'm changing the spec
19:10:41brixeneww
19:10:52evanto actually test what it says it's testing
19:11:06evanand not adding in unrelated (and wrong) bits
19:29:41marcandreevan: hi!
19:36:47marcandreevan: I'm not sure I see what's wrong with the spec of Array#hash, expect maybe replacing specifying that the hash need be the same for _equal_ recursive arrays
19:48:12marcandreevan: let me know if you'd like me to help with the implementation in Rubinius
20:06:52ddubhash on recursive arrays, fun
20:08:10marcandreddub: it was, actually :-)
20:35:05dbussinkbrixen: been reworking lazy array a bit and it's also passing all specs now :)
20:35:17dbussinkevan: i did find a weirdness with the new frozen stuff btw
20:38:35brixendbussink: cool
20:38:50brixendbussink: but do you see why the approach is so brittle and basically bad?
20:39:16brixenalso, I've got a compiler fix so transforms don't choke an a.+(*b)
20:39:24brixenI'll push after lunch
20:39:27dbussinkbrixen: i definitely do yeah, i have the excuse though i didn't write it ;)
20:39:36brixendbussink: totally understood
20:39:42dbussinkbrixen: actually most nasty is the undeffing part
20:39:58brixenI think that the attempt to proxy in this case is a complete design fail
20:40:12brixenclients of the lib should NOT expect an Array
20:40:23brixenthey should be working with a real lazy DT
20:40:45brixenanyway, I'm freakin' starving
20:40:51dbussinkbrixen: well, the abstraction of having the lazyness abtracted away works really well actually
20:40:57brixenlunch, bbiab...
21:13:01dbussinkevan: you there?
21:13:39evanyep
21:14:44dbussinkevan: looks like frozen is not correct yet, since optparse is failing for me
21:15:21dbussinkevan: i'll get you a backtrace
21:15:43evank
21:15:48evanopen an issue
21:16:13dbussinkother than that i've cleaned up extlib ;)
21:16:26dbussinkevan: were you able to reproduce the segfault with ri and rdoc enabled btw?
21:16:29benschwarzwhatup ephoenix
21:16:35evanhaven't tried again
21:16:37evanbenschwarz: hey!
21:16:40evannice mustache
21:16:45benschwarzsaw your video too
21:16:45benschwarz\
21:16:48benschwarzthanks :)
21:16:53evanwhich video?
21:17:05benschwarzthe rbx, japan one
21:17:11benschwarzcan't remember the name of the conf this second :P
21:20:40evanah yes
21:20:41evanrubyworld.
21:22:45marcandreevan: did you figure out the recursive array specs? Or am I missing something?
21:23:15brixen312 people have clicked through the link I posted on @rubinius for your talk evan
21:23:36evanmarcandre: i've changed them to actually test what they say they test
21:23:59evanbrixen: sweet
21:24:27marcandreevan: have you pushed the changes?
21:24:31evannot yet
21:24:33evanwill shortly
21:25:06marcandrek. let me know, I'm curious as to what you've changed.
21:25:33evank
21:34:24evanmarcandre: I just pushed the change
21:34:26evancheck it out.
21:34:31evanto rbx
21:34:38boyscoutFix recursive Array#hash specs - 1bc7345 - Evan Phoenix
21:34:38boyscoutUpdate Array#hash tags - 8c295a8 - Evan Phoenix
21:36:28marcandremmmm
21:36:28boyscoutCI: 8c295a8 success. 3002 files, 11391 examples, 35402 expectations, 0 failures, 0 errors
21:36:49slavahi evan
21:37:38marcandreevan: those changes are not valid.
21:37:50evanthen the spec is worded wrong
21:38:05evanbecause putting it inside another array isn't testing what the spec says
21:38:15evanand that behavior is not related
21:38:30marcandreI changed the wording after reading your conversation...
21:38:53marcandreThe point of the specs is this: since rec == [rec] == [[rec]], they should have the same hash
21:39:11marcandreI'm talking about the original rec, i.e. rec = []; rec << rec
21:39:12evanthats got nothing to do with recursive hash values
21:39:25evanand I don't believe that is a requirement
21:39:35evanwhy must rec.hash == [rec].hash
21:39:35evan?
21:39:35brixenmarcandre: how is a = []; a << a the same as [a] ?
21:40:28marcandreIt's a long thread...
21:40:42evani think that "rec.hash == [rec].hash" is a red herring
21:40:43marcandreBasically: what is the difference between rec and rec[0] and [rec]
21:40:53evanit's a coincidence that they're equal on 1.9
21:41:00evanthere is no requirement that they are
21:41:10marcandreevan: It's definitely not a coincidence :-)
21:41:15evansure it is
21:41:18evani went through the 1.9 code
21:41:24evanit's definitely a coincidence.
21:41:28marcandregood. i _wrote_ the 1.9 code!
21:41:40slavawhy don't the 1.9 devs just give up and admit defeat?
21:41:43slavatheir impl sucks
21:41:50evanmaybe you didn't intent for it to be, but I read it to be a coincidence
21:42:01evanslava: please, we're having a discussion, if you don't have anything productive, save it for later.
21:42:28slavasorry evan
21:42:45brixenmarcandre: http://gist.github.com/231292
21:42:47evanmarcandre: i'm happy to read anything about why "rec.hash == [rec].hash"
21:42:49brixenmarcandre: can you explain?
21:42:53evanbut i don't understand why it's related at all.
21:43:04evanthats like saying
21:43:10evan"[].hash == [[]].hash"
21:43:20marcandrenot at all.
21:43:24evanwhy not?
21:43:26evanthats what it is.
21:43:30evanit's a hash inside a hash
21:43:31marcandreBecause [] != [[]]
21:43:37marcandrebut rec == [rec]
21:43:37evanyeah
21:43:40evanand rec != [rec]
21:43:42evanno
21:43:43evan!
21:43:43marcandrenope
21:43:50evanwhy would rec == [rec]
21:43:55marcandrerec == [rec] == [[rec]] == rec[0] == rec[0][0]
21:44:02marcandreName me a difference
21:44:37evanone is an array, one is that array in another array
21:44:43evanseems pretty different to me
21:44:58marcandreBoth are arrays, containing one element.
21:45:06evanright...
21:45:07evanso?
21:45:08marcandreThat element is equal because... goto previous line
21:45:09evan[1] != [2]
21:45:35evanjust beacuse something is == doesn't mean they have the same hash value
21:45:46marcandreLet's put it this way: array1 == array2 unless they have different sizes or there is a difference in their arguments
21:45:53evani did just realize you mean actualy Array#==
21:46:02evanand not the mathmatical property of equality
21:46:04marcandreevan: if they are eql? than yes, they _have_ to have the same hash value.
21:46:05evanwhich is what I meant.
21:46:35evanhm.
21:46:40evanok. i see where you're going.
21:47:00marcandreI do mean Array#==
21:47:34brixenok, well there is precisely one case in which this is true then: a = []; a << a; [a], [[a]] etc
21:47:51marcandrebrixen: right
21:48:00marcandreBut there are other "shapes" of recursive arrays
21:48:06brixenyes
21:48:09marcandrer2 = []; r2 << r2 << r2.
21:48:14marcandreThen [r2, r2] == r2
21:48:37brixengotcha
21:48:41evanwell fuck.
21:48:46evanbecause i don't think 1.9 passes that
21:48:50evanit uses the size in the hash value
21:48:59evanso [r2, r2].hash != r2.hash
21:49:20marcandrefunky = []; funky << strange = [funky]. Then rec == funky
21:49:29marcandre[r2, r2].hash == r2.hash.
21:49:37brixenyeah, it passes
21:49:38evanhow can that be on 1.9
21:49:43evanit uses the size in the hash value
21:49:48marcandreThey both have two elements
21:49:55evanoh
21:49:58evani misread it
21:50:02evanyou're r2 has 2 values.
21:50:14marcandreI used the size in the implementation because it's an quick way to make rec.hash != r2.hash, but I didn't spec that.
21:50:27evanwell, please add another spec that details exactly why rec.hash == [rec].hash
21:50:40evana nice big comment above it would be great
21:50:46evanbecause this is quite twisty.
21:50:47marcandreIt already exists: equal_spec!
21:50:48brixenmarcandre: yeah, you should include at least 2 cases in this instance
21:51:02evanmarcandre: then the test shouldn't be in hash
21:51:17evanor the hash spec needs a comment that mentions the equal_spec
21:51:18marcandreWhat I'll do is I'll refer to the equality thing in the specs.
21:51:25evanbecause i had no idea.
21:51:38marcandreThat's also why you are right that my title was not correct.
21:51:58brixenmarcandre: yes, please do document with a comment
21:52:12brixenthe spec description string can only convey so much in this case
21:52:45evanthe more comment on this, the better.
21:52:55brixenslather on the comments
21:52:59marcandreevan: It's not trivial to implement the right #hash, because it is the outermost call to #hash which has to return the "hash for recursive arrays" values.
21:52:59evanmentioning that hash has to match up with eql is important in this.
21:53:13evanoh
21:53:14evani know.
21:53:15evan:)
21:53:15brixendon't be worried about high cholesterol
21:53:19evani'm poking at it now.
21:53:47marcandreI'll fix the specs now. Let me know if you'd like me to help with the implementation in rubinius.
21:53:57marcandreI almost feel responsible for the trouble ;-)
21:55:03brixenmarcandre: and you are! it's all your fault for trying to bring some consistency to MRI
21:55:06brixen:)
21:59:31marcandreDone
22:01:01marcandrebrixen: I know :-) Hey, we never celebrated the birth of Object#<=>. Bring the champagne next time ;-)
22:01:34brixenheh
22:01:59brixenmarcandre: I don't mean to be a pain, but can you actually add a comment that states the condition for Array#==
22:02:06brixenunless it's there and I'm missing it
22:02:29brixen"same elements in the same order" / something
22:02:56brixenand explain why that impacts recursive array hashes
22:03:08marcandreI guess we can wait until it can be spec'ed out. I'm still waiting on Matz to explain what he wanted.
22:03:33marcandreOh, yeah. I checked Hash#eql? and that was ok, so I assumed I did it for arrays too.
22:03:49brixenoh, I didn't look at Hash#eql?
22:04:46marcandreAh, ujihisa actually wrote the recursive Array#eql? specs. I'm commenting them now.
22:05:00brixenah, ok. thanks
22:11:29ddubrecursive collection equivalence, *shiver*
22:17:08marcandreI hope this is a bit more clear.
22:18:15marcandreAh, there's struct also...
22:19:20marcandreWell, just the way I worded the == spec makes it more clear. I'm commenting Struct#hash
23:21:34brixencrosses fingers
23:21:41brixendoing a clean build now
23:59:27boyscoutFix a few last Array spec failures - 61a46c9 - Evan Phoenix
23:59:27boyscoutWrap specs that rubinius doesn't support in not_complaint_on - eb4e095 - Evan Phoenix
23:59:27boyscoutUpdate Array tags - 1824ab5 - Evan Phoenix
23:59:35evanok, Array is good.
23:59:50evanthe only fail tags are now because we're missing an implementation of permutation
23:59:55evani'll let someone else do that.