Index

Show enters and exits. Hide enters and exits.

02:17:47evanok, found a GC issue.
02:17:51evanthat dbussink pointed out.
02:18:08evangotta figure out how to fix it now.
02:18:39slavaevan!
02:18:44evansenior slava.
02:18:47slavado you plan on adding callcc to rbx?
02:18:52evanin the bits
02:19:01evan(thats like in the flesh, but for IRC)
02:19:07evanyeah, i do.
02:19:17slavaby copying stacks, or something else?
02:19:20evanusing pretty much the same technique you use
02:19:25evanhoist the stack to the heap
02:19:37slavaI guess callcc isn't used all that much in ruby code
02:19:42evanwith some metadata to be able to walk it properly
02:19:49evannope, it's not used at all.
02:20:31slavaalso, what's with the architecture block diagrams on the web site? :)
02:20:40evanyou know you want one
02:20:47evani can get you good price on one.
02:20:54evani gotta friend.
02:22:25evanhows NZ?
02:22:34evanstill just hanging out or did you get a job?
02:22:36slavaso you'll need a way to walk the callstack and identify frames?
02:22:45slavahow will this work for interpreter/native frames?
02:23:37evanthey're the same currently
02:23:43evanso easily.
02:23:50evanas for the callstack
02:24:01evanevery stack has a CallFrame* linked list thats laced on it
02:24:13evanthe list points to addresses within the stack
02:24:17slavaright
02:24:21evanso when you copy the stack to the heap
02:24:30evanyou know what the start and destination addresses were
02:24:46evanso you can walk it like normal, just adjusting pointers
02:25:02slavaand when you copy it back, you know its going to start at the same base offset?
02:25:28evanyeah, i'd restrict restore a continuation to the same thread that created it
02:25:32evanrestoring, rather.
02:25:40slavaah
02:25:40evanand therefore the same base stack address
02:25:52evancould probably work it out restore on any thread
02:26:06evanbut for a first cut, no cross threading
02:26:07slavasuppose you have the following call stack:
02:26:11evani think MRI already doesn't allow that
02:26:19slavaJITted method -> C++ code in VM -> JITted method
02:26:30slavaand the C++ code has a GC root in its stack frame
02:26:40slavahow will you trace that after the continuation was captured into the heap
02:26:41evanthen it's registered elsewhere
02:26:53evani don't support (nor will I) stack roots in unmanaged frames
02:27:09evanthat C++ code would have to have used OnStack<>
02:27:21evanwhich registers the stack locations into a thread local list
02:27:47evanand that list would have to be made aware of potential pointer adjustments
02:27:52slavaok
02:27:53evanwhich isn't too bad.
02:28:41slavain factor, VM frames can never mix with JITted frames
02:28:52evani almost never do
02:29:00slavathe VM frames are always at the top, if there are any
02:29:01evanit's extremely restricted.
02:29:03evanand hard to do
02:29:06evanon purpose.
02:29:15slavaand continuations are only captured directly from JITted code
02:29:23slavaso VM frames never end up in a callstack object in the heap
02:29:25evanyep
02:29:36evanthats pretty much the same setup we have
02:29:39slavaso I control the layout of every frame in a continuation directly
02:30:06slavaalso there are no pointers between stack frames, instead every stack frame stores a length in bytes
02:30:16slavaso there's no fixup to do if a continuation isrestored at a different base address
02:30:24slavathis can happen if you capture a continuation, save the image, start a new session, and restore it
02:30:48evanah, gotcha.
02:31:40evanslava: you gc immediately when you detect that you're out of memory, yes?
02:36:25slavaevan: when the heap is full, yeah. remember I have one big heap where everything lives
02:36:44evanyep yep
02:36:51evani just mean
02:36:54evando you have a red zone
02:37:00evanwhere you then set a flag to say "gc soon!"
02:37:07evanor is it "HOLY SHIT NO SPACE GC NOW!!"
02:37:14slavathe latter
02:37:21slavaGC doesn't allocate while its GCing, so it works out OK
02:37:35evanright
02:37:44evanmeans that all allocation points are safe points
02:37:53slavayeah
02:38:15slavaI used to have a 'red zone' thingy before I had the data_root<> stuff worked out; VM primitives couldn't run GC at arbiary points because of on-stack roots
02:39:05evanso what is a VM prim does an allocation in the middle of some code
02:39:07evanand there is no space
02:40:05slavathen it runs GC before allocating
02:40:20evanso if it does 2 allocations
02:40:21slavasince that's safe now, all references to objects from local vars in C++ Code are wrapped in data_root<>
02:40:26evanit has to be sure to stack the first in a data_root<>
02:40:29evaner.
02:40:32evans/stack/stash/
02:40:32slavayes
02:40:46slavaotherwise it might lose the first one
02:40:55evanyep
02:41:27slavathis leads to hard to track down bugs if I forget to data_root<> something
02:41:43evanyeah, course.
02:42:55slavaof course if a GC doesn't free up enough memory for the new allocation, it grows the heap
02:43:36evando you still use that longjmp to grow the heap?
02:44:02slavayeah, GC can fail half-way through like that
02:44:11slavasuppose its doing a minor collection, copying form nursery to aging
02:44:15slavaand aging fills up before it sdone
02:44:21slavathen it aborts and starts doing an aging GC
02:44:53evanright
02:45:35slavayour tenured space is 'infinite' because you just malloc more memory whe nyou need to, right?
02:46:06evanyeah
02:46:26evanthough i've been thinking about the one big-ass-flat-memory-space more and more lately
02:46:47slavathere's a serious disadvantage to that on 32-bit systems
02:46:58slavawhile you're growing the heap, both the old and new heaps are in your addr space at the same time
02:47:12slavawhich means your maximum heap size is limited
02:47:20ruehttp://blog.llvm.org/2010/01/x86-disassembler.html
02:47:36slavaevan: one approach I want to try is to allocate a big-ass heap on startup, as large as possible
02:47:39evanslava: right, meaning if you want a 2G+ heap
02:47:48slavaevan: but only use the part up to an allocation pointer
02:47:50evanslava: yeah, thats what i'm thinking
02:47:54slavaevan: then growing the heap means bumping that pointer
02:47:59evanfigure out how to play some mmap/VirtualAlloc tricks
02:48:01slavawhich commits more pages to memory as they get written to
02:48:05evanto get a huge chunk
02:48:10evanbut with uncommited pages
02:48:14slavayeah
02:48:27evanperhaps i'll do some experiments with that tonight
02:48:34slavathe only platform I'm aware of where this won't work is Windows CE
02:48:35evanthe biggy with that is the ability to uncommit pages
02:48:36slavano overcommit
02:48:51slavawhat makes you lean towards a flat heap now?
02:49:10evanit could simpify some things
02:49:18evanwould simplify write barriers too.
02:49:26slavathinking of card marking then?
02:49:30evanyeah
02:49:36slavacool
02:49:38evanwith everything in one address range
02:49:40evanmight as well
02:52:53slavaso if you have one huge heap that's allocated on startup, you'd uncommit pages past the end after a compaction, right?
02:53:12evanwell, when you start up
02:53:17evanyou get one big range, say, 1G
02:53:21slavayeah
02:53:25evanstarting at 0x1000
02:53:34evanit's all uncommited though
02:53:47evanso you'd probably say "ok, i want 15% for young, etc"
02:54:03evanso you'd probably put the young objects at the front
02:54:17evanand then leave room between the end of the young objects and the start of the old
02:54:24evanso you can inflate young if you need to
02:54:33evanby just writing into the uncommited pages
02:54:40slavaI never resize young dynamically, since I'm not sure what a good heuristic is
02:54:51evansure
02:54:53evanthats an option too
02:55:00slavaone downside of the 1GB heap thing is that you might cause problems for people who want to mmap large files
02:55:35evanright
02:55:38evanit's got downsides for sure
02:56:29slavaalso you can't delay GC until the heap is full obviously; you'd have a high water mark
02:56:47evanright
02:56:52evanok, we'll have to suspend this
02:56:56evani want to continue it though
02:56:59evanit's dinner time.
02:57:02slavaenjoy
03:40:15rueLooks like rubini.us has propagated
04:25:38wayneeseguinevan: oh hell yeah : http://rvm.beginrescueend.com/benchmarks/2010-01-06/
04:25:48wayneeseguinlol so much for PM
04:25:52wayneeseguinrue: ^
04:26:47wayneeseguinbrixen: ^
04:33:24mistergibsoncongratulations, that is impressive
04:41:21wayneeseguinIt's not a complete benchmark suite yet but we'll definitely get there soon
08:03:47dbussinkevan: still some time spec failures for me, because i'm in a different tz
08:04:00evanoh hm.
08:04:01evanok
08:04:05dbussinkTime.mktime(1900, 12, 31, 23, 59, 59, 0) => Mon Dec 31 23:59:59 +0019 1900 on mri
08:04:09evandbussink: found your GC bug.
08:04:17evanspend most of the afternoon poking around
08:04:19dbussinkbut Time.mktime(1900, 12, 31, 23, 59, 59, 0) => Tue Jan 01 00:19:31 +0100 1901 on rbx
08:04:37dbussinkevan: ah ok, the sleep leak one or the one i saw probably when running datamapper specs?
08:04:44evansleep
08:05:08dbussinkah ok
08:05:13dbussinktricky issue?
08:05:47evancompletely unrelated to sleep
08:05:48evanactually
08:05:50evanand Channel
08:06:22dbussinkah ok, a generic issue?
08:06:29evanand everything else that uses the immix GC.
08:06:39evanimmix GC was not reusing space properly
08:06:45dbussinkah! looks like i uncovered something then ;)
08:06:49evanvery much so
08:06:56evanChannel's are allocated mature
08:07:00evanso they really hammered it
08:07:04evanand so we saw it.
08:09:05dbussinkdeliberately allocated as mature then
08:09:06dbussink?
08:09:40evanwell, it just causes a big load on the GC
08:09:49evanand caused it to get confused about what it could and could not reuse
08:11:54slavayo evan
08:12:09evanhi hi
08:12:27dbussinkevan: i wonder whether the fix would have any effect on those other issues i saw, but i'll test that right after the fix then :)
08:12:40evanyeah, unknown
08:12:42evanwe'll see.
08:36:01evandbussink: ok, pretty sure i've got it sorted
08:36:07evanbut it's at a really low level
08:36:14dbussinkevan: w00t :)
08:36:14evani need to go over it again in the morning before committing it
08:36:26dbussinkevan: ah, too bad, would be nice to test with it today a bit
08:36:28evanor I could easily swamp everyones machines
08:37:04evanhttp://gist.github.com/271089
08:37:05evango for it.
08:37:06evanlet me know.
08:37:13dbussinkok, cool :)
08:37:31evannite
08:38:27dbussinknite1
09:15:39dbussinkevan: tested your patch a bit, but it still grows on: https://gist.github.com/50589ee37e77207c9589
13:23:14boyscoutUpdated specs for Enumerator#each_with_index. - 6e2d329 - Mikko Perttunen
13:23:14boyscoutFix Enumerator#each_with_index. - c7c8ddf - Mikko Perttunen
13:26:34boyscoutCI: rubinius: c7c8ddf successful: 3022 files, 11696 examples, 35896 expectations, 0 failures, 0 errors
13:42:12rueHm. Interesting results
13:44:56ruedbussink: That is pretty pathological :P
16:54:06evandbussink: does it stabalize?
16:54:11evanthat code you have there was my test case here
16:54:16evanit flattens out
17:15:14brixenmorning
17:17:43evanallo
17:34:17wayneeseguinello!
17:34:24evanmorning mr. wayne.
17:36:04wayneeseguinG'marnin evan!
17:36:36brixenwayneeseguin: you hear from monty? I thought you could help him get set up with some scripts to make charts and such
17:36:50wayneeseguinbrixen: Monty from MagLev?
17:37:16brixenyeah
17:37:47wayneeseguinHe is supposed to call me today about getting MagLev running under rvm :)
17:42:52brixenwayneeseguin: ok cool
17:52:04cyndisdo i need to commit new specs to rubyspec + rubinius or is rubinius enough?
17:54:57brixencyndis_: just commit to rubinius if you are working on rubinius
17:55:08cyndisok, good
18:35:11brixenI thought 1.9 was going to not dispatch to private methods via #send
18:35:23brixendid I imagine that or did they retract it?
18:35:32evanwho the fuck knows.
18:35:37brixenexactly
18:35:38brixen:-/
18:35:43wayneeseguinI heard that as well however that doesn't mean anything ;)
18:35:45evanthey were then going to add a funcall method that would
18:35:47evanor something
18:35:58brixenok
18:36:16brixenwell, in 1.9.2 head, you can still send to private methods
18:36:56Zoxc__send__?
18:37:13evanperhaps they reverted it.
18:37:14brixenthis is an issue for the Kernel methods that exist as both "functions" (ie private methods) and module functions on Kernel
18:37:23brixenan issue for the specs rather
18:37:49brixenanyway, I have a method that works
18:37:54brixenI was just curious
18:54:08rueIt was retracted.
18:55:17brixenrue: oh, is there a thread on that?
18:58:13rueThink it was discussed on -core, post hoc at least
18:59:40rueBut currently and in the forseeable future, the #funcall thing was scuttled
18:59:51rue(And the alternative #send!)
18:59:53brixenit just boggles my mind that path canonicalization for $LOADED_FEATURES was not done till 1.9
19:00:02brixenand that it wasn't backported to 1.8.7
19:00:22brixenrue: ok, thanks
19:01:51evanwell, this immix bug has exposed a whole failed set of logic.
19:01:58evannow how to fix it...
19:02:14brixenwhat's the failed logic+
19:02:14brixener ?
19:03:32rueIf true == false
19:05:46evanha
19:05:48evanno not that bad.
19:05:54evanthere are 2 questions a GC has to answer
19:05:59evan1) when do I collect?
19:06:04evan2) when should I expand?
19:06:06evani guess 3
19:06:10evan3) when should I contract?
19:06:50evanour immix GC is flawed because right now the logic looks like
19:06:59evanif just_expanded; collect_soon; end
19:07:06evananyone see the problem there?
19:08:07brixenjust_expanded == allocated more chunks?
19:08:12evancorrect.
19:08:20brixencollect_soon == ?
19:08:34evanrun the GC at the next safe point
19:08:42brixenwill it run right away then?
19:08:46evanno.
19:08:52evanthe GC never runs right away
19:08:56brixenbut very soon I mean
19:09:02evanvery soon, yes.
19:09:26brixenhm
19:09:51brixenbut it just expanded, so it's got some space
19:09:56brixenI dunno, what's it doing
19:10:12evanif you're always waiting to collect til right after you expand your bounds
19:10:19evanthen you only collect when you don't need to
19:10:28evanand so the memory grows unbounded
19:10:28brixenok that's what I was thinking
19:10:32brixengotcha
19:10:44evanbecause the point of collection is to avoid expansion
19:11:07evanbasically, whats happening right now is that the logic is causing immix to expand until it reaches some max size for the set
19:11:17evanand then it's not collecting.
19:11:21evananyway, it's busted.
19:11:39evani've got some logic now that does
19:11:43brixenyeah, I see the problem
19:11:50evanif low_on_memory; collect_soon; end
19:12:03evanto try and avoid an expansion
19:12:05Defilerif just_collected && low_on_memry; expand?
19:12:09brixenyeah, seems you need to checks
19:12:12evanbut now i'm hitting a pathalogical case
19:12:17evanwhere it spins collecting
19:12:18brixenone when allocating and one after collection
19:12:25evanand should probably expand
19:12:25brixens/to/two/
19:12:38brixenyeah
19:12:49evanDefiler: yeah, i'm adding some extra logic after a collection to see how much space is available
19:12:56evanand there is less than, say, 10%
19:12:58evani'll expand.
19:13:03evansee what that does.
19:13:53brixenI'm almost full, collect soon; I'm still full, unbuckle the belt one
19:14:26evanheh
19:14:30brixenbut what happens if soon doesn't come before it's full to the brim?
19:14:36evanyeah, move to the next notch
19:14:43evanand hope we don't run out of notches!
19:14:46brixenheh
19:15:18brixenso you have a high water mark on collection but is there a OOM that suspends everything and collects immediately?
19:15:23brixenor you just expand in that case?
19:15:39brixenOOM == out of memory "exception"
19:15:53brixener high water mark on allocation
19:15:54brixendammit
19:16:38evanno
19:16:54evanthere isn't an "OH NO NO MORE MEMORY" condition
19:17:04evanthere is just a series of fallbacks
19:17:20evanthe last one being going straight to malloc() in the large object array
19:17:21evanarea
19:17:23evanif that fails
19:17:27evanthen i should probably abort();
19:17:43brixenok
19:18:00brixenright, forgot about the LO space
19:18:07Zoxcshouldn't it throw an exception before that? :/
19:18:17evanto who?
19:18:21brixenheh
19:18:22evana ruby one?
19:18:25Zoxcyeah
19:18:26evanyou're out of memory
19:18:40evanhow are you going to come back from that?
19:19:17Zoxcexit propertly, don't do anything, free some memory?
19:19:32brixenabort() is a proper exit, malloc() just failed
19:19:49brixenand you have no more room to run
19:20:16Zoxcabort doesn't sound like a proper exit, it sounds like a forced exit :/
19:20:45evani'd argue there is no proper exit on an OOM condition.
19:20:55evanpretty much no program handles it in a proper way.
19:21:03evanMRI just abort()s
19:22:05brixenyou could conceivably reserve some memory to try to clean things up, but that could launch you right back into OOM condition
19:22:12brixenabort() is totally reasonable
19:22:49brixenreserve could just postpone OOM actually, not prevent it
19:24:12brixenI think there's a ulrich drepper redhat paper on memory that discusses OOM strategies
19:24:29Zoxcyou could end up with a chain of NoMemoryError terminating the application, but atleast it's attemting to terminate propertly
19:25:38evani'm going to spend my time trying to avoid OOM conditions
19:25:52brixengood plan
19:28:16Zoxcthat doesn't work when you're actually out of memory though :/
19:28:16dbussinkevan: i saw you said it stabilized for you, for me it's at almost 900 mb now and still growing
19:28:37evanit's at that now?
19:28:41evanso it's growing slowly?
19:28:42dbussinkevan: yeah
19:28:46dbussinkgrowing slowly
19:28:50dbussinkwith your patch you gisted that is
19:28:54evanok
19:28:57evanbefore it was growing very fast
19:29:01evanso perhaps i didn't wait long enough.
19:29:02dbussinkyeah
19:29:20dbussinksometimes it looks that it stabilized for like 20 secs
19:29:24dbussinkand then starts growing further
19:30:53dbussinkevan: 1G now
19:31:00evankill it
19:31:02evanit's not useful.
19:31:10dbussinkhehe
19:31:20dbussinkbut it still grows then ;)
19:31:26evanle sigh
19:31:28evani'm working on it!
19:32:31dbussinkhehe, np, just read up on the architectural issue it has
19:32:34dbussinkwhich is pretty nasty
19:32:41dbussinkto have to rethink something like that
19:33:00DefilerThat's the whole fun part about working on a project like this
19:33:02evani'm open to ideas.
19:33:06DefilerDon't try to take it away from him! :)
19:33:08evani'm the only one that ever works on this code.
19:33:59brixen:(
19:34:08brixenI'll trade you these fucking require specs
19:34:27brixenI swear, everyone loses their commit bit if I ever see specs like this again
19:34:36brixenbut there is light at the end of the tunnel now
19:34:39DefilerIt seems to me that '(wired object size before collection - wired object size after collection) / size before collection' is the metric worth caring about
19:34:59DefilerLike.. GC success velocity
19:35:22Defilerand that as that approaches zero, your need to allocate more memory approaches 100%
19:35:23brixenwhat's a wired object?
19:35:33Defilerreachable object, sorry
19:35:40brixenoh heh
19:35:54Defilerbeen spending too long in activity monitor
19:36:01brixenheh
19:39:04DefilerSo, if you figured that number, and allocated more every time it was less than 0.1.. that seems like it would work
19:40:03DefilerIn other words, any time a collection cycle fails to get you at least 10% more free space
19:40:49evanright.
19:42:57dbussinkaren't there some papers that investigate this exact problem?
19:43:05evannot that i've found.
19:43:08dbussinkor is it something everyone tweaks a bit with for themselves
19:43:17evanthey almost all talk about how to collect
19:43:21evanbut not when to collect.
19:43:50Defilerif would_be_nice_to_have_more_space_for_what_comes_next then collect...
19:44:30evanif nearly_out_of_space; chillix(i.got_this); end
19:44:36evanif nearly_out_of_space; chillax(i.got_this); end
19:45:39Defilerchillix would be a better GC name though
19:45:50evanhah
19:45:52evanyes, it would.
19:46:36evani think i'm going to the grilled chese trunk for lunch today
19:46:36scooprcillitbang
19:46:37evanmmmm.
19:46:54BrianRice-workmmm grilled cheese grill
19:47:19evanwhat is this crazy-ness you ask? http://thegrilledcheesetruck.com/
19:47:41BrianRice-workhttp://www.grilledcheesegrill.com/
19:48:25evanoh yeah! well our trunk has cheese flames on the side!
19:48:27evanbeat that!
19:48:35evanyou heard me
19:48:37evanCHEESE FLAMES
19:48:49BrianRice-workheh
19:48:51evanoh man, it's only 5 blocks away.
19:50:15evanok, added a live_bytes_percentage to post collection
19:50:29evanand expanding when thats greater than 85
19:50:37evanseems to work
19:52:49evanthough i think there is another rubinius memory leak
19:53:07evanbecause by the end, there was 100M of immix data allocated
19:53:19evanbut AM said there was like 300M+ wired
19:53:43evanperhaps thats the VMMethod leak.
19:53:47dbussinkevan: that could be what i was seeing then
19:53:50evanwhich i want to try and fix today.
19:53:55evanprobably not
19:54:02evanunless you're creating methods in a loop :)
19:55:01dbussinknope, still the same example :)
19:56:02evandbussink: 10.6?
19:56:13dbussinkevan: yeah, 64 bit
19:56:15evank
20:01:39evanI should note: http://www.technovelty.org/code/arch/micro-analysis.html
20:01:44evanthat is very interesting
20:01:51evani might have to play with it inside vbox.
20:03:05brixenmm interesting
20:03:13evanit's the other GC time!
20:03:19evanGrilled Cheese!
20:03:45evanmy live_cheese_quotant is low! must refill!
20:04:43brixenheh
20:05:03brixenah there's a link to that drepper paper on this page
20:40:51dbussinkevan: do you think we should use ./configure to check for headers that are explicitly needed for building? like readline etc. ?
20:40:57wayneeseguinbrixen: I just got off the phone with Monty, I showed him the benchmark report
20:41:03wayneeseguinwe're going to get MagLev on it
20:44:01brixensweet
20:44:22brixendbussink: yeah
20:46:05evandbussink: no
20:46:08evanconfigure should not do that
20:46:12evanthe extension itself should
20:46:15dbussinkconflicting ideas!
20:46:22evanand it should just not build if what it wants aren't available
20:46:54evanadding cases to ./configure to detect things that the extensions need doesn't scale
20:46:58evanand it's confusing
20:47:15dbussinkisn't not building also pretty confusing?
20:47:20evannah.
20:47:25brixenevan: I thought we discussed adding a flag to configure to ignore missing readline etc
20:47:41evanwe talked about what to do
20:47:53evani recall us saying that an extension should detect and build
20:48:03brixenwell, autotool configure uses --with-blah etc
20:48:04evanat any rate, thats the direction i'd prefer we go.
20:48:11brixenI don't see why that doesn't scale
20:48:38brixenanyway whatever works
20:48:49brixenI'm not getting distracted from these specs
20:48:54evank
20:48:58evani'm open to either
20:48:59brixenbecause they are ruining my fucking year
20:48:59evanreally
20:49:29brixenI just need to finish them
20:49:31brixenno distractions
20:49:46brixenwhatever works with configure, etc, great
20:49:49evanyes please
20:49:55brixenthe ext building is still a horrid mess
20:49:56brixenle sight
20:49:59brixener -t
20:50:00brixenanyway
20:50:05brixenseeks caffeine
22:01:54evanok, i think this immix code is working fine
22:01:59evanand better than before
22:02:04evani don't see the pathalogical cases anymore.
22:02:35boyscoutAdd spec for method_missing + super behavior - 62524d0 - Evan Phoenix
22:02:35boyscoutFix method_missing + super behavior. Fixes #157. - 31ddb88 - Evan Phoenix
22:02:35boyscoutKludge around an immix memory increase boundary case - defd53a - Evan Phoenix
22:06:11boyscoutCI: rubinius: defd53a successful: 3022 files, 11697 examples, 35898 expectations, 0 failures, 0 errors
22:12:20evanwell thanks good.
22:13:52dbussinkevan: looks like stabilized at around 75mb here
22:14:00evanoh good.
22:14:04evani was hoping you'd say that.
22:14:11dbussinkhehe, i can imagine :)
22:18:23dbussinkevan: you're were going to check out the next leak?
22:18:33evanyeah, in VMMethod
22:18:35evani know what it is
22:18:49evani have to figure out how to rearchitect to get rid of it though.
22:58:39coredhi guys
22:58:44coredevan: are you around
22:58:46cored?
22:58:53evanyep
23:00:03coredi was reading your article about coerce
23:00:11evanah, yep.
23:00:48coredhttp://gist.github.com/271699
23:00:54coredthat was my try to solve the Float part
23:01:22coredis that right ?
23:01:37coredi don't think i understand very well what were you talking about
23:01:38evandoes it do what you think it should do?
23:01:51coredkinda
23:01:52cored:-P
23:01:56evanheh
23:02:11coredit's returning 10
23:02:24corednot 10.0 but it handle the Float
23:02:39evanyou coerced the Float to an int
23:02:49evanit coerce other.to_i is called.
23:04:19coredhm, so in that case it can be specific to Float switching the cast to to_f
23:04:32coredbut it won't handle the Integer case, unless i put another switch statement
23:06:30evanso put one
23:06:32evanno harm
23:09:26coredok
23:09:28coredthanks