Show enters and exits. Hide enters and exits.
| 00:01:11 | brixen | kronos_vano: I'll work on these strings a bit |
| 00:01:25 | brixen | kronos_vano: but a couple of things to think about... |
| 00:01:28 | evan | brixen: check IM. |
| 00:01:59 | tarcieri | hrmm |
| 00:02:03 | tarcieri | rbx just segv'd on me |
| 00:02:06 | tarcieri | and I can't reproduce it |
| 00:02:29 | evan | tarcieri: well, if you can work back to the crash in anyway, that would be great. |
| 00:02:55 | brixen | kronos_vano: think of describe as setting of the context for your expectations |
| 00:02:56 | tarcieri | I have the stack trace from the crash... that's about it :/ |
| 00:03:31 | boyscout | CI: rubinius: f79bf37 successful: 3460 files, 13708 examples, 41325 expectations, 0 failures, 0 errors |
| 00:03:32 | brixen | kronos_vano: anyway, I'll show you once I work on it a bit |
| 00:04:02 | tarcieri | http://gist.github.com/407021 if you're curious *shrug* |
| 00:04:25 | evan | tarcieri: hm, interesting ok |
| 00:04:29 | evan | better than nothing |
| 00:04:30 | evan | ! |
| 00:04:33 | tarcieri | heh |
| 00:04:35 | evan | glad we added the backtrace on segfault code |
| 00:05:33 | evan | tarcieri: oh, i fixed this one already. |
| 00:05:34 | kronos_vano | brixen, ok. describing specs is very hard for me |
| 00:05:40 | evan | tarcieri: it's fixed on head |
| 00:05:42 | tarcieri | evan: ok |
| 00:05:43 | tarcieri | cool |
| 00:05:58 | evan | _ZN8rubinius13VariableScope4Info9auto_markEPNS_6ObjectERNS_10ObjectMarkE + 280 |
| 00:05:59 | evan | is the key |
| 00:06:03 | evan | if you see a segfault with that in it |
| 00:06:09 | evan | then thats the one I fixed. |
| 00:06:16 | tarcieri | aight |
| 00:06:19 | evan | VariableScope::auto_mark+280 |
| 00:06:38 | brixen | kronos_vano: I know, I'm just trying to help you think about *how* to describe it |
| 00:06:44 | evan | I should fix the unmangler for linux |
| 00:06:46 | brixen | kronos_vano: I understand the language is a pain :) |
| 00:18:10 | kronos_vano | Next week i want start experiment with improving performance of Packer. Is it ok? Fixing bugs is so boring. Making bugs is more funny :) |
| 00:18:20 | evan | hehe |
| 00:18:22 | evan | go right ahead. |
| 00:18:32 | evan | if you're going to be experimenting though |
| 00:18:38 | evan | please do it either on a fork or in a branch |
| 15:41:44 | brixen | Defiler: any luck with that const weirdness you were seeing? |
| 15:44:01 | Defiler | unfortunately I haven't had a chance to work on it again. crunch-tastic until next week |
| 15:44:18 | Defiler | but I've got it saved off ready to look at when I can |
| 15:44:41 | brixen | ok cool |
| 15:57:07 | evan | brixen: the debugger is looking o/~ aaawwwesome o/~ |
| 15:57:23 | evan | a quick teaser: |
| 15:57:32 | evan | | Breakpoint: Blah#foo(name="evan") at scratch/breakpoint2.rb:6 (+9) |
| 15:57:33 | evan | | 6: puts "done" |
| 16:01:45 | brixen | sweeeet! |
| 16:02:14 | brixen | I'm trying to track down a couple weird spec fails after syncing |
| 16:02:26 | brixen | I think I'm going to tag and push then work on them |
| 16:02:54 | brixen | also, marcandre is fixing a bunch of Matrix bugs which causes us to fail the specs |
| 16:03:03 | brixen | since we are using the broken 1.8.7 stuff |
| 16:03:21 | brixen | what do you think about importing just the fixed Matrix from 1.9? |
| 16:03:38 | evan | depends on how big it is |
| 16:03:42 | evan | but it's probably ok. |
| 16:03:47 | brixen | k |
| 16:04:01 | brixen | it's not that it is big, just that Matrix was riddled with bugs |
| 16:04:10 | brixen | I can't see any drawback to having the fixed version |
| 16:04:11 | evan | yeah, i recall. |
| 16:04:23 | evan | well, other than if people use it then go back to MRI |
| 16:04:26 | evan | they'll be sad. |
| 16:04:30 | evan | :) |
| 16:04:33 | brixen | heh |
| 16:04:39 | brixen | what a minus... |
| 16:04:46 | slava | the matrix is riddled with bugs? who would've thought |
| 16:05:49 | brixen | heh |
| 16:06:06 | brixen | oh wolfram alpha, how much you have to learn... |
| 16:06:25 | brixen | Rubinius vs Python returns results for... wait for it... snakes |
| 16:06:47 | brixen | Rubinius vs MRI... an airport in Alaska |
| 16:06:58 | brixen | from which you can probably see Russia or something |
| 16:07:46 | evan | hah |
| 16:07:58 | brixen | heh, closest interpretation for Rubinius... Blennius: which is in the class of ray-finned fish! |
| 16:08:05 | evan | oh cool |
| 16:08:13 | brixen | Rubinius 2.0 should be Blennius! |
| 16:08:27 | evan | lets get some other ideas first |
| 16:08:31 | brixen | heh |
| 16:08:31 | evan | before we settle on something |
| 16:08:32 | evan | :D |
| 16:08:44 | evan | Rubinius started out as Rubinus |
| 16:08:52 | brixen | yeah |
| 16:08:53 | evan | so no surprise there are latin names that are close |
| 16:11:44 | evan | or maybe Vermilion |
| 16:11:45 | evan | http://en.wikipedia.org/wiki/Vermilion_Flycatcher |
| 16:11:51 | evan | look at the latin name |
| 16:15:20 | brixen | heh, cool |
| 16:27:00 | brixen | hmm, this Float issue sucks |
| 16:27:34 | evan | Float sucks in general. |
| 16:27:40 | evan | i know i'm not helping. |
| 16:28:28 | brixen | marcandre: ping |
| 16:28:32 | Defiler | Floats are great, people just use them too much :) |
| 16:28:43 | brixen | marcandre: we need to discuss redmine #3273 |
| 16:30:04 | brixen | Rootbeer Floats are great |
| 16:31:24 | brixen | the stupid thing is people will not give up the idea that floats should roundtrip in strings of some small # of characters |
| 16:31:24 | slava | evan: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1641 |
| 16:31:46 | slava | evan: this paper discusses a better approach to tracking local variables for GC than just dumping them to the operand stack at every subroutine call |
| 16:31:59 | evan | oh? whats their idea? |
| 16:32:32 | slava | compute the set of live values at every gc point, store it in a map off to the side |
| 16:32:49 | evan | you know something is up when yon go to a citeceer url and more than half of the citation links are the "you've visited this" color |
| 16:32:55 | brixen | marcandre: http://gist.github.com/407768 and rubyspec commit 43bc4bae |
| 16:32:56 | slava | heh |
| 16:37:23 | evan | slava: looks like it requires strict control of the stack layout |
| 16:37:28 | evan | and it's creating maps |
| 16:38:02 | slava | I think llvm has a gc map facility though |
| 16:38:05 | slava | or does that not work for jit? |
| 16:38:20 | evan | it has one someone hacked in for ocaml |
| 16:38:33 | evan | but i found out it's really no better than dumping to the operand stack. |
| 16:38:46 | evan | because it still just dumps everything to the C stack |
| 16:38:57 | evan | and gives you a map of where the variables are in the C stack |
| 16:39:41 | slava | it gives the compiler more flexibility when performing optimizations |
| 16:39:55 | evan | i think thats true hypothetically |
| 16:40:01 | evan | but it's not true about LLVM atm. |
| 16:41:08 | evan | don't forget, i'm not dumping to the operand stack |
| 16:41:24 | evan | since i'm always reading and writing from teh operand stack |
| 16:41:30 | evan | it's the primary home of variables |
| 16:41:40 | evan | LLVM is free to optimize out redundent accesses |
| 16:41:42 | evan | which it does |
| 16:41:50 | evan | and when we cross a GC point |
| 16:42:08 | evan | it knows that it can't use the previous SSA variables for reads |
| 16:42:31 | slava | but it should be able to use the previous SSA value |
| 16:42:33 | slava | that's the point |
| 16:42:54 | evan | why? |
| 16:42:58 | evan | why would it be able to? |
| 16:42:58 | slava | you'll get better optimizations by having operand stack entries become SSA values |
| 16:43:01 | evan | it's a GC variable |
| 16:43:05 | evan | it might have moved. |
| 16:43:08 | slava | instead of factoring it into lots of small live ranges |
| 16:43:28 | evan | the movement happens external to the optimizations, so the optimizations are conservative |
| 16:43:29 | slava | so llvm's register allocator spills values to the C stac kacross calls |
| 16:43:44 | slava | all you need to do is have the GC know which stack slots are GC roots |
| 16:43:45 | slava | and update those |
| 16:43:51 | evan | "all you need" |
| 16:43:52 | evan | :/ |
| 16:44:03 | slava | heh |
| 16:44:42 | evan | so, assume no GC variables are in registers because LLVM spills them entirely |
| 16:44:59 | evan | the only upside is that the GC would write to the stack location that LLVM would reload from |
| 16:45:04 | slava | oh, I guess you also have the whole callee-save and caller-save register thing |
| 16:45:17 | evan | which actually doesn't work. |
| 16:45:23 | slava | how so? |
| 16:45:30 | evan | because that would happen at the machine code gen/opt level. |
| 16:45:45 | evan | and LLVM would have to be told "anything at this stack position must be reread" |
| 16:45:55 | slava | won't it be re-read anyway? |
| 16:46:04 | slava | when it retrns to executing that frame |
| 16:46:07 | evan | well, no. |
| 16:46:10 | evan | because say I do. |
| 16:46:16 | evan | $klass = $obj->klass; |
| 16:46:25 | evan | oh, $klass would be updated too |
| 16:46:30 | slava | yeah, if its a gc root |
| 16:46:40 | evan | well, anywho |
| 16:46:52 | slava | see, having the same SSA value is stronger than ahving two SSA values which "must alias" or whatever |
| 16:47:00 | evan | this requires me to have a very intimate knowledge of how the ocaml GC mapper works |
| 16:47:10 | evan | which I don't yet have. |
| 16:47:19 | evan | slava: sure. |
| 16:47:27 | slava | I think most llvm-based jits take the 'operand stack' approach |
| 16:48:05 | evan | macruby doesn't |
| 16:48:13 | slava | it uses the ocaml gc mappeR? |
| 16:48:14 | evan | it lowers everything to SSA variables |
| 16:48:26 | evan | no, it's using the objective-c 2.0 GC |
| 16:48:29 | evan | which is conservative. |
| 16:48:34 | slava | oh, ok |
| 16:48:40 | evan | which doesn't count :) |
| 16:49:16 | slava | I do the same thing yo udo at subroutine calls |
| 16:49:25 | slava | at inline allocations I compute precise stack maps |
| 16:49:25 | slava | right now I'm wo |
| 16:49:31 | slava | rking on computing stack maps for FFI call sites |
| 16:49:35 | slava | and then normal call sites |
| 16:49:50 | slava | the goal is to lower more stuff to SSA values |
| 16:50:43 | evan | i do want to get more into how to push stuff into the lower LLVM levels |
| 16:50:54 | evan | so this is a good place for me to research. |
| 16:54:13 | slava | one hard thing about using LLVM must be knowing how to get it to do what you want :) |
| 16:55:04 | evan | it's not too hard |
| 16:55:09 | evan | because the LLVM devs are really nice guys. |
| 16:55:22 | evan | so I just have to formulate my question properly |
| 16:55:32 | evan | to get pointed in the right direction |
| 16:55:57 | slava | hehe |
| 17:13:17 | boyscout | Updated CI specs to RubySpec 2396c9fe. - 87d498d - Brian Ford |
| 17:13:17 | boyscout | Updated CI tags for rubyspec sync. - c204c4f - Brian Ford |
| 17:13:34 | brixen | evan: so, I need to write some more Signal.trap specs |
| 17:13:42 | brixen | then I'll fix that one tag |
| 17:13:59 | brixen | basically, in mri, Signal.trap(:<SIG>, nil) is allowed |
| 17:14:16 | brixen | and Signal.trap returns "DEFAULT" instead of nil if no signal handler is set |
| 17:14:39 | brixen | Signal.trap(X, nil) actually sets it to "IGNORE" |
| 17:15:02 | evan | :/ |
| 17:15:06 | evan | yeah, i noticed that we had none. |
| 17:15:09 | brixen | first I'm going to look into adding matrix and set |
| 17:15:33 | evan | k |
| 17:19:02 | brixen | ruby 1.8.8 :( |
| 17:19:04 | brixen | le sigh |
| 17:19:26 | brixen | basically, not all the enumerator stuff got fixed in 1.8.7 |
| 17:19:33 | evan | what?! |
| 17:19:33 | brixen | so eg Set is being fixed in 1.8.8 |
| 17:19:34 | evan | :/ |
| 17:19:36 | brixen | oh well |
| 17:19:39 | brixen | whatevs |
| 17:19:55 | brixen | I'm just tagging these spurious "should raise LJE" |
| 17:20:50 | brixen | what I could do is convert all these version guards to with_feature(:enumerators) |
| 17:20:55 | brixen | that would probably be the best |
| 17:21:11 | evan | where did you see the thing about 1.8.8 |
| 17:21:21 | boyscout | CI: rubinius: c204c4f successful: 3462 files, 13730 examples, 41332 expectations, 0 failures, 0 errors |
| 17:21:26 | brixen | I pulled set.rb from MRI |
| 17:21:45 | brixen | and marcandre added version guards for 1.8.8 to the specs |
| 17:21:53 | evan | you're tagging what? |
| 17:22:13 | brixen | see spec/ruby/library/set/classify_spec.rb |
| 17:22:29 | evan | what do you mean LJE |
| 17:22:33 | evan | we're don't have LJE anymore. |
| 17:22:38 | brixen | LocalJumpError |
| 17:22:39 | evan | LocalJumpError? |
| 17:22:39 | evan | ok. |
| 17:22:44 | evan | that means that code is crazy. |
| 17:22:50 | evan | in set |
| 17:23:06 | brixen | it's not crazy, it just got around to adding enumerator support |
| 17:23:42 | brixen | which is supposedly going to be in 1.8.8 for set.rb |
| 17:23:56 | brixen | whereas everything else got it in 1.8.7 or some patchlevel thereof |
| 17:24:22 | evan | UG |
| 17:24:37 | evan | it's fucking STUPID that that set.rb won't run on 1.8.7 then. |
| 17:24:40 | evan | on MRI |
| 17:24:50 | evan | because it sounds like it's using loop stop iterations or something |
| 17:25:55 | evan | maybe this will cheer you up |
| 17:25:58 | brixen | I think it's reasonable to use with_feature(:enumerators) |
| 17:26:00 | evan | https://gist.github.com/7c82130901c5a0868a01 |
| 17:27:10 | brixen | sweet! |
| 17:27:30 | evan | :) |
| 17:28:05 | evan | i'm trying to decide if I should print out the values of the arguments in the main line for the frame |
| 17:28:24 | evan | initially that seemed like a good idea, but it's problematic |
| 17:28:25 | brixen | I like how you have it there |
| 17:28:27 | evan | because it could get really big. |
| 17:28:30 | brixen | hmm |
| 17:28:33 | evan | maybe just the names? |
| 17:28:41 | evan | #load_script(path) |
| 17:28:51 | brixen | sure |
| 17:29:45 | brixen | could make it really fancy: if it's an immediate, print it; if an object, #inspect it and add ... after 20 chars or something |
| 17:29:59 | evan | yeah, that was my idea too |
| 17:30:04 | evan | i'll leave that for the next go around. |
| 17:30:04 | brixen | of course, this could be a mode you toggle |
| 17:30:18 | brixen | by default, #load_script(path) would be great |
| 17:34:25 | evan | https://gist.github.com/5dd9742956f5083d3613 |
| 17:40:23 | brixen | that's cool |
| 17:44:25 | evan | rad |
| 17:44:27 | evan | added frame |
| 17:44:40 | evan | so you can move around and inspect data at any frame along the backtrace |
| 17:44:57 | evan | ok, I think this good enough to push. |
| 17:47:40 | brixen | that is awesome |
| 17:47:56 | evan | i'm adding a quick variable system |
| 17:48:04 | evan | to allow you to set variables |
| 17:52:33 | brixen | fsking mri, way to make everything 5x more complicated than it needs to be |
| 17:52:58 | brixen | evan: new set.rb with tags for stupid LJE errors or no new set.rb? |
| 17:54:02 | evan | well |
| 17:54:05 | evan | i'd say no new set.rb |
| 17:54:09 | brixen | k |
| 17:54:14 | evan | can we find a set.rb in the MRI source thats not for 1.8.8? |
| 17:54:20 | evan | go back in time a little bit |
| 17:54:28 | evan | or did the bug fixes get made just for 1.8.8 |
| 17:54:53 | brixen | the bug fixes are for 1.8.8+ |
| 17:55:08 | brixen | bug fixes plus enumerator support |
| 17:55:19 | brixen | which is a bug imo |
| 17:55:32 | brixen | if 1.8.7 added enumerators, it should have been done uniformly |
| 17:57:20 | brixen | for the love of... |
| 17:57:57 | brixen | matrix had ErrOperationNotDefined for ** with float arg, but changed it to ErrOperationNotImplemented |
| 17:58:00 | brixen | why? |
| 17:58:19 | evan | for fun. |
| 17:59:47 | brixen | http://gist.github.com/407864 |
| 17:59:51 | brixen | hopeless :/ |
| 18:00:17 | evan | :/ |
| 18:00:22 | evan | ok, lets abort doing matrix for now |
| 18:00:35 | evan | we're clearly going to need to take a long approach to it. |
| 18:01:19 | brixen | no, it's fine |
| 18:01:22 | brixen | that was one failure |
| 18:01:34 | brixen | I'm just changing it back to the old exception for now |
| 18:01:42 | brixen | better that the stupid thing actually works |
| 18:02:12 | brixen | it's just the approach that is so... omgwhatwhyseriously |
| 18:02:50 | evan | ok |
| 18:03:07 | evan | is it a big enough change that it should not go in 1.0.1? |
| 18:04:39 | brixen | I think it should go in 1.0.1 but you can look at it |
| 18:04:42 | brixen | I'm about to push it |
| 18:05:10 | evan | k |
| 18:11:52 | brixen | yeah, this fixes like 72 bugs |
| 18:12:01 | evan | ok |
| 18:12:21 | spastorino | hi guys ideas on what's going on here http://pastie.org/969839 |
| 18:12:57 | evan | yikes |
| 18:12:59 | evan | something very bad. |
| 18:13:12 | evan | Rubinius has loaded an extension compiled for MRI |
| 18:13:33 | evan | i wonder if this is another rvm bug. |
| 18:13:34 | spastorino | :D |
| 18:13:35 | Defiler | are you using bundler on that project, spastorino? |
| 18:13:42 | spastorino | yes |
| 18:13:45 | spastorino | it's rails |
| 18:13:53 | Defiler | rm -rf .bundle && bundle install |
| 18:13:55 | evan | because rbx-1.0.0-20100514/gems/json-1.4.3/ext/json/ext/json/ext/parser.so should not be calling rb_define_method in libruby1.8 |
| 18:13:56 | Defiler | try that |
| 18:14:07 | Defiler | you probably have MRI c extensions built in there |
| 18:14:11 | evan | Defiler: it's not using a bundled json gem. |
| 18:14:21 | evan | Defiler: bundler is supposed to use a different directory for rbx |
| 18:14:23 | evan | is it not? |
| 18:14:45 | Defiler | not to my knowledge |
| 18:14:53 | evan | bad bad bad. |
| 18:14:56 | spastorino | i deleted all |
| 18:14:58 | Defiler | you're meant to just do a 'bundle install' when you change architectures |
| 18:14:58 | spastorino | let me see |
| 18:15:04 | spastorino | i had done this |
| 18:15:04 | Defiler | and not check in the binaries |
| 18:15:09 | spastorino | but let me check again |
| 18:15:11 | evan | Defiler: could you please double check the path bundler is putting stuff into? |
| 18:15:14 | evan | i need to report than a bundler bug. |
| 18:16:06 | Defiler | checking it now |
| 18:18:28 | dbussink | evan: i've seen bundler use a different path for different impls |
| 18:18:36 | Defiler | I just did a 'bundle install' using rvm's rbx-head in a clean project |
| 18:18:37 | dbussink | maybe an older bundler version |
| 18:19:04 | Defiler | and it installs them properly to the rubygems dir |
| 18:19:11 | wayneeseguin | bug? |
| 18:19:14 | evan | Defiler: what dir? |
| 18:19:22 | evan | wayneeseguin: check out spastorino's pastie |
| 18:19:46 | Defiler | e.g. /Users/wilson/.rvm/gems/rbx-head/gems/haml-3.0.4 |
| 18:19:58 | wayneeseguin | spastorino: show me your 'rvm info' |
| 18:20:00 | evan | Defiler: ok. |
| 18:20:26 | Defiler | and "bundle exec gem which haml" reports /Users/wilson/.rvm/gems/rbx-head/gems/haml-3.0.4/lib/haml.rb |
| 18:20:35 | Defiler | so it is getting the proper path at execution time as well |
| 18:20:36 | spastorino | wayneeseguin: i'm reinstalling rbx |
| 18:20:46 | spastorino | i think the problem was on bundler |
| 18:20:51 | spastorino | when i did bundle install |
| 18:21:08 | spastorino | perhaps i get the gems from MRI copied on rbx gems |
| 18:21:10 | wayneeseguin | spastorino: ok, let me know. I'll adjust anything needed. |
| 18:21:13 | spastorino | checking again |
| 18:21:16 | Defiler | yeah, 'gem which haml' returns the same path both in and out of bundler |
| 18:25:33 | Defiler | that's good; it has gotten simpler in the 0.9 era, definitely |
| 18:26:17 | boyscout | Make sure the arguments are Strings. @bugfix - 94481ac - Evan Phoenix |
| 18:26:18 | boyscout | Set the stack start and size properly in a thread. @bugfix - 7cff50f - Evan Phoenix |
| 18:26:18 | boyscout | Rewire debugger infrastructure, add new simple debugger. - 6035068 - Evan Phoenix |
| 18:26:18 | boyscout | Merge branch 'debugger' - add9d4b - Evan Phoenix |
| 18:26:48 | evan | brixen: http://gist.github.com/407903 |
| 18:26:54 | evan | thats my sample script I was using to debug |
| 18:27:03 | brixen | sweet |
| 18:27:06 | evan | i'd set a breakpoint on as "b Blah#foo:6" |
| 18:27:37 | brixen | what is Debugger.here? |
| 18:27:45 | evan | thats like Kernel#breakpoint |
| 18:27:48 | brixen | ok |
| 18:27:53 | evan | says "launch the debugger here" |
| 18:27:57 | evan | it's the same as .start currently |
| 18:28:05 | brixen | ah ok |
| 18:28:06 | evan | because it's smart enough to not reinitialize itself |
| 18:31:05 | evan | please put it through it's paces |
| 18:31:12 | evan | since i'm sure i've forgotten something |
| 18:31:16 | evan | other than control flow :) |
| 18:34:18 | brixen | is that a hint that you want me to fix a bunch of bugs? :) |
| 18:34:35 | evan | nah |
| 18:34:36 | evan | just tell me. |
| 18:34:41 | evan | you can if you want |
| 18:34:44 | brixen | heh |
| 18:34:46 | evan | but i want to hear about them |
| 18:34:54 | evan | because i don't know where the current scheme will fall down yet. |
| 18:34:59 | brixen | right |
| 18:35:06 | brixen | of course, I'd let you know :) |
| 18:35:09 | evan | :) |
| 18:36:01 | brixen | so, I think the best way to add this as -Xdebug is not to breakpoint the script, but just drop into the debugger as soon as it's feasible in loader.rb |
| 18:36:09 | brixen | that gives the greatest flexibility |
| 18:36:18 | brixen | and you could debug -e lines then |
| 18:36:49 | evan | well, we can do that if you'd like |
| 18:36:57 | evan | but my feel was it's not very useful for real code |
| 18:37:09 | evan | because when you've got a whole mess of code |
| 18:37:14 | evan | you don't want to stop before any is loaded |
| 18:37:17 | evan | you want to stop after it's all loaded. |
| 18:37:26 | brixen | can you not br and cont? |
| 18:37:35 | evan | no |
| 18:37:39 | brixen | oh |
| 18:37:41 | evan | because there is nowhere to br to |
| 18:37:47 | evan | you haven't loaded anything to set a breakpoint at. |
| 18:37:59 | brixen | well! |
| 18:38:06 | brixen | first feature request then! |
| 18:38:11 | brixen | deferred br's |
| 18:38:20 | brixen | gdb let's me do that :) |
| 18:38:25 | evan | thats what I was asking adam about yesterday |
| 18:38:34 | evan | when should I resolve any deffered br's? |
| 18:38:42 | evan | after require returns? |
| 18:38:44 | brixen | when loading |
| 18:38:45 | brixen | yeah |
| 18:38:47 | evan | i could add a hook in require for the debugger to use |
| 18:38:51 | brixen | sure |
| 18:39:05 | evan | ok, that should be easy |
| 18:39:14 | evan | i'll do that after I cherry pick stuff into 1.0-bugfix |
| 18:39:14 | brixen | I bet you can find where to add it in 2 sec flat |
| 18:39:18 | brixen | ok |
| 18:39:25 | boyscout | CI: rubinius: add9d4b successful: 3462 files, 13730 examples, 41332 expectations, 0 failures, 0 errors |
| 18:39:27 | brixen | what with the fancy new codes and all |
| 18:39:46 | evan | mm nice |
| 18:39:51 | evan | gitk lets me cherry pick. |
| 18:39:56 | brixen | nice |
| 18:40:16 | evan | except the font blows |
| 18:40:19 | evan | how do I fix that again.. |
| 18:41:14 | evan | oh ha! |
| 18:41:15 | spastorino | evan: wayneeseguin: all is working now |
| 18:41:16 | evan | i have a .gitk |
| 18:41:19 | evan | hilarious. |
| 18:41:24 | evan | spastorino: oh good! |
| 18:41:51 | spastorino | many things using bundler and rvm |
| 18:41:59 | dbussink | evan: does this count as a bug? https://gist.github.com/5869393acae701f31f1a |
| 18:42:21 | spastorino | ~/.gem ~/.bundle rails/.bundle and .rvm/(gems, bundle) dirs |
| 18:42:21 | dbussink | evan: there a nice gitx branch |
| 18:42:29 | evan | dbussink: eh? |
| 18:42:34 | evan | gitx doesn't do cherry picks |
| 18:42:51 | dbussink | evan: http://github.com/brotherbard/gitx |
| 18:42:56 | evan | dbussink: sure, that counts as a bug AND counts as you being dumb |
| 18:43:00 | evan | you didn't say what to print! |
| 18:43:06 | dbussink | evan: i know :P |
| 18:43:10 | dbussink | evan: but that's why i tried |
| 18:43:16 | dbussink | because it's stuff i'd forget myself ;) |
| 18:43:18 | dbussink | evan: "xperimental fork of Pieter's nice git GUI for OS X. Includes: sidebar, fetch, pull, push, add remote, merge, cherry-pick, rebase, clone, clone to" |
| 18:43:30 | dbussink | it's a whole lot better than the standard gitx |
| 18:43:40 | evan | ok, i'll try it. |
| 18:43:53 | wayneeseguin | spastorino: was it something I need to adjust for or ? |
| 18:44:03 | dbussink | evan: want me to continue with my annoying testing? :P |
| 18:44:09 | dbussink | i'm good at monkey testing |
| 18:44:18 | evan | dbussink: why do you go ahead and fix those annoying bugs too |
| 18:44:19 | evan | :) |
| 18:45:28 | dbussink | evan: maybe i will ;) |
| 18:45:39 | evan | maybe you will! |
| 18:47:32 | evan | dbussink: oh wow. |
| 18:47:37 | evan | this other gitx is totally different. |
| 18:47:39 | dbussink | evan: how do i quit the debugger? |
| 18:47:47 | evan | hit c |
| 18:47:49 | evan | to continue |
| 18:47:54 | evan | and your script will run to the end. |
| 18:48:00 | dbussink | ah ok, cool |
| 18:48:02 | spastorino | wayneeseguin: i really don't know |
| 18:48:07 | wayneeseguin | lol *majik* |
| 18:48:14 | spastorino | wayneeseguin: let's private |
| 18:48:20 | wayneeseguin | giggity |
| 18:49:15 | evan | rad. |
| 18:49:18 | evan | this new gitx is the bomb. |
| 18:49:26 | evan | made doing these cherry pick trivial. |
| 18:49:40 | dbussink | evan: good to hear :) |
| 18:53:01 | dbussink | evan: better than poking around in ugly gitk ;) |
| 18:53:08 | evan | heh |
| 18:53:12 | evan | i fixed the fonts in gitk at least |
| 18:55:02 | evan | I wish there was a way to associate cherry picked commits with their original. |
| 18:56:27 | evan | oh there is |
| 18:56:32 | evan | -x |
| 18:56:36 | evan | time to hack gitx! |
| 18:56:59 | brixen | hacker! |
| 18:57:33 | evan | woop! |
| 18:57:42 | evan | i do like that gitx just shells out to git |
| 18:57:45 | evan | makes it easy to make these changes. |
| 18:57:54 | brixen | so, Kernel#private_methods is just terribly broken in 1.8? |
| 18:58:02 | evan | perhaps? |
| 18:58:06 | brixen | it does not respect the superclass flag |
| 18:58:26 | evan | in MRI it doesn't? |
| 18:59:13 | brixen | http://gist.github.com/407937 |
| 19:02:08 | brixen | evan: hmm, do you want @bugfix tags in these matrix commits? |
| 19:02:25 | evan | if there is no ticket, yeah. |
| 19:02:35 | brixen | k |
| 19:02:36 | evan | makes it easier for me to figure out how to pick them. |
| 19:03:41 | brixen | well, I've got specs, new mspec matchers, etc here |
| 19:03:49 | boyscout | More specs for Bignum#divmod - 1d3fa56 - Ivan Samsonov (1.0-bugfix) |
| 19:03:49 | boyscout | Repair Bignum#divmod for cases with negative numbers. Fixes #319. - d3a4259 - Ivan Samsonov (1.0-bugfix) |
| 19:03:49 | boyscout | Updated CI specs to RubySpec 2396c9fe. - 037ee04 - Brian Ford (1.0-bugfix) |
| 19:03:49 | boyscout | Updated CI tags for rubyspec sync. - 810232a - Brian Ford (1.0-bugfix) |
| 19:03:49 | boyscout | Make sure the arguments are Strings. @bugfix - eb7145a - Evan Phoenix (1.0-bugfix) |
| 19:03:49 | boyscout | Set the stack start and size properly in a thread. @bugfix - 1b57730 - Evan Phoenix (1.0-bugfix) |
| 19:04:07 | evan | boyscout: hm, ok. |
| 19:04:18 | evan | putting @bugfix on all of them is a pain |
| 19:04:19 | evan | hm |
| 19:06:44 | brixen | git rb -i ftw |
| 19:09:21 | evan | i'm going to prune some of our public branches |
| 19:10:02 | evan | a lot of them are stale and the work there is no longer useful. |
| 19:10:09 | boyscout | Imported lib/matrix.rb from 1.9 with many bug fixes. @bugfix - b240f79 - Brian Ford |
| 19:10:09 | boyscout | Revert Matrix#** behavior for exception to 1.8 version. @bugfix - f718053 - Brian Ford |
| 19:10:09 | boyscout | Removed CI tags for passing Matrix specs. @bugfix - 2d9e2e5 - Brian Ford |
| 19:10:09 | boyscout | Added have_private_method matcher to mspec. @bugfix - 7dd37f0 - Brian Ford |
| 19:10:09 | boyscout | Fixed Matrix.new spec. @bugfix - 19957da - Brian Ford |
| 19:10:12 | brixen | good idea |
| 19:11:18 | brixen | so, what is the reason for bugfix releases? |
| 19:11:45 | evan | huh? |
| 19:11:50 | brixen | sounds like a silly question but it's not |
| 19:12:08 | brixen | for example, are bug fix releases likely to get into a distro? |
| 19:12:14 | brixen | not likely |
| 19:12:19 | evan | well |
| 19:12:20 | brixen | they would be feature releases |
| 19:12:28 | evan | the idea is to allow us to get bugfixes out faster |
| 19:12:34 | evan | without destabalizing |
| 19:12:44 | brixen | right |
| 19:13:02 | brixen | but rather than any bug fix, maybe bugfix releases should only be for critical bugs |
| 19:13:19 | brixen | I'm trying to see where someone would install the bugfix release vs using master |
| 19:13:28 | brixen | that use case would be the reason for a bugfix release |
| 19:13:34 | evan | well, master is going to have new features |
| 19:13:39 | brixen | right |
| 19:13:42 | brixen | but they should be sane |
| 19:13:45 | evan | it's more of a moving target |
| 19:13:49 | brixen | we don't put unstable stuff in master |
| 19:14:01 | evan | well, but it's hard for some no say "hey, we're in production, but we need to use master because thats where the bugfix is" |
| 19:14:08 | evan | s/no/to/ |
| 19:14:21 | brixen | for using MRI's master, sure |
| 19:14:28 | brixen | ours is quite a bit different |
| 19:15:14 | brixen | seems like too much emphasis on bugfix releases to me, at this point |
| 19:16:24 | evan | hm. |
| 19:16:30 | evan | ok, i'm going to grab some lunch |
| 19:16:33 | evan | then lets discuss this. |
| 19:16:37 | brixen | me too! |
| 19:18:02 | boyscout | CI: rubinius: 19957da successful: 3462 files, 13782 examples, 41439 expectations, 0 failures, 0 errors |
| 21:36:59 | dbussink | what % of rubyspec do we pass these days actually? |
| 21:41:39 | brixen | ~96% |
| 21:42:07 | brixen | we could gain on that number but we keep writing more specs :P |
| 21:42:23 | brixen | at least someone is... ;) |
| 21:43:17 | dbussink | brixen: i was looking a bit at failing stuff, but a lot is also stuff tagged as bugs in mri |
| 21:43:57 | dbussink | but i'm going to get some sleep :) |
| 21:44:01 | dbussink | nite! |
| 21:45:11 | brixen | dbussink: nite! |
| 21:48:44 | boyscout | Cleanup and speed up Struct - cfd31fe - Evan Phoenix |
| 21:48:47 | evan | heh |
| 21:49:04 | evan | Struct.new on created Structs is now 10x faster. |
| 21:51:23 | brixen | sweet |
| 21:53:16 | boyscout | Specialize Struct::Tms - e539ae0 - Evan Phoenix |
| 21:54:21 | evan | oops, that was premature. |
| 21:56:33 | brixen | man, wtf |
| 21:56:41 | boyscout | CI: rubinius: cfd31fe successful: 3462 files, 13782 examples, 41439 expectations, 0 failures, 0 errors |
| 21:56:53 | brixen | setting a trap in 1.9 does not trap the signal in thet spec, but does on the cmd line |
| 21:57:46 | evan | ug |
| 21:57:54 | evan | I think this is why I avoided doing Signal.trap |
| 21:58:24 | brixen | here's what I have so far http://gist.github.com/408168 |
| 21:58:30 | brixen | feedback? |
| 21:58:47 | boyscout | Staticly specialize Struct::Tms - 403295e - Evan Phoenix |
| 21:59:04 | brixen | I tried to avoid sending signals in the .trap specs, but it's the only way I could think of testing those that do |
| 21:59:50 | evan | well |
| 21:59:51 | evan | yeah |
| 21:59:56 | evan | you have to send signals |
| 21:59:58 | evan | i think thats fine |
| 22:00:04 | evan | i wouldn't go much further |
| 22:00:18 | brixen | yeah, this covers the cases I can think of |
| 22:00:18 | evan | because how you can spec that a signal is on the default or ignored. |
| 22:00:24 | brixen | right |
| 22:01:28 | brixen | cool, only 2f/5e on rbx :) |
| 22:02:00 | evan | really? |
| 22:02:02 | evan | which ones? |
| 22:02:36 | evan | oh hm |
| 22:02:39 | brixen | http://gist.github.com/408174 |
| 22:02:46 | evan | probably the tests for setting it to ignore, then the next one returning "IGNORE" |
| 22:03:22 | brixen | shouldn't be hard to fix these |
| 22:03:28 | evan | :/ |
| 22:03:31 | evan | i thought I just did |
| 22:03:32 | evan | is all. |
| 22:03:37 | brixen | heh |
| 22:03:41 | brixen | hard to know with no specs |
| 22:03:49 | brixen | I didn't know 1/2 of this |
| 22:04:35 | evan | oh der. |
| 22:04:36 | evan | yeah |
| 22:04:36 | evan | ok |
| 22:04:39 | evan | i can fix these |
| 22:04:41 | evan | i was just in there. |
| 22:04:59 | brixen | ok, I'll push the specs |
| 22:05:01 | brixen | sec.. |
| 22:05:03 | evan | k |
| 22:05:05 | brixen | er well, hm |
| 22:05:11 | brixen | should I tag them then? |
| 22:05:14 | evan | nah |
| 22:05:15 | evan | i'll do it now. |
| 22:05:52 | brixen | Signal.trap is very easy to read actually |
| 22:05:58 | brixen | I already looked at it |
| 22:06:06 | brixen | pleasantly surprised |
| 22:06:13 | brixen | since I've been looking at MRI :/ |
| 22:06:42 | boyscout | CI: rubinius: 403295e successful: 3462 files, 13782 examples, 41439 expectations, 0 failures, 0 errors |
| 22:06:46 | evan | well, you know who to thank for that |
| 22:07:08 | brixen | lebron? |
| 22:07:23 | brixen | wait, what am I thanking who for? |
| 22:07:30 | evan | no, he lebron doesn't task himself with such menial duties. |
| 22:07:30 | brixen | for whom am I thanking what? |
| 22:07:35 | brixen | heh |
| 22:07:49 | evan | (i meant me, btw) |
| 22:08:06 | brixen | jvoorhis_: woot on the kong deal, just read about it :) |
| 22:08:43 | brixen | evan: ohhh, thank you indeed |
| 22:09:54 | evan | brixen: i'm idle |
| 22:09:57 | evan | just waiting on your specs |
| 22:10:00 | evan | and i'll fix trap. |
| 22:10:04 | brixen | huh? |
| 22:10:07 | brixen | I pastied them |
| 22:10:19 | brixen | you want me to commit a breaking set?! |
| 22:10:22 | brixen | what what what? |
| 22:10:50 | brixen | http://gist.github.com/408168 |
| 22:10:53 | evan | oh ok |
| 22:10:55 | evan | i'll do that. |
| 22:10:57 | evan | sorry! |
| 22:11:01 | brixen | heh |
| 22:11:01 | evan | we had a miscomm. |
| 22:11:08 | brixen | that was my tag question |
| 22:11:19 | evan | i'll apply that and commit the specs and the fixes |
| 22:11:29 | brixen | k |
| 22:11:46 | brixen | so, I want to start working on ragel pack |
| 22:12:02 | brixen | which means finally revising/rewriting the #pack/#unpack specs |
| 22:12:27 | brixen | 3 parts bitter : 1 part sweet |
| 22:12:28 | evan | no prob. |
| 22:12:30 | evan | hah |
| 22:12:32 | evan | yeah :/ |
| 22:12:50 | brixen | but I have a great new tool! should be_computed_by |
| 22:13:18 | brixen | I'm going to break the specs out into files as well |
| 22:13:30 | brixen | array/pack/a_spec.rb I think |
| 22:13:51 | evan | yeah, sounds much more managable that way. |
| 22:15:59 | brixen | evan: be sure to remove the Process.kill tag I added with the spec sync |
| 22:16:12 | evan | remove the tag? |
| 22:16:26 | brixen | I tagged a failing Process.kill spec |
| 22:16:31 | brixen | that was caused by not accepting nil |
| 22:16:35 | brixen | in Signal.trap |
| 22:17:01 | brixen | so bin/mspec tag --del fails core/process/kill |
| 22:17:03 | evan | ah ok |
| 22:30:27 | boyscout | Add spec for Signal.trap - 44474ff - Evan Phoenix |
| 22:30:27 | boyscout | Fix Signal.trap - 19bd359 - Evan Phoenix |
| 22:34:01 | boyscout | Untag Process.kill/Signal.trap interaction spec - 58de1ad - Evan Phoenix |
| 22:38:32 | boyscout | CI: rubinius: 19bd359 successful: 3462 files, 13794 examples, 41451 expectations, 0 failures, 0 errors |
| 23:21:41 | brixen | I am so glad our build is not like MRI's, that is all |
| 23:22:33 | evan | hah |
| 23:22:40 | evan | i'm adding defered breakpoints. |
| 23:22:45 | brixen | nice |
| 23:22:51 | brixen | I'm working on getting the build to run with 1.9 |
| 23:23:01 | brixen | and *hating* mri |
| 23:23:07 | brixen | oh wait, I don't have to work on that... |
| 23:23:32 | evan | yeah |
| 23:23:34 | evan | don't work on that. |
| 23:38:50 | evan | ha! they work. |
| 23:38:53 | evan | hilarious. |
| 23:39:09 | brixen | sweet |
| 23:39:28 | evan | the hooks at are when a file is done being require/loaded |
| 23:39:36 | evan | so you can't defer a breakpoint to later in a file |
| 23:39:38 | evan | which seems fine. |
| 23:40:02 | evan | i'll go ahead and add Debugger.resolve! |
| 23:40:14 | evan | which will be an explicit way to ask for any defered breakpoints to be resolved |
| 23:40:59 | brixen | sounds good |
| 23:41:31 | brixen | a deferred breakpoint for a loaded file doesn't make sense |
| 23:41:37 | brixen | why would you do that? |
| 23:42:13 | evan | the only way it could happen is if it's the same script |
| 23:42:19 | evan | ie, you put Debugger.start at the top of a script |
| 23:42:33 | evan | and then create a class and use it below that in the script |
| 23:42:44 | evan | you could call code that would normally have a breakpoint |
| 23:42:56 | evan | but the debugger has had no chance to jump in there |
| 23:42:57 | evan | actually |
| 23:43:07 | evan | i could put hooks in class creation and method addition |
| 23:43:11 | evan | i've meant to do that anyways |
| 23:43:30 | evan | then the debugger would have more points to try and resolve breakpoints. |
| 23:44:31 | brixen | that sounds good |
| 23:44:40 | jarib | was the build fixed on 1.9, or did you postpone it? |
| 23:44:52 | brixen | jarib: I'm looking at it now |
| 23:45:02 | brixen | jarib: is using rvm an issue for you? |
| 23:45:15 | jarib | yes, there's an issue with rvm on arch linux |
| 23:45:21 | jarib | openssl related |
| 23:45:24 | brixen | because I'd like to defer this till we have the new build system |
| 23:45:32 | jarib | haven't looked into it too closely |
| 23:45:34 | brixen | how does rvm have an issue like that? |
| 23:45:35 | jarib | no worries |
| 23:45:50 | evan | brixen: yes, i would too. |
| 23:45:52 | jarib | let me see what it was |
| 23:45:52 | brixen | rvm just builds mri or whatever |
| 23:46:43 | brixen | evan: you'd like to defer the 1.9 building? |
| 23:47:00 | evan | yeah |
| 23:47:04 | brixen | k |
| 23:47:05 | evan | til we have a better build system sorted. |
| 23:47:13 | jarib | brixen: http://bbs.archlinux.org/viewtopic.php?id=95320 |
| 23:47:21 | jarib | it's really not your problem. :) |
| 23:47:23 | brixen | yeah, the big problem is invoking rake via the ruby interp |
| 23:47:36 | brixen | mri doesn't support ruby -S rake correctly |
| 23:47:43 | brixen | afaics from trying to get this to work |
| 23:50:18 | wayneeseguin | jarib: I use arch linux for all my servers. |
| 23:50:22 | wayneeseguin | jarib: http://rvm.beginrescueend.com/packages/openssl/ |
| 23:50:57 | brixen | begin; wayneeseguin to the rescue; end :) |
| 23:51:04 | wayneeseguin | LOL |
| 23:51:10 | brixen | heh |
| 23:51:14 | brixen | wayneeseguin: thanks! |
| 23:52:05 | jarib | ahh, great |
| 23:52:08 | jarib | thanks |
| 23:53:14 | evan | I didn't realize so many people used archlinux |
| 23:53:21 | brixen | me neither |
| 23:53:30 | evan | does it still use the totally weird directory layout? |
| 23:54:05 | brixen | you mean like: C:\System\Program Files\My Documents ? |
| 23:54:09 | evan | hah |
| 23:54:12 | brixen | heh |
| 23:57:46 | evan | muhahah |
| 23:57:47 | evan | man |
| 23:57:50 | evan | this is too easy. |
| 23:57:56 | evan | it would be such a fucking pain in C. |