Index

Show enters and exits. Hide enters and exits.

00:51:06rueBedtime, nite
01:40:00dgtizedbrixen: have you seen this stuff about non-blocking hash tables: http://blogs.azulsystems.com/cliff/2007/03/a_nonblocking_h.html
01:43:25brixenyes
01:47:33dgtizedk, just checking
05:47:22ddubkinda quiet tonight
05:50:55scooprg'morning
16:32:38yakischlobarue: ping
16:34:02yakischlobaor anyone, actually. this isn't really a rubinius question but i think someone in here might have insight
16:35:21manveruyakischloba: ffi? :)
16:36:33ddubgood morning, those for whom it is morning :)
16:36:35yakischlobaim using FFI and some external library functions are allocating memory. the MRI gc at least, seems unaware of this memory being allocated, and so does not take it into consideration when it decides whether or not to run GC. This is a problem because my only hook for freeing the memory is the finalizer, so im ending up with huge RAM consumption because GC doesn't think memory is being used up
16:36:54manveruddub: does 00:36 count as morning? :)
16:37:05ddubmanveru: just barely
16:37:25yakischlobaanyone run into this issue before?
16:37:56manveruthat sounds like quite a big issue...
16:38:16yakischlobayeah but i mean, how the hell do you deal with it heh
16:38:41yakischlobaI don't know if other GC's have awareness of other memory being allocated
16:38:53yakischlobai have no idea how its supposed to be handled
16:40:01manveruhmm
16:40:07dduba GC has no awareness of non-GC objects, normally
16:40:09manveruyakischloba: googling for 'ruby ffi gc' gives some stuff
16:42:32yakischlobahmm.
16:42:43ddubyakischloba: I'd look at MemoryPointer
16:42:56yakischlobaddub: What do you mean?
16:43:31ddubI would imagine that if there was a way to indicate that a pointer has a certain amount of memory associated with it for GC purposes, that would be the object it would be exposed on
16:43:48yakischlobaah ok. i'll check it out.
16:43:54ddubbut I kinda doubt it, I think your problem is one of zones
16:44:13ddubsay there is the young object zone, which has a copy collector, and the mature object zone which has mark and sweep
16:44:30ddubyou have another zone, which is the libc-managed zone
16:44:57ddubI don't believe there is any process which monitors say the sum of these three to make GC decisions
16:45:10yakischlobaI'm curious about this but I don't think it will even solve my problem. I need to figure out where exactly it's happening, but basically copying a bunch of string data into ruby is giving me crazy performance decrease
16:46:03yakischlobaHas anyone used FFI for operations like this, where a lot of string data is getting moved into Ruby?
16:46:03ddubhmm
16:46:17ddubnot i
16:52:09rueyakischloba: You should not rely on the finalizer
16:53:23yakischlobarue: yeah I am coming to this conclusion
16:53:59yakischlobaso then my problem is that I have to move all my string data into ruby when I instantiate the object, and then free the memory
16:54:14yakischlobabut copying it all seems to take a long time ;(
16:54:23rueYes, it would be the simplest starting point
16:55:10rueOther than that, you can possibly arrange a [un]register option for the FFI-backed data as a more explicit finalizer
16:59:08rueHow much data do you have, anyway? And Strings?
16:59:21yakischlobadatabase query results
17:01:08rueDo you have a defined scope in which they (or part thereof at least) live?
17:01:22yakischlobahttp://pastie.org/private/l2yb2emwuvkojb0s7ac3w that is what i am doing
17:01:35yakischlobabut it is slow for large query result
17:01:45yakischlobadefined scope meaning what?
17:02:28yakischlobathey're buffered into memory allocated by the library and then it doesnt mess with it anymore, i believe
17:03:08rueHow long do you need the data for?
17:03:38yakischlobawell, so i'm trying to make a typical database adapter. someone should be able to use it manually, through an ORM, etc
17:04:25rueSo you have to convert it to Ruby form at some point anyway, right?
17:04:31yakischlobacorrect
17:08:00yakischlobaIs there a faster way to do what I am doing in the pastie?
17:08:44rueDo it lazily
17:09:28yakischlobabut I have to free the underlying buffer in the constructor
17:09:42yakischlobabecause I can't rely on the finalizer
17:12:14yakischlobano good solution to this, is there :/
17:12:31rueIf you have a big chunk of memory
17:15:50yakischlobaIf I have a big chunk of memory, what? :0
17:15:54yakischloba;)
17:18:00rueIf you have one big chunk of memory, you may need to release it all at once. If you have multiple small ones, then no
17:19:54yakischlobawhat are you saying? lazily free each row region or something?
17:20:07yakischlobaif the user doesn't use the result, then im screwed again
17:22:14yakischlobait will suck if I am only able to produce a really slow thing with FFI :(
17:24:06rueWhat about something as simple as a block form?
17:24:39yakischlobaconnection.query do |result| which frees at the end?
17:25:14yakischlobamakes sense. just still the slowness remains if the data set is slightly large
17:28:49rueCombine that with laziness
17:29:04yakischlobaright
17:29:27yakischlobabest thing to do I guess
17:31:00yakischlobatis a shame it cannot be more performant. a pure ruby library would almost be faster
17:33:35rueIt is not the ideal use case
17:34:09yakischlobayeah.
17:34:11rueIt is not possible to specify that you are getting strings?
17:34:45yakischlobawhat do you mean?
18:02:09evanmorning
18:03:28brixenmorning
18:03:36rueMoomin
18:04:13evanyakischloba: you still around?
18:04:57yakischlobaevan: yo.
18:05:15evanyakischloba: how are you allocating a bunch of memory?
18:05:31yakischlobaevan: with the library i am using via ffi
18:05:39evanso the library allocates the memory
18:05:42yakischlobayes
18:05:51evanand how is that memory supposed to be freed?
18:05:56yakischlobaalso through the library
18:05:57evanis there another function to call to free it?
18:06:02evanso thats all you need to be doing
18:06:02yakischlobayes
18:06:33yakischlobayeah, i know
18:06:45evanbut your problem is "when do I free it"?
18:06:50yakischlobathat issue is resolved, i guess
18:06:51yakischlobawell
18:07:19yakischlobafirst I was wrapping those pointers with AutoPointer and using a finalizer to free it, but that turns out to not work well
18:07:31evanno
18:07:32evanit won't.
18:07:39evanbecause finalizers suck.
18:07:41evanin general.
18:07:49yakischlobaso I have to somehow free it when I know my user is done with it
18:08:02yakischlobaso thats fine, i can work around that
18:08:10yakischlobathe only issue now really is that its slow to copy so much string data into ruby ;(
18:08:14evanyou require them to use it in a block
18:08:20evanand free the memory when the block ends
18:08:21yakischlobayeah
18:08:36evanhow much string data?
18:08:39evanand how are you copying it?
18:08:58yakischlobathis is an example of how I am getting it: http://pastie.org/private/l2yb2emwuvkojb0s7ac3w
18:09:21yakischlobathat is prior to the discussion of this lazy-copy block yielding thingy idea
18:09:24evanthat means nothing to me
18:09:29evanbecause I can't see where the FFI calls are
18:09:37evanso i can't make heads or tails of this code
18:09:47yakischlobarowptr[i].get_string(0)
18:09:52yakischlobaget_string, thats how im getting the strings into ruby
18:09:54evanis row a FFI Pointer?
18:10:10yakischlobarowptr is, yes
18:10:40yakischlobaits a database client lib, so the amount of data is variable, but could be huge
18:10:40rueyakischloba: I meant that if you can indicate to FFI that the data you are getting is Strings, it should do the conversion
18:10:43rueI thinks
18:11:03evanit should be converting it
18:11:11evan.get_string returns a string.
18:11:22evanyakischloba: well, yeah
18:11:23yakischlobauh, yeah.
18:11:27evansadly, this is how FFI has to work
18:11:35evanyou have to copy the data out to persist it.
18:11:42evanbecause it's unmanaged
18:12:01yakischlobaright. so lazy #get_string'ing is the best possible way to do it
18:12:14evanprobably, yes.
18:12:23evanhow slow is it?
18:12:30evanmaybe there is a bug in .get_string
18:17:20rueCan you specify [:string] rather than :pointer or something?
18:18:03yakischlobayeah, but I don't think that has anything to do with it. not sure I could make it work either
18:19:28yakischlobait isnt *that* slow
18:19:37evanthen stop complaining! :D
18:19:50yakischlobahah. just looking for ideas mang ;)
18:19:55evani know.
18:20:06evanyeah, this is just an artifact of FFI
18:20:34evani take it using the finalizer blew up the memory footprint of your process?
18:21:05yakischlobawell, the finalizer itself didn't seem to be the problem. the GC just wasn't aware of the memory allocated by the library, so it didn't think it needed to run
18:21:25yakischlobaso even the ruby objects wrapping the pointers weren't getting GC'd
18:21:45evanwell
18:21:49evanthats not completely true
18:22:14evanwhat happens, in this case, is that because the GC can't see those external allocations
18:22:20evanit doesn't realize memory is running low
18:22:23evanso it doesn't run the GC
18:22:30evanMRI has a little bit of code to handle this case
18:22:45yakischlobaoh? it didn't seem to be working very well this morning :p
18:22:45evanbut it's just that when malloc() is called, if it fails, run the GC
18:22:50yakischlobaoh.
18:22:58evanbasically
18:23:04yakischlobauseless heh
18:23:06evanif you make 10 ruby objects that each point to 100M of memory
18:23:15evanMRI's GC only sees the 10 objcts
18:23:25evanit doesn't take the 100M into account for if the GC should run.
18:23:27rueCan force-request a GC run, of course
18:23:36evanrubinius has an internal API to advise the GC on this
18:23:55rueProvided that the orphaned FFI objects would release their memory when collected
18:24:08evanrue: right, thats the trick
18:24:10yakischlobaevan: that's nice
18:24:17evanif the user throws a ref to that ruby object somewher
18:24:19rueMemoryPointer can be prescribed as the "owner" of its pointee, right?
18:24:20evaneek!
18:24:23evan100M in the bucket!
18:24:29evanyeah
18:24:35evanthats basically the AutoPointer thing
18:24:38evanthat the MRI API added
18:24:41evanwhich I need to port over
18:25:18evanAutoPointer says "I'm the owner of this pointer, and it should be free()d when I'm GCd"
18:29:35yakischlobayeah.
18:49:42yakischlobaevan: as an extremely unscientific comparison
18:50:02yakischlobawell, nevermind. its that silly heh.
18:50:57evanhah
18:51:00evanwell played.
18:51:16yakischlobafor fun im just comparing my thing against the libmysqlclient MRI extension
18:51:29evanthats probably very unfair
18:51:36evansince they do completely different things
18:51:38evandon't they?
18:51:46yakischlobawhat does different things
18:52:03evanis your FFI library a mysql client?
18:52:41yakischlobait uses libdrizzle, which is based on libmysqlclient, and speaks mysql protocol (and has better performance in and of itself than libmysqlclient)
18:53:13yakischlobaso it's doing the same thing: running a mysql query
18:53:52evanok
18:54:00yakischlobarunning it 1000 times, my thing takes 25 seconds and the MRI ext takes 10 seconds
18:54:01evanperhaps that is a fair comparison
18:54:10evanwell, use a profiler
18:54:15evanand see where your 25 seconds is going
18:54:18evandon't assume it's FFI
18:54:29yakischlobaheh. I have been trying to. (and im not, necessarily)
18:55:04yakischlobaI'm trying to use the google perftools profiler. I guess I'll have to build ffi against it, as well as libdrizzle, huh
18:55:28evani mean a ruby profiler.
18:55:47yakischlobaOh. I am not familiar with ruby profilers
18:55:48evanlike rubyprof
18:55:55evansince you're writing in ruby
18:56:00evanyou should be using a ruby profiler
18:57:27evanyakischloba: are you new to ruby?
18:57:31yakischlobaevan: no.
18:57:35yakischlobaevan: i learned on ruby.
18:57:52yakischlobabut i guess 'new' is a loose term :p
18:57:57evantime to learn to use a ruby profiler then.
18:58:11evanyou pretty much can't say anything about ruby performance unless you use a ruby profiler
18:58:46yakischlobaok. i am trying it now.
18:58:47rueMm, but would a Ruby profiler in any way distinguish time in the lib?
18:59:13yakischlobayeah i duno. I just figured in this case, there is very little ruby code, so at best it can help me narrow down where in the C the time is being spent.
18:59:38evanrue: no, but it would tell you whether or not you should consider the lib
18:59:43evanit's a process of elimination
19:00:13evanrubyprof should be able to show you calls into the FFI layers though
19:00:22evanwhich will tell you if FFI is the thing taking the most time
19:00:32yakischlobaindeed. I am running it now.
19:00:37brixenours reports time in ffi and capi calls, but our ffi may not support that code
19:04:31rueevan: Yeah, although I am not sure how well it groks the stubs
19:04:58rueEither way, definitely a good idea. I just assumed that you were seeing something definitely from the FFI side :)
19:07:56evanrue: probably not at all (grok the stubs)
19:08:08evanmight be neat if it did though!
19:08:46Arjenevan, brixen, I was curious if guys have a (rough) date in mind for a 1.0 release? Couldn't resist asking, sorry. :)
19:09:07evanwe don't.
19:09:17evansometime in 2009
19:09:37brixenArjen_: did you see the roadmap?
19:09:44Arjenbrixen, yep!
19:09:49brixenok cool
19:10:15brixenthat gives at least some idea of what we're driving at
19:10:22brixenArjen_: help us fix bugs :)
19:11:27ArjenI know, I know. Can't be of much use though (trust me).
19:12:04brixenheh
19:45:31yakischlobaah, back from lunch. this is my output from ruby-prof here http://pastie.org/private/dgyfkwu2rxt3cjgrsqjla
19:45:57yakischlobawhic i dont really know how to interpret. is %self a percentage of total run time?
19:47:57evanruby-prof has a weird output format
19:48:06yakischlobayeah.
19:48:57evani'd assume self% is "the ammount of time the program spent running this method, but not it's children"
19:49:09evanso, i'm assuming you benchmarked with 1000.times or something
19:49:13yakischlobayes
19:49:15evanand you didn't run enough iterations
19:49:23evanbecause the looping itself was the highest cost
19:49:45yakischlobai did not run enough iterations...so i should...5000.times?
19:50:07evanmore
19:50:09evanprobably lots lots
19:50:14yakischlobaheh
19:50:18evanyou should get it to last at least 10 seconds
19:50:22evanbefore it outputs anything
19:50:41yakischlobawith the profiler, that took almost 5 minutes
19:50:50yakischlobaTotal: 293.370000 <- isn't that seconds?
19:50:51evan:/
19:50:54evani dunno
19:50:57evanit doesn't say.
19:50:59yakischlobaand without it, it takes only 25 seconds
19:51:04yakischlobawell
19:51:08yakischlobai *know* it took almost 5 minutes
19:51:17yakischlobai sat there waiting for it :)
19:51:25evanwithout what?
19:51:31yakischlobawithout the profiler
19:53:15yakischlobaI don't understand how that could possibly be the case, that it's taking the most time, unless my ruby build has a broken Integer#times
19:54:10evanit is odd.
19:54:17evanwell, rerun it
19:54:20evanand use a while loop
19:54:24evaninstead of #times
19:54:24yakischlobak.
20:01:29yakischlobaevan: Ah. That call to #times that its seeing is inside my code, not the loop iterator.
20:04:24evanah.
20:04:25yakischlobaevan: since it gets called for every row of a result.
20:04:36evanyes, thats the problem with MRIs profiler support
20:04:46evanit reports code in blocks incorrectly.
20:04:58evanit reports them as on the caller of the bolck
20:04:59evanblock
20:05:05evanrather than the definer of the block
20:06:39yakischlobayeah, i'm having trouble understanding what it is telling me heh.
20:07:53yakischlobaother than that the thing I spend the most time on is the thing I do the greatest number of times :)
20:16:12dgtizedevan: what do we need to do to hookup the Selector / SendSite profilers again?
20:16:59evannot sure
20:17:06evandidn't know they weren't hooked up.
20:20:33ruedbussink: Are you still seeing a segfault?
20:21:40dbussinkrue: haven't been any changes, have there?
20:21:53dbussinkso still seeing those segfaults yeah
20:24:23evanok
20:24:29evananyone that sees a segfault
20:24:34evanplease gather as much info as you can
20:24:40evanand open an issue on github
20:24:42evanso we don't loose them
20:24:59evanI didn't know people were seeing segfaults
20:27:16rueI do not seem to be getting them anymore.
20:28:03dbussinkevan: this is with llvm and jit enabled though
20:31:37dbussinkevan: is there an easy way to do a ci spec run in gdb?
20:31:58brixengdb --args vm/vm mspec/bin/mspec-ci
20:33:29dbussinkhttp://gist.github.com/115032
20:34:35brixenevan fixed that at some point
20:34:49brixeniirc, that symbol is in llvm too
20:35:02dbussinkbrixen: this is against latest svn head
20:35:38brixenok, well, lunch for me, bbiab..
20:36:06dbussinkfrom llvm that is, something that a rake clean would miss?
20:38:28dgtizedevan: it just looks like SendSites::ALL and Selectors::ALL aren't getting filled with any entries
20:39:36dgtizedor wait, maybe it's something else, just a sec
20:41:25ruedbussink: Could conceivably need distclean if it is LLVM code itself
20:44:10dgtizedevan: nm it's not that it's not filling the ::ALL variable, it's just that SendSite.hits and .misses is never getting larger then 10 somehow
20:47:07evanhm
20:47:22dgtizedbecause .hits and .misses is always 0
20:47:47evanoh
20:47:50evanwell, thats easy.
20:47:59dbussinkrue: trying with a complete new llvm checkout and distclean rubinius, see whether it still fails
20:48:02evanit's just not being used atm I guess.
20:48:11evandbussink: whats the segfault you're seeing?
20:48:21dbussinkevan: http://gist.github.com/115032
20:48:39evannot sure why that would be LLVM related at all
20:48:49evanare you saying you compiled with RBX_LLVM=1
20:48:50evan?
20:48:55dbussinkevan: me neither, but it wasn't failing before
20:48:57dbussinkevan: yeah
20:49:17evanoh
20:49:18evani recall.
20:49:30evanyes, this should be fixed already.
20:49:43evandbussink: are you compiling against SVN HEAD?
20:49:59evanoh oh
20:50:00evani know
20:50:03evanyou need to do a distlean
20:50:03dbussinkevan: yeah
20:50:04evandistclean
20:50:11evanbecause I changed the name of that symbol
20:50:19dbussinkevan: doing it atm, let's the see whether it fails after that
20:50:20evanof s2b_D2A
20:50:23dbussinkrebuilding llvm atm
20:50:32evanit should be fine then
20:50:36evanthat was a really weird error.
20:50:40evanit's a symbol conflict
20:50:59dbussinkbetween rbx and llvm?
20:52:54evanbetween the custom strtof we use
20:52:56evanand llvm
20:54:58dgtizedevan: we only increment hits/misses in mono_performer and mono_mm_performer, should we be incrementing them in SendSite::fill or find_method?
20:58:24evanno
20:58:28dgtizedor I guess more importantly why aren't we using mono_performer and mono_mm_performer?
20:58:32evani've half reworked that
20:58:36dgtizedk
20:58:37evanand need to work on it more
20:58:42evanto make hit/misses work again
20:59:18dgtizedalright, I'll just wait on it then
21:00:40dgtizedhad hoped that was something I could work on, but that sounds like it's not low hanging fruit
21:12:38ddubwaves
21:13:22ddubI really would like to work on making a more maintainable compiler
21:13:32dbussinkevan: hmm, weird, with everything clean, the first time running RBX_LLVM=1 rake fails with the __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS error
21:13:42dbussinkthe second time i run rake after that it, it does continue
21:13:45ddubbut I fear that at most I would be able to make one incrementally better due to execution speed requirements
21:13:58seydarddub: the ruby -> bytecode compiler, you mean?
21:20:41dbussinkevan: http://gist.github.com/115065
21:21:00ddubprobaby ruby -> sexy
21:21:07dbussinkevan: those are the different commands that are run the first compile and the second
21:21:14ddubwhere sexy should probably be written sexp, but thats how I pronounce it
21:22:30seydarddub: but isn't the ruby->bytecode compiler an all-in-one program?
21:24:21seydarddub: if you set up an hg/git repo, i'd be glad to help you out with it
21:30:40evandbussink: hm..
21:30:52dbussinkevan: no segfaults anymore though
21:30:52evandbussink: a bug in the rakefile i'm guessing.
21:31:39evanhuzzah!
21:31:52evanddub: what ideas do you have for improving on the compiler?
21:32:53seydarevan: if you could say hazzah to make it a palindrome... much appreciated
21:33:27evanhazzah!
21:33:49ruedbussink: Yeah, the macro fix is not defined for the configure phase or something, I did not look into it too far
21:34:37boyscoutFinish teaching the JIT about all the instructions - 9209540 - Evan Phoenix
21:39:56evanwow
21:40:06evani'm surprised how in sync using multiple spearsk in itunes is
21:41:38seydarddub: so how do you want to change the compiler?
21:45:14rueevan: Like, stereo?
21:45:26evanquadero
21:46:28boyscoutCI: 9209540 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors
21:47:15dbussinkevan: more errors when running an extconf.rb: http://gist.github.com/115081
21:50:02rue'Das a nil
21:52:10ruedbussink: What does this look like in frames 1/2?
21:52:50evanum.
21:53:19ruePresumably there is a bound_method_
21:53:19evanwhy is this nil...
21:53:30evanwell, this should not be nil.
21:54:25evandbussink: i need to know what you ran to get to that point
21:55:46dbussinkevan: any extconf.rb from binary extensions seems to be triggering it
21:55:51evandbussink: also
21:55:57evani need you to get a ruby backtrace
21:56:00dbussinktested with some DO gems, but also with for example ruby-pg
21:56:10evanto up to a frame with a CallFrame
21:56:11evanand run
21:56:17evanp call_frame->print_backtrace(state)
21:56:50evanand I need the whole gdb backtrace
21:56:55dbussinkevan: updated the gist: http://gist.github.com/115081
21:57:20evanprimarly
21:57:21seydarpeaces
21:57:32evanhow the fuck did a Proc get created without block_ set.
21:57:59evanBLAH
21:58:00evanfuck.
21:58:24evanrue: I guess i presume you meant there is ONLY a bound_method_
21:58:29evanwhich I didn't grok.
21:58:32evanok, one sec.
21:58:34rueYes, sorry
21:58:44rueWhich it probably should not have?
21:59:12ruebound_method_ is for Method only, right?
21:59:16evanyeah
21:59:20evanthis is Proc having to be overloaded
21:59:23evani did a refactoring of Proc
21:59:29evanand must have screwed this up
21:59:30evanone sec.
21:59:34evanit's just missing an extra check.
22:00:02evanhm.
22:00:12evani must have screwed up the merge....
22:00:18evanbecause I did fix this...
22:09:30dbussinkevan: am i being annoying? :P
22:09:35evannope
22:09:42evani'm annoyed I reintroduced this bug.
22:10:44evanok, incoming.
22:10:56boyscoutFix Method objects being used as blocks - e60c69b - Evan Phoenix
22:11:13evandbussink: please to use issues on GH though
22:11:20evanit's easier to track these longterm
22:11:28evanand I can close them via commit then.
22:11:37evanplease do use, rather.
22:11:38dbussinkevan: yeah, ok, will do next time
22:12:04dbussinkare these call_frame tricks etc. on the wiki too?
22:12:11dbussinkso people can use that when reporting bugs?
22:12:26evanwhat wiki?
22:12:32evanwe have a wiki?
22:12:39dbussinkLH pages probably
22:12:47dbussinkor is stuff moved to github wiki already?
22:12:58evanwe've never used the GH wiki
22:12:58brixenstuff is/should be in /doc in the repo
22:13:02evanas far as I know.
22:13:18brixenwe aren't going to use a wiki
22:14:40dbussinkok, well, main thing is that these debug tricks are very handy to have written down somewhere
22:15:29brixenwe should make rbt work from gdb again
22:15:40brixendbussink: /doc/debugging.txt
22:15:50brixenit's a bit dated, but you could update it
22:16:14dbussinkhow about doing something with catching a segfault and printing debugging instructions?
22:16:27dbussinkwould that be a useful tool or to hard to do properly?
22:16:39evanwell
22:16:39evanhm.
22:16:45evanwe could install a SIGSEGV handler
22:16:59evanto try and handle and display backtraces
22:17:00boyscoutCI: e60c69b success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors
22:17:58dbussinkevan: i think it would greatly help people on reporting bugs
22:19:05evanI can add one
22:19:12evanbut it will fail sometimes
22:19:25evani'll go ahead and do it.
22:19:46evanhm.. how to get the most recent CallFrame though...
22:34:10dbussinkbrixen: still doing capi function requests? :P
22:39:38brixendbussink: sure
22:39:58dbussinkbrixen: rb_exc_raise seems to be missing (throws the passed exception)
22:40:25brixenk
22:40:40brixenwhat ext are you testing?
22:41:56evani still need to do those things that EM is missing
22:41:58evanso we can run thin
22:42:17macournoyeryeaaaaaaaah!
22:42:26evan:D
22:42:30macournoyernice work!
22:42:31dbussinkbrixen: trying to get a somewhat a sane exception hierarchy for DO
22:42:38dbussinkinstead of just one type of exceptions :)
22:42:40slavahi evan
22:42:49evandbussink: any functions you are missing
22:42:54evanthrow them in GH issues
22:43:07dbussinkevan: hehe, yeah, i get it :P
22:43:07evansince we can easily close them with commits
22:43:14evan:D
22:43:19evani just don't want to forget!
22:43:27evanmy dynamic memory sucks.
22:43:49macournoyermove it to the mature generation
22:44:13evanfate dealt me a highly reliable static mapping memory
22:44:15evanbut thats about it.
22:44:35evanthe layout of every home/school/mall i've been to?
22:44:36evancheck, got that.
22:44:41dbussinkmade one, specially for you :)
22:44:51evanmy wife's phone number though?
22:44:52evannope.
22:44:53evannot in there.
22:44:54evansadly.
22:45:01evandbussink: yay!
22:45:03dbussinkevan: ah, yeah, the i'm there for the first time and know the way back exactly?
22:45:03macournoyerhaha
22:45:16evandbussink: yep
22:45:24evani can navigate directly to the pretzel stand!
22:45:31evanor the bathrooms
22:45:38evanor the principals office
22:46:27dbussinkthey redid a lot in my old high school, so i would probably be lost anyway now
22:47:47evanduring my 10 year reunion
22:47:53evani wandered around my high school illegally
22:48:00evanit was pretty much how I left it
22:48:44dbussinkthey rebuilt a whole bunch of stuff in the two years after i've left, so a lot changed, felt a bit weird actually
22:48:54evani'll bet.
22:50:14evanok, i need to get some fresh air
22:50:20evanthen on to getting more of the JIT wired up.
23:28:56tarcierithis thread on Pythonic indentation is cracking me up
23:29:33slavahi tarcieri
23:29:36tarcierisup
23:30:46tarcieripeople just don't get why sticking pythonic indent blocks in expressions is... very hard
23:31:38tarcieriit took me quite awhile to understand too
23:31:40tarcieriI guess
23:36:02evantarcieri: i hear you're giving a talk on reia?
23:47:01tarcierievan: I gave one at Erlang Factory... giving another one tonight for the local Ruby group
23:47:16evanyep, i saw chad's tweet.
23:47:26tarcieriorly
23:47:27tarcieriheh
23:47:34evantoo bad it's not taped
23:47:36tarciericrazy
23:47:36evani'd love to hear it.
23:47:57tarcierithe Erlang Factory one will be online soon, hopefully
23:48:06tarcierivideo, that is
23:48:16evancool
23:48:37tarcieriheh, haven't seen Chad Fowler at our Ruby group here in like... years
23:49:07evanhis tweet made it sound that way, yeah :D
23:50:17tarcieriit was crazy when like... we had Chad Fowler and Ara Howard attending regularly
23:50:56evanara doesn't go anymore?
23:51:02evani haven't seen him in a while
23:51:17tarcieriactually he presented at the last one
23:51:28tarcieribut he has some scheduling conflict normally I guess
23:51:37evanah
23:54:36slavatarcieri: are there any projects using reia yet?
23:56:11tarcierislava: Ryan... a web framework