Index

Show enters and exits. Hide enters and exits.

00:07:09postmodernhey your tests for Socket#getnameinfo are wrong
00:07:19postmodernthat returns the first name associated with localhost
00:07:26postmodernfor those of us who name our computers
00:44:25boyscoutAdd timed locking and lock interruption - 34979d1 - Evan Phoenix (hydra)
00:44:26boyscoutnil out @owner, then unlock - df2b000 - Evan Phoenix (hydra)
00:44:26boyscoutCatch exceptions inside the background thread - f765501 - Evan Phoenix (hydra)
00:44:26boyscoutPass down the thread's state. Fixes thread alloc corruption bug. - d474224 - Evan Phoenix (hydra)
00:44:26boyscoutChange call protocol to remove Dispatch&. Make IC thread-safe. - 45a2de9 - Evan Phoenix (hydra)
05:20:49brixenwoot! thread safe ICs
05:21:15brixenopens xmas presents
05:42:57evanbrixen: you make it to carlsbad?
05:43:55brixenescondido, but yes :)
05:44:03brixengot in about an hour ago
05:44:15brixenfreeway land is so so crazy
05:44:24evanwelcome to my hood! :)
05:44:31brixenI took 5 to 210 to (via some crazy shit) 15
05:44:36brixenheh
05:44:52brixenand you're going to be in my hood this weekend, crazy :)
05:45:08evanhehe
05:45:11evanyep!
05:45:20evanyou think i'll need to rent a car?
05:45:29evani told ya where the wedding is, right?
05:45:35brixenahh hm, yeah I think you probably will want to
05:45:47evanok
05:45:52brixenyeah, there is pretty good bus access to that area
05:46:02brixenbut I don't think you want to take the bus in wedding duds :)
05:46:03evanit's hot right? maybe i'll splurg for a Ferrari
05:46:05evan:D
05:46:07brixenhah
05:46:11brixendo it! :)
05:46:36brixensupposed to be in the 70's this weekend
05:46:38tarcierihey uhh
05:46:49brixentarcieri: uhh hey
05:46:55evanlooks up how much it is
05:46:55tarcieridid you guys read Charlie's shit on Oracle v. Google?
05:47:01brixennot yet
05:47:10brixenI've been trying to relax
05:47:11tarcieriI'm curious if Rubinius is in violation of: Interpreting Functions Utilizing A Hybrid Of Virtual And Native Machine Instructions (6,910,205)
05:47:14tarcieri:(
05:47:17tarcierifucking software patents
05:47:25brixenfuck scoracle
05:48:13evantarcieri: yes.
05:48:16evanprobably.
05:48:28evanbut we copied strongtalk
05:48:33evanwhich is prior art.
05:48:36evanso fuck 'em.
05:48:38tarcierinice!
05:48:39tarcieriheh
05:49:19tarcieriit now makes sense to me why the .NET CLR doesn't have an interpreter
05:49:59tarcierihow the hell can you patent something that abstract though? jeezus
05:51:01brixendid someone patent the process of patenting?
05:51:02scooprdon't all the new javascript engines do basically the same as well?
05:51:07evanbrixen: yes
05:51:11tarcieriscoopr: V8 doesn't
05:51:16tarcieriscoopr: but yeah, a bunch of the other ones do
05:51:22evansomeone patenting using a patent as a 2nd party against someone else
05:52:13bakkdoorlol hopefully we're not getting software patents in the eu
05:52:25bakkdoorgood evening btw :P
05:52:33brixenhi bakkdoor
05:52:36tarcieriheh
05:52:41tarcieriyeah that's really weird with my company
05:52:45tarcierisince we're spread all over the world
05:52:46scooprI wonder if it's good business to software "us-excluding" :P
05:52:50tarcieria bunch of patents only apply in the US
05:52:51bakkdoorhi brixen :)
05:52:51scoopr+do
05:53:08tarcieriscoopr: a ton of patents on the stuff we do just disappears when you're not dealing with the US market
05:53:49bakkdoortrue.. although there was a court case recently in germany that kind of made software patents legal.. we'll see how that progresses..
05:54:37tarcierioh yeah, here's my personal "most ridiculous usage of git ever": http://github.com/tarcieri/resque/commit/2e66384b750d6923c673cab0f57e9b88424cd6a7
05:54:50tarcieridefunkt requested a patch, and I'm like "hey it's github, might as well use it"
05:57:01bakkdoorhaha nice :P
05:57:38tarcieriit's pretty badass the json gem is now portable
05:57:43bakkdoorwhich reminds me to get back to working on fancy again once i'm back in germany. haven't had time to work on it for the whole time i've been here really
05:57:47bakkdoorsounds good
05:58:01tarcieritook a lot of bitching on my part :)
05:58:15bakkdoor^^
05:59:19tarcierievan: do you have a whole point of "irreducible complexity" when it comes to inlining?
05:59:27tarcieriI only have the vaguest idea of how that works on HotSpot
06:00:05evanyou mean when trying to determine what to inline?
06:00:21tarcieriwell, more like when to inline, I guess
06:00:34evanwell, when to inline is a fucking guess
06:00:36evaneveryone guesses.
06:00:37tarcieriheh
06:00:52bakkdoorguesses are cool
06:01:02evanno one has figured out a cheap algorithm for determining an optimal when
06:01:22evanwhat to inline optimal is irreducible pretty much
06:01:28tarcieriyeah, HotSpot apparently has some threshhold of code complexity at which point it's like "fuck that, I can't help you, sorry"
06:01:38evanyou have to build a massive lattice of values and even then, it's a trade off.
06:02:13bakkdoorit probably is undecidable within a decent timeframe.. stochasticly determining it probably is the best way to go
06:02:24evanwell, hotspot gives up if a method gets too big
06:02:32tarcierievan: yeah that's what I'm talking about
06:02:53evanthere is no specific reason to do that other than giant methods hang up the compiler thread
06:03:08evanthey could still use cheap inline decisions
06:04:15tarcieriwouldn't inlining naturally result in big complex methods?
06:04:29evanit inflates them, yes.
06:04:35evanbut you can govern that
06:04:37evani do.
06:04:52evanfar from perfectly, but you can.
06:05:16tarcieriI really have no idea what you're doing but it sounds pretty exciting :)
06:05:54evani'm just guessing.
06:06:08evaneveryone i've talked to about dynamic compilers makes it up.
06:06:10evanmetric wise.
06:06:27evan"umm, how about 5123 runs until compiled" "sure, why not."
06:06:54tarcierihehe
06:08:50evani need to do more stats work on that number and figuring out what methods to inline
06:09:01evanatm, i just inline like crazy until the budget is exhausted.
06:10:01evanfinding out what other runtimes do is... hard.
06:10:11evanthat logic is buried deep deep.
06:21:25tarcieriheh
06:21:32tarcieriyeah sounds like voodoo
07:01:24dbussinkmorning
07:02:09dbussinkevan: if you're interested, this is a backtrace with current hydra i have now: https://gist.github.com/46e4061f474ccc27d49e
07:14:12postmodernman brixen wasn't joking
07:14:22postmodernthe rubinius jit is *fast*
07:18:01dbussinkpostmodern: of course it is :)
07:18:10postmoderndbussink, and how
07:18:15dbussinkpostmodern: what are you running?
07:18:29postmoderndbussink, i double checked the numbers to make sure it wasn't just startup time
07:18:38postmoderndbussink, first gen amd64
07:18:41postmoderndbussink, most laptops are faster than my desktop now
07:18:53dbussinkpostmodern: i mean what ruby code :)
07:19:00postmoderndbussink, also mri 1.9.2, rubinius head, python 2.6
07:19:08postmoderndbussink, just fib code under time
07:19:22dbussinkah, the infamous fib benchmark :P
07:19:32dbussinktotally useless but fun to show ;)
07:19:34postmodernyep tail-recursion benchs
07:19:43postmodernwell recursion took to the extreme
07:20:18postmoderni wonder how LLVM handles algebraic optimizations?
07:20:29postmodernlike expanding x ** 2 to x * x
07:21:00postmodernor using shl shr instead of x * 2 or x / 2
07:28:27dbussinkpostmodern: dunno how llvm does those exactly
07:28:35dbussinkpostmodern: but those aren't what makes something like fib fast
07:28:58postmoderndbussink, but it helps for number heavy apps
07:29:12postmoderndbussink, since pow's and multi's can add up
07:29:26dbussinkpostmodern: true, but the effects are usually relatively minimal
07:29:26postmoderndbussink, for things like imagine processing or crypto
07:29:38dbussinkyeah, there it can help
07:29:39postmoderndbussink, ha idk
07:29:44postmodernyeah
07:29:57postmoderndbussink, that' the algorithm taken to the extreme
07:30:09postmoderndbussink, much like fib, it has a certain property that is maxed out
07:31:04postmoderndbussink, also most of what makes Java smoking fast in number crunching demos are tons of backhanded tricks
07:31:29postmoderndbussink, that and all the money thrown at it
07:34:06postmoderndbussink, hmm not looking good for i ** 2 in Rubinius
07:34:23postmoderndbussink, mri 1.9.2-rc2 finished around 1min
07:34:31postmoderndbussink, rbx i had to stop after 5min
07:34:42dbussinkpostmodern: well, first of all, i ** 2 doesn't mean i * i in ruby perse
07:34:55postmoderndbussink, it doesn't but it's equivalent for Integers
07:34:56dbussinkbecause the ** method can do something totally different
07:35:06postmoderndbussink, unless it's not overrided
07:35:07dbussinktrue, but people can overwrite that for integers
07:35:15postmodernbut if they dont
07:35:22postmodernbonus points in the performance department
07:35:28postmodernalso why is MRI faster?
07:35:35dbussinkbut you have to check whether it's the dispatching that is most overhead or the actual implementation of **
07:35:42postmoderni consider this a longterm performance issue?
07:36:06dbussinkwell, i haven't seen ** come up in any performance profile, so it's not an issue
07:36:19postmoderndbussink, puts (1..100_000_000).inject { |sum,i| sum + i ** 2 }
07:36:26dbussinkso if you have real code that depends on this performance, please generate some benchmarks
07:36:39dbussinkpostmodern: well, we have a bunch benchmarks in there already
07:36:49dbussinkpostmodern: you can run those and see if you can optimize them if you want
07:36:56postmoderndbussink, and how long will i have to wait for it to be fixed, so my real code can be fast? :)
07:37:03dbussinkthere are other things way more important things than that
07:37:09postmodernok
07:37:14dbussinkmost likely until you fix it yourself ;)
07:37:23postmodernso any ** related code in Rubinius *will* be much slower than mri
07:37:27postmodernduely noted
07:37:33dbussinkmost likely not
07:37:41dbussinksince nothing does so much ** that it will be noticed
07:37:43postmoderndo not use rubinius for power related computations
07:38:01dbussinkit being a tad slower, but that is by far overwhelmed by other code being run
07:38:22dbussinkwe can make ** faster, or perhaps we can make method dispatch faster
07:38:23postmoderndbussink, unless all your doing is number crunching
07:38:31postmoderndbussink, than Rubinius is a horrible choice
07:38:57postmoderndbussink, let me try dispatching a simple method call and comparing times
07:38:57dbussinkpostmodern: depends on what kind of number crunching
07:39:11postmoderndbussink, number crunching involving complex operators of course
07:39:27dbussinkbecause a lot of stuff like +, -, * and / is faster
07:39:45postmodernit is
07:39:45dbussinkpostmodern: if you depend on number crunching performance like that, you usually don't use ruby at all
07:39:47postmoderner
07:39:58postmodernwell shl and shr will always be faster than * 2 or / 2
07:40:08postmoderndbussink, that's defeatist thinking sir
07:40:09dbussinkbut some statically typed language that always will be faster
07:40:18postmoderndbussink, since MRI *is* faster in this case
07:40:20dbussinkpostmodern: that's realistic thinking :)
07:40:42dbussinkmaybe mri has some peephole optimizations?
07:40:47dbussinkdid you check that?
07:40:53postmodernprobably maybe
07:40:56postmoderni didn't
07:41:02postmodernim just illuminating this issue
07:41:17postmoderngiving feedback almost
07:41:22dbussinkwell, the problem is that there are probably thousands of these issues :)
07:41:23postmodernabout Rubinius's VM/JIT
07:41:43postmodernok i changed the benchmark to i * i
07:41:44dbussinkwell, this is why benchmarking is really really hard
07:41:56postmodernand it shaved off 20s
07:41:56dbussinkbecause people will jump to generic conclusions
07:42:05postmodernso your probably right in method dispatch overhead
07:42:30postmodernbut still, if MRI could save 20s, rubinius could also
07:43:01postmodernalso these optimizations are pretty old tricks
07:43:14dbussinkwell, nothing is stopping you from trying to add them :)
07:43:26postmodernwell first i have to finish my time-machine
07:43:31dbussinkpostmodern: the point is that there are way more important things to improve right now :)
07:43:32postmodernso i can add extra hours to my work day
07:43:45postmodernonce that's done, i'll get those patches submitted and documented ASAP
07:43:53postmoderndbussink, indeed indeed
07:44:08postmoderndbussink, just pointing out some low hangs fruit
07:44:15postmodern*low hanging fruit
07:45:04dbussinkpostmodern: well, we all have limited resources too :)
07:45:13postmodernha
07:45:22postmoderndbussink, i'll share my time-machine with you when i complete it
07:45:22dbussinkfor example string performance is way more important atm
07:45:30dbussinkbecause that affects way more real life code out there
07:45:39postmodernoh double-word (no-pun) to string performance
07:45:45postmodernhow is Array perf too?
07:45:55dbussinkso unless someone has a pressing need to improve **, other things will happen first
07:46:37dbussinkpostmodern: you can try to run the available benchmarks
07:46:45dbussinkpostmodern: there are a bunch for various objects
07:46:48dbussinkclasses
07:46:53postmoderncool
16:21:57evanmorning
16:22:18evandbussink: i really don't like "00:38 postmodern: dbussink, than Rubinius is a horrible choice"
16:22:21evan:(
16:29:35brixenmorning
16:32:21evanhello sir!
17:16:19dbussinkevan: yeah, well, i try not to get too fussed up about stuff like that
17:19:42brixendbussink: well, his point was that rbx is slower on something and I don't think the response is "oh well, it's not used that much"
17:19:59brixenwe can just ask for code or benchmarks and see what we can do to make it faster
17:20:11dbussinkyeah, well, we already have those benchmarks
17:20:15brixenI fully expect to use rbx for "number crunching" code
17:20:37dbussinkjust tried to make clear that we can't jump on just any of such reports
17:20:59brixenwell, give us a report and we'll see if we can jump on it :)
17:21:21dbussinkwell, i think string in general can use some love ;)
17:21:33brixenETOOGENERAL
17:21:43dbussinkhehe
17:21:46brixenString has had lots of love
17:22:00evanneeds love is not a valid bug report.
17:22:10evandata talks.
17:22:23evan:)
17:22:25brixenneeding love in general is not a bug :)
17:22:30brixeneveryone needs love
17:22:48dbussinkgroup hug!
17:22:52brixenheh
17:23:04dbussinkevan: i have a hydra crash for you if you want data ;)
17:23:05evanskips around the meadow
17:23:10evani saw.
17:23:15evanit's sadly not useful
17:23:33evanbecause it's a crash inside LLVM
17:23:36evanso there is no place to start.
17:25:14dbussinkevan: ah, too bad
17:25:32dbussinkevan: because something else corrupted code then that llvm chokes on subsequently?
17:25:45evanhas to be
17:25:49evanLLVM itself can't crash.
17:26:04evanso if you see a crash inside it, thats not LLVMs fault.
17:26:15evanand because we use in fairly opaquely
17:26:23evantracking a crash from inside it isn't useful.
17:26:44dbussinkevan: and llvm itself should still run single threaded right? in the compiling thread?
17:27:02evanyeah, LLVM runs serially
17:27:05evanin it's own thread
17:27:08evanas it always has.
17:27:13evanno change there.
17:29:39dbussinkevan: ran clean through a ci run now though :)
17:29:47evanyeah, so there is a bug somewheres
17:29:47brixenwoot!
17:29:57dbussinkevan: going to try if compiling specs makes a difference
17:30:03dbussinkif it has to do that or now
17:30:04dbussinknot
17:30:06evanwe just have to coax it out in a way that lets us see it.
17:30:26evana crash inside LLVM typically means something used some memory that was freed
17:30:37evanie, we corrupted some of LLVMs memory
17:39:15dbussinkevan: haven't been able to get it to crash again now though
17:39:28evanwelcome to thread bugs.
17:39:44dbussinkyeah, always annoying
17:40:18dbussinkevan: i'm going to torture it with datamapper specs
17:40:31evanok
17:40:41dbussinksee if it buckles under that
17:47:08dbussinkevan: i should write some torture script that is doing nasty stuff in parallel threads :)
17:47:17evando it.
17:47:22evanthats how i've been finding stuff
17:47:28evanthe last round was doing
17:47:38evan100000.times { timeout(1) { 1 + 1 } }
17:47:46evanand fixing the bugs that that created.
17:47:56evans/created/exposed/
17:59:41ZoxcLLVM is totally bug free :]
18:02:22evanfor this experiment, it is.
18:03:11sbryantYou do not question the LLVM.
18:03:21sbryantYou do not taunt LLVM.
18:05:43dbussinkevan: hmm, my torture tests seem to happily create threads and go along
18:06:04evan:D :D
18:06:39dbussink1.8's green threads are cheap though
18:07:02dbussinklooking at the performance
18:08:09dbussinkbut rbx seems way faster on this thread creation than 1.9 for me
18:11:38evannice!
18:11:53evanwe'll probably eventually have to add some thread pooling
18:12:08evana small pool of 3 or 4 threads would probably be fine.
18:23:28dbussinkevan: to spin up threads fast you mean? by reusing them from a pool?
18:23:34dbussinkevan: jvm does stuff like this too right?
18:24:15dbussinkevan: 1.9 seems to crumble with large numbers of threads, rbx scales up linearly at least until creating 100000 threads :)
18:24:19evanyeah
18:24:28evanzoinks!
18:24:31evan100000!!!
18:26:34dbussinkevan: takes around 16 seconds
18:26:44dbussinkalso runs some bits of code :P
18:26:50dbussinki didn't want for 1.9 to finish
18:26:57evandid you collect the threads into an array?
18:27:02dbussinkevan: yeah
18:27:04evanor did you allow them to be GCd
18:27:05evank
18:27:09dbussinkevan: and joined on all them
18:27:29evanrbx wise, they'll run and exit themselves before others start
18:27:34evanso you'll get a window
18:27:39evanbecause of the concurrency
18:27:42evanwhere as with 1.9
18:27:54evanyou won't because the GIL prevents the windowing effect
18:28:13evanso with rbx you'll get maybe 50 threads running concurrently, but with 1.9 you'll get thousands and thousands
18:28:37blowmageevan: windowing effect?
18:29:12evanblowmage: when the threads are concurrent
18:29:27evanby the time the 51st thread is spun up, the 1st thread has already exited
18:29:29dbussinkevan: got a crash :)
18:29:44dbussinkevan: ah, ok, that makes sense yeah
18:29:49evanso the kernel will reuse resources from the 1st thread in the 51st thread
18:30:17evanthe more cores you have, the bigger the window
18:30:17dbussinkok, this was dumb
18:30:23evanhah
18:30:25dbussinkthread apply all bt
18:30:27evandid you swamp your machine?
18:30:28evanhaha
18:30:29evanoops.
18:30:30dbussinkin my gdb crash
18:31:32dbussinkevan: Assertion failed: (refill_slab((*i)->local_slab())), function collect_young, file vm/objectmemory.cpp, line 192
18:31:38dbussinki have 100 threads now
18:31:39evanfun.
18:31:49evanthats weird..
18:32:01evanline 192?
18:32:08evan:/
18:32:12evanthere is no assert there..
18:32:56dbussinkevan: this is the backtrace for the crash for the thread in which it occured: https://gist.github.com/5643629c407601f7f297
18:34:15dbussinkevan: ah, wait, sorry
18:34:45dbussinki think my build is a bit confused about master / hydra atm
18:34:48dbussinklet me recheck
18:34:53evank
18:35:11evanthats definitely something to verify.
18:35:40dbussinkmaybe this even crashes master
18:35:49evancould be.
18:41:29dbussinkevan: what's your idea on behavior of stuff like Array#<< when there's no gil?
18:42:15evanheadius and I have discussed that.
18:42:37evanbasically, it's not possible to make the core classes like String/Array thread safe and keep them at their current performance level
18:43:04evanso they can tolerate internal confusion, but they can't cause the VM to crash.
18:43:07dbussinkevan: this is same test under hydra: https://gist.github.com/1c08e79088ee558f1854
18:43:29evaninteresitng.
18:43:30dbussink1000 threads, so i can sample a few, but listing all is tricky :)
18:43:32evanok
18:43:39evani know what the issue is.
18:43:48evanyou need more slabs that the eden can provide
18:43:58evanmaster has the same issue.
18:44:08dbussinkah, exhausting eden actually
18:44:12dbussinkbecause of the number of threads
18:44:15evanyep.
18:44:26evanbecause each thread wants at least one slab
18:44:39dbussinkyeah
18:44:48evanwhat we should do it just set the slab size to 0
18:45:02evanso that all allocations in that thread are slower, but capable.
18:45:06evanfeel free to make that change.
18:45:11evanrather than the assert, do
18:45:16dbussinkevan: you mean if it can't allocate a slab?
18:45:32evanif(addr) { slab.refill(addr, slab_size_); } else { slab.refill(0, 0); }
18:45:51evanright, if there are no slabs to have
18:45:59evanrefill the local slab with a size of 0
18:46:03evanso that using it always fails
18:46:05evanat runtime
18:46:28evanand goes out to the normal ObjectMemory allocations
18:47:51dbussinkevan: what does the objects_allocated += slab.allocations(); do there?
18:48:09evanso, each slab tracks how many times it was used
18:48:10dbussinkdoes that need to happen in that case too?
18:48:20evanthat should happen no matter what, yeah.
18:48:33evanbasically, we keep metrics on allocations now
18:48:41evanand to keep that metric thread safe
18:48:45evanthe slab tracks it's own allocations
18:48:58evanand all slabs allocations are added to the global total each GC
18:49:21dbussinkevan: ah ok, makes sense then yeah
18:49:30dbussinkand this gets the allocations before the slab was refilled
18:50:26evanyes.
18:50:34evanrefill resets allocations to 0
18:50:41dbussinki assumed as much :)
18:52:02dbussinkevan: do appreciate explaining stuff like this :)
18:52:11evanno problem!
18:52:24dbussinkmakes total sense now, but don't have that high level picture you have in your head that makes it easy to pinpoint stuff :)
18:52:28evanfeel free to add a comment in there that reflects what i told ya also.
18:52:38dbussinkyeah, already did add some :)
18:53:19evank :)
18:54:59dbussinkevan: onto the next one!
18:55:14evandid ya push it?
18:55:24dbussinkevan: https://gist.github.com/051776023f0c0e445ce5
18:55:25dbussinkevan: not yet
18:55:50evank
18:58:45boyscoutFallback to ObjectMemory allocation if a slab can't be allocated - ff3dedc - Dirkjan Bussink (hydra)
19:03:03dbussinkevan: any idea what could cause that one?
19:03:40evanlooks like perhaps the global list of threads is getting corrupted
19:03:56evango through everywhere it's used and make sure they're all syncronized
19:04:26evanyou don't need to worry about synchronizing reading it in the GC btw
19:05:12dbussinkevan: the gc is locked yeah
19:05:18evanright
19:06:30dbussinkevan: hmm, stop_the_world runs already locked?
19:06:41evanin a way, yes.
19:06:50evanit's more complicated than a single lock.
19:07:16evanbecause it waits for all other threads to checkin before continuing
19:08:22dbussinkevan: could it be the agent?
19:08:58evanmm
19:09:00evani don't think so
19:09:05dbussinkit has GlobalLock::LockGuard uncommented
19:09:06evanunless you were using the agent
19:09:11dbussinkbut i'm not using the agent
19:09:14evanyeah, but you didn't have the agent on
19:09:18evanso it could'nt be the agent.
19:10:57dbussinkevan: because i can't find it used unlocked or outside gc anywhere else
19:11:39evanit being the list?
19:11:48dbussinkevan: the threads list yeah
19:11:52evanhm
19:11:58evanok, well, you'll have to dig around a little more.
19:13:00dbussinkevan: hmm, maybe SharedState itself?
19:13:07dbussinkthat it's refcounts are wrong?
19:13:56evan*shrug*
19:13:59evanthats for you to find out.
19:14:22dbussinki'll poke a bit in the dark then :p
19:14:36evanthats what I do
19:14:39evanif you can repro it easily
19:14:43evanthen try some different things
19:32:45boyscoutUse a channel to coordinate Timeout better - e473723 - Evan Phoenix (hydra)
19:32:46boyscoutAdd the semaphore count optimization to Channel - 44ba8d1 - Evan Phoenix (hydra)
19:32:46boyscoutUse a dedicated place to store the interrupting exception - fd708d8 - Evan Phoenix (hydra)
20:04:05dbussinkevan: hmm, could it be related to joining on an already closed thread?
20:30:56dbussinkevan: still there?
21:19:36evanhey
21:19:43brixenyo
21:20:04brixennow we just need the rest of the sentence
21:25:32evanheh
23:22:03idlhey, what's this hydra branch all about? I'm intrigued
23:22:55idlthat topic is amazing
23:25:02brixenidl: it's a branch to work on removing the GIL
23:25:16idlah cool
23:25:22brixenyes :)
23:32:16evanbrixen: so, we setup the active_path of required files to be their expanded path
23:32:47evanrather than simple load_path_entry + subpath
23:32:52evanis there a reason for that?
23:34:05evanerm, maybe not... hm...
23:37:31brixenactive_path should be what require was given iirc
23:37:44evanyeah, i'm investigating
23:40:39evanoh i see!
23:40:42evandoing -Ilib
23:40:53evanis putting File.expand_path(part) into $:
23:41:21evanand it's not suppose to expand it
23:41:36evanwhich is dumb, because if you chdir, that lib is something else then
23:41:38evan*eyeroll*
23:48:43brixenyes, that's a quite crazy situation