Show enters and exits. Hide enters and exits.
| 18:34:04 | jvoorhis | hello |
| 18:34:52 | jvoorhis | evan et al: may i solicit some more feedback on ruby-llvm? :) |
| 18:34:57 | jvoorhis | http://github.com/jvoorhis/ruby-llvm/blob/master/samples/factorial.rb |
| 18:38:01 | rue | Morning |
| 18:39:09 | evan | jvoorhis: i think with_block should yield the builder |
| 18:39:28 | evan | builder.with_block(block) { |b| b.cond(b.icmp(..)) } |
| 18:44:41 | dbussink | evening :) |
| 18:49:46 | jvoorhis | evan: i was iffy on that one |
| 18:49:50 | jvoorhis | it makes a lot of sense |
| 18:50:40 | evan | why iffy? |
| 18:50:55 | jvoorhis | but in my example, the with_block blocks would have two locals for the same object |
| 18:50:59 | evan | additionally, because you must use with_block first |
| 18:51:09 | evan | why not just have Block#build |
| 18:51:13 | jvoorhis | yeah |
| 18:51:14 | evan | that yields a builder |
| 18:51:21 | evan | which is for that block |
| 18:51:30 | jvoorhis | builders are inexpensive to create and destroy, right? |
| 18:51:38 | evan | block.build { |b| b.cond b.icmp() } |
| 18:51:39 | evan | yeah |
| 18:51:46 | jvoorhis | that resolves the cognitive dissonance :) |
| 18:52:19 | evan | or, optionally, |
| 18:52:25 | evan | allow #build to take the builder |
| 18:52:30 | jvoorhis | i'll be nice and have BasicBlock#build do ensure; Builder#destroy |
| 18:52:35 | evan | which will be assigned to the block and then yielded |
| 18:52:35 | jvoorhis | hm |
| 18:52:42 | jvoorhis | that works also |
| 18:52:43 | evan | that gives people the flexibility |
| 18:52:51 | jvoorhis | and dispose if it's block-local |
| 18:53:05 | evan | def build(builder=Builder.new) builder.set_block(self); yield builder; end |
| 18:53:48 | jvoorhis | except if i construct it in the default, then i can't know whether it's local and disposable unless i use e.g. AutoPointer :) |
| 18:54:19 | jvoorhis | but the method signature looks good |
| 18:55:18 | jvoorhis | def build(builder=nil) builder, dispose = builder ? [builder,false] : [Builder.new,true]; yield builder; ensure builder.dispose if dispose end :) |
| 18:56:14 | jvoorhis | my Builder#with_block implementation also has a little magic that restores the builder's original position |
| 18:56:37 | jvoorhis | and Builder#with_block is not at all primitive, it just uses wrapped api calls |
| 18:57:01 | jvoorhis | so maybe Block#build could work in terms of Builder#with_block |
| 18:57:14 | evan | huh? |
| 18:57:20 | evan | you're build is confusing. |
| 18:57:34 | evan | oh, i see. |
| 18:57:41 | evan | you're disposing of it if you created it. |
| 18:57:45 | jvoorhis | exactly |
| 18:57:53 | jvoorhis | i won't golf the real version :) |
| 18:58:17 | jvoorhis | and this is the state-restoring part i mentioned: http://github.com/jvoorhis/ruby-llvm/blob/master/lib/llvm/core/builder.rb#L32 |
| 18:58:40 | evan | #build can certainly do that too |
| 18:58:43 | jvoorhis | it should probably take the current instruction into account as well, instead of just using position_at_end |
| 18:58:46 | jvoorhis | yeah |
| 18:58:54 | evan | since you now have logic you can run if the user passed in an external builder |
| 18:59:14 | jvoorhis | well, BasicBlock#build could just use Builder#with_block |
| 18:59:33 | jvoorhis | and layer the auto-dispose logic on top |
| 18:59:34 | evan | seems needless, but sure. |
| 18:59:40 | jvoorhis | yeah, maybe |
| 18:59:40 | evan | i'd just get rid of #with_block all together. |
| 18:59:49 | jvoorhis | sure |
| 18:59:59 | jvoorhis | and if anyone wants a shared builder, they can fall back on api primitives |
| 19:00:12 | evan | exactly. |
| 19:00:16 | evan | this is icing anyway. |
| 19:00:18 | jvoorhis | i like it |
| 19:00:26 | jvoorhis | yeah, it is icing |
| 19:00:31 | jvoorhis | but i think it counts for something |
| 19:00:40 | evan | it definitely does |
| 19:00:54 | evan | a cake without icing is useless! |
| 19:00:54 | evan | :D |
| 19:01:09 | jvoorhis | points to pound cake as a counter example |
| 19:01:15 | evan | useless! |
| 19:01:16 | evan | :D |
| 19:01:18 | evan | MORE ICING! |
| 19:01:22 | jvoorhis | haha |
| 19:01:34 | rue | Ew, American cakes |
| 19:01:40 | jvoorhis | i definitely want this to have a good look and feel |
| 19:02:33 | jvoorhis | if the api suggests a sensible usage, and the examples are very straightforward, then people might find LLVM less intimidating |
| 19:03:47 | jvoorhis | documentation would also help :) i'll probably just find a way to generate cross-references to the LLVM docs |
| 19:04:16 | evan | we should probably write it up ourselves |
| 19:04:22 | evan | and reference the original LLVM docs |
| 19:04:31 | jvoorhis | yeah, the builder methods would cross-reference |
| 19:05:22 | jvoorhis | is that the royal we, or do you want to write some docs? :) |
| 19:05:56 | jvoorhis | evan: also, it's not running on rbx yet, but now it does run on MRI 1.8.x and JRuby, so hopefully it's not far off |
| 19:06:43 | evan | i'll help |
| 19:06:44 | evan | sure. |
| 19:06:58 | jvoorhis | awesome |
| 19:07:15 | jvoorhis | this thing has legs :) |
| 19:11:05 | jvoorhis | evan: would you rather be added to the github project, or just fork? |
| 19:11:19 | evan | thats up to you. |
| 19:11:28 | evan | however you want the workflow to work |
| 19:11:32 | evan | i'm fine with. |
| 19:12:44 | jvoorhis | i just added evanphx as a collaborator |
| 19:12:55 | evan | sounds good! |
| 19:13:07 | evan | i'll poke at getting it running on rbx |
| 19:13:08 | evan | should be easy. |
| 19:13:12 | jvoorhis | excellent |
| 19:13:26 | jvoorhis | i *did* make a bit of use of Wayne's implicit #to_ptr hack |
| 19:13:33 | jvoorhis | it may take a little work to undo that |
| 19:13:49 | jvoorhis | and i also use FFI enums |
| 19:14:20 | jvoorhis | which afaict rubinius doesn't support yet |
| 19:14:29 | evan | i'm ok with #to_ptr at this point |
| 19:14:33 | slava | evan: I removed my primitive table, they're looked up by name now :) |
| 19:14:35 | evan | i've seen people use it enough |
| 19:14:43 | evan | that i think it's probably here to stay |
| 19:14:46 | evan | so i need to add support for it. |
| 19:14:47 | jvoorhis | ok |
| 19:14:58 | jvoorhis | how do you feel about enums? |
| 19:15:03 | evan | we should support them |
| 19:15:09 | evan | just haven't bother to fold in the implementation |
| 19:15:11 | evan | i'll do that. |
| 19:15:15 | jvoorhis | makes sense |
| 19:15:54 | jvoorhis | i'm happy to motivate some of that – i'd really like to see wider uptake of FFI |
| 19:17:16 | evan | me too. |
| 19:17:58 | dbussink | evan: did you find some time to take a look at the issues i had or digging into something else atm? |
| 19:18:06 | evan | i'll tell ya when i look |
| 19:18:08 | evan | i haven't yet. |
| 19:18:20 | evan | no need to keep nagging :) |
| 19:18:37 | dbussink | evan: hehe, i'll shut up for a while then :P |
| 19:18:46 | dbussink | or find new stuff ;) |
| 19:19:14 | evan | an easier repro would be great |
| 19:19:16 | evan | if you can find that. |
| 19:19:30 | dbussink | evan: i have tested the onig update that was recently released, seems to pass all specs |
| 19:19:40 | dbussink | released 5.9.2 not too long ago |
| 19:19:54 | dbussink | evan: i've been trying, but haven't been able too :( |
| 19:20:11 | dbussink | evan: although the issue happens pretty fast now and you only need a few gems installed |
| 19:20:18 | dbussink | evan: it was a lot worse actually |
| 19:21:05 | evan | is the ticket up to date? |
| 19:21:10 | evan | you mentioned it not happening in some cases |
| 19:21:32 | dbussink | evan: well, it happens for me now, so it should be up to date |
| 19:22:05 | evan | k |
| 19:22:18 | evan | i got a SIGSEGV yesterday running the activesupport spes |
| 19:23:40 | dbussink | evan: ah ok, well it seems to happen when compiling a lot of stuff and subsequently jitting in the compiler |
| 19:23:48 | dbussink | that's at least where it failed for me when it failed |
| 19:24:03 | dbussink | evan: so it could very well be the same or a very similar issue |
| 19:24:23 | dbussink | evan: is that segsegv reproducable? |
| 19:25:01 | evan | got it once |
| 19:25:05 | evan | i was trying to get to something else |
| 19:25:10 | evan | so ran again and it was gone |
| 19:25:17 | evan | but i know the scenario it was produced in |
| 19:25:22 | evan | so i'm going to investigate. |
| 19:25:35 | dbussink | evan: did you remove rbc's intermittently? |
| 19:25:52 | evan | thats what i'm going to do to reproduce it |
| 19:27:59 | dbussink | evan: ah, then it's also probably related, so if you are able to fix that, i'll test again first |
| 19:28:15 | evan | k |
| 19:29:24 | dbussink | evan: you're ok with upgrading oniguruma? http://www.geocities.jp/kosako3/oniguruma/ |
| 19:29:33 | evan | yeah |
| 19:29:36 | evan | esp if it's faster |
| 19:29:37 | evan | ! |
| 19:29:44 | dbussink | evan: or do we have local changes to it? i couldn't find any in the history |
| 19:29:52 | evan | no, we don't. |
| 19:29:56 | evan | i've been strict on that |
| 19:29:56 | dbussink | it has fixes for memory leaks |
| 19:30:01 | evan | since i know we would upgrade. |
| 20:26:58 | dbussink | evan: hmm, upgrading breaks a few specs though :( |
| 20:27:06 | evan | damn. |
| 20:30:05 | slava | morning |
| 20:30:10 | dbussink | evan: hmm, mri doesn't have the change that breaks it either |
| 20:30:20 | dbussink | evan: do you know if 1.9 and onig are kept in sync? |
| 20:30:25 | evan | i don't think they are. |
| 20:30:29 | evan | slava: allo! |
| 20:35:16 | evan | dbussink: just found a bug running the specs that was causing a crash. |
| 20:35:23 | evan | could very well be the same thing you saw. |
| 20:35:33 | dbussink | evan: ah, cool, something jit related? |
| 20:35:37 | evan | yep. |
| 20:35:48 | evan | the completely broken way that a JIT'd function is cleaned up. |
| 20:43:31 | boyscout | Remove Undefined constant all together - 0d65b32 - Evan Phoenix |
| 20:43:31 | boyscout | Call StringValue in Dir.mkdir and Dir.rmdir - caff583 - Evan Phoenix |
| 20:43:31 | boyscout | Fix Time#+ rounding microseconds - 50372bb - Evan Phoenix |
| 20:43:31 | boyscout | Fix how Kernel.require creates a LoadError (rails fix) - c5cbca3 - Evan Phoenix |
| 20:43:31 | boyscout | Add specs for cases found running active_support - 0e5a0cc - Evan Phoenix |
| 20:43:32 | boyscout | Disable JIT'd code cleanup, it's totally broken - 173dac2 - Evan Phoenix |
| 20:44:29 | evan | lunch! |
| 20:45:43 | dbussink | evan: i'm going to test it a bit :) |
| 20:47:12 | evan | k |
| 20:47:25 | boyscout | CI: rubinius: 173dac2 successful: 3024 files, 11752 examples, 35958 expectations, 0 failures, 0 errors |
| 21:59:38 | evan | dbussink: any luck? |
| 21:59:57 | dbussink | evan: still seeing the same kind of issues, so doesn't look like it solves it for me |
| 22:00:30 | evan | k |
| 22:23:53 | evan | dbussink: what ticket number has the info? |
| 22:23:56 | evan | i'm going to look into it now? |
| 22:24:00 | evan | s/now?/now. |
| 22:24:26 | dbussink | evan: http://github.com/evanphx/rubinius/issues#issue/171 |
| 22:24:51 | dbussink | evan: problem is that it doesn't fail like that now for me anymore |
| 22:25:03 | evan | thats why I asked you to update the ticket |
| 22:25:06 | evan | please do that. |
| 22:25:18 | dbussink | evan: well, it's not reliable now anymore |
| 22:25:37 | evan | still needs to be updated |
| 22:25:43 | dbussink | there are always some specs that fail, and sometimes a segfault, i haven't been able to reliably do it now after your last changes |
| 22:25:46 | evan | since your ticket says it's reliable. |
| 22:26:18 | dbussink | evan: it was for that revision then |
| 22:26:32 | evan | huh? |
| 22:26:51 | dbussink | evan: this was before your last few changes |
| 22:26:59 | evan | what revision? |
| 22:27:02 | evan | le sigh. |
| 22:27:11 | evan | this is what I meant by keeping the ticket up to date. |
| 22:27:51 | dbussink | evan: well, i'm pretty busy with something else atm, if i have time i'll update it again with more information on how to repro |
| 22:27:58 | evan | k |
| 22:28:05 | evan | i'll try what you've got |
| 22:28:08 | evan | see what happens |
| 22:28:10 | evan | UG. |
| 22:28:21 | evan | got a .rbc compile error. |
| 22:29:25 | evan | the ticket also doesn't saw what to run it under |
| 22:29:32 | evan | is this git master of datamapper? |
| 22:29:35 | dbussink | yeah |
| 22:29:41 | dbussink | i'll add a link |
| 22:29:58 | evan | edit the ticket |
| 22:30:00 | evan | and fix it |
| 22:30:03 | evan | rather than leaving it in a comment. |
| 22:30:07 | slava | wow, I didn't know skype was peer to peer |
| 22:32:01 | evan | you didn't? |
| 22:32:44 | evan | dbussink: looks like all those collection specs pass |
| 22:33:08 | dbussink | evan: yeah, i'm trying with an older revision to see whether that one still shows it |
| 22:33:39 | dbussink | evan: if you run ADAPTERS="in_memory" ../rubinius/bin/rbx -S rake spec you'll see stuff fail after some time |
| 22:33:48 | dbussink | evan: and those pass if run seperately |
| 22:33:55 | dbussink | but that's a real bitch to debug like that |
| 22:34:06 | dbussink | evan: not something you'd want to get into ;) |
| 22:35:48 | evan | i'll run them all |
| 22:35:50 | evan | see what happens. |
| 22:36:42 | evan | that doesn't seem to work |
| 22:36:51 | evan | it just complains about |
| 22:36:52 | evan | Missing some dependencies. Install them with the following commands: |
| 22:36:52 | evan | gem install rspec --version "~> 1.2.9" |
| 22:37:02 | evan | and rspec 1.3 is installed |
| 22:37:53 | dbussink | evan: hmm, probably a dev requirement, haven't tested if 1.3.0 breaks stuff on mri |
| 22:37:58 | dbussink | evan: but i have 1.2.9 here locally |
| 22:38:13 | dbussink | evan: i've got the repro, but that's with an older revision, not with the latest rubinius master |
| 22:38:31 | dbussink | evan: so it could be that that's your change that fixed that specific case |
| 22:39:50 | dbussink | evan: i've updated the issue with more information on the specific rubinius revision etc. |
| 22:39:53 | dbussink | http://github.com/evanphx/rubinius/issues/issue/171 |
| 22:39:59 | evan | ok |
| 22:51:48 | evan | i'm getting a bunch of failures |
| 22:51:55 | evan | no segfaults |
| 22:52:03 | evan | and a whole screen of yellow *'s |
| 22:52:08 | evan | i don't know what that means |
| 22:52:13 | dbussink | yeah, the yellow ones are fine, pending stuff |
| 22:52:20 | evan | geez |
| 22:52:21 | dbussink | it should be all green |
| 22:52:23 | evan | is the whole thing pending?! |
| 22:52:36 | evan | it's been just doing pending ones here for the last few minutes |
| 22:52:42 | dbussink | not every driver supports every part (yet) |
| 22:52:48 | dbussink | so those are shown as pending |
| 22:52:58 | evan | what does pending mean? |
| 22:53:25 | dbussink | that some feature is pending, not supported / working yet, but will be implemented in the future |
| 22:53:35 | evan | but to the specs |
| 22:53:46 | evan | because it appears to be running something for all those pending things |
| 22:53:51 | evan | not just skipping them |
| 22:54:01 | dbussink | evan: that's rspec's magic doing things i guess |
| 22:54:04 | evan | if it were skipping them |
| 22:54:09 | evan | i'd expect them to fly by |
| 22:54:30 | dbussink | evan: there could be setup / teardown stuff in there |
| 22:54:39 | evan | if so |
| 22:54:44 | evan | there is a shitton of that. |
| 22:54:45 | dbussink | i can also setup something that fails on elle if that would be more helpful? |
| 22:55:00 | evan | only slightly |
| 22:55:04 | evan | i'll still have to repro it here. |
| 22:56:10 | dbussink | hmm, maybe try aborting it? it fails really fast in like half of the cases for me here now |
| 22:56:33 | dbussink | with that huge command that loads up all specs and probably puts a strain on the compiler |
| 22:56:44 | evan | i'm going to let it finish |
| 22:56:47 | evan | it isn't stuck |
| 22:57:37 | evan | Finished in 762.211625 seconds |
| 22:57:37 | evan | 9368 examples, 322 failures, 3445 pending |
| 22:57:52 | evan | those pending numbers seem right? |
| 22:58:02 | dbussink | yeah, for in memory that's seems about right |
| 22:58:20 | dbussink | do you have a dev build |
| 22:58:21 | dbussink | ? |
| 22:58:52 | dbussink | because it's often a usz what i get and i saw that check is only enabled with dev enabled |
| 22:58:58 | evan | no, no dev build |
| 22:59:04 | evan | because i was hoping for the crash. |
| 22:59:09 | evan | wait |
| 22:59:14 | evan | you ONLY see it in dev mode? |
| 22:59:48 | dbussink | i see a sporadic crash during the spec runs, but far more often an usz with dev mode |
| 22:59:51 | evan | your ticket doesn't mention a usz. |
| 23:02:35 | dbussink | evan: i've added the usz i'm seeing now reasonably reliable (not always but like half of the time when running that command) |
| 23:02:43 | dbussink | when it happens, it happens at the very beginning |
| 23:02:57 | evan | ok, i just got a crash. |
| 23:03:19 | dbussink | ah ok, does it make any sense? |
| 23:03:50 | evan | i see it |
| 23:03:56 | evan | they never make sense at first |
| 23:04:04 | evan | gdb didn't get it |
| 23:04:08 | evan | because i ran it under rake |
| 23:04:10 | evan | so i'm trying again. |
| 23:09:04 | dbussink | evan: ah ok, hopefully you can get something useful out of it |
| 23:09:10 | dbussink | i really need to get some sleep |
| 23:09:14 | evan | it disappeared again |
| 23:09:16 | evan | ok, nite. |
| 23:09:46 | dbussink | evan: i can really understand the frustration, it's not a nice clean way to reproduce but i really haven't been able to properly isolate it further |
| 23:09:57 | dbussink | if you want to focus on other things, please do so :) |
| 23:09:58 | evan | i know. |
| 23:10:03 | evan | :) |
| 23:10:11 | evan | i'm frusterated with the crash |
| 23:10:12 | evan | not you |
| 23:10:12 | evan | :) |
| 23:10:22 | dbussink | hehe, ok, that's good to hear ;) |
| 23:10:24 | dbussink | good hunting! |
| 23:10:27 | dbussink | nite |
| 23:11:30 | evan | nite! |