Show enters and exits. Hide enters and exits.
| 06:30:58 | tarcieri | http://use.perl.org/~Ovid/journal/38818 |
| 06:31:01 | tarcieri | *facepalm* |
| 06:43:29 | brixen | heh, djwhitt plugs rubyspec and keeps 'em honest |
| 06:43:52 | brixen | perl... what is this? '93 :) |
| 06:54:52 | slava | tarcieri: don't hate on perl man |
| 06:56:04 | dkubb | slava: yeah, the distributed test system that CPAN uses is genius work. I always wondered why something similar hasn't caught on in the ruby world.. for testing gems and other ruby projects |
| 07:00:18 | brixen | there is http://seattlerb.rubyforge.org/tinderbox/ |
| 07:03:05 | boyscout | Handle missing backtrace more gracefully. - 2db6d95 - Brian Ford |
| 07:03:05 | boyscout | Conform $LOAD_PATH more closely to MRI. - 785621f - Brian Ford |
| 07:04:31 | boyscout | CI: 785621f success. 1503 files, 7245 examples, 23659 expectations, 0 failures, 0 errors |
| 07:05:34 | dkubb | brixen: it's been a while since I was heavily involved in the perl community, but as I recall people could install a deamon running on their site, and as new module were uploaded they'd run the test cases and upload the test output to a central server |
| 07:05:45 | dkubb | er, on their computer.. not site |
| 07:07:35 | dkubb | my only CPAN module (something embarrassingly simple) was tested on about 70 platforms and versions of perl, and I get some nice reports like http://matrix.cpantesters.org/?dist=CGI-State+0.02 |
| 07:07:55 | dkubb | I guess the system is now called CPANTS |
| 07:11:19 | brixen | cool |
| 07:12:51 | erikh | actually, drbrain tried to get something going with a project a while back related to CPAN testers |
| 07:12:52 | slava | I'm revisiting the problem of integrating X11 into a non-blocking I/O event loop |
| 07:13:06 | erikh | I was going to hack in rubygems support, but then I got all jobbed up and had no time |
| 07:13:33 | erikh | I want to say he called it tinderbox? |
| 07:13:46 | brixen | erikh: yeah, I pasted that above |
| 07:13:53 | erikh | oh; sorry |
| 07:14:01 | brixen | heh, no worries |
| 07:14:15 | brixen | http://seattlerb.rubyforge.org/tinderbox/ if you're interested |
| 07:14:36 | erikh | yeah, basically someone just needs to hack in the support for it to run optionally for rubygems users and it becomes quite distributed |
| 07:14:57 | erikh | i just have no time for it |
| 07:19:47 | dkubb | a few months ago I was working with someone to make a distributed test app to be used with DataMapper and DataObjects initially.. with the plan to make it available for any project that wanted it. a central place would still be needed for aggregating results, and there'd have to be some mechanism to let the clients know when there was a change.. I'd work on it if I wasn't already tied up with other projects |
| 07:24:17 | brixen | there's a guy working on this http://rubyspecresults.org/ |
| 07:24:24 | brixen | it's just for rubyspec atm |
| 07:24:42 | brixen | but the idea is to accept submissions from CI bots |
| 07:26:25 | dkubb | wow, that's cool. that's what I was talking about |
| 07:26:41 | boyscout | Generate backtrace when primitives raise exceptions. - 94f4b58 - Brian Ford |
| 07:27:30 | dkubb | I think it's great that it's just for rubyspec atm. better to get things ironed out with a smaller scope, and then extract it into something usable by more projects later |
| 07:27:37 | brixen | it needs a lot of functionality still |
| 07:27:41 | brixen | yeah, true |
| 07:29:11 | boyscout | CI: 94f4b58 success. 1503 files, 7245 examples, 23659 expectations, 0 failures, 0 errors |
| 07:29:27 | erikh | TAP would go a long way into standardizing how ruby users view tests. |
| 07:30:25 | brixen | erikh: tell me more |
| 07:30:29 | brixen | tap is very cool |
| 07:30:34 | erikh | TAP - the test anything protocol |
| 07:30:34 | brixen | I want to get rbx to use it |
| 07:30:36 | dkubb | TAP: http://en.wikipedia.org/wiki/Test_Anything_Protocol |
| 07:30:37 | brixen | oh that |
| 07:30:49 | brixen | I thought you meant tap |
| 07:30:51 | erikh | it's just standardized test output |
| 07:31:14 | brixen | this tap http://tap.rubyforge.org/ :{ |
| 07:31:56 | brixen | I have a "tap" for mspec |
| 07:32:02 | brixen | it's called yaml :) |
| 07:32:11 | erikh | it's very effective. in the perl world, knowing that no matter what you use to build your modules or even architect your test suite you'll get the same output is priceless |
| 07:34:24 | dkubb | looks like bacon does tap output already |
| 07:34:47 | erikh | yeah, chris2 is a big fan of tap |
| 07:34:48 | dkubb | re: http://testanything.org/wiki/index.php/Testing_with_Ruby |
| 07:35:14 | erikh | he actually wrote a little module that monkeypatches Test::Unit to emit TAP too |
| 07:36:07 | dkubb | it should be pretty easy to make a formatter for rspec to do TAP |
| 07:36:13 | erikh | ok; gonna get in the zone for some prime free-hacking time, see you guys later. |
| 07:56:32 | tarcieri | lol slava |
| 07:56:40 | tarcieri | I don't hate on Perl |
| 07:56:50 | tarcieri | Larry Wall is my second favorite language creator after Alan Kay |
| 07:57:11 | tarcieri | it's just Perl's time has passed |
| 07:57:15 | tarcieri | and everyone should move on |
| 07:57:19 | tarcieri | but some people are stuck |
| 07:57:21 | slava | chuck moore > alan kay |
| 07:57:30 | tarcieri | Alan Kay is the shit |
| 07:57:37 | slava | I don't think perl is worse than any other scripting language |
| 07:57:57 | tarcieri | I like, umm, arguments... to functions |
| 07:58:03 | tarcieri | being passed discretely |
| 07:58:23 | tarcieri | automatically flattening structures? yeah in most cases that's bad |
| 07:58:45 | tarcieri | lexical scoping is cool |
| 07:58:55 | slava | ruby has plenty of warts |
| 07:59:05 | tarcieri | yeah a lot of them were inherited from Perl |
| 07:59:18 | tarcieri | especially the nonsensical $* crap |
| 07:59:37 | tarcieri | there's still cases I see people using that and it's just WTF |
| 07:59:50 | slava | the way blocks work kind of sucks |
| 07:59:55 | tarcieri | yeah |
| 08:00:00 | slava | so does the whole 'open class' thing |
| 08:00:01 | tarcieri | I'm trying to fix that |
| 08:00:02 | tarcieri | yep |
| 08:00:05 | tarcieri | especially core |
| 08:00:11 | tarcieri | core should not be open |
| 08:00:21 | slava | neither should anything, the whole model is flawed |
| 08:00:24 | tarcieri | yeah |
| 08:00:26 | slava | because of name clashes |
| 08:00:31 | tarcieri | I would like an add-only approach |
| 08:00:42 | slava | no, the concept of adding methods to existing classes is wrong |
| 08:00:52 | tarcieri | I don't agree |
| 08:01:01 | slava | it amounts to having one global selector namespace |
| 08:01:06 | slava | global names = bad |
| 08:01:18 | tarcieri | have you read open reusable object models? |
| 08:01:28 | slava | if you're going to have message passing OO, do what Java does, and only allow new class definitions to introduce methods |
| 08:01:50 | tarcieri | "if you're going to have message passing OO, do what Java does" my brain shut off about there |
| 08:02:21 | tarcieri | like uhh |
| 08:02:31 | tarcieri | imperative OO is not message passing OO |
| 08:02:44 | slava | I was talking about one specific aspect of Java's object model |
| 08:02:49 | slava | the fact that classes are 'sealed' |
| 08:02:49 | tarcieri | I'm tired of people waving their hands in the air talking about messages when message really mean "function calls that act on mutable state" |
| 08:03:07 | tarcieri | in my languages, messages are real |
| 08:03:10 | slava | when I say 'message passing OO' I mean the smalltalk/java/ruby model |
| 08:03:18 | tarcieri | Smalltalk yes! |
| 08:03:20 | tarcieri | Java NO |
| 08:03:22 | tarcieri | Ruby kinda |
| 08:03:56 | tarcieri | Reia has real messages |
| 08:03:59 | tarcieri | first class messages |
| 08:04:05 | slava | yeah, and its slow as hell |
| 08:04:20 | tarcieri | not a concern of mine |
| 08:04:27 | slava | you took the slowest operation in erlang, and made it the central means of computation :) |
| 08:04:43 | tarcieri | that's one way of looking at it, I suppose |
| 08:04:55 | tarcieri | it's the central means of modeling identity and synchronizing state |
| 08:05:16 | tarcieri | not necessarily "computation" |
| 08:05:55 | tarcieri | the world around an object/process is free to change, because an object/process communicates with the outside world using messages |
| 08:06:31 | tarcieri | not """messages""" which is a fancy high falloting word for "function calls which mutate state" |
| 08:06:31 | slava | if your processes are too fine grained, then its easy to write code that deadlocks or has races of various types |
| 08:06:49 | slava | foo.bar() - bar dispatches on foo's type |
| 08:06:52 | tarcieri | there is a particular type of deadlock which is exceedingly common |
| 08:06:53 | slava | that's message passing OO |
| 08:07:02 | tarcieri | I have a solution for that |
| 08:07:09 | tarcieri | the others are edge cases |
| 08:09:08 | slava | within a class, there's a list of methods named by strings |
| 08:09:17 | slava | if more than one module can add methods to this list, then you have name clashes |
| 08:09:21 | slava | that's unavoidable |
| 08:09:28 | slava | so the solution is to say that a module is a class and you can't add methods to other classes |
| 08:09:55 | tarcieri | I'm aiming for an approach where only the metaclass can add methods to a class |
| 08:11:17 | tarcieri | slava: have you ever read this guy's blog: http://james-iry.blogspot.com/ |
| 08:11:26 | tarcieri | he's pretty awesome |
| 08:13:21 | slava | yes |
| 08:14:44 | tarcieri | I think what he's ultimately trying to get at is in Erlang, messages have side effects |
| 08:15:03 | tarcieri | oh noes side effects |
| 08:15:46 | tarcieri | Erlang people are OMG SIDE EFFECTS until it comes to I/O and concurrency |
| 08:16:34 | tarcieri | apparently those are the only two areas where side effects kick ass |
| 08:17:36 | slava | that's an arbitrary line you're drawing there |
| 08:17:46 | slava | why allow side effects for I/O and concurrency but not anything else? |
| 08:17:57 | slava | hashtables and other data structures need side effects |
| 08:18:10 | slava | on the other hand some people like even controlling I/O effects with monads |
| 08:18:54 | tarcieri | I don't draw that line |
| 08:18:58 | tarcieri | I add MORE SIDE EFFECTS! |
| 08:19:08 | tarcieri | most are localized |
| 08:19:14 | tarcieri | some aren't entirely localized |
| 08:19:17 | tarcieri | like hidden state |
| 08:19:37 | tarcieri | but I entirely agree the Erlang people draw an arbitrary line |
| 08:20:44 | tarcieri | Erlang has a very imperative approach to I/O |
| 08:20:50 | tarcieri | an approach I would call "practical" |
| 08:20:51 | tarcieri | heh |
| 08:21:16 | tarcieri | I/O is a very imperative sort of thing |
| 08:21:25 | slava | how fast is erlang I/O ? |
| 08:21:30 | tarcieri | trying to wrap it up a neat pure functional package is retarded |
| 08:21:43 | tarcieri | extremely fast, unless you're talking about the "io" module |
| 08:21:51 | tarcieri | which is poorly named |
| 08:21:57 | tarcieri | another persistent Erlang problem |
| 08:22:05 | tarcieri | they suck at naming stuff |
| 08:22:39 | tarcieri | I think it's very hard to guess what the "io" module does by its name |
| 08:23:30 | tarcieri | it's basically terminal I/O |
| 08:23:50 | tarcieri | Erlang is slow at terminal I/O because it provides some awesome abstractions for terminal I/O across distributed systems |
| 08:23:58 | tarcieri | the "group leader" system |
| 08:24:10 | tarcieri | all terminal I/O happens through the group leader |
| 08:24:19 | tarcieri | if you have one node it's a needless layer of indirection |
| 08:24:37 | tarcieri | if you have a cluster it's an invaluable way to get everything you're interested in directed to a particular node |
| 08:25:11 | tarcieri | it has nothing to do with file or socket I/O |
| 08:25:53 | tarcieri | for socket I/O Erlang has "kernel poll" which is an abstract interface to epoll/kqueue/etc |
| 08:26:01 | tarcieri | for file I/O Erlang has the async thread pool |
| 08:26:27 | tarcieri | which can be used for anything else which requires blocking system calls |
| 08:29:16 | tarcieri | you should rename Factor to LSD and backronym it to "Language that Slava Designed" |
| 08:29:45 | slava | haha |
| 08:29:56 | slava | what about getting data in and out of string form in erlang? |
| 08:30:12 | tarcieri | if by "string" you mean binary that's easy |
| 08:30:29 | slava | no, suppose its a long file and I want to process each line, and its utf8 |
| 08:30:34 | slava | not a binary file |
| 08:30:37 | slava | no mmap |
| 08:30:39 | tarcieri | then it sucks |
| 08:30:49 | tarcieri | well |
| 08:30:52 | tarcieri | if it's UTF-8 |
| 08:30:56 | tarcieri | and you're running R13A |
| 08:31:02 | tarcieri | then it doesn't suck so bad |
| 08:31:29 | tarcieri | but yeah, you need the absolute latest bleeding edge release |
| 12:30:33 | tilman | brixen: how about this? http://235d48fe2c846551.paste.se/ |
| 12:30:56 | tilman | brixen: has the advantage that it works with any target, and not just those who know about an --valgrind switch |
| 13:44:30 | tilman | did my patch get through to the mailing list? |
| 16:27:10 | brixen | tilman: yeah, that's fine |
| 16:27:20 | brixen | which mailing list did you send the patch to? |
| 16:28:43 | brixen | tilman: do you have specs for it? |
| 16:29:22 | tilman | i mailed rubinius-dev@googlegroups.com |
| 16:29:38 | tilman | but i guess i failed somehow :) |
| 16:29:46 | tilman | brixen: specs for what? the valgrind thing? |
| 16:35:22 | brixen | oh rubinius-dev |
| 16:35:28 | brixen | I was looking at rubyspec ml |
| 16:35:43 | brixen | yeah, specs for the valgrind thing |
| 16:35:50 | tilman | sorry; that patch is unrelated to the mspec diff |
| 16:36:13 | brixen | heh ok |
| 16:36:23 | tilman | anyway, i don't have spces, no |
| 16:37:08 | brixen | k, I can add the patch and write some |
| 16:37:16 | tilman | \o/ |
| 16:38:42 | tilman | so... |
| 16:38:57 | tilman | this isn't well by rbx atm: [1,2,3].each |
| 16:39:07 | tilman | ie, call a method that yields without having a block to yield to |
| 16:40:11 | tilman | it will try to read before the stk array in CallFrame... ie the sp points at the first item in stk, and then the yield_stack instruction calls CallFrame::stack_back_position(1) |
| 16:40:32 | brixen | drm |
| 16:40:34 | tilman | and we up reading memory _before_ stk (-> 'unwinds') |
| 16:40:36 | brixen | hrm |
| 16:40:59 | rue | That returns an enumerator in 1.8.7 |
| 16:41:08 | rue | Error in 1.8.6 |
| 16:41:08 | tilman | true |
| 16:41:30 | tilman | rue: what kind of error? i don't have .6 handy right now |
| 16:41:37 | tilman | LocalJumpError or somesuch? |
| 16:41:39 | brixen | should raise |
| 16:41:41 | brixen | yeah |
| 16:41:46 | tilman | ah, i see |
| 16:41:49 | rue | LocalJumpError: no block |
| 16:42:11 | tilman | for now i can add an assertion that will at least kill the vm if it tries to do that |
| 16:42:18 | rue | The check should be in yield |
| 16:42:36 | brixen | tilman: I can't repro that in rbx in irb |
| 16:42:39 | brixen | what's your code? |
| 16:42:49 | tilman | ary = [1, 2, 3] |
| 16:42:49 | tilman | ary.each |
| 16:43:06 | brixen | localjumperror |
| 16:43:24 | tilman | heh, hang on |
| 16:43:42 | tilman | brixen: the invalid memory access is now caught by an assertion i added. so it dies before it can raise, i think |
| 16:43:50 | tilman | yes, that's it. |
| 16:43:55 | tilman | sec |
| 16:44:25 | tilman | rue: gen/instructions.cpp, ca. 1897. it's not a block, it's not a proc, so let's raise there? |
| 16:44:32 | tilman | op_iml_yield_stack |
| 16:44:37 | tilman | op_impl_yield_stack |
| 16:45:14 | brixen | http://gist.github.com/97664 |
| 16:45:34 | tilman | sure, i believe you |
| 16:45:38 | tilman | but my analysis is correct |
| 16:45:39 | brixen | NilClass#call raises |
| 16:45:51 | brixen | well, I'm trying to repro it |
| 16:45:54 | tilman | if unwind[maxunwind] contains a special kind of crap, you'd probably see a segfault |
| 16:45:56 | brixen | your case gives me lje |
| 16:46:29 | tilman | brixen: sec |
| 16:46:51 | tilman | brixen: http://e40dfd299962cab5.paste.se/ |
| 16:46:58 | tilman | try running with that |
| 16:47:31 | tilman | so i guess we need a nil_p check in that code |
| 16:47:41 | tilman | and not call call_frame->stack_back_position in that case |
| 16:48:02 | brixen | we don't need a nil_p check |
| 16:48:10 | brixen | NilClass#call raises |
| 16:48:37 | tilman | read again please |
| 16:49:19 | brixen | we need to make sure nil is on the stack for the block |
| 16:49:51 | brixen | tilman: ok, I get your assert abort |
| 16:51:37 | brixen | you'll have to check with evan, but since any method can take (or ignore) a block, there should be a nil on the stack if a block wasn't passed |
| 16:51:44 | brixen | maybe he's changed that |
| 16:53:46 | tilman | mmh |
| 16:57:03 | tilman | yield_stack is called with the number of arguments that are to be passed to the block, right? |
| 16:57:48 | rue | tilman: How is it a Proc if there is no block? |
| 16:58:49 | tilman | rue: it's not a proc either. both conditions are false |
| 17:01:27 | brixen | tilman: hehe, only problem with your assert is a = [1,2,3]; a.each &nil also aborts |
| 17:02:23 | brixen | and so does a.each { } |
| 17:03:52 | brixen | helozjisky: sup? where you the one trying to install rbx? |
| 17:08:19 | brixen | hrm, something seems to be wrong with the profiler's total sec under certain conditions |
| 17:08:45 | brixen | probably missing a leave() somewhere |
| 17:11:30 | boyscout | Added -P<sort column> to run profiler and sort output. - ef93221 - Brian Ford |
| 17:11:41 | tilman | [].each &nil should raise LJE, right? |
| 17:11:48 | brixen | yeah |
| 17:11:58 | rue | dbussink: Will attend EuRuKo after all |
| 17:12:00 | tilman | okay, that's working with my crappy patch |
| 17:12:11 | tilman | but [].each {} isn't handled yet |
| 17:12:22 | tilman | need to see how the bytecode looks for that |
| 17:12:34 | dbussink | rue: i've read it :) |
| 17:12:41 | dbussink | rue: that you got a ticket from someone |
| 17:12:58 | boyscout | CI: ef93221 success. 1503 files, 7245 examples, 23659 expectations, 0 failures, 0 errors |
| 17:13:23 | rue | tilman: `[].each {}` seems to work fine :) |
| 17:13:41 | tilman | rue: damn my laziness. [1,2,3].each{} should die though |
| 17:13:48 | rue | Nope |
| 17:13:58 | tilman | rue: did you apply my assert diff? |
| 17:14:13 | rue | Nah |
| 17:14:27 | brixen | tilman: .each {} shouldn't die |
| 17:14:29 | rue | dbussink: Ah, yeah, I was not sure if anyone actually read it since thingy did not have posts anytime recently |
| 17:14:30 | brixen | why would it? |
| 17:14:36 | tilman | brixen: i know, but it does ;) |
| 17:14:51 | brixen | perhaps because your assert is not right? |
| 17:14:52 | rue | Is it compiling right? |
| 17:15:06 | tilman | the assertion is correct |
| 17:15:18 | rue | assert(assert()) |
| 17:17:02 | tilman | rue: i'm staring at the output of lib/bin/describe right now, but i don't really get it :D |
| 17:17:24 | tilman | i think i need to see how send_stack_with_block is implemented |
| 17:17:50 | rue | Is it `[].each({})` or `[].each {}`? |
| 17:18:02 | tilman | ary = [1,2,3]; ary.each {} |
| 17:22:27 | tilman | seems like yield doesn't push the value onto the stack if the block doesn't take an argument |
| 17:23:34 | rue | Yeah, but the block should not be worrying about the stack then anyway? |
| 17:24:03 | tilman | yield_stack is called with 1 though, so it tries to pop 1 value off the stack |
| 17:24:42 | tilman | it knows not to push, but it pops anyway |
| 17:24:46 | tilman | or something |
| 17:28:23 | malumalu | is there some way to temporarly switch off garbage collection in the vm? |
| 17:49:36 | tilman | actually with [1,2,3].each{} another assertion is hit -- the one in CallFrame::push |
| 17:59:30 | tilman | but that assertion is backwards |
| 18:01:25 | tilman | oh man |
| 18:03:23 | tilman | with all assertions enabled, http://8cfacdf45ab9b3ee.paste.se/ will work, i believe. without invalid memory accesses. (i realize it might not be the correct/best bugfix) |
| 18:17:06 | tilman | brixen: turns out my assertion _is_ flawed. the return value may be stk-1 if position is 0 :) |
| 18:17:25 | brixen | tilman: :) |
| 18:17:44 | tilman | i hit that case with "catch :foo" |
| 18:18:03 | brixen | I remember this when we first switched to c++ |
| 18:18:14 | brixen | but I couldn't remember the details |
| 18:18:24 | brixen | I figured you'd figure it out eventually :P |
| 18:20:23 | tilman | s/if position is 0// *cough* |
| 18:22:16 | brixen | tilman: there was some debugging output for the stack |
| 18:22:22 | brixen | that's why I knew it could be -1 |
| 18:22:33 | brixen | I wonder if that's still in there |
| 18:24:26 | brixen | you might assume that Class.new would be a relatively little used method |
| 18:24:29 | tilman | GAH |
| 18:24:31 | tilman | no. |
| 18:24:34 | tilman | asdf |
| 18:24:42 | brixen | unless you happened to profile starting rails |
| 18:24:49 | brixen | 330974 calls to Class.new |
| 18:24:55 | tilman | brixen: the return value cannot be at stk-1,because that's obviously outside the memory allocated for stk |
| 18:25:34 | tilman | but the assert should only be done if position > 0 |
| 18:25:42 | brixen | hrm |
| 18:25:45 | tilman | because: if the stack is empty, js.stack points at stk[-1] |
| 18:25:51 | brixen | ok |
| 18:25:55 | brixen | that's what I remember |
| 18:25:55 | tilman | humhum |
| 18:26:04 | tilman | should it be okay to call stack_back_position(0) in that case? |
| 18:26:10 | tilman | probably not |
| 18:26:12 | tilman | what a mess %) |
| 18:26:29 | brixen | right, not if it *accesses* stk[-1] |
| 18:26:46 | tilman | yeah |
| 18:59:39 | rue | Look hjyeah |
| 19:00:21 | rue | malumalu: No, although it could be added reasonably simply. Why? |
| 19:54:54 | malumalu | rue: just thought about ObjectSpace.each_object; i just thought about making an array of each object of each gc and call .each on this array |
| 19:56:03 | malumalu | and because i don't want the objects to disapear while .each'ing the array |
| 19:57:19 | malumalu | eh, moment, when the objects are in the array they shouldn't disappear because there is a reference to it |
| 20:00:35 | rue | Right |
| 20:00:55 | rue | Of course you should never ever use ObjectSpace but you know |
| 20:29:19 | flgr | brixen: what does Rails it Class.new for? |
| 21:00:33 | brixen | flgr: heh, the profiler is messed up, it's more like 600 calls to Class.new |
| 21:01:37 | brixen | malumalu: you don't want to make an array of each object |
| 21:02:00 | brixen | we will probably need to make an iterator in OM that can call a block with an abject |
| 21:02:18 | brixen | I plan on talking to evan about it next week |
| 21:41:09 | headius | anyone around? |
| 21:43:35 | slava | I am but I'm useless to you |
| 21:45:02 | headius | yes you are |
| 21:45:07 | headius | but I won't hold it against you |
| 21:46:10 | headius | trying to find a short list of rubinius opcodes |
| 21:46:17 | headius | we're going to start coming up with an IR for jruby |
| 21:53:10 | malumalu | headius: kernel/compiler/iseq.rb maybe |
| 21:54:33 | headius | yeah, just found that, thanks |
| 21:54:36 | headius | that's good enough |
| 22:19:55 | tilman | brixen: i suck so much. the real fix is like to use stack_back_position(count - 1) :( |
| 22:20:10 | tilman | likely* |