Index

Show enters and exits. Hide enters and exits.

18:59:38dbussinksilence before the release storm? :)
18:59:56evan:)
19:00:06evanjust finished up the last of the debugger functionality it looks like.
19:00:17evannamely, the ability to debug with the JIT on.
19:18:42dbussinkevan: cool :)
19:18:57evangoing to do some debugging docs and cleanup later today
19:19:21dbussinkah nice, brixen is finishing the audit i guess, those are the last things?
19:19:37evanbrixen is going to finish up pack/unpack
19:19:59evanthen need to get the rails3 tests green.
19:37:13boyscoutSupport switching a method from JIT to debugging interpreter - 7e97a1c - Evan Phoenix
19:37:13boyscoutMerge branch 'jit_deopt' - 903d16d - Evan Phoenix
19:37:14boyscoutCleanup some old breakpoint cruft - 8fdb4a4 - Evan Phoenix
19:37:45dbussinkevan: hehe, i can even get headius and enebo bug hunting in jruby ;)
19:49:17boyscoutCI: rubinius: 8fdb4a4 successful: 3522 files, 15318 examples, 43186 expectations, 0 failures, 0 errors
19:49:54dbussinkevan: ah, it completely deopts for the debugger?
19:57:25dbussinkbrixen: irc issues?
19:57:30brixendunno
19:57:35brixenjust got back from lunch
19:57:57dbussinkbrixen: btw, just got a nice compiler blow up found due to a bug in jruby: ./bin/rbx -e "class Fixnum; def -@; 'hello'; end; end; puts eval('-1')"
19:58:08dbussinkjust wanted to show you what that does :)
19:58:35brixenwhat is "that"?
19:59:24dbussinkbrixen: the compiler blow up
20:00:02brixenyou can't redefine @-
20:00:07brixenwhat sense does that make?
20:01:26dbussinkit doesn't
20:01:37brixenso what is the point?
20:01:49dbussinkbut i was discussing some bug in #jruby and headius tested this to see how mri and rbx behave here
20:01:58dbussinkand he was just surprised by the output
20:02:02brixenwhy?
20:02:11brixenwhat would you reasonably expect?
20:02:24dbussinki guess he expects a more descriptive error
20:02:29dbussinkthat's the main thing
20:02:52brixensuddenly a Fixnum is a string
20:03:03brixenI suppose I should test for that
20:03:10brixenthat's fucking stupid
20:03:14brixen:)
20:03:53dbussinklooks like mri just ignores it
20:04:06brixenbig surprise
20:04:12brixenMRI is a C library
20:04:26brixenrbx is a (mostly) Ruby library
20:04:53dbussinkyeah, exactly
20:05:06brixenbesides
20:05:08dbussinkbut anyway, it's not that i would expect anything to happen with it
20:05:11brixenyou should be testing this:
20:05:12dbussinkjust wanted to show you
20:05:12brixenruby -e "class Fixnum; def -@; 'hello'; end; end; puts -eval('1')"
20:09:09brixendbussink: just fyi, so you know what you are testing: http://gist.github.com/562857
20:09:54dbussinkbrixen: it actually was about how :negate came into play here
20:10:02dbussinkbut anyway, doesn't really matter
20:10:32brixenmy point is there is no requirement that negate call -@
20:23:47slavabrixen: its amazing that you can monkeypatch Fixnum#- and ruby doesn't crash immediately
20:27:52brixenslava: it's amazing that anyone would monkeypatch Fixnum#-
20:28:00slavado people do this in real code?
20:28:00evanslava: thats not subtraction
20:28:03evanthats negation
20:28:07evanlike
20:28:07brixenslava: no
20:28:10evany = -x
20:28:15slavahi evan :)
20:28:22brixenyeah, actually Fixnum#-@
20:28:41dbussinkbrixen: btw, for bignum, mri does run the -@
20:28:48slavain factor, redefining fixnum ops wouldn't get as far as printing the next REPL prompt
20:28:55evandbussink: yeah, thats not surprising.
20:31:24slavait seems problematic in general if every method that a given method X calls is part of the public API of X's class
20:31:39slavaand people override random things expecting things to work based on how MRI happens to be implemented
20:31:55dbussinkslava: sadly that is part of how people write some ruby code
20:32:07dbussinkslava: there's even ruby stdlib code that does that
20:32:10slavaI bet if you subclass Array and override [], then most MRI array ops wont' go through your custom []
20:32:15slavabut in rbx they would
20:32:23slavaand some monkey's ajax frontend crap will break
20:32:30evanit's getting better actually
20:32:38evanrubinius is a stick in the mud
20:32:47evanso people have a harder time being stupid in their libraries
20:32:55dbussinkslava: brixen wrote a nice article on it to raise some awareness: http://www.engineyard.com/blog/2010/rubinius-wants-to-help-you-make-ruby-better/
20:33:01evanbecause users report "this library doesn't work on rbx" and we push back a little
20:34:06slavathat's a good blog post
20:35:52evanyeah, i'm pretty proud of brixen. That post has gotten a lot of traction.
20:36:06slavahas there been much resistance to doing things right?
20:36:16slavapeople who say "it works with MRI so I won't bother?"
20:36:54evanmost people recognize pretty quickly when we push
20:37:01evanif they're doing something dumb
20:37:18evana common response is "yeah, a quick hack, worked fine in MRI, but pretty dumb."
20:37:39evanwhen we provide them with better solutions, they're usually amenable.
20:39:51brixenyeah, very rarely are people trying to do something wrong
20:40:11brixenit's easy to not notice something and MRI goes happily away calling C functions
20:40:20brixenthat's the biggest case
20:40:57evanknowing about the weirdness is 80% of the battle
20:41:01evanwhich we're winning.
20:43:55brixenevan: so, trying to debug a segfault where the GC is trying to promote a 32M tuple
20:44:08brixenwhich of course is not really true
20:44:15evanhm.
20:44:26brixenbut I'm not seeing where full_size_ could get written to
20:44:32brixenthe header is not corrupted
20:44:46evanfull_size_ is 32M?
20:44:49brixenyeah
20:44:58evanmaybe it's not corrupted
20:45:05evanmaybe it was set that at the beginning
20:45:15brixenwell, it couldn't be in young space could it?
20:45:25evanmm, no, it could not.
20:45:42evanbut maybe the code that sets full_size_ is screwed up
20:45:42evan?
20:45:54brixenI have the assert in Tuple::create
20:46:03brixenwhich is the only place I see full_size_ being set
20:46:09evanis this crash happening every time?
20:46:17brixenyeah
20:46:21evanoh good.
20:46:26evanthats excellent for a GC bug.
20:46:35evangist me your changes
20:46:41brixensec..
20:49:39brixenevan: http://gist.github.com/562918
20:52:12evanhrm
20:52:24evanwant me to replicate it here?
20:52:36brixenwell, I suppose
20:52:41brixenI can keep looking at it
20:52:43evani don't see anything off hand
20:52:52brixenjust curious what you might do to debug
20:53:02brixenI can watch full_size_ being set
20:53:18evanthats going to be beyond tedious to do in gdb
20:53:23evanbecause there are so many Tuples
20:53:34brixenwell, I was just going to puts it and grep :)
20:53:38brixenrather than a watchpoint
20:54:12evanwhy did you introduce int32_t?
20:54:17evanbtw
20:54:35brixenI thought I changed that to native_int
20:54:46brixensince the uint32_t will always fit in that
20:54:50evanI see you changing it to int32_t
20:54:53brixenand the external code will use that
20:55:24brixenfor num_fields() ?
20:55:30evanthe argument to at()
20:56:05brixenah, that's old
20:56:12evanold?
20:56:23brixenwell, it's incorrecty
20:56:26brixener -y
20:56:37brixenI was trying to work out the type for num_fields
20:56:56brixenmy reasoning is, num_fields should be native_int because that's what code will use when eg getting a Fixnum from ruby
20:57:07brixenboth at() used size_t before
20:57:08evanok
20:57:16evani'm going to replicate it here
20:57:19brixenI changed num_fields() and forgot that
20:57:25evani don't know how to tell you how to debug it unless I do it myself :)
20:57:29evani could screencast it again.
20:57:41brixenwell, one more thing to look at
20:57:44brixenTuple::reverse
20:58:06brixeni just realized we set limit, but never use it
20:58:21brixenbut I think there was a boundary bug using full_size_ directly initially
20:58:43brixenbecause the value of o_start comes in as a Fixnum
20:58:55brixenand full_size_ will be bigger than num_fields()
20:59:10brixenso you could say start at num_fields() + 1
20:59:11evanum
20:59:13evanwtf
20:59:16evantotally
20:59:22evanwhy the fuck is this code using full_size_ directly
20:59:26brixennot sure
20:59:31brixenyou wrote it :)
20:59:34evanit's not related to the number of slots at all
20:59:37evanwell, mega fail on me.
20:59:39brixenhah
20:59:58evanit works because limit isn't used
21:00:00evani'm guessing.
21:00:03brixenyeah
21:00:06brixenjust realized that
21:00:13evanbut the bounds check is fully wrong.
21:00:37brixenwell if(start > num_fields()) seems right
21:00:38evanit will happily write off the end of the Tuple
21:01:11brixenbut yes, the bound needs to be fixed
21:02:44evanwhat workload cases the crash?
21:02:51brixenoh, running specs
21:03:04brixenI'm just doing: bin/mspec ci --gdb
21:03:14evanyour gist looks cut off
21:03:34evanand patch complains about that too
21:03:37brixenI think it's right
21:03:38evancould you double check it?
21:03:53brixenlooks the same as my cat'd file of the diff
21:04:00evank
21:04:09brixendid it not apply?
21:04:13evannope
21:04:16evanpatch didn't
21:04:19evani'll try git apply
21:04:28evannope
21:04:30evansays it's corrupt
21:04:34brixenweird
21:04:47evangit apply says it ends early
21:05:10brixenoh, you didn't patch < it
21:05:12brixen?
21:05:16evani did
21:05:21brixenhum
21:05:21evanI got rejects in regexp.cpp
21:05:29evanand it complained about it ending unexpectedly
21:05:40brixenI'll give you a git fp
21:05:57evank
21:06:19brixenactually, le'me fix ::reverse
21:06:29evank
21:27:56evanwhich one do you guys prefer:
21:27:59evanDebugger.here
21:28:00evanor
21:28:01evanDebugger.start
21:28:09evani'm taking votes for the next 5 minutes.
21:28:59cremesis there a contra command like Debugger.stop?
21:29:06bougymanDebugger.exterminate
21:29:10evanno.
21:29:12evanthere is not.
21:29:17evanit's like Kernel.debugger
21:29:23evanie, it starts the debugger at that point
21:29:30evanfor you to begin debugging
21:32:03cremes'start' sounds funny to me without a related 'stop'; 'here' is okay but unfamiliar...
21:32:23evanok
21:32:30evanany other votes?
21:32:41cremesis it supposed to act like a breakpoint?
21:32:58cremes(i looked up Kernel.debugger but didn't find anything for MRI)
21:33:05evanit's in ruby-debug
21:33:07evanyeah
21:33:11cremesoh
21:33:15evanwhen you call it, it acts like a breakpoint
21:33:22evanit starts you into the CLI
21:33:27brixenDebugger.start is my pref
21:33:30kronos_vanovotes -> Debugger.start
21:33:32evaninside the called method
21:33:36evanok
21:33:36cremesthen i like Debugger.break
21:33:43cremes:)
21:33:45evanbreak is a keyword
21:33:50evani dislike using break as a method.
21:34:00cremesDebugger.breakpoint
21:34:06cremesor break_point
21:34:19brixenstart seem simpler to me
21:34:28brixenyou set a breakpoint *in* the debugger
21:34:36kevinclarkDebugger.whats_the_problem_already?
21:34:38cremes'start' makes it sound like a profiler
21:34:44brixenkevinclark!
21:34:58evankevinclark: Debugger.pay_attention_to_me!
21:35:10kevinclark!
21:35:29kevinclarkhow's it going brian?
21:35:34cremesi don't really have a dog in this hunt; my code doesn't have bugs so i don't need a debugger.... :P
21:35:38brixenevan: just pulled and merged, rebuilding, then I'll give you an fp
21:35:44evank
21:35:52brixenkevinclark: good, you?
21:36:32kevinclarkgood good. post-vacation I get to wait and see how much of the team evaporates. (my boss gave notice this morning)
21:36:54evankevinclark: you didn't give notice too?
21:37:14brixenkevinclark: you could be the boss then! :)
21:38:12kevinclarkhaven't yet. Decided that I should start moving towards teaching (which is what I've wanted to do for a while anyway), so I might let MS help pay for me to finish undergrad
21:38:30kevinclarkneed to figure out what system I'd want to to teach in, though, and what the reqs would be
21:38:34kevinclarkmaybe I still don't need it
21:41:15brixenevan: http://gist.github.com/563006
21:42:15brixenkevinclark: you should see if they'll pay for your school
21:42:42brixenkevinclark: despite all the "you don't need a degree" talk you hear, I think it's good and if they pay, win! :)
21:43:38evanbrixen: do you have changes in regexp? or something?
21:43:45evanthis won't apply for me.
21:44:03kevinclarkbrixen: yeah, I think they give 6.5k a year towards it, which'd help a lot
21:44:55brixenevan: hrm
21:45:32evanjust push this to a public branch
21:45:32brixenevan: no changes not in that fp
21:45:38evani can't get it to apply
21:45:46evani don't know wtf is going on.
21:50:14evanwtf git
21:50:17evanthis should totally apply
21:50:27evani have no clue whats going on.
21:51:31evanit's telling me this:
21:51:34evanDid you hand edit your patch?
21:51:34evanIt does not apply to blobs recorded in its index.
21:51:39boyscoutNormalizing all access of Tuple and ByteArray. - 3db5989 - Brian Ford (native_int)
21:51:56brixenI just git fp'd it
21:51:57evanhow were you getting that into a gist?
21:52:00brixenand pasted it in gist
21:52:03evanhow?
21:52:15evando you have the gist cli tool?
21:52:17brixencopy from the terminal, paste into the gist textarea
21:52:19brixennope
21:52:21evanUG
21:52:23evanthats probably it
21:52:27evanthe cut and paste screwed it up somehow.
21:52:33brixenweird
21:53:34brixenwell, I pushed you a branch
21:53:39evanyep
21:53:41evancompiling now.
21:55:05evanoh shit.
21:55:06evani see
21:55:15evani diff'd your gist with my making a fp from your commit
21:55:19evanthere are hard tabs in there
21:55:26evanand your cut and paste turned them into spaces
21:55:36brixenhard tabs in regexp?
21:55:39evanyep.
21:55:43brixenugh
21:55:50evanthose Tuple::from lines
21:55:54evanthat are way intended
21:56:02evanhave hard tabs
21:56:21brixendo you have vim highlight tabs?
21:56:24evanyou should get the gist cli tool
21:56:49evani don't recall how to have vim show you
21:57:16brixenevan: btw, there's some spec failures I'm fixing
21:57:28brixenwas just trying to get past that segfault to a complete run
21:57:28evanhttp://gist.github.com/563028
21:57:33evanthats my diff of the diffs
21:57:39evanfyi.
21:57:43evanok
21:57:45brixenk
21:57:49brixenI'll fix those tabs
21:57:49evani'm not getting the segfault yet
21:58:18brixenit appears to happen for me reliably in the spec/core/method/parameters specs from a full run
21:58:27brixenno segfault on just that file
21:59:03evanfor me, rbx started sucking down memory
21:59:09evannow at 750M
21:59:20evani stopped it.
22:00:09brixenhm
22:00:41evan#7 0x00000001000840c6 in rubinius::ObjectMemory::promote_object (this=0x10131a1d0, obj=0x1022c5ef8) at vm/objectmemory.cpp:160
22:00:41evan160 Object* copy = immix_->allocate(sz);
22:00:41evan(gdb) p sz
22:00:43evan$1 = 36459912
22:00:50evan36M
22:00:58brixenis it a tuple?
22:01:00evanand it's a tuple.
22:01:03brixenk
22:22:05evanbrixen: hm
22:22:08evani'm.... stumped.
22:22:17brixenevan: you probably already know this, but an assert on full_size_ in Tuple::create for this big a size never fails
22:22:31evanyeah
22:22:32brixenif course, it could never get allocated
22:22:33evani tried that too.
22:22:35brixenok
22:23:11brixenallocated in young gen I mean
22:23:46evanyep
22:23:50brixenso it could be a random write, or a write behind?
22:24:02brixenie, it doesn't seem like something wrote over the header
22:24:07brixeninto full_size_
22:25:03evanyeah, it doesn't seem that way
22:25:16evanthe klass pointer is right
22:25:21evanand it's adjacent to the size
22:26:30brixenhow do you watch for an obj address being alloc'd again?
22:27:03evanset the env var WATCH to it's address
22:28:22brixenhmm, I wonder if this is an odd coincidence, the full_size_ value is really close to the same value as the *address* of the obj being copied
22:29:44evanhm...
22:29:50evani didn't notice that
22:29:53evanbut you might be onto something
22:29:57evani'm backing out your tuple changes
22:30:00evanand seeing if it goes away
22:30:29brixenwell, interestingly enough, I've had random segfaults running specs that I could not repro
22:30:34brixenbefore any of the tuple stuff
22:30:47brixenabout the same place
22:30:58brixenthe bt would be ?? and the abort frame
22:31:08evanit was an abort?
22:31:15evanwhat was the condition?
22:31:48brixenwhat's interesting here, the gc is getting called from the rbx_ prolog_check
22:31:50evanbrixen: oh, run the specs with the JIT off
22:31:52evansee what happens
22:31:55brixenk
22:32:52brixenwell, by abort frame I mean the mangled cpp terminate frame
22:33:08brixenso, like 3 frames, ??, something, cpp terminate
22:33:30evanok
22:33:34evangood news
22:33:41evangoing back to before your tuple changes fixes the problem
22:33:56evanso now it's time to binary search the changes
22:33:57brixenheh, well, "fixes"
22:34:20evanyes
22:34:22evanfixes.
22:34:23evan:)
22:34:49evanoh maybe not
22:34:54evangot a crash.
22:34:59evanbut different
22:35:21evan:/
22:35:28evanit's a corrupt object
22:37:14brixenok, got it with -Xint
22:37:36evank
22:37:38evangood.
22:37:40brixenlet's see if it's the same object addr repeatably with -Xint
22:37:42evannot a JIT bug then.
22:38:27evanoh oh
22:38:33evani caused the crash with my debugging code
22:38:33evanyay.
22:38:46brixenyay
22:38:52brixenwhat's your debugging code?
22:39:11evani did something silly
22:39:15evanused an undefined local
22:39:18evanwhich i guess sort of worked sometimes
22:39:27evangotta redo my initial test now actually
22:39:31brixenok
22:41:28brixenunfortunately, it's not easy to separate parts of that diff
22:42:39brixenI'm really curious about this value being so close to an obj address
22:42:39evansure it is
22:42:44evani did
22:42:51brixenwhich parts?
22:42:53evangit checkout HEAD^ -- vm/builtin/tuple.?pp
22:42:57evanto go back on them
22:43:34brixenwell, yeah, tuple is better isolated than bytearray
22:44:07evanhm so
22:44:29evanit's almost definitely part of an object reference
22:44:45evan(gdb) p t->full_size_
22:44:45evan$3 = 35747248
22:44:45evan(gdb) p (void*)$3
22:44:47evan$4 = (void *) 0x22175b0
22:45:12evant is 0x102217c48
22:45:13brixenwhat is the diff between the size and other's address?
22:45:19evanwhich other?
22:45:31evanit's only part of an address
22:45:31brixenin copy_body
22:45:35evanhuh?
22:45:41evani'm not getting a crash in copy_body
22:45:46evanso i'm not sure what you're refering to
22:45:52brixenmy segfault is in ObjectHeader::copy_body
22:45:57evanok
22:45:58evannot here.
22:46:03brixenah
22:46:03evani put in an assert in baker.cpp
22:46:08evanto catch a giant tuple before it gets promoted
22:46:17evanotherwise we spin out chewing up memory
22:46:30brixenoh, well you're just a couple frames up then I'm guessing
22:46:42brixenwhere's the assert?
22:46:51evan if(Tuple* t = try_as<Tuple>(obj)) {
22:46:52evan assert(t->full_size_ < 20000000);
22:46:52evan }
22:46:57evanon line 67 of baker.cpp
22:47:20brixen:sp
22:47:23brixener ... :)
22:47:32evanheh
22:48:06brixenok, sure, and I'm below promote_object, so in the same place basically
22:48:35brixenwhat's the diff between the 32bits of obj's address and the full_size_ there?
22:48:49brixenI'm just wondering if it's a constant difference
22:50:05evanthats not a full address
22:50:10evanit's missing the 10 in the high bits
22:51:01evanif I add the high bits in, it's 1688
22:51:06evani doubt it's related.
22:51:16evani think it's just another straw reference
22:52:01evanstray, rather.
23:03:42brixenyay, hit a watch point with a funny value :)
23:04:09brixenhttp://gist.github.com/563125
23:05:04evani have a hunch.
23:05:05brixenhmm, the right magnitude
23:05:16evanwe might have a latent bug
23:05:28evanwhere we tried to set the -1'st field in the tuple
23:05:37brixenyeah
23:05:39evanand when they were unsigned, that was a field way out in the middle of nowhere
23:05:43evanbut not that they ARE signed
23:05:44evanwhen it sets -1
23:05:49evanthats where full_size_ is.
23:06:16evani'm putting asserts around all field[] code to be sure the index is positive
23:06:20evanwe'll see what that does.
23:06:21brixenI've seen Tuple::put come through this watch
23:09:09evank
23:09:35evanwe need to be guarding field[] more
23:09:44evanwe should do that as part of this cleanup.
23:10:11brixenk
23:21:51brixenawesome, got an assert failure
23:22:41evanwhere at?
23:23:12brixenwell, it was building, so I'm retrying in gdb
23:23:55brixenah dammit, wrong condition
23:23:58brixen:/
23:24:04evan:/
23:24:09evani got it to go away here
23:24:10evani think i'm close
23:27:12evanBINGO.
23:27:23evangot it
23:27:25evanyep
23:27:28evancode is passing -1 to put
23:27:50evan:/
23:27:53evanit's code you just added I think.
23:28:22evandid you just add
23:28:30evanit "raises an Rubinius::ObjectBoundsExceededError when index is less than zero" do
23:28:37evanin core/tuple/shared/put.rb
23:28:38evan?
23:29:36brixenerm, no that's been there
23:29:47evanok, then we had a latent bug
23:29:52evanbecause we were using a size_t there
23:30:01evanso it was setting some far off memory
23:30:10evancould be the source of some of those random crashes we've seen.
23:30:19evani'm going to shore up tuple right now
23:30:29evanwith object_bounds and asserts.
23:30:54brixenok
23:30:56evanoh oh
23:30:57evanno
23:30:59evanit wasn't a latent bug
23:31:15evanthe -1 would turn into a giant positive size_t
23:31:25evanwhich would fail the num_fields() <= idx comparison
23:31:31evanand raise the exception
23:31:35evanok
23:31:46evanso all these places that we changed size_t to native_int
23:31:55evanwe need to also add code to check for negative values
23:32:13brixenyeah
23:33:32brixenok, now I have a real assert failure
23:33:46brixenArray::Iterator::at
23:38:23evanbrixen: i'm making the code a little less forgiving
23:38:28evanand closer to what i talked about before
23:38:36evanie, more C++ exception isolation
23:39:51brixenhmm ok
23:41:52evanyou'll see
23:41:54evanit's not a big change.
23:42:17brixenthat's cool
23:42:28brixenare you just going to push it to native_int br?
23:42:35evanyep
23:42:37brixenk
23:42:38evanyou can merge it back then.
23:42:48brixenok
23:50:00brixenhmm, this is a challenging issue
23:50:09brixenideally, we would not have redundant bounds checks
23:50:24brixenbut Array typically returns nil for out-of-bounds access
23:50:47evanyeah, i know
23:50:48brixenbut if we rely on users of Tuple to do bounds checks, Tuple is vulnerable
23:50:56evani'm refactoring out the part that is core
23:51:03brixenbut if we do bounds checks before calling Tuple, we duplicate it
23:51:06evanand wrapping it multiple places with the different bounds checks
23:51:35brixenso, Array::Iterator blindly dispatched and expects Tuple to raise
23:51:45brixenbut I don't think raising is the best idea
23:51:59brixenI think Array::Iterator should perhaps have Array behavior
23:52:05brixenie, nil for OOB access
23:52:50brixenideally, all of Array would be in Ruby and the JIT would handle removing duplicate checks :)
23:53:25evanyeah
23:53:29evanevenutally it will handle that
23:53:42brixenso what do you think for Array::Iterator?
23:53:42evanbetter to have more checks than not enough
23:53:44evanas we just saw.
23:53:58brixenshould it return nil or depend on Tuple to raise?
23:54:11evanwell, where are we using Array::Iterator?
23:54:37brixena bunch of places in Array
23:55:00evanwell, if it's there
23:55:03evanit needs to be checking.
23:55:10evaneven if they are redundent
23:55:45brixenhmm, yeah, but I'm wondering whether to return nil or raise
23:55:52evanah.
23:56:10evanmmm
23:56:22evanreturn nil seems more consistent
23:56:25evansince Array does that
23:56:34evanTuple cases bounds errors
23:56:35brixenyeah
23:56:40evantuple raises, rather.
23:56:51brixenI think I was thinking it was more implementation level, so it should fail harder
23:57:24evanup to you.
23:57:31brixenbut I think the bounds errors apply more clearly to a very low level structure like Tuple
23:57:53evanperformance wise, Array::Iterator is already a bit slower than accessing the underlying tuple directly
23:58:07evanso if we're worried about performance there, we should take a critical eye to Array::Iterator usage.
23:58:19brixenwell, perhaps we should remove it then
23:58:25brixensince the jit is performing so well
23:58:34evanok
23:58:37evani'd be fine with that.
23:58:42evani've removed it in a few places.
23:58:42brixenthe jit should handle any while loops pretty well these days, right?
23:58:52evanyeah
23:58:56brixenk
23:59:05brixenthis predates the jit being on by default
23:59:05evanwe don't need another abstraction for tuple to sit behind
23:59:07evanArray does that.
23:59:15brixenI'd rather put more pressure on the jit
23:59:32evanwell, do you think Array::Iterator is faster in the interpreter than not using it?
23:59:35brixenie, if we get slow reports that involve looping, we are better situated to handle that now
23:59:42brixenyeah, it was faster