Show enters and exits. Hide enters and exits.
| 00:07:59 | evan | quiet today |
| 00:08:04 | evan | that too longer than I expected. |
| 00:10:00 | ujihisa | quiet -> less CO2 consumption -> ECO! |
| 00:10:57 | brixen | heh, the quiet of no netsplits is deafening |
| 00:14:42 | evan | hah |
| 00:14:54 | evan | i'm working on the answers to 2 questions |
| 00:15:04 | evan | 1) how do you detect when to JIT a method. |
| 00:15:22 | evan | 2) what happens to the values used to detect JITing when you actually go to JIT |
| 00:15:36 | evan | meaning, if you use a call counter to determine when to JIT |
| 00:15:36 | brixen | interesting |
| 00:15:40 | evan | whan happens to the call counter when you go to JIT |
| 00:15:55 | brixen | I'm also working on 2 questions |
| 00:15:56 | evan | this is complicated because we inline methods. |
| 00:16:23 | brixen | hmm |
| 00:16:37 | brixen | the call counter is on the IC though, right? |
| 00:16:56 | evan | no |
| 00:17:04 | evan | there is counters there |
| 00:17:12 | evan | but they don't influence when to JIT at all. |
| 00:18:19 | brixen | I thought they trigger a search for a method to start jitting |
| 00:18:26 | brixen | what does trigger it then? |
| 00:18:37 | evan | a call counter on the method itself. |
| 00:18:48 | evan | when the interpreter enters a method, in ticks the counter. |
| 00:18:49 | brixen | oh ok |
| 00:18:52 | evan | s/in/it/ |
| 00:19:22 | brixen | well that's hella confusing potentially |
| 00:19:31 | evan | how? |
| 00:19:38 | evan | thats how it's always worked. |
| 00:19:41 | brixen | since there's one call counter and multiple places the method could be inlined? |
| 00:19:53 | evan | now you're getting into the real questions. |
| 00:19:55 | brixen | or is this what you are working on |
| 00:19:58 | brixen | oh ok |
| 00:20:08 | evan | when a counter overflows |
| 00:20:16 | evan | we consider the call stack to figure out what to actually JIT |
| 00:20:25 | evan | so we don't actually JIT the method that overflowed. |
| 00:20:29 | evan | because we wanna inline. |
| 00:20:36 | brixen | right |
| 00:21:04 | brixen | is it possible to begin inlining and never reach the method that triggered the search? |
| 00:21:22 | brixen | because of code size or something? |
| 00:21:35 | brixen | what is the max inline depth budget now? |
| 00:22:24 | evan | depends. |
| 00:22:45 | evan | checkout vm/llvm/inline_policy.hpp |
| 00:23:47 | brixen | hm |
| 00:24:41 | evan | you can see there are different policys |
| 00:24:45 | evan | based now on original size. |
| 00:24:53 | brixen | yeah |
| 00:25:01 | evan | those are largely just made up |
| 00:25:04 | evan | fyi. |
| 00:25:05 | evan | :D |
| 00:25:17 | brixen | heh |
| 00:25:40 | brixen | yes, a hankering for 10*N*(2^3+2) |
| 00:25:52 | evan | pretty much. |
| 00:26:13 | brixen | er another factor of 2 in there |
| 00:26:18 | brixen | anyway |
| 00:28:49 | evan | as you can see |
| 00:28:59 | evan | this policy class governs whether or not to inline a method. |
| 00:31:43 | brixen | yes |
| 00:39:08 | BrianRice-work | interesting |
| 00:40:48 | slava | hi BrianRice-work |
| 00:42:12 | BrianRice-work | howdy |
| 01:09:23 | evan | slava: hows NZ? |
| 01:09:37 | evan | slava: you still going to be working on factor? |
| 03:00:35 | slava | evan: I'm at a coffee shop, working on it right now in fact :) |
| 03:00:40 | slava | evan: NZ is really nice. auckland is one of my favorite cities |
| 05:33:17 | Defiler | Hrm, I'm having trouble with rbt in gdb |
| 05:33:47 | Defiler | printbt takes a CallFrame argument now it looks like? |
| 05:44:40 | brixen | Defiler: that's broken |
| 05:44:53 | brixen | you need to fr to an interpreter frame and do p call_frame->print_backtrace(state) |
| 06:17:50 | brixen | the #require specs should undeniably be cast in bronze as a warning to all that pass by |
| 06:17:58 | brixen | pass by what, I don't know |
| 06:18:13 | brixen | a scene from some horrid horror flick |
| 06:19:16 | brixen | I cannot fathom what inspired this code |
| 06:58:57 | rue | It would be nice to improve |
| 16:08:58 | rue | evan: The date tag in the rc1 download; should it be considered a filesystem artifact or part of the version? |
| 16:57:09 | evan | rue: thats part of the file. |
| 16:57:21 | evan | it's not an artifact, and not part of the version. |
| 16:57:25 | lopex | evan: probably obvious for you: http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programmi ng_GCAP_09.pdf |
| 16:57:45 | lopex | c++/cache misses |
| 16:58:00 | evan | it was requested that the tarballs included in the filename |
| 16:58:25 | rue | The date in the file name? |
| 16:58:53 | evan | yep. |
| 16:58:55 | rue | Dun really matter to me either way, just fixing up rvm. |
| 17:15:19 | evan | lopex: quite interesting. |
| 17:16:13 | lopex | evan: enebo said click said this is major limiter in perf |
| 17:17:28 | Defiler | Does 'rp' in gdb not work on Modules? |
| 17:17:36 | evan | lopex: makes sense. |
| 17:17:39 | evan | Defiler: it should. |
| 17:17:41 | Defiler | I get results like "-4467297868000003004" when I try sometimes |
| 17:17:50 | Defiler | $3 = (class rubinius::Module *) 0x8401f083fffff889 |
| 17:17:54 | Defiler | results in that when I rp it |
| 17:18:18 | evan | huh? |
| 17:18:27 | evan | that looks like p, not rp. |
| 17:18:28 | enebo | That talk was about advances in hardware architectures and optimizing compilers is pretty much limited by cache misses now...how previously things like branch predition and the like have been useful but wont get much better |
| 17:19:11 | Defiler | http://gist.github.com/259623 |
| 17:19:22 | Defiler | Oh, whoops.. time for some lunch. sorry; don't mean to gist and run :) |
| 17:19:34 | Defiler | It's probably something I am mangling on those objects |
| 17:19:43 | evan | enebo: we need better tools for diagnosing cache misses |
| 17:19:47 | evan | thats the limiting factor |
| 17:19:56 | evan | i wanna reduce them |
| 17:20:00 | evan | but SEEING them is quite hard. |
| 17:20:37 | lopex | gcc ... -O10 -show-cache-misses |
| 17:21:03 | lopex | and -print-pretty-diagram |
| 17:21:32 | lopex | and (fancy-colors) sub option |
| 17:22:28 | evan | i'd just love someone to explain to me how to use Shark to see them. |
| 17:22:41 | evan | it might be in there |
| 17:22:51 | evan | but I just don't know what to look for. |
| 17:31:17 | wayneeseguin | evan: I *know* I've asked this particular one before and hence I am being daft, however... http://pastie.org/private/ibcxcoqkq0n8duydeg5kva |
| 17:31:57 | evan | um |
| 17:32:15 | wayneeseguin | is it something to do with the -S ? |
| 17:32:23 | evan | no, gem doesn't need -S |
| 17:32:27 | evan | it's entirely unrelated to that |
| 17:32:29 | evan | you got a syntax error. |
| 17:32:38 | evan | why is a shell script being run as ruby code? |
| 17:32:40 | evan | thats your problem. |
| 17:32:47 | wayneeseguin | ok without -s |
| 17:32:47 | wayneeseguin | http://pastie.org/private/vayczdy8akywqzhfxlhw |
| 17:33:28 | evan | yes, the -S is fucking it up |
| 17:33:32 | evan | because it's finding a gem command |
| 17:33:36 | evan | thats a shell script. |
| 17:33:49 | evan | why the 2nd one fails, i dunno. |
| 17:33:54 | evan | i'd have to look into that. |
| 17:34:13 | wayneeseguin | ahh ok |
| 17:34:18 | wayneeseguin | the shell gem command does the |
| 17:34:29 | wayneeseguin | excec "rbx" "$@" trick |
| 17:34:36 | wayneeseguin | IIRC |
| 17:34:51 | wayneeseguin | after setting up environment like GEM_PATH |
| 17:34:52 | wayneeseguin | and GEM_HOME |
| 18:27:35 | rue | evan: Philosophy: in 1.0.0-rc1, is the entire string the version, or can "rc1" be considered comparable to a patchlevel? |
| 18:28:00 | evan | i'd say comparable to patchlevel |
| 18:28:10 | evan | i suppose in a way it depends on the context it's being used |
| 18:28:17 | evan | because without including it in some contexts |
| 18:28:23 | evan | it will be ambigious when rc2 comes out |
| 18:28:29 | wayneeseguin | rue: best solution would be to remove the - between 1.0.0 and rc1 |
| 18:30:07 | evan | how are you using it? |
| 18:30:24 | brixen | rc1, dev, etc should be considered something like a non-version specifier for disambiguation |
| 18:31:01 | rue | This is why "version" is such a bad concept :) |
| 18:31:08 | brixen | 1.0.0 - no specifier, release version, 1.0.0-rcN, 1.0.1-dev the upcoming 1.0.1 version |
| 18:31:51 | brixen | 1.1.0-dev => 1.1.0-rc1 |
| 18:33:11 | wayneeseguin | evan: the real issue I have is that rvm uses -'s to separate it's ruby string specifiers |
| 18:33:15 | evan | the - identifier avoids the 0.99999 version problem |
| 18:33:15 | wayneeseguin | so each component means something |
| 18:33:29 | wayneeseguin | {interpreter,version,patchlevel,tag,revision,etc} |
| 18:33:47 | evan | it would probably be patchlevel in there. |
| 18:33:57 | wayneeseguin | evan: that's how I implemented it |
| 18:34:03 | evan | thats acceptable |
| 18:34:09 | wayneeseguin | evan: rue is helping me make the rvm installer of rbx solid |
| 18:34:12 | evan | since that code must explicit compare patchlevels |
| 18:34:21 | evan | in which case, when rc2 comes out |
| 18:34:23 | rue | Revisions + optional names would be better as the standard approach |
| 18:34:32 | evan | the difference between rc1 and rc2 is obvious |
| 18:34:32 | wayneeseguin | The only issue was what to do with hte date tag |
| 18:34:34 | Zoxc | would like to see a solid rbx windows installer :D |
| 18:34:43 | evan | Zoxc: we have to run on windows first |
| 18:34:49 | evan | we've got no windows devs helping |
| 18:34:50 | Zoxc | aww :( |
| 18:34:57 | wayneeseguin | Zoxc: rvm supposedly runs under cygwin ;) |
| 18:35:04 | wayneeseguin | or so I'm told :D |
| 18:35:05 | Zoxc | I'll help after I finish mirb ;D |
| 18:35:06 | evan | if I have to figure it out, i'll do it |
| 18:35:12 | evan | but i'm holding out hope that a windows dev helps out |
| 18:35:17 | evan | so I don't have to learn it all myself. |
| 18:35:50 | Zoxc | it's usually just avoiding forking and shebangs, and possibly using other APIs |
| 18:35:57 | Defiler | I hate how much damage you have to do to build scripts in general when porting to Windows |
| 18:36:13 | Defiler | Anything that uses make is automatically a hassle :( |
| 18:36:51 | Zoxc | make usually works fine in msys |
| 18:36:58 | Zoxc | but I hate make |
| 18:37:05 | evan | do you have to install bash first? |
| 18:37:06 | Defiler | Once you've found the 100 parts you have to change to make Windows happy, yeah |
| 18:37:07 | evan | to make make work? |
| 18:37:14 | brixen | avoiding forking?? no wonder windows sucks so bad |
| 18:37:16 | brixen | boring |
| 18:37:19 | Defiler | Yeah |
| 18:37:26 | Defiler | evan: Nope |
| 18:37:39 | Zoxc | what's good about forking? |
| 18:37:39 | Defiler | http://gnuwin32.sourceforge.net/packages/make.htm |
| 18:37:48 | brixen | Zoxc: it's a joke |
| 18:37:53 | Defiler | forking has insanely useful semantics |
| 18:37:55 | brixen | forking => fucking |
| 18:37:59 | wayneeseguin | :D |
| 18:38:03 | wayneeseguin | likes "forking" |
| 18:38:30 | brixen | and yes, in real terms, forking is a very good thing |
| 18:38:37 | brixen | and windows sucks period |
| 18:38:38 | Zoxc | forks brixen with rake |
| 18:40:51 | evan | my biggest grip is that fork + threads == unknown behavior |
| 18:40:52 | brixen | is thrown into a state of confusion, which instance should type... |
| 18:41:06 | evan | as in, there is no programmer on the planet that knows the behavior |
| 18:41:11 | evan | nor how to properly handle it. |
| 18:41:15 | Defiler | hrm.. let's say I have a dup of an object I captured, and then I have a modified object |
| 18:41:16 | Defiler | is there a good way in 1.8 to see the nitty gritty details of what is different? |
| 18:41:17 | Defiler | I've got this before and after metaclass, looks like only the superclass changes, but I want to make sure of that |
| 18:42:03 | evan | Defiler: whether or not it has a metaclass is the only thing |
| 18:42:15 | evan | for what it's worth #clone duplicates the metaclass also. |
| 18:42:18 | Zoxc | that's because forking is crazy and usually just a poor solution :) |
| 18:42:29 | Defiler | I can't think of a way to check in MRI whether something already has a metaclass |
| 18:42:30 | wayneeseguin | disagrees |
| 18:42:32 | wayneeseguin | <3 fork |
| 18:42:33 | Defiler | is there one? |
| 18:42:47 | wayneeseguin | fork-exec == powerful combo |
| 18:42:49 | evan | Defiler: no, you have to write a C extension to do it |
| 18:43:02 | Defiler | Thought so |
| 18:43:30 | brixen | Defiler: or maybe use the memprof thing by joe |
| 18:44:20 | brixen | Defiler: seen? http://timetobleed.com/what-is-a-ruby-object-introducing-memprof-dump/ |
| 18:45:08 | Defiler | yeah, I love his blog |
| 18:45:24 | evan | he's insane. |
| 18:45:35 | evan | the runtime patching of code in memory |
| 18:45:40 | evan | i hope no one depends on that. |
| 18:45:57 | Defiler | his lightning talk at GoRuCo was great |
| 18:46:09 | evan | the caveats for it actually working are insane. |
| 18:46:18 | brixen | "if a tool is built and no one uses it, does it exist?" |
| 18:46:34 | brixen | someone somewhere will always use some insane thing |
| 18:46:56 | wayneeseguin | I have a great deal of respect for Joe and his blog is quite possibly my favorite to read |
| 18:47:00 | evan | i just hope they don't use it when really need it to work. |
| 18:47:58 | Defiler | There's really no way to prevent people from shooting themselves in the face |
| 18:48:04 | evan | it feels like a saw who's blade randomly breaks off and flys in your face |
| 18:48:23 | evan | and the density of the material being sawed randomly causes the saw to break |
| 18:52:25 | evan | man, then "when to JIT" question is hard to answer |
| 18:52:41 | evan | SELF uses this interesting "invocation rate" idea |
| 18:53:07 | BrianRice-work | yeah, it makes profile counts within a time window |
| 18:53:17 | evan | counters that are inc'd on entrance to a method, and a backtrace thread divides all counters by a constant factor every N seconds |
| 18:53:24 | evan | basically, counters with a halflife. |
| 18:54:03 | BrianRice-work | ever looked at Strongtalk WRT this? |
| 18:54:23 | evan | the SELF thesis brings a lot of good points about problems with the halflife counters |
| 18:54:24 | Defiler | Ever gazed into the abyss of madness? |
| 18:54:29 | evan | BrianRice-work: i TRIED to look. |
| 18:54:31 | evan | i've got the source here |
| 18:54:36 | BrianRice-work | hehe |
| 18:54:39 | evan | but I couldn't find in the source where it was. |
| 18:54:50 | evan | yes, the Strongtalk code is like staring into the abyss |
| 18:54:56 | BrianRice-work | fair enough. |
| 18:54:57 | evan | my C++ has gotten strong enough again that I can get more of it. |
| 18:54:59 | Defiler | I think that logic is encoded in the strongtalk source file names and checksums |
| 18:55:06 | evan | but the organization leaves something to be desired. |
| 18:55:26 | evan | and it's hard to know what to look for |
| 18:55:37 | evan | ack "when to JIT" gives me nothing. |
| 18:57:11 | evan | there are some serious gems in the Strongtalk source though |
| 18:57:15 | evan | here is your line of the day: |
| 18:57:16 | evan | assert(*((u_char*)_invocation_counter_addr - 2) == 0x81, "not a cmp edx, imm32 instruction anymore?") |
| 18:57:44 | evan | there is so much win in that i don't even know where to start. |
| 18:57:51 | evan | :) |
| 18:58:10 | Defiler | we have way more meta-metaclasses involved in booting up rbx than I would have expected |
| 18:58:14 | BrianRice-work | :( |
| 18:58:48 | evan | Defiler: i noticed that myself. |
| 18:59:11 | Defiler | The first one is the meta-metaclass Object, trying to figure out what the hell is opening it |
| 18:59:18 | Defiler | but there are several in FFI as well |
| 18:59:36 | evan | find a CallFrame |
| 18:59:41 | evan | in the stack |
| 18:59:49 | evan | and use call_frame->print_backtrace(state) |
| 18:59:51 | Defiler | That's all newer than my last involvement unfortunately, haven't quite figured out how to navigate it |
| 19:00:03 | Defiler | So I'm looking for something in bt that takes a CallFrame as an arg? |
| 19:00:09 | evan | yeah |
| 19:00:16 | evan | should only be a couple frames away |
| 19:00:33 | Defiler | Gotcha.. in this case, vm_attach_method has one, 5 back |
| 19:01:06 | Defiler | 0x7fff5fbfccc0: Autoload.__class_init__ in kernel/common/autoload.rb:49 (+135) |
| 19:01:06 | Defiler | 0x7fff5fbfdaf0: Object#__script__ in kernel/common/autoload.rb:4 (+29) |
| 19:01:14 | Defiler | haha, I probably wrote that code. owned. |
| 19:01:40 | Defiler | waaaaaait.. |
| 19:01:58 | Defiler | class << self in a class body should just be a metaclass, not a meta-metaclass |
| 19:02:26 | Defiler | but in the MetaClass::attach that results from this, the 'obj' receiver is a MetaClass |
| 19:02:43 | Defiler | try_as<MetaClass> will return NULL when given a Class instance, right? |
| 19:02:55 | evan | if it's not a MetaClass, yes. |
| 19:03:14 | evan | a MetaClass is a Class |
| 19:03:19 | evan | but a Class is not always a MetaClass |
| 19:03:21 | Defiler | This is ultra mysterious to me then. Huh |
| 19:04:10 | Defiler | obj should be #<Class:Autoload> here not #<MetaClass:Class Object> |
| 19:04:38 | evan | Defiler: gist the gdb bt |
| 19:04:45 | evan | so 20 frames |
| 19:04:49 | evan | er. say 20 frames |
| 19:04:51 | Defiler | k |
| 19:06:01 | Defiler | http://gist.github.com/259684 |
| 19:06:28 | evan | bingo. |
| 19:06:42 | Defiler | I like/hate it when you say that |
| 19:06:42 | evan | you're creating a metaclass on the metaclass right there. |
| 19:06:55 | evan | see the nested called to MetaClass::attach? |
| 19:07:14 | Defiler | aaaah |
| 19:07:40 | Defiler | ooooooohh damnit |
| 19:07:42 | Defiler | right |
| 19:07:51 | Defiler | I need to just try_as<MetaClass> on the klass |
| 19:07:55 | Defiler | not call metaclass(state) |
| 19:08:02 | evan | yes |
| 19:08:04 | evan | if you do that |
| 19:08:06 | evan | you'll generate one |
| 19:08:11 | Defiler | OK, I'll crush this after this meeting |
| 19:08:16 | evan | CRUSH |
| 19:08:19 | evan | ORANGE CRUSH |
| 19:08:24 | Defiler | :) |
| 19:08:25 | evan | WITH A SANDWICH |
| 19:08:45 | evan | I think the Hulk would be a fun pairing partner. |
| 19:10:05 | brixen | I thought you paired with ryan before |
| 19:10:18 | evan | ZING |
| 19:10:23 | brixen | heh |
| 19:10:34 | evan | I actually have not paired with ryan very much |
| 19:10:37 | evan | a few times. |
| 20:37:53 | Defiler | WOW this behavior is strange |
| 20:38:01 | Defiler | I guess I have to go decode eval.c to see what it really does :( |
| 20:39:52 | brixen | make sure you wear one of those harness thingies and use the ventilator |
| 20:39:59 | brixen | so if you pass out, we can extract you |
| 20:40:08 | Defiler | hah, good idea |
| 20:40:26 | Defiler | It definitely is doing something more subtle than changing the superclass of the receiver |
| 20:40:49 | Defiler | even though in running ruby code it really really looks that way |
| 20:40:59 | Defiler | Object.m.superclass == Object.m.m returns true, for example |
| 20:41:09 | brixen | hmm |
| 20:42:05 | brixen | gets some lunch |
| 20:42:34 | Defiler | I can't tell you how many times I have seen Exception2MessageMapper working on this :) |
| 20:57:18 | rue | I heard it can cause a condition similar to snow blindness |
| 21:06:19 | Zoxc | how do you show the right name of the method in the backtrace if the method is used multiple places? |
| 21:08:23 | Defiler | can you explain what you mean by that? |
| 21:22:01 | Zoxc | 1.9 doesn't seem to handle define_method(:hi, new.method(:hello).to_proc) atleast |
| 21:22:08 | Zoxc | still shows hello in the backtrace |
| 21:24:25 | Defiler | odd |
| 21:25:48 | Zoxc | so I guess I can attach a name to each compiled block then :D |
| 21:25:54 | Defiler | Don't |
| 21:26:00 | Defiler | get the name from the call site at runtime |
| 21:26:14 | Defiler | at calltime, that is |
| 21:29:15 | Zoxc | I'd have to store the names of the calls then and it might be slightly confusing when looking at the source too |
| 21:29:31 | Defiler | You already have to do that if you want to run, say, rspec |
| 21:30:03 | Defiler | eval("caller(0)", some_proc) |
| 21:30:53 | Zoxc | I probably won't be supporting bindings either |
| 21:31:03 | Defiler | What are you building? |
| 21:31:24 | Zoxc | Ruby VM =P |
| 21:31:55 | Defiler | If you're not doing bindings, you're not building a Ruby impl (not being rude, just a heads up heh) |
| 21:32:09 | Defiler | because without them you can't run irb, rails, rspec, etc etc etc |
| 21:32:48 | Zoxc | I don't really plan to |
| 21:32:55 | Zoxc | and http://ruby-std.netlab.jp/ approves ;D |
| 21:35:15 | Defiler | Yeah, well.. almost no real ruby code would run using only the things defined in that standard |
| 21:35:19 | Defiler | :) |
| 21:38:02 | Zoxc | I'm wanting to embed Ruby into other applications where you would usually use an application specific API, requiring new code anyway |
| 21:39:05 | Defiler | Aah, OK. Cool |
| 21:39:27 | Defiler | So you're going C99, embeddable, etc etc, Lua-style? |
| 21:40:05 | Zoxc | Yeah, except I'm using a JIT :) |
| 21:40:18 | Defiler | My advice is simply to attempt to pass rubyspec where you can |
| 21:40:31 | Defiler | the consequences of 'aah, I'll leave that out, nobody uses it' can be very difficult to forsee |
| 21:40:45 | Zoxc | I could easily implement binding later on anyway |
| 21:41:02 | Defiler | Pretty much every extension or deviation rubinius has ever done has needed pulling eventually |
| 21:41:12 | Defiler | most recently metaclasses being instances of MetaClass |
| 22:08:20 | Zoxc | how does MRI deal with object allocators and C methods operating on these objects? |
| 22:34:06 | evan | Zoxc: do you have an example? |
| 22:36:02 | Zoxc | say Array#size, which could be implemented like return RArray(obj)->size |
| 22:36:18 | Zoxc | it would be kind of bad if that method was moved to the String class |
| 22:44:01 | brixen | Zoxc: you can't do that |
| 22:49:14 | evan | Zoxc: i don't see how moving a method is related to object allocation |
| 22:49:24 | evan | but none the less, you can't move methods in ruby. |
| 22:50:25 | Zoxc | doesn't unbind + bind move methods? |
| 22:50:28 | evan | nope |
| 22:50:40 | Zoxc | what does it do then? |
| 22:51:05 | evan | Method#call is a special way to invoke a method that is unrelated to where the method originally lived |
| 22:51:34 | evan | and UnboundMethod#bind validates the object and the class it contains internally |
| 22:51:44 | evan | you can't bind an Array method to a String object. |
| 22:56:15 | Zoxc | MRI has some special object allocator which I assume ensures that a String.allocate always returns a internal string object |
| 23:09:08 | evan | Zoxc: String.allocate can only return a String |
| 23:09:12 | evan | how could it return anything else? |
| 23:09:15 | evan | i don't get your point. |
| 23:10:29 | Zoxc | dunno, but the allocator stuff probably has to do something |
| 23:59:21 | evan | Zoxc: it allocates an object of the class you ask it to |
| 23:59:23 | evan | thats all. |