Da
Show enters and exits. Hide enters and exits.
| 00:00:01 | evan | heh |
| 00:01:13 | boyscout | 1 commit by Benjamin Andresen |
| 00:01:14 | boyscout | * initial rubuildius commit, read tools/rubuildius/README; 23f4753 |
| 00:01:26 | evan | there ya go! |
| 00:01:34 | benny | yay, my 2nd time the name came up... I get super internets credits ;-) |
| 00:04:24 | rubuildius | Evan Phoenix: 346abe2f8; 4507 examples, 16867 expectations, 0 failures, 0 errors |
| 00:05:16 | agardiner | and there it is > 4500 examples! |
| 00:08:01 | evan | i unexcluded a bunch of kernel ones today |
| 00:08:06 | evan | they're stupid specs |
| 00:08:11 | evan | they just test that some methods exist |
| 00:08:13 | evan | but not what they do |
| 00:08:16 | evan | so i just made them exist. |
| 00:08:17 | evan | :) |
| 00:08:27 | agardiner | hehe |
| 00:08:28 | evan | def trace_var(*args) |
| 00:08:32 | evan | raise NotImplementedError |
| 00:08:32 | evan | end |
| 00:08:51 | agardiner | and still the specs pass... stoopid! :-D |
| 00:08:56 | evan | yep! |
| 00:09:36 | agardiner | we should fill out all the missing specs the same way, and be done! :-P |
| 00:09:47 | evan | heh |
| 00:09:56 | drbrain | evan: see Hash#clone's spec |
| 00:09:57 | zenspider | wha? |
| 00:10:01 | zenspider | Hangup? |
| 00:10:05 | evan | having the method exist in the first step to passing! |
| 00:10:06 | drbrain | I fully implemented it, but the spec is awesome |
| 00:10:21 | zenspider | fucking HUP |
| 00:10:34 | evan | zenspider: more process specs. |
| 00:10:42 | evan | drbrain: HA! |
| 00:10:44 | evan | dumb. |
| 00:10:48 | evan | not as bad as trace_var's spec. |
| 00:11:02 | zenspider | right... well.. I'm running bin/ci bunch_o_files and they're not excluding |
| 00:11:11 | zenspider | do we have file level excludes as well?!? |
| 00:11:26 | evan | i don't think so. |
| 00:11:48 | zenspider | huh... I'm not sure why this is happening then |
| 00:14:01 | brixen | this specs were that the methods are private, not that they exist |
| 00:14:14 | brixen | whether that's a critical thing to spec remains to be seen |
| 00:14:19 | evan | brixen: well, it's a spec for both |
| 00:14:21 | rubuildius | Benjamin Andresen: 23f4753ff; 4507 examples, 16867 expectations, 0 failures, 0 errors |
| 00:14:24 | evan | can't be private if it doesn't exist. |
| 00:14:27 | brixen | right |
| 00:14:33 | brixen | but it can't pass if it's not private ;) |
| 00:14:40 | evan | true. |
| 00:15:15 | brixen | evan: are we implementing trace_var? |
| 00:15:24 | evan | is it just for globals? |
| 00:15:24 | zenspider | brixen: I'd rather us have zero specs on a method than a single private spec |
| 00:15:33 | zenspider | easier for use to know we've not done a damn thing on it |
| 00:16:04 | brixen | evan: yeah, looks like it |
| 00:16:04 | brixen | zenspider: any specs are fine |
| 00:16:04 | evan | then sure. |
| 00:16:11 | evan | since globals are all in the GlobalVariables class |
| 00:16:20 | brixen | zenspider: we know when we've done something by the ones that pass |
| 00:16:36 | evan | hm. bugger. |
| 00:16:49 | evan | this Hash#[]= code was never rehashing |
| 00:16:57 | evan | i'll bet thats why we've had bad performance for Hash |
| 00:17:13 | zenspider | brixen: yes, but that means that bin/completeness will say that is has coverage, right? |
| 00:17:28 | brixen | zenspider: no one should use that script |
| 00:17:34 | brixen | laments the day he wrote it |
| 00:17:44 | brixen | zenspider: why would you pay attention to that script? |
| 00:17:45 | zenspider | then delete it... because they are |
| 00:17:56 | zenspider | the fact that I can pass with def blah; end; private :blah is a false positive |
| 00:18:11 | zenspider | if I'm not supposed to run it, it shouldn't be there |
| 00:18:12 | brixen | well, what would you suggest? |
| 00:18:21 | brixen | the fact it tells you if there is *no* spec is useful |
| 00:18:49 | evan | in the future |
| 00:18:50 | brixen | well, why don't you run shotgun/compile to compile shotgun? |
| 00:18:56 | evan | having specs that just test a method exists is not useful |
| 00:19:01 | evan | no reason to delete the ones we have though. |
| 00:19:02 | brixen | use the script for what it's useful for |
| 00:19:17 | brixen | it's not, it's testing that it's a private method |
| 00:19:23 | evan | perhaps we should go in and add a 'fail' spec to the ones that just test for private |
| 00:19:28 | brixen | what would we do, wait to test that until it's implemented? |
| 00:19:33 | evan | ie, they don't test the behavior of the method |
| 00:19:41 | brixen | no, we just need more specs |
| 00:19:45 | brixen | but we can't have them all at once |
| 00:19:45 | evan | sure |
| 00:19:52 | evan | zenspider is saying that people might not realize that we need them |
| 00:20:03 | zenspider | brixen: my point is that knowing there is no spec is MORE useful than seeing that there is "something" there but the spec is functionally useless |
| 00:20:04 | evan | because they'd notice that we SOME coverage on those |
| 00:20:07 | brixen | well, you can't know everything by the summary dots |
| 00:20:07 | drbrain | what's up with the regex once flag? |
| 00:20:09 | evan | when what we have is not really specing the behavior |
| 00:20:28 | evan | the fact that it's private isn't really it's behavior. |
| 00:20:42 | evan | drbrain: not working? |
| 00:20:48 | brixen | if a spec is describing any significant aspect of behavior, it should be there |
| 00:20:49 | zenspider | drbrain: what do you mean? |
| 00:20:49 | evan | drbrain: i debugged it a while back. |
| 00:20:50 | drbrain | not working |
| 00:21:06 | evan | it doesn't do it once? |
| 00:21:07 | brixen | if whether a method is private is not significant, then we don't need a spec for it |
| 00:21:11 | evan | you get a nil back? |
| 00:21:32 | zenspider | brixen: NOBODY is arguing with that... a spec that only checks the visibility is NOT a behavioral spec |
| 00:21:32 | evan | brixen: it's not that, it's that it's the only spec |
| 00:21:38 | drbrain | it's in a case, and it's falling through to the else which raises |
| 00:21:43 | drbrain | so, I must be getting nil |
| 00:21:54 | brixen | evan: I know, but we have to start somewhere, right? |
| 00:22:03 | drbrain | let me poke harder |
| 00:22:17 | zenspider | walks away |
| 00:22:24 | brixen | unless we want to start imposing guidelines on the order of specs to write |
| 00:31:01 | drbrain | evan: http://rafb.net/p/QzQKqb17.html |
| 00:31:06 | drbrain | it's complicated :( |
| 00:31:12 | drbrain | that first match needs to be there |
| 00:32:17 | drbrain | evan: simpler: http://rafb.net/p/Pxtqz992.html |
| 00:32:40 | drbrain | changing RE to a local causes it to go away, removing o causes it to go away |
| 00:33:44 | drbrain | oh, and removing the first failing match causes it to go away |
| 00:33:54 | drbrain | or, making the first match match makes it go away |
| 00:34:11 | zenspider | Attempted to access field of non-reference? |
| 00:34:18 | zenspider | does that translate to "run again" ? |
| 00:34:33 | evan | no. |
| 00:34:41 | evan | that translates into "something did something bad" |
| 00:38:08 | drbrain | ha! ok |
| 00:38:24 | drbrain | so, /#{X}/o is grabbing the previous regexp |
| 00:38:47 | evan | thats what it does. |
| 00:38:50 | drbrain | if I add p self => str to Regexp#=~, I see {/x/=>"y"} twice |
| 00:38:56 | evan | wait |
| 00:39:00 | evan | the previous one... |
| 00:39:01 | drbrain | no, that's not what it does |
| 00:39:07 | drbrain | it should be /=/ |
| 00:39:10 | evan | you mean the one on the line before it? |
| 00:39:14 | drbrain | yes, it's grabbing the previous one |
| 00:39:15 | evan | or the last time it was run |
| 00:39:17 | drbrain | yes |
| 00:39:22 | evan | it's not a yes/no question |
| 00:39:25 | drbrain | the previous line |
| 00:39:43 | drbrain | instead of the interpolated one |
| 00:39:49 | evan | odd. |
| 00:40:00 | evan | it's pulling from the wrong literal then. |
| 00:43:30 | drbrain | where should I go looking for this? |
| 00:43:37 | agardiner | strange... looks like only a single literal slot was allocated for the regex |
| 00:43:46 | agardiner | this was the same issue i fixed before |
| 00:44:03 | agardiner | drbrain: its in the compiler |
| 00:45:32 | drbrain | in RegexLiteral#bytecode, I'm seeing @source having the correct value |
| 00:46:03 | drbrain | oh, I need to look at both, yes? |
| 00:46:42 | agardiner | its to do with the allocation of a slot to hold the literal regex once its been instantiated |
| 00:47:09 | agardiner | it looks like both RE literals are being given the same index into the literals tuple |
| 00:48:16 | zenspider | evan: hrm. it is repeatable. All I'm doing is running bin/ci -c |
| 00:48:42 | evan | what is? |
| 00:48:58 | zenspider | my non-reference bug |
| 00:49:16 | evan | happens in the same spec everytime? |
| 00:49:53 | zenspider | huh... it SEEMS to have done what I want, which is add the exclusions I need for the parser specs |
| 00:50:00 | zenspider | so it obviously died afterwards |
| 00:50:07 | zenspider | no output when I run with -c, so I dunno |
| 00:50:15 | zenspider | lemme try changing the format |
| 00:50:20 | evan | -c runs everything |
| 00:50:22 | zenspider | hrm. no. there is ZERO output from -c |
| 00:50:24 | evan | as I recall |
| 00:50:34 | brixen | give it a path to the file |
| 00:50:39 | brixen | bin/ci runs everything |
| 00:50:43 | zenspider | it didn't seem to, given how many passing specs I found |
| 00:50:45 | evan | so maybe it's hitting some specs that are very bad. |
| 00:50:48 | brixen | if you give it -c, it will run everything |
| 00:50:56 | brixen | yeah, most likely |
| 00:51:08 | evan | zenspider: you're running 'bin/ci -c <files>' or 'bin/ci -c' |
| 00:51:08 | brixen | bin/ci -c path/to/spec/to/exclude |
| 00:51:11 | zenspider | ok. so it should be the same as bin/mspec spec, right? |
| 00:51:20 | zenspider | evan: latter |
| 00:51:35 | brixen | zenspider: you will surely die if you run the latter |
| 00:51:40 | zenspider | ok... well then it is no big deal |
| 00:51:40 | evan | yeah, run it only for a certain subpath |
| 00:51:43 | zenspider | right |
| 00:51:54 | evan | i should take a look at what is blowin' shit up though. |
| 00:52:08 | zenspider | so no worries. I misunderstood what -c did because I've uncovered so many specs that pass as-is |
| 00:52:19 | zenspider | I thought it was additive only |
| 00:52:19 | brixen | zenspider: yes, that's the problem |
| 00:52:25 | brixen | many pass in isolation |
| 00:52:38 | brixen | although, far fewer than before have this issue |
| 00:52:43 | zenspider | no, I checked that they passed in combo too |
| 00:52:53 | zenspider | the only one that went wonky evan fixed in parallel |
| 00:52:53 | brixen | bin/mspec spec/ruby will tell you a lot |
| 00:53:01 | zenspider | oh, and I fixed Symbol::all_symbols |
| 00:53:11 | zenspider | "fixed" |
| 00:53:30 | zenspider | really we should not allow :"" into the symbol table, but I added a TODO |
| 00:53:36 | evan | i wonder if some Symbol spec is trying :"" |
| 00:53:38 | evan | actually |
| 00:53:41 | evan | :"" is allowed in 1.9 |
| 00:53:43 | evan | as I recall. |
| 00:53:47 | zenspider | yeah... something is |
| 00:54:12 | zenspider | well... can we decide what we're targeting and stick to it? |
| 00:54:26 | evan | 1.8, and i'm just saying. |
| 00:54:48 | zenspider | anyone understand shell/buffer limitations? |
| 00:55:07 | evan | you passing to many things on the command line with autotest? |
| 00:55:30 | zenspider | the way autotest currently works, it blows up on rubinius. we've got a 70ish Kb string being passed to -e |
| 00:55:38 | evan | no way around that. |
| 00:55:43 | zenspider | when I make them plain args instead of -e "blahblah", it runs |
| 00:55:43 | evan | save it to a file |
| 00:55:46 | evan | or load via stdin |
| 00:55:51 | brixen | zenspider: why can't you ran a script instead? |
| 00:55:56 | brixen | s/ran/run/ |
| 00:56:00 | evan | zenspider: hm |
| 00:56:02 | evan | interesting |
| 00:56:03 | zenspider | is that a token size limitation, or is that a command line length limit? |
| 00:56:11 | evan | i think it's a command line length limit |
| 00:56:15 | zenspider | if it is token size, then I'm fine |
| 00:56:19 | evan | but it depends entirely on the shell |
| 00:56:20 | drbrain | agardiner: I changed DynamicOnceRegex from push_literal to add_literal |
| 00:56:26 | drbrain | but that didn't fix it |
| 00:56:30 | zenspider | if I happened to remove JUST ENOUGH to slip under, then I'm screwed in a day. :) |
| 00:56:33 | evan | i know bash handles this different than zsh |
| 00:57:04 | agardiner | drbrain: yeah, just looking at this... |
| 00:57:07 | evan | zenspider: echo list | rubinius -e "STDIN.readlines.each { |l| require l }" |
| 00:57:26 | evan | though |
| 00:57:31 | evan | the 'echo list' |
| 00:57:37 | evan | may have the same problem |
| 00:57:44 | brixen | cat list ? |
| 00:57:48 | evan | yeah |
| 00:57:54 | evan | I think you have to go to file |
| 00:58:09 | brixen | I wish someone would explain why running a script doesn't work |
| 00:58:10 | zenspider | evan: yeah. we thought of that... it should have the same problems |
| 00:58:17 | drbrain | agardiner: I get a new slot, but I think the wrong thing is going into it |
| 00:58:40 | zenspider | brixen: because I don't want to if I don't have to |
| 00:58:43 | evan | brixen: i think they just wanted to avoid making temp files |
| 00:58:44 | agardiner | drbrain: i'm not sure if a dregx ought to go into a literal slot... |
| 00:59:00 | drbrain | agardiner: it's a dregx once |
| 00:59:02 | zenspider | ok. one more bin/ci question... |
| 00:59:11 | zenspider | I'm running bin/ci lots_of_specs |
| 00:59:15 | agardiner | ahh - ok |
| 00:59:17 | zenspider | and getting failures |
| 00:59:23 | drbrain | so, it only gets compiled once, then stored and reused after that |
| 00:59:24 | zenspider | my bin/ci by itself runs clean |
| 00:59:33 | evan | zenspider: go look at the code for bin/ci |
| 00:59:38 | evan | mspec/scripts/ci.rb |
| 00:59:42 | evan | bin/ci DOESNT run everything |
| 00:59:44 | brixen | zenspider: most likely ordering issues |
| 00:59:44 | zenspider | where else should I be looking to see what it is doing differently? |
| 00:59:49 | evan | only runs everything under certain directories |
| 00:59:53 | brixen | specs are dependent in an order |
| 01:00:02 | brixen | and right now they are run alphabetical |
| 01:00:13 | drbrain | agardiner: also, changing RE to a local variable makes this work |
| 01:00:14 | zenspider | evan: ah. poopy. yeah. I'm running a lot more right now |
| 01:00:19 | drbrain | if it's a constant, it won't work |
| 01:00:27 | evan | zenspider: since ci is via exclude, not include |
| 01:00:39 | evan | zenspider: you're running ALL the library specs and stuff |
| 01:00:45 | evan | that we don't normally run currently |
| 01:00:48 | zenspider | brixen: dependent in a certain order? does that imply that some specs won't run in isolation? |
| 01:00:52 | zenspider | right |
| 01:00:55 | brixen | and, we are not going to be able to run the library specs with everything else, because of stuff like rational and date |
| 01:01:00 | agardiner | drbrain: looking at the sexp, this is showing as a dregx, not a dregx_once |
| 01:01:18 | brixen | zenspider: not necessarily, it more likely means that A, B runs but B, A doesn |
| 01:01:20 | brixen | 't |
| 01:01:32 | drbrain | agardiner: I'm definitely hitting DynamicOnceRegex in lib/compiler/bytecode.rb |
| 01:01:37 | zenspider | brixen: hrm... ok. I'll mull on that |
| 01:01:42 | drbrain | agardiner: it's the second regex that's screwed up |
| 01:01:56 | evan | drbrain: which is the file you're working on? |
| 01:02:03 | brixen | zenspider: spec/ruby/1.8/library runs fine in isolation but blows things up when run together |
| 01:02:18 | evan | brixen: oh, thats because library introduces code that screws with other shit |
| 01:02:20 | evan | like mathn |
| 01:02:21 | evan | and friends. |
| 01:02:22 | brixen | zenspider: just add spec/ruby/1.8/library to bin/ci CI_SPEC_FILE or whatever |
| 01:02:23 | evan | yes? |
| 01:02:32 | brixen | evan: no, I don't think so |
| 01:02:33 | drbrain | http://rafb.net/p/Pxtqz992.html |
| 01:02:36 | brixen | runs fine by itself |
| 01:02:53 | agardiner | weird... i don't seem to be hitting it on that simple example you pasted |
| 01:03:19 | brixen | evan: just run: bin/ci spec/ruby/1.8/core spec/ruby/1.8.language spec/ruby/1.8/library |
| 01:03:23 | brixen | and you should see stuff |
| 01:03:26 | drbrain | I'm running it like this: |
| 01:03:38 | drbrain | ruby once_test.rb && rake && rm -f once_test.rbc && echo '---' && shotgun/rubinius once_test.rb |
| 01:03:45 | drbrain | something's up with recompilation |
| 01:04:54 | brixen | evan: actually, library specs were running ok, they now fail for me in isolation |
| 01:05:23 | evan | interesting. |
| 01:05:28 | brixen | DRb.start_server |
| 01:05:40 | drbrain | evan: the auto-recompile seems broken too |
| 01:05:40 | evan | # => :started |
| 01:05:48 | evan | wonderful. |
| 01:05:53 | brixen | strange object detected as exception: nil (NilClass) |
| 01:07:13 | agardiner | drbrain: the two examples you pastied are different... the simpler example does not use dregx_once |
| 01:07:48 | drbrain | agardiner: maybe I pasted wrong |
| 01:07:56 | drbrain | add the o flag to the second regex |
| 01:08:16 | drbrain | agardiner: wait, what? |
| 01:08:23 | drbrain | no, this has three regex |
| 01:08:30 | drbrain | /y/, /x/, /#{RE}/o |
| 01:08:36 | drbrain | http://rafb.net/p/Pxtqz992.html |
| 01:08:37 | agardiner | sorry, you're right... |
| 01:08:38 | evan | drbrain: a better test is |
| 01:08:44 | evan | p(/#{RE}/.source) |
| 01:08:47 | agardiner | i must have had a copy/paste error |
| 01:08:49 | evan | that shows the bug nicely |
| 01:08:51 | evan | i get "x" for both |
| 01:09:01 | drbrain | yeah |
| 01:10:10 | evan | oh |
| 01:10:13 | evan | this code is doing |
| 01:10:16 | drbrain | RE = /y/; def doit() p /x/; p /#{RE}/o.source; end; doit |
| 01:10:16 | evan | g.push_literal nil |
| 01:10:17 | evan | thats the bug. |
| 01:10:21 | evan | one sec |
| 01:10:22 | evan | easy fix. |
| 01:11:09 | zenspider | brixen: do you mean that the directory order is maintained but the files found within that directory are alphabetized? |
| 01:11:38 | boyscout | 1 commit by Evan Phoenix |
| 01:11:39 | boyscout | * Process /ao#{o}/o properly; dbacd99 |
| 01:11:41 | evan | drbrain: there ya go. |
| 01:12:29 | brixen | zenspider: yeah |
| 01:12:39 | agardiner | evan: you beat me to it :-P |
| 01:12:42 | brixen | mspec/scripts/ci.rb:130-138 |
| 01:13:14 | agardiner | didn't help i was looking at something that wasn't showing the problem! :-O |
| 01:13:47 | evan | :D |
| 01:14:05 | zenspider | brixen: do you know why we can't run any specs in any combination and have them pass? |
| 01:14:18 | brixen | zenspider: no |
| 01:14:21 | brixen | heh |
| 01:14:43 | drbrain | evan: now URI is broken |
| 01:14:48 | drbrain | shotgun/rubinius -r uri -e 0 |
| 01:14:55 | zenspider | ok. |
| 01:14:57 | brixen | ideally they'd be independent, but they're running on the same vm |
| 01:15:10 | zenspider | I'm not gonna worry about it atm, but it is something we should look at |
| 01:15:14 | evan | destabilization specs |
| 01:15:24 | evan | drbrain: works here. |
| 01:15:24 | brixen | yeah, we should have a randomize mode |
| 01:15:35 | drbrain | hrm |
| 01:15:36 | evan | drbrain: i did 'rake pristine' first too. |
| 01:15:47 | drbrain | let me try that |
| 01:16:07 | drbrain | fixed it, thanks |
| 01:16:18 | drbrain | so, something really is up with the compiler check |
| 01:16:33 | brixen | drbrain: did you change that file? |
| 01:16:38 | zenspider | brixen: randomize would be awesome. I've been meaning to add it to autotest |
| 01:16:56 | drbrain | brixen: it got changed by git |
| 01:17:13 | brixen | drbrain: uri I mean |
| 01:17:19 | drbrain | no |
| 01:17:30 | brixen | well, then the compiler wouldn't recompile it |
| 01:17:42 | brixen | assuming the change to the compiler fixed something |
| 01:17:47 | brixen | or is that different now? |
| 01:17:49 | drbrain | it should check the version and recompile it |
| 01:17:53 | brixen | ahh |
| 01:18:18 | brixen | yeah, I've been using pristine too much then ;) |
| 01:18:48 | evan | hm. |
| 01:18:50 | drbrain | it's supposed to be different now |
| 01:19:28 | drbrain | I had the compiler two minutes newer than my once_test.rb file, and it wasn't rebuilding the .rbc |
| 01:20:28 | evan | lets see if i can repro that quickly. |
| 01:20:44 | agardiner | i saw the same thing too... i made changes to bytecode.rb, but it didn't recompile my rb_test file |
| 01:21:08 | evan | ok |
| 01:21:10 | evan | that was easy |
| 01:21:15 | evan | lets see why now... |
| 01:21:32 | agardiner | evan: do you use max of compiler times? |
| 01:22:01 | agardiner | er.. compiler file times? |
| 01:23:47 | evan | wtf. |
| 01:23:54 | evan | it's not pulling in the version number... |
| 01:23:55 | evan | OH. |
| 01:23:59 | evan | there is a race. |
| 01:24:04 | evan | THATS why. |
| 01:24:23 | rubuildius | Evan Phoenix: dbacd996d; 4507 examples, 16867 expectations, 1 failure, 0 errors; http://rafb.net/p/JrHrRW94.html |
| 01:24:40 | evan | ARG! |
| 01:24:51 | evan | ah crap. |
| 01:24:54 | evan | it's the regex change. |
| 01:24:55 | evan | ok. |
| 01:24:56 | agardiner | looks like a compiler spec needs updating |
| 01:25:05 | evan | i'll fix this race first. |
| 01:31:48 | boyscout | 1 commit by Evan Phoenix |
| 01:31:49 | boyscout | * Fix race in compiler version number, fix regex spec; 9cca76a |
| 01:31:50 | evan | ok, recompiling is fixed. |
| 01:32:00 | evan | the problem was that if everything was already compiled |
| 01:32:05 | evan | it never loaded the compiler |
| 01:32:13 | evan | and thus always had the version number at 0 |
| 01:32:25 | evan | the compiler is now forced to load, even if it's not needed |
| 01:32:39 | evan | so the proper version number is calculated. |
| 01:32:59 | agardiner | ah - makes sense |
| 01:33:18 | drbrain | yay! |
| 01:35:04 | evan | whats funny about |
| 01:35:18 | evan | the case when you mostly like WANTED it to run (you have everything compiled already) |
| 01:35:21 | evan | it wouldn't. |
| 01:40:24 | agardiner | hmmm... is there anyway to put a timeout on a channel.receive? |
| 01:40:31 | evan | yeah |
| 01:41:25 | evan | Scheduler.send_in_microseconds |
| 01:41:53 | zenspider | just got my first clean run via autotest |
| 01:41:58 | zenspider | ... and I have to run |
| 01:42:01 | zenspider | :) |
| 01:42:11 | evan | ohh |
| 01:42:13 | evan | i want to use! |
| 01:42:14 | evan | commit! |
| 01:42:21 | agardiner | zenspider: nice! |
| 01:42:54 | drbrain | too late, he'll commit later |
| 01:43:02 | evan | bah. |
| 01:44:22 | rubuildius | Evan Phoenix: 9cca76acb; 4507 examples, 16867 expectations, 0 failures, 0 errors |
| 01:44:55 | drbrain | woo! down below 4000 lines of failure for RubyGems |
| 01:45:22 | drbrain | I'll retry the DependencyInstaller tests when I get home, that's a huge chunk of it |
| 01:48:56 | evan | k |
| 01:48:59 | evan | drbrain: and slow. |
| 01:49:29 | evan | hm |
| 01:49:31 | evan | no ARGF specs. |
| 01:54:10 | brixen | hah, the pirate specs |
| 01:54:16 | brixen | ARGF |
| 01:54:18 | evan | HAH |
| 01:54:29 | evan | i think i'm going to do it the dumbest way possible |
| 01:54:31 | evan | commit it |
| 01:54:34 | evan | and let someone else write specs. |
| 02:23:49 | shoe | is "defined?" a keyword or a method? |
| 02:25:59 | shoe | I guess it's a keyword. |
| 02:26:41 | agardiner | yeah, i believe so - it converts to :defined or something in the sexp |
| 02:31:00 | drbrain | keyword |
| 02:33:15 | shoe | Somehow, I never realized that until today - I just figured it was a method on Kernel or something. |
| 02:57:56 | Defiler | shoe: Sadly no. defined?(exit) doesn't exit the process. Heh |
| 02:58:28 | Defiler | Can someone explain to me how ARGF is meant to work in MRI? |
| 02:58:35 | Defiler | I tried to understand it, and it isn't clicking |
| 02:58:40 | Defiler | It seems to just do.. things.. |
| 02:58:49 | drbrain | it's the concatenation of the input files |
| 02:59:00 | drbrain | ... I'll expand |
| 02:59:13 | drbrain | it's the concatenation of the contents of the input file names |
| 02:59:37 | Defiler | Can you give me a sample command-line that it would be used with? |
| 02:59:46 | Defiler | ruby your_program.rb some_file.dat ? |
| 02:59:56 | drbrain | echo x > x; echo y > y; ruby -e 'p ARGF.read' x y # => "x\ny\n" |
| 02:59:59 | drbrain | I think |
| 03:00:08 | drbrain | yes |
| 03:00:29 | Defiler | OK, that seems sane. The behavior when no file was passed seems bizarre, though |
| 03:00:34 | Defiler | It seems like sometimes it just blocks forever? |
| 03:01:06 | drbrain | it's reading from stdin |
| 03:01:19 | drbrain | type some stuff and hit ^D |
| 03:02:20 | Defiler | ahaaaa |
| 03:02:26 | drbrain | probably, ARGF = $stdin if ARGV.empty? |
| 03:02:27 | Defiler | clever girl *dies* |
| 05:14:35 | boyscout | 1 commit by Adam Gardiner |
| 05:14:36 | boyscout | * Fix bug retrieving local names in CompiledMethod#decode; 5dd9c69 |
| 05:24:24 | rubuildius | Adam Gardiner: 5dd9c69f1; 4507 examples, 16867 expectations, 0 failures, 0 errors |
| 05:49:26 | tomtt | /join mephisto |
| 06:39:05 | rue | Evening |
| 06:42:59 | crafterm | hi rue |
| 06:59:48 | rue | evan: *pong |
| 07:01:28 | brixen | rue: talking with evan today, I'm adding general tag files that shadow the spec files |
| 07:01:53 | brixen | rue: so, e.g. excluded(This is why):Kernel#callcc returns ... |
| 07:02:19 | brixen | rue: I'm curious how the guard stuff you're working on needs to be integrated with the runner scripts |
| 07:05:02 | rue | Hm, there really is not much needed in the way of integration, I suppose |
| 07:06:20 | rue | Anything not considering failing runs completely normally |
| 07:07:24 | rue | Any guards considered failing will go through the contained block and for each #it it encounters, it grabs the spec string, replaces the block with a { <raise error> } and sends it to spec_runner for normal processing |
| 07:07:42 | brixen | ok |
| 07:07:58 | brixen | I'm generalizing running or not running specs based on these tags |
| 07:08:20 | rue | I made a few exception subclasses so that if needed the output can be altered, like not printing backtraces or whatever |
| 07:08:31 | brixen | and hopefully a more general/useful way of creating the tags based on the specs passing or failing |
| 07:08:33 | rue | Altered without touching the runner |
| 07:08:53 | brixen | so, instead of a formatter? |
| 07:08:58 | brixen | where does the logic go? |
| 07:09:18 | rue | Hm, let me pastie the guards.rb file |
| 07:10:01 | rue | http://pastie.org/143171 |
| 07:10:51 | rue | In VERBOSE_GUARDS mode, if a guard determines it needs to fail, it creates a GuardFailure instance with the appropriate exception |
| 07:11:29 | rue | The GF then instance_evals the block it gets to weed out the #its |
| 07:12:33 | brixen | what's the :host_only, :target_only? |
| 07:13:42 | rue | This goes to the terminology difference but :host_only means that the attribute, e.g. :version, only matched against the host (impl running) |
| 07:14:21 | rue | :target_only means :version matched against the target version (1.8.6) but not the host version (say, ruby 1.8.5) |
| 07:14:24 | brixen | well, we have to resolve this terminology difference |
| 07:14:33 | brixen | because this is hella confusing |
| 07:14:56 | brixen | there's only one thing running the specs at any given time, right? |
| 07:15:26 | rue | Yes.. sort of split between platform (OS, hardware) and host (Ruby impl) |
| 07:15:45 | brixen | well, yes, different facets of one thing |
| 07:15:51 | rue | Right |
| 07:16:06 | brixen | so, whatever you are, you either match that guard or not, right |
| 07:16:09 | brixen | it's binary |
| 07:16:19 | brixen | match, no match |
| 07:16:26 | brixen | host, target is just so confusing |
| 07:16:52 | brixen | because the "target" could be a composite set of attributes that matches multiple impl |
| 07:17:40 | brixen | not to mention the "legacy" meaning of these two terms |
| 07:18:01 | rue | Yep |
| 07:18:08 | rue | I was thinking other nomenclature |
| 07:18:11 | brixen | sure |
| 07:18:25 | brixen | I just want to keep the (match/no match) thing clear |
| 07:18:44 | brixen | because on the set of attributes side, there's no single impl necessarily being referenced |
| 07:18:48 | rue | I do not think target should be used for the currently running impl either, but the "spec goal/target" could simply be "standard" instead |
| 07:19:00 | brixen | yeah, but do you see what I mean? |
| 07:19:09 | rue | Well, target is always a single implementation |
| 07:19:39 | brixen | I'm saying the way you specify the attributes on a guard |
| 07:19:47 | brixen | it's not necessarily a single impl |
| 07:19:48 | brixen | right? |
| 07:20:00 | rue | Multiple hosts could match it, yes |
| 07:20:11 | brixen | so, lhs (a set of attributes) == rhs (a single impl that is currently running the specs) |
| 07:20:15 | brixen | ^^^ agree? |
| 07:20:40 | brixen | if lhs == rhs, then run the specs else do not |
| 07:20:43 | rue | For normal mode, yes |
| 07:20:56 | brixen | well, for either mode, right? |
| 07:21:04 | brixen | the diff is what you do about it |
| 07:21:08 | brixen | or with it |
| 07:21:15 | rue | Perhaps I misunderstand |
| 07:21:21 | rue | Illustration |
| 07:22:05 | rue | If I have platform_is :version => '1.8.5' do ... end in normal mode it will run if the host/runner identifies as 1.8.5 |
| 07:22:14 | brixen | k |
| 07:22:43 | rue | In failure mode, if target_version != 1.8.5, that is an invalid spec |
| 07:22:52 | brixen | sure |
| 07:23:04 | brixen | it's still binary, unless I'm misunderstanding |
| 07:23:14 | brixen | match in normal mode, run normally |
| 07:23:22 | brixen | no match in failure mode, fail |
| 07:24:17 | rue | Essentially, yeah. For any given spec, there are multiple possible specific failure types but yes, broadly it is runs or fails vs. runs or skips in normal |
| 07:24:19 | brixen | my problem is that in trying to pin a name on the "set of attributes", we're confusing a single impl with merely a set of tests |
| 07:24:45 | brixen | so, what are the possible failure types? |
| 07:25:58 | brixen | I want to say, "if guard X matches the implmentation, then A happens in Y mode" |
| 07:26:07 | brixen | doesn't that seem more clear? |
| 07:26:50 | rue | At the top of the pastie; SpecTargetFailure means a broken/nonsensical spec like not_compliant_on :ruby. PlatformMismatch is when I have e.g. :version => [1.8.6, 1.8.5] and host and target match different versions |
| 07:27:16 | brixen | hmm |
| 07:27:18 | brixen | ok |
| 07:27:27 | rue | ComplianceFailure is something that either does or does not execute on host (while the target does the opposite) |
| 07:28:02 | brixen | can we use more generally, "implementation matches or does not match the guard" ? |
| 07:28:21 | brixen | implementation means "the impl running the specs" |
| 07:28:31 | brixen | the guard is whatever guard? |
| 07:28:57 | brixen | like PlatformMismatch seems overkill to me |
| 07:29:04 | rue | Yeah, I kind of would like to have something that says specifically "currently running implementation" but I am coming up short |
| 07:29:22 | brixen | well, that's what I'm saying, there can be only one :P |
| 07:29:27 | brixen | so, that's redundant |
| 07:29:44 | brixen | the implementation is all there is, the guard is the set of attributes that matches or does not match |
| 07:29:59 | rue | There is sort of a dichtomy: ComplianceFailures indicates broken implementation, the other two broken specs |
| 07:30:13 | brixen | because the guard doesn't necessarily designate a single impl |
| 07:30:41 | brixen | well, let's keep those two really, really, really far apart |
| 07:30:51 | brixen | "broken spec" can mean a zillion things |
| 07:31:03 | brixen | I'd rather that be part of the audit process, not a guard logic |
| 07:31:32 | brixen | the tags file will provide for: incomplete(This needs to do foo):Class#method blah blah |
| 07:32:00 | brixen | so, we can actually document the audit process, rather than embedding not_compliant_on :ruby as some sort of exception |
| 07:32:03 | brixen | follow? |
| 07:33:49 | brixen | rue: this has to be considered like set membership, the guard is the set, the "current"ly running impl is an element |
| 07:34:10 | brixen | so, in general, you have a binary truth value: x el of S or x not el of S |
| 07:34:26 | brixen | I don't want to confuse S with a single impl any more than a set with an element |
| 07:34:55 | rue | This is more like error handling. A guard can imply compliance, noncompliance or there may be an error processing it. It is very convenient to be present |
| 07:35:19 | rue | Specifically, you absolutely do not want to *intentionally* write a spec that raises a SpecTargetFailure |
| 07:35:39 | brixen | sure |
| 07:35:50 | brixen | but I think trying to encode all that in the guards is a rabbit hole |
| 07:35:55 | brixen | and really unnecessary |
| 07:36:21 | rue | It is a byproduct. The information is already produced |
| 07:37:24 | rue | But what is the tag idea, then? The incomplete there seems obvious enough but how were you going to scope it? Also, I am assuming this is a separate file? |
| 07:38:21 | brixen | yeah, it's a generalization of the existing excludes file |
| 07:38:25 | brixen | but it has 2 parts |
| 07:38:35 | brixen | <tag>:<spec description string> |
| 07:38:58 | brixen | <tag> : <name> [ '(' <any text> ')' ] |
| 07:39:44 | brixen | rue: I just don't want to encode stuff like: not_compliant_on :ruby as an error |
| 07:40:25 | rue | Oh, and I think I did not address one point there. I do not think of it as a distinct entity, but 1. the semantics of the guard and 2. the attributes like :os to the guard make up the total of the guard |
| 07:40:34 | brixen | like GuardFailure, that seems so over the top |
| 07:40:58 | rue | Within any given single run, that entity can either match or not match |
| 07:40:59 | brixen | sure, the guard is both those |
| 07:41:03 | brixen | right |
| 07:41:15 | brixen | but there is no target, host |
| 07:41:28 | brixen | impl matches/does not match guard |
| 07:41:38 | brixen | x el of S, etc |
| 07:41:56 | rue | Correct, impl will either match or not |
| 07:41:57 | brixen | I think that will be less confusing |
| 07:42:25 | brixen | so, "implementation" or (redundantly) "current implementation" is the ruby impl running the specs |
| 07:42:25 | rue | However, whether the guard itself is considered matched depends on its semantics |
| 07:42:29 | brixen | does that work? |
| 07:42:46 | rue | Sure |
| 07:42:59 | brixen | well, the "guard" being a set of attributes and a meaning assigned to those attributes either matches or not? |
| 07:43:16 | brixen | I'm not following the "semantics" part of the guard |
| 07:43:25 | rue | Probably terminology |
| 07:43:40 | brixen | you're saying a guard has a context? |
| 07:43:43 | rue | Let us call 1.8.6-p111-2007/09/24 collectively the "standard" |
| 07:44:12 | brixen | k |
| 07:44:20 | rue | For a guard like #compliant_on, the standard is a part of its semantics |
| 07:45:11 | brixen | ahh, so you're saying, you will encode a single "implementation" into the guards as "the standard"? |
| 07:45:11 | rue | So in order for #compliant_on to be considered 'successful' (i.e. the block runs), the implementation must be matched, AND the standard must be matched |
| 07:45:19 | rue | Yes |
| 07:45:24 | brixen | oh lordy |
| 07:45:27 | brixen | ok |
| 07:45:37 | rue | Now, mind you, this IS an audit tool |
| 07:45:53 | rue | Normally, you always always run without -G |
| 07:45:56 | brixen | sure |
| 07:46:11 | brixen | just trying to find a sentence to express this idea |
| 07:46:19 | rue | Right |
| 07:46:35 | brixen | it's really modal |
| 07:46:40 | rue | The semantics are a bitch to get exactly right. |
| 07:47:05 | brixen | so, normal mode: a guard is a set of attributes that matches/does not match the implementation |
| 07:47:16 | brixen | what's the other mode called? |
| 07:47:25 | rue | Yes. Any guard is only considered in relation to the implementation |
| 07:47:40 | brixen | exception mode? |
| 07:48:09 | rue | I started with just "verbose guards" or "guard failure reporting" |
| 07:48:16 | brixen | ok |
| 07:48:26 | brixen | verify mode? |
| 07:48:37 | rue | Sounds good |
| 07:49:23 | brixen | ok, so, verify mode: a guard is a set of attributes that matches/does not match the implementation *and* whose behavior is relative to the standard |
| 07:49:30 | brixen | are those two accurate? |
| 07:49:46 | rue | (Completely OT right now but cool hash algos: http://cmph.sourceforge.net/) |
| 07:49:59 | brixen | nice |
| 07:50:22 | brixen | rue: did you check out the revactor site? nice stuff |
| 07:50:41 | rue | I would stress the standard, perhaps |
| 07:51:26 | brixen | so, our glossary has these terms: implementation, guard, standard, normal mode, verify mode ? |
| 07:52:30 | rue | Yep |
| 07:53:14 | brixen | cool beans, I think those are much clearer |
| 07:53:30 | brixen | OT, I wish restoring from time machine was better |
| 07:53:37 | mass | better? |
| 07:53:45 | brixen | I have to reinstall everything from macports to xcode |
| 07:53:51 | rue | "Standard" should be OK, I went with "target" originally because it implies something that has been specifically designated (but may change in the future) |
| 07:54:13 | brixen | rue: yeah, I got it now, but I really like "standard" better |
| 07:54:20 | brixen | since we're talking about a spec :) |
| 07:54:37 | rue | It is probably simpler |
| 07:54:46 | rue | "Reference," too |
| 07:55:05 | rue | Too technical |
| 07:55:25 | brixen | yeah |
| 07:56:33 | brixen | my reluctance on the GuardFailure class is that we could use other helpers in the future, I'd rather not over guess this now |
| 07:56:33 | rue | OK, so the tags give us a way to set up excludes and explain why they are excluded |
| 07:56:39 | brixen | yeah |
| 07:56:44 | brixen | any tag |
| 07:56:46 | brixen | really |
| 07:56:59 | brixen | but for now, "incomplete" and "excluded" will have special meaning |
| 07:57:02 | rue | What do you mean by other helpers? |
| 07:57:14 | brixen | not sure, that's the point :P |
| 07:57:26 | brixen | methods called in a block that aren't in the special list |
| 07:58:51 | brixen | it just seems to me that this could be way simplified by using a different #describe method on the runner for verify mode |
| 07:58:58 | brixen | and dispense with all the exceptions |
| 07:59:09 | rue | Ah. It is there for testing purposes now, actually, I am not sure whether to leave it in or out. Generally though a guard should exactly wrap an #it (or #describe as soon as I add it) |
| 07:59:37 | brixen | also #before, #after |
| 07:59:40 | rue | It is possible that it might turn out simpler, definitely, definitely |
| 08:00:00 | rue | Those three need no special processing |
| 08:00:02 | brixen | I'd rather guard a whole #before, #after for e.g. windows than have the guard inside |
| 08:00:08 | rue | Yes |
| 08:01:53 | brixen | rue: it just seems that they could all be fashioned like #quarantine!, normal mode: do one thing, verify mode, do another |
| 08:02:15 | brixen | and in the #describe block, normal mode: handle exception one way, verify mode: handle it another |
| 08:02:28 | brixen | but maybe using the exception classes is the simplest way to encapsulate that |
| 08:04:41 | brixen | MSpec.verify_mode? is much easier on the eyes than MSpec::VERBOSE_GUARDS ;) |
| 08:05:27 | rue | Mm, I like constants |
| 08:05:41 | brixen | well, it's a predicate |
| 08:05:48 | brixen | or it should be |
| 08:06:11 | brixen | we'll get there |
| 08:06:17 | brixen | anyway, must sleep, very early class |
| 08:06:30 | rue | Okaydoke, progress :) |
| 08:06:35 | brixen | indeed |
| 08:06:38 | rue | Lateroo |
| 08:06:42 | brixen | later |
| 08:17:39 | rue | tarcieri: Nice work on the docs for Revactor |
| 08:21:14 | tarcieri | rue: thanks |
| 08:23:08 | rue | No, thank you! ;) |
| 08:25:56 | tarcieri | rue: Now if only I can figure out why trunk is 16 thousand messages per second slower than the release... |
| 08:26:48 | headius | evening |
| 08:26:55 | evan | allo. |
| 08:34:50 | dbussink | evan: i saw some of the 64 bit fixes, but i'm still able to produce segfaults |
| 08:35:01 | dbussink | evan: or did you notice that too? |
| 08:37:16 | evan | damn. |
| 08:37:17 | evan | no |
| 08:37:20 | evan | it went away for me. |
| 08:38:23 | dbussink | running in gdb right now |
| 08:40:11 | dbussink | evan: http://pastie.caboo.se/143188 |
| 08:40:36 | evan | hrm |
| 08:40:38 | evan | same place |
| 08:40:40 | evan | ok |
| 08:49:08 | dbussink | i see some places where byte_array_address is cast to a uint32 and i have seen the error occur during string ops |
| 08:49:12 | dbussink | maybe there is a link? |
| 08:49:35 | dbussink | dunno about the exact details of bytearray_byte_address though |
| 08:50:01 | evan | it should be cast to a uint8* |
| 08:50:16 | evan | unless the cast as for the inside of the object |
| 08:50:31 | dbussink | but shouldn't it be a uint_ptr in that case? |
| 08:51:09 | evan | where did you see that cast? |
| 08:51:12 | evan | i'd have to see it to tell ya |
| 08:51:26 | dbussink | shotgun/lib/bytearray.c: ibuf = (uint32_t*)bytearray_byte_address(state, self); |
| 08:51:46 | dbussink | shotgun/lib/instruction_funcs.gen: insn = (uint32_t*)bytearray_byte_address(state, iseq); |
| 08:51:58 | evan | oh |
| 08:52:02 | dbussink | and the instructions file, but the .gen is generated from that |
| 08:52:10 | evan | yeah |
| 08:52:24 | evan | those are because a compiled ISeq contains runtime specific data |
| 08:52:37 | evan | mainly, a uint32 array |
| 08:52:40 | evan | but good call |
| 08:52:45 | evan | that needs to be changed |
| 08:52:48 | evan | maybe thats the problem. |
| 08:52:55 | dbussink | i can test with it |
| 08:53:31 | evan | look at cpu_compile_method |
| 08:53:50 | evan | it takes an ISeq and processes it to run |
| 08:55:42 | dbussink | yeah, but there it is an OBJECT pointer |
| 08:56:04 | evan | eh? |
| 08:56:18 | dbussink | or am i looking at the wrong thing? |
| 08:58:54 | evan | what are you looking at |
| 08:59:19 | dbussink | i was looking at the cpu_compile_method in cpu_instructions.c |
| 08:59:31 | dbussink | but i guess i'm getting the point |
| 09:00:31 | zimbatm | hi |
| 09:40:06 | rue | Hola |
| 09:40:26 | TheVoice | morning |
| 09:40:50 | TheVoice | rue: what code bits are you working on? |
| 09:45:08 | rue | TheVoice: Right now, finishing up the verification guard system for MSpec |
| 09:50:26 | rue | After that, I think we need to hit IO specs pretty hard |
| 09:50:29 | TheVoice | I'd like to contribute if I could. |
| 09:51:07 | rue | I am sure you can! Did you have something in mind, an area of interest? |
| 09:52:15 | TheVoice | well I'm a project manager and lover of all things ruby. But I'm not much of a programmer and Evan is doing a fine job at the project management from what I can tell. |
| 09:52:32 | evan | (he could use help) |
| 09:52:36 | evan | (yes, he's still awake) |
| 09:52:36 | drbrain | I need IO#fsync, so if somebody could take care of that while I sleep, it would be awesome |
| 09:52:53 | TheVoice | evan: got any ideas how I could help in that area? |
| 09:53:12 | evan | can we talk tomorrow |
| 09:53:15 | evan | i really should be in bed |
| 09:53:41 | TheVoice | ok I'll do what I do best. Tell people what to do. Evan, go to bed. |
| 09:54:35 | rue | TheVoice: Actually, you know where we could really use some management? Patches |
| 09:54:58 | TheVoice | you want me to tell people that they arn't worthy? |
| 09:55:04 | rue | Exactly! |
| 09:55:11 | TheVoice | sweet, right up my alley |
| 09:55:17 | rue | Heh |
| 09:55:56 | TheVoice | so what do the patches need exactly, reviewing? |
| 09:56:02 | rue | Unfortunately right now there just is not enough discipline in checking and committing patches timely |
| 09:56:42 | rue | Yeah, reviewing or even just flat-out making someone do it |
| 09:57:40 | TheVoice | I could also do some organizational stuff, keeping track of which patches are relevant to whats going on in |
| 09:57:43 | TheVoice | that kind of thing |
| 09:57:53 | rue | Yeah |
| 09:58:44 | rue | We want to probably have a Big Discussion but because there are definitely different levels of patches from specs to Core to VM code, it may be best if specific people are assigned to areas of responsibility |
| 09:59:45 | rue | TheVoice: Anyway, I am sure there are other areas where we can use your talent but that is the first thing I thought of if it is something that seems in any way interesting |
| 09:59:58 | rue | It definitely is not the most glamorous thing out there, I admit |
| 10:00:19 | TheVoice | are there any issues right now with 2 developers working on the same thing? Or something organizational like that? |
| 10:00:59 | rue | It has not been too bad, definitely every now and then two people start doing the same thing |
| 10:01:20 | rue | Usually they figure it out early enough though fortunately |
| 10:01:59 | zimbatm | yeah, sync happens on this channel |
| 10:02:03 | rue | Right now the work model is basically do whatever motivates you so drbrain is working on getting Gems going for example, that sort of thing |
| 10:02:13 | TheVoice | yeah thats what I've noticed |
| 10:02:33 | zimbatm | we could also much more benefit of the decentralized features of git |
| 10:02:49 | TheVoice | it would be worthwhile to talk to each commiter and find out what they are working on and a wishlist of things they would like someone else to come in and fix. |
| 10:03:03 | zimbatm | instead of pushing in the main repo, each dev would have it's own, and there would be a merger |
| 10:03:06 | rue | And we have floated ideas like trying to keep a roster of who is doing what but that requires maintenance |
| 10:03:36 | zimbatm | a proper wiki would be nice too, the current one is a bit painful |
| 10:04:01 | TheVoice | rue: thats not a whole lot of maintenance |
| 10:04:27 | TheVoice | I think I'll start by asking evan tomorrow what management tasks are pissing him on that I could take over. |
| 10:04:40 | TheVoice | s/on/off |
| 10:05:30 | rue | TheVoice: To a programmer, taking the Mt. Dew cans out is too much maintenance :) |
| 10:05:42 | rue | </stereotype> |
| 10:06:05 | TheVoice | I only drink water, the first sign I don't know how to code. |
| 10:06:13 | rue | Hehe |
| 10:06:23 | TheVoice | thats the name of my blog actually |
| 10:06:30 | TheVoice | its called I can't code, now what? |
| 10:06:43 | rue | I stick with water mostly myself too. Some milk, and that Simply Apple juice |
| 10:07:39 | rue | TheVoice: Definitely talk to him, though, I am sure there is plenty that needs a steady hand |
| 10:08:45 | rue | TheVoice: brixen is setting up the new web "presence" too, so it might be possible to incorporate some stuff in that process so see what is on his mind, too |
| 10:09:44 | TheVoice | ok I'll ping him for info on whats going on with that. |
| 10:10:09 | TheVoice | another simple thing I noticed was most of the main committer's blogs arn't registered with rubycorner.com |
| 10:10:35 | rue | There is, I bet, a lot in the processes that can be improved |
| 10:10:35 | TheVoice | so there could be more code monkeys out there that arn't aware of rubinius |
| 10:11:05 | rue | The project is pretty organic right now, contrast it with headius' methodical approach ;) |
| 10:11:08 | TheVoice | I find it hard to believe that any person who uses ruby daily doesn't know about it but who knows.l |
| 10:11:37 | TheVoice | when headius is in the channel its like UFC, really fun to watch and you learn a bunch |
| 10:11:47 | headius | methodical, eh? |
| 10:11:55 | TheVoice | well I'm not sure how much you learn from UFC but you get the drift |
| 10:11:58 | rue | Heh, I am sure there are at least folks with outdated info |
| 10:12:39 | rue | headius: Yep! There, I said it, you are methodical :D |
| 10:13:13 | TheVoice | not a bad trait for a language implementer |
| 10:15:16 | rue | headius: Did you put the IO stuff in spec/test form, by the way? |
| 10:15:26 | headius | I think vv started to do some |
| 10:15:32 | headius | I haven't yet |
| 10:15:59 | rue | OK |
| 10:16:56 | rue | headius: You do not think it would be worth it to bother ruby-core about possibly doing some simplification fixes for IO? Or have you concluded that all behaviour is necessary? |
| 10:17:44 | rue | I hope I can get started with the IO stuff shortly |
| 10:17:57 | headius | well, reopen and initialize_copy are pretty complicated, but mostly because they encapsulate a lot of behavior |
| 10:18:05 | TheVoice | thats all going to built ontop of libev right? |
| 10:18:12 | headius | the pipe stuff I don't entirely understand yet, but the rest of it isn't unusual |
| 10:18:30 | headius | and all the other operations are mostly thin wrappers around libc |
| 10:18:49 | headius | if you aren't using FILE* you'll end up doing what I had to do, implement your own buffered IO logic |
| 10:19:31 | headius | gods, op element assignment is a lot of operations |
| 11:35:23 | boyscout | 1 commit by Vladimir Sizikov |
| 11:35:24 | boyscout | * Adjusted socket specs, so they pass on MacOS (MRI/JRuby).; 907081d |
| 11:49:21 | rubuildius | Vladimir Sizikov: 907081db8; 4507 examples, 16867 expectations, 0 failures, 0 errors |
| 11:58:51 | rue | Bedtime, be back in a couple |
| 12:42:34 | boyscout | 1 commit by Vladimir Sizikov |
| 12:42:35 | boyscout | * New specs for String#unpack with 'Q/q' patterns.; 0ef7d55 |
| 12:54:21 | rubuildius | Vladimir Sizikov: 0ef7d55eb; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 13:32:36 | boyscout | 1 commit by Vladimir Sizikov |
| 13:32:38 | boyscout | * New specs for IO#seek, IO#pos=, StringIO#seek and non-fixnum args.; 3af242c |
| 13:44:22 | rubuildius | Vladimir Sizikov: 3af242cc1; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 15:31:08 | pate | ok, sign me up as excited for mod_rubinius |
| 15:55:18 | rue | pate: Alrighty, you are all signed up |
| 15:55:31 | rue | You will be deployed February 6th |
| 15:55:55 | pate | woot! |
| 16:10:06 | dbussink | too bad i get the idea i'm the only one having problems with rubinius on 64 bit :( |
| 16:10:14 | dbussink | i'm not the guy for fixing this :P |
| 16:14:06 | djwhitt | you're not the only one, but I don't feel up to trying to fix them either |
| 16:16:27 | djwhitt | if anyone needs any amd64 debugging output though, let me know |
| 16:16:52 | dbussink | i gave mine to evan already, he did fix some things but there is still something |
| 16:17:51 | djwhitt | Defiler was working on some changes I thought |
| 16:19:09 | dbussink | yeah, but he was focussing on getting rid of the warnings and clear errors |
| 16:19:18 | dbussink | he didn't know al about it too |
| 16:25:24 | djwhitt | dbussink: what error are you getting now? |
| 16:25:39 | dbussink | still the attempted to access field errors |
| 16:25:41 | djwhitt | I'm getting: Attempted to access field 3 in an object with 0 fields. |
| 16:25:42 | djwhitt | yeah |
| 16:26:05 | djwhitt | you running amd64 as well? |
| 16:26:31 | dbussink | i have a server i can use with it |
| 16:26:39 | dbussink | not really mine, but i manage the thing |
| 16:27:45 | djwhitt | hmm... I could probably give someone a login to my box if they wanted to try to track the issue down |
| 16:27:51 | rue | dbussink: Was it a consistent or intermittent issue? |
| 16:28:13 | djwhitt | rue: it's consistent for me |
| 16:28:20 | dbussink | well, it's not consistent as in that it occurs at the exact same moment every time |
| 16:28:21 | rue | Google slow for anyone else? |
| 16:28:36 | dbussink | but it will fail during a ./bin/ci run |
| 16:28:47 | djwhitt | I see the same behavior |
| 16:28:58 | djwhitt | not the same spec everytime, but it always fails running ./bin/ci |
| 16:29:51 | dbussink | something corrupts during gc, probably because of a overflowing pointer |
| 16:29:56 | dbussink | but i can't find it |
| 16:30:45 | rue | Can you try with RUBINIUS_OMSIZE=8388608 ? |
| 16:30:56 | dbussink | running or compiling? |
| 16:31:07 | rue | Running |
| 16:32:20 | dbussink | i just ran RUBINIUS_OMSIZE=8388608 ./bin/ci and it shows the same problem |
| 16:32:39 | rue | OK |
| 16:32:52 | rue | OMSIZE, as you may guess, is the object memory size |
| 16:33:14 | dbussink | what is the default right now? |
| 16:33:45 | rue | This would indicate that we are definitely dealing with corruption rather than allocation issues |
| 16:34:11 | rue | 4MiB |
| 16:36:46 | rue | Man, I should really sleep longer than three hours one of these nights |
| 16:37:20 | Arjen | Sleep is for the weak. |
| 16:37:49 | dbussink | Arjen_: hey, another dutchman |
| 16:38:04 | rue | Careful, he could be an impostor! |
| 16:38:07 | Arjen | dbussink, hi. :) |
| 16:38:18 | dbussink | rue: i know his company :P |
| 16:38:29 | Arjen | dbussink, and I know yours. :) |
| 16:38:39 | dbussink | which one? :) |
| 16:38:45 | Arjen | Byte? |
| 16:39:03 | dbussink | yeah, them too |
| 16:58:52 | rue | brixen: Hm, how about s/implementation/engine/g from last night? I dunno, to me it implies the "current" part more but I am not sure if it reads the same to you? |
| 17:09:01 | rue | I guess implementation is a bit more generic |
| 17:09:06 | dbussink | how do i forse an exclude for certain specs? |
| 17:10:21 | rue | You can create an exclude set with -c against a specific directory, for example |
| 17:10:41 | dbussink | but i want to exclude a set of specs that doesn't fail |
| 17:10:54 | pate | w00t! it's announced ... I can let the cat out of the bag ... |
| 17:11:05 | rue | dbussink: Why? It would probably be a guard |
| 17:11:21 | pate | Ezra and Evan are going to be the opening keynote at the MountainWest RubyConf in March |
| 17:11:28 | pate | does a happy dance |
| 17:11:35 | rue | pate: Did we not have a talk about animal cruelty? |
| 17:11:35 | dbussink | rue: i have an idea what the culprit might be that causes the 64 bit faults |
| 17:11:44 | rue | pate: Oh, very nice! |
| 17:12:06 | dbussink | rue: so i want to exclude a set of specs and run all others, to see whether the bug is triggered |
| 17:12:08 | rue | The conf is definitely looking good otherwise too |
| 17:12:13 | pate | rue, thanks |
| 17:12:44 | rue | pate: And no more holding cats hostage! I am sure evan can be persuaded without kittynapping :) |
| 17:13:30 | rue | dbussink: You could manually add them to the exclude file, I suppose unless a guard is sufficient |
| 17:15:23 | rue | It is just describe_text + ' ' + spec_text, I think |
| 17:17:16 | boyscout | 1 commit by Vladimir Sizikov |
| 17:17:17 | boyscout | * Added a guard for undefined AF_UNIX in Socket specs.; 1834801 |
| 17:17:18 | dbussink | rue: i just removed some spec files from tmp/last_ci.rb, it's ugly but the quickest way |
| 17:17:33 | dbussink | rue: i really hope i found it... |
| 17:18:01 | rue | What are you looking at? |
| 17:18:33 | dbussink | i'm suspecting that the onigurama library is one of the main causes of the 64 bit issues |
| 17:18:58 | VVSiz | dbussink: you could use -x switch to exclude some tests from running |
| 17:19:07 | rue | Really? |
| 17:19:21 | rue | Stupid Google being slow |
| 17:19:31 | dbussink | rue: yeah, looks like it's completely 64 bit unsafe |
| 17:19:50 | dbussink | weird xmallocs that return an int instead of a pointer |
| 17:21:01 | dbussink | rue: and we're gonna need to fix some things in libmquark to |
| 17:21:04 | rue | Oh, wait.. something on ruby-core I saw |
| 17:22:07 | rue | http://www.ruby-forum.com/topic/140117 |
| 17:23:04 | dbussink | rue: looks like another issue |
| 17:23:39 | dbussink | rue: www.ruytersenverberkt.nl |
| 17:23:49 | dbussink | rue: argh |
| 17:23:53 | dbussink | rue: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/255198 |
| 17:24:10 | rue | Just found that too |
| 17:24:16 | rue | I am actually *really* surprised |
| 17:27:57 | dbussink | and a lot of things use regexp |
| 17:29:21 | rubuildius | Vladimir Sizikov: 183480122; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 17:37:37 | dbussink | what is the actual difference between xmalloc and malloc? |
| 17:41:14 | rue | I think xmalloc() checks for OOM |
| 17:42:36 | dbussink | but it's strange that it returns an int and not a pointer |
| 17:42:43 | dbussink | but this only happens for onig |
| 17:42:50 | boyscout | 1 commit by Vladimir Sizikov |
| 17:42:51 | boyscout | * Better detection of AF_INET6 support in socket specs.; fe8433c |
| 17:54:20 | rubuildius | Vladimir Sizikov: fe8433cda; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 17:54:56 | zimbatm | vlad is frenzy today |
| 18:51:14 | rue | brixen: Also, #verify_mode? or #verification_mode? |
| 19:01:41 | evan | morning |
| 19:02:02 | evan | i've been trying to figure out if we're going skydiving tomorrow or not |
| 19:02:38 | evan | hm, /i on regex's seems to be broken |
| 19:02:53 | evan | ditto with calling it with Regexp.new(... ::IGNORECASE) |
| 19:03:06 | rue | Hehee, morning! That is one of the things you want to know about before it is too late |
| 19:03:38 | evan | yeah, it's about an hour and a half drive to the place |
| 19:03:46 | evan | so hopefully we'll know whats up tomorrow morning |
| 19:03:48 | evan | before we drive out. |
| 19:03:52 | rue | Heh |
| 19:04:54 | rue | Really? "foo" =~ /FOO/i matches here |
| 19:05:09 | evan | hrm. |
| 19:05:22 | evan | something is up with this regex then... |
| 19:05:32 | rue | Could it be the #=~ itself? |
| 19:05:41 | evan | i'm calling match |
| 19:05:45 | evan | i guess it could be... |
| 19:05:53 | evan | let me try something |
| 19:06:13 | evan | wtf. |
| 19:06:24 | evan | r = Regexp.new("[^-+',.\/:0-9@a-z]+", Regexp::IGNORECASE) |
| 19:06:29 | rue | What are you calling it on? |
| 19:06:31 | evan | r.match "Wednesday" |
| 19:06:34 | goodney | evan:send me a text... |
| 19:06:38 | evan | p m[0] |
| 19:06:42 | evan | on 1.8 |
| 19:06:48 | evan | " " |
| 19:06:50 | evan | on rubinius |
| 19:06:51 | evan | "W" |
| 19:07:03 | evan | the next is actually "Wednesday <more stuff>" |
| 19:07:19 | evan | goodney: sent |
| 19:07:23 | goodney | k |
| 19:08:06 | rue | Hum, I am actually seeing an error in MRI :P |
| 19:08:48 | rue | Does \w work instead? |
| 19:09:03 | rue | Or not work, I suppose it might be here |
| 19:09:23 | evan | no |
| 19:09:28 | evan | \w doesn't seem to work either. |
| 19:09:47 | goodney | text recieved... |
| 19:09:51 | evan | if i make it just |
| 19:09:52 | goodney | that seemed to take awhile |
| 19:09:59 | evan | [^a-z]+ |
| 19:10:06 | evan | MRI gets " ", rbx gets "W" |
| 19:10:41 | evan | i'm starting to think it's onig... |
| 19:11:08 | rue | dbussink located what looks like a 64-bit issue with onig earlier |
| 19:11:53 | evan | OH HO |
| 19:11:55 | evan | look at that. |
| 19:12:03 | evan | MRI trunk uses a different regex. |
| 19:12:20 | evan | and no /i |
| 19:12:29 | evan | i wonder if onig behaves differently for this... |
| 19:12:41 | rue | Is Onig not applying /i to the character classes? |
| 19:12:52 | rue | Erm, is rather |
| 19:13:07 | evan | perhaps |
| 19:13:12 | rue | tizianobis is going to have a long tail if this keeps up |
| 19:14:22 | brixen | rue: verify_mode? seems nice, it's shorter ;) |
| 19:14:23 | rue | Heh--so trunk differs here, what is this Date code? |
| 19:14:35 | evan | rue: Date._parse |
| 19:14:41 | evan | Time.parse calls it. |
| 19:14:49 | rue | brixen: OK, what about 'implementation' vs. 'engine'? |
| 19:15:12 | rue | evan: Aha, yep. I was actually just writing a little parser for that |
| 19:15:30 | evan | i think i'm going to copy in the trunk versions |
| 19:15:34 | evan | see if they work as is. |
| 19:15:34 | brixen | rue: well, hmm, if we can get people to adopt RUBY_ENGINE that would be slick, but I think implementation has the least ambiguity |
| 19:15:42 | evan | it looks like they've got a lot of fixes |
| 19:16:09 | rue | brixen: OK |
| 19:17:34 | rue | evan: I meant to ask, what are we doing for broken/bad stdlib stuff? I am not sure there are such situations now but is there a general rule against ever just rewriting the lib? |
| 19:17:47 | rue | Or patching it or whatever |
| 19:18:27 | evan | for a total rewrite, we have to have a really good reason |
| 19:18:40 | rue | Sure, that was probably a bad choice of words |
| 19:18:41 | evan | small patches are fine, so long as they don't change functionality |
| 19:19:30 | rue | OK, sure. API compatibility is no-brainer, just wanted to make sure that we do not need to accept a tarball Stdlib from MRI or something |
| 19:19:54 | rue | Hopefully it will not be an issue, Stdlib just seems a bit neglected though. |
| 19:20:23 | VVSiz | brixen: a few questions for you... we struggling a bit with running/filtering specs for Unix sockets under JRuby |
| 19:20:32 | brixen | VVSiz: ok |
| 19:20:51 | brixen | VVSiz: btw, generalized tagging is coming, so can add a comment for why you have something excluded |
| 19:20:53 | VVSiz | I can mark them as non_compliant_on :jruby, but that's not the best option |
| 19:21:06 | VVSiz | oh |
| 19:21:24 | VVSiz | also, MRI on Windows also does not support unix sockets |
| 19:21:37 | VVSiz | and sooner or later, the specs will be tried under windows... :) |
| 19:22:20 | VVSiz | I tried to guard using if Socket.const_defined?(:AF_UNIX), but also doesn't work, since MRI on windows DOES have this defined (damn!) :) |
| 19:22:22 | brixen | VVSiz: so, why do you need the non_compliant... is it just behaving badly, can't impl, etc? |
| 19:22:46 | VVSiz | it's completely not supported and might never be supported in JRuby |
| 19:23:02 | VVSiz | it also not supported in MRI on Windows (but that's not really critical for me now :) ) |
| 19:23:15 | brixen | VVSiz: so, you're saying something that says #not_supported_on ? |
| 19:24:03 | VVSiz | I dunno... how do you express that not supported on MRI under Windows, but not if under Cygwin? :) |
| 19:24:17 | brixen | yeah, I see the issue |
| 19:25:07 | VVSiz | for now, I sure can just mark as non_complian_on :jruby, but that won't be solved 100% since somebody on Windows would still have the problem, and sooner or later something needs to be done to handle both cases |
| 19:25:52 | brixen | but non_compliant_on takes multiple implementations |
| 19:25:57 | brixen | is that not the issue? |
| 19:26:08 | brixen | non_compliant_on :jruby, :mswin |
| 19:26:26 | VVSiz | oh, you can do that? :) |
| 19:26:27 | brixen | I'm ok adding #not_supported_on |
| 19:26:33 | brixen | yeah, 'course ;) |
| 19:27:05 | VVSiz | heheheeh, you seems to be anticipating everything! ;) |
| 19:27:12 | VVSiz | I like #no_supported_on |
| 19:27:28 | VVSiz | the intent is clear, and much better than just non_compliant_on |
| 19:27:37 | brixen | ok, makes sense, some things there is just no way to do, so you shouldn't be penalized I guess |
| 19:27:40 | brixen | yeah |
| 19:28:26 | rue | brixen, VVSiz: Actually #compliant_on requires an implementation name currently although that can be changed |
| 19:28:52 | rue | But #not_supported_on sounds better to me |
| 19:29:40 | VVSiz | there are very few things that might never be possible to implement 100% on top of VM (fork, callccs, unix sockets)... it would be good to mark them as such |
| 19:29:51 | brixen | VVSiz: yep, agreed |
| 19:31:20 | brixen | rue: #compliant_on wouldn't require an impl name? |
| 19:31:48 | brixen | VVSiz: you want to add the #not_supported_on ? |
| 19:32:25 | VVSiz | sure I can. it will be just a different name for not_compliant_on, right? |
| 19:32:46 | brixen | same semantics, yes |
| 19:32:58 | VVSiz | OK, will do (right now) |
| 19:33:06 | VVSiz | thanks! |
| 19:33:07 | rue | brixen: Sure |
| 19:33:19 | rue | brixen: I meant that #compliant_on cannot use a platform |
| 19:34:01 | brixen | rue: ah, right |
| 19:34:18 | brixen | so the guards except for #platform take an implementation (engine) |
| 19:34:23 | rue | Yes |
| 19:34:54 | brixen | I toyed with the idea of adding engine to #platform, but seems like it would just be abused |
| 19:35:15 | evan | HA! |
| 19:35:22 | evan | MRI has a cut off for 2 digit years |
| 19:35:42 | evan | 0..39 => means 2000+ |
| 19:36:00 | evan | 69..139 => 1900+ |
| 19:36:15 | evan | oh actually |
| 19:36:23 | evan | 40..68 is 1900+ too |
| 19:36:43 | drbrain | 2039 makes sense |
| 19:36:56 | drbrain | I've never seen it used, though |
| 19:36:58 | evan | i've making that change to our code |
| 19:37:05 | evan | but then i'm going to fix Time.parse |
| 19:37:12 | evan | it's emitting 2 digit dates |
| 19:37:16 | evan | year wise |
| 19:37:16 | rue | brixen: Probably |
| 19:37:57 | rue | brixen: Aargh with the premature carriage returns today! I would actually like to move :version etc. out of #platform for that matter |
| 19:38:31 | brixen | rue: remove it, or move it to the impl guards? |
| 19:40:03 | rue | Moving it to something like #engine_is is what I was thinking |
| 19:40:16 | rue | Although it could certainly go to the guards too |
| 19:40:53 | rue | not_compliant_on :version => '0.9' or whatever |
| 19:41:22 | brixen | well, the primary reason for :version was because we were trying to track more than one MRI |
| 19:41:34 | brixen | is there a good reason to track another impl's version? |
| 19:43:20 | rue | Well, I think that *having* :version et al. available is good even though we should not be using them, really |
| 19:43:21 | brixen | rue: also, with this tagging, I think I'm going to need to hook into the runner directly, rather than just giving the formatter a different output IO |
| 19:43:49 | rue | Whether it goes into a new guard or old not sure |
| 19:43:57 | brixen | rue: ok, I'd rather add :version to those other guards than make a #engine_is guard |
| 19:44:19 | rue | brixen: Oh, you have an example/use case for the output? |
| 19:44:34 | rue | brixen: Roger roger |
| 19:44:47 | brixen | sure, I'm thinking it would be good to be able to assign two actions, 1 for when the spec passes, 2 for when it fails |
| 19:44:50 | VVSiz | I just confirmed that not_supported/compliant_on :mswin won't work |
| 19:44:51 | brixen | so, excludes would be... |
| 19:45:04 | brixen | pass: nothing, fail, write out the exclude tag |
| 19:45:12 | brixen | creating excludes that is |
| 19:45:21 | brixen | VVSiz: why's that? |
| 19:45:35 | rue | brixen: You know, I realized too late but I really should have just shown you the verbose_guards spec run first yesterday, would probably have avoided some confusion :) |
| 19:45:40 | VVSiz | I guess that's what rue tried to say earlier |
| 19:45:49 | rue | Yeap |
| 19:45:58 | brixen | ahhh |
| 19:46:08 | brixen | yes, mswin isn't an engine |
| 19:46:15 | brixen | it's a rusty old bicycle :P |
| 19:46:24 | VVSiz | :) |
| 19:46:30 | rue | brixen: At which point is the exclude checked for skipping anyway? |
| 19:46:40 | VVSiz | on a bright side, mspec can run on windows (doing it right now) :) |
| 19:46:43 | rue | Op, need to head out in a bit.. semi-AFK |
| 19:46:44 | brixen | rue: well, that's a different layer |
| 19:46:52 | brixen | rue: ok, le'me think on this |
| 19:47:02 | brixen | VVSiz: nice :) |
| 19:47:33 | rue | brixen: By all means put your ideas on the channel, I will catch up |
| 19:47:34 | evan | //inox |
| 19:47:34 | evan | ^^^ |
| 19:47:36 | evan | inox? |
| 19:47:39 | VVSiz | and I could have nice MacOS X instead of this crappy Vistax64!!! :) |
| 19:47:46 | rue | n is no multibyte |
| 19:47:53 | rue | o is once, x extended |
| 19:48:12 | rue | brixen: But yeah, I am not sure if you can use the same "technique" I did |
| 19:48:35 | evan | rue: danke |
| 19:48:42 | brixen | rue: well, generally, the idea is you would associate a tag with whether to execute or not |
| 19:49:10 | brixen | rue: so for *running* excludes, tag == excluded, don't run |
| 19:49:14 | rue | brixen: Right, so how you implement the messaging, I think, would depend on when you can determine the spec is excluded right? |
| 19:49:40 | rue | OR, if you want to be lazy, just exclude like you do now and just fake the output |
| 19:49:46 | brixen | rue: well, think of it as a pre-action, post-action |
| 19:49:54 | brixen | pre-action could be: don't run if it has this tag |
| 19:50:04 | brixen | post-action would be: write exclude tag if it fails |
| 19:50:25 | brixen | or think of it as filters and triggers |
| 19:50:42 | brixen | filters say yes or no to executing the spec, pass/fail triggers some other action |
| 19:51:05 | rue | OK, so the exclude itself causes the filter to reject which can be detected in the post-action? |
| 19:51:20 | brixen | no, just prevents the spec from running |
| 19:51:44 | brixen | bin/ci -i would be an opposite filter, run those tagged with excluded |
| 19:51:48 | brixen | that sort of thing |
| 19:51:53 | brixen | the triggers are separate |
| 19:52:31 | brixen | VVSiz / rue: so, I think we'll have to generalize what get's passed to the normal guards (excluding #platform) |
| 19:52:42 | brixen | because :mswin should really be it's own thing |
| 19:53:41 | brixen | or composite them? #not_supported_on :ruby, :under => :mswin ? |
| 19:54:00 | brixen | windows complicates everything under the sun, ugh |
| 19:55:37 | rue | That quickly gets into AND/OR requirements from users |
| 19:55:45 | brixen | yeah |
| 19:56:34 | rue | Which is fine, but needs to be decided |
| 19:56:36 | brixen | we could simply allow the engine? and platform? there: e.g. not_supported_on :jruby, :mswin |
| 19:57:15 | brixen | for a particular symbol, if it matches engine? or platform? it's not run |
| 19:57:51 | brixen | makes sense for :msdos too, I suppose |
| 19:58:33 | brixen | or for :palm perhaps |
| 20:05:34 | rue | Yeah |
| 20:05:52 | rue | I have no problem getting it all implemented once we know what we are going to do |
| 20:05:57 | drbrain | weird |
| 20:06:06 | drbrain | shotgun/rubinius -rfileutils -e FileUtils.symlink |
| 20:06:15 | drbrain | but, ln_s "works" (reponts ArgumentError) |
| 20:06:20 | drbrain | reports |
| 20:06:42 | rue | evan, brixen: I will probably not be back until around 11pm PST |
| 20:06:53 | brixen | rue: ok |
| 20:07:01 | evan | no problem. |
| 20:07:10 | brixen | rue: I'm thinking I'm going to implement this machinery in SpecRunner itself |
| 20:07:14 | brixen | rather than the scripts |
| 20:07:26 | brixen | rue: you should be able to hook into it easily for the verify_mode guards |
| 20:07:42 | rue | brixen: Out the door now but elaborate in the buffer if you can |
| 20:08:01 | rue | I have no particular attachment to current design so we will figure it out |
| 20:08:10 | brixen | rue: ok |
| 20:09:22 | boyscout | 1 commit by Vladimir Sizikov |
| 20:09:23 | boyscout | * Added not_supported_on guard.; 041e5e3 |
| 20:11:26 | VVSiz | brixen: so I'll just use not_supported_on :jruby, and we could update the guards if/when :mswin is supported, or any other decision is made. |
| 20:12:12 | brixen | VVSiz: ok, sure |
| 20:13:51 | evan | does output() take a regex? |
| 20:14:02 | evan | i want to match the not directly |
| 20:14:05 | brixen | yeah |
| 20:14:06 | evan | i fixed warn |
| 20:14:09 | evan | so it prints the file and line |
| 20:14:11 | brixen | I think headius added that |
| 20:14:13 | evan | now the warn specs fail |
| 20:14:31 | dgtized | evan: should we replace Globals and Thread locals with the LookupTable? |
| 20:14:37 | brixen | so, lambda { .. }.should output(/this/) |
| 20:14:38 | evan | dgtized: already did |
| 20:14:42 | evan | dgtized: Globals at least |
| 20:14:44 | evan | about to commit it. |
| 20:14:53 | evan | Thread locals though, yes. |
| 20:14:56 | dgtized | it's a single line change for Thread locals too |
| 20:15:16 | evan | yeah, go for it. |
| 20:15:46 | evan | i might move LookupTable#[] as a primitive only |
| 20:15:52 | evan | we'll see. |
| 20:17:00 | dgtized | I haven't had a chance to do a performance regression on it though it certainly would be expected to speed things up |
| 20:19:25 | rubuildius | Vladimir Sizikov: 041e5e3f3; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 20:20:59 | boyscout | 1 commit by Evan Phoenix |
| 20:21:00 | boyscout | * A couple of easy fixes, fix Time to handle 2 digit dates, pull in trunk date; 78ca098 |
| 20:22:33 | evan | wtf. |
| 20:22:41 | evan | undefine_finalizer |
| 20:22:42 | evan | :P |
| 20:24:19 | dgtized | that's pretty unfinal |
| 20:24:23 | boyscout | 1 commit by Charles Comstock |
| 20:24:24 | boyscout | * switched Thread local variable storage to use a LookupTable instead of a Hash for ...; 02e1e6e |
| 20:26:50 | VVSiz | pastie: gimme? |
| 20:27:07 | pastie | http://pastie.org/143467 by VVSiz. |
| 20:27:27 | VVSiz | the crash I get with the latest rbx running ci |
| 20:28:24 | evan | hrm |
| 20:28:26 | VVSiz | doing full clean-rebuild now, just to make sure... |
| 20:32:28 | dgtized | So does LookupTable automatically store everything as a symbol? |
| 20:32:35 | evan | no |
| 20:32:44 | evan | thats the callers duty. |
| 20:33:07 | dgtized | k, there is already wrapper code in the Thread specs to convert everything to symbols, it seems like it would be useful to have a Hash subclass with that behavior though |
| 20:33:45 | dgtized | or at least a module to include into specific instances |
| 20:34:06 | evan | a module that does what? |
| 20:34:20 | rubuildius | Charles Comstock: 02e1e6ed2; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 20:36:07 | dgtized | a module that swaps out [], []=, and store so that they automatically change the keys to symbols |
| 20:36:26 | dgtized | presumption being your hashing on a string or symbol |
| 20:36:34 | dgtized | or number I guess |
| 20:37:49 | evan | who would use that? |
| 20:37:55 | evan | what would be the API? |
| 20:38:06 | evan | maybe add |
| 20:38:14 | evan | LookupTable#symbols_only! |
| 20:38:32 | evan | that causes the Table to have SymbolsConvert mixed into the object |
| 20:39:31 | VVSiz | evan: nope, after full rake clean, rake pristine, rake, still a SIGABRT when running ci |
| 20:39:39 | evan | great. |
| 20:39:40 | evan | what platform? |
| 20:39:47 | VVSiz | ubuntu linux |
| 20:40:04 | VVSiz | trying to narrow down to particular spec |
| 20:40:11 | evan | it's in the GC |
| 20:40:24 | evan | so it's likely not going to be a specific spec. |
| 20:40:56 | VVSiz | bin/ci -V -t x spec/ruby/1.8/library/digest/md5/digest_spec.rb |
| 20:40:59 | VVSiz | that's the one |
| 20:41:35 | VVSiz | pastie: for evan |
| 20:41:50 | pastie | evan: http://pastie.org/143481 by VVSiz. |
| 20:42:03 | evan | not the same |
| 20:42:07 | evan | but still valid |
| 20:42:08 | evan | one sec |
| 20:42:10 | VVSiz | yeah |
| 20:42:27 | evan | drbrain is free'ing memory twice. |
| 20:48:20 | boyscout | 1 commit by Vladimir Sizikov |
| 20:48:21 | boyscout | * Updated not_compliant_on --> not_supported_on, where appropriate.; ecd3ee8 |
| 20:48:27 | evan | drbrain: you around? |
| 20:59:19 | rubuildius | Vladimir Sizikov: ecd3ee8a0; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 20:59:31 | VVSiz | hey, it seems that the default ci completely igrones the whole spec/ruby/1.8/library dir!!! |
| 21:00:12 | dgtized | VVSiz: I'm not getting a SIGABRT on ubuntu |
| 21:00:38 | VVSiz | dgtized: how do you run? by the command line above? |
| 21:02:45 | VVSiz | and there are a lot of failures when library specs are run in CI |
| 21:04:06 | Defiler | evan: Around? |
| 21:06:54 | Defiler | ezmobius: ping, when you have a minute |
| 21:07:02 | ezmobius | pongage |
| 21:07:46 | Defiler | ezmobius: So, I'm using merb to rewrite my paste site.. |
| 21:08:14 | ezmobius | k |
| 21:08:19 | Defiler | ezmobius: Is there a way to get the ActiveRecord rspec helpers to load? In particular, I am trying to use "@foo.should have(2).errors_on(:baz)" |
| 21:09:22 | ezmobius | hmm good question. i havent used AR in a long time. let me ask some of the guys that are using it |
| 21:09:38 | Defiler | Cool. Thanks. |
| 21:09:49 | Defiler | What are you using now instead of AR? |
| 21:10:56 | ezmobius | sequel or datamapper. but i;ve mainly been workign with entrepot which is our ejabberd/mnsesia heirarchal xmpp database thinguy |
| 21:11:04 | Defiler | Aah |
| 21:20:30 | dgtized | VVSiz: I just run bin/ci and it runs clean. I agree there are lots of library specs that fail, not certain they should be included by default in the bin/ci test, perhaps we need bin/ci --library? |
| 21:21:45 | dgtized | VVSiz: when I run the cmd you posted above it fails, but there is no SIGABRT |
| 21:24:26 | boyscout | 1 commit by Evan Phoenix |
| 21:24:27 | boyscout | * Fix Enumerable#sort_by, fix memory error in digest; 105bad5 |
| 21:24:27 | evan | VVSiz: update and try that ^^^^ |
| 21:28:42 | evan | ok, lunch. |
| 21:34:18 | rubuildius | Evan Phoenix: 105bad5f1; 4509 examples, 16873 expectations, 0 failures, 0 errors |
| 21:43:37 | Defiler | Any Makefile hackers around? |
| 21:43:41 | Defiler | I need an extra pair of eyes |
| 21:44:47 | brixen | I can take a look |
| 21:45:06 | Defiler | OK.. so, shotgun/lib/Makefile |
| 21:45:22 | Defiler | line 73 sets the CFLAGS variable based on CPPFLAGS |
| 21:45:51 | brixen | k |
| 21:45:52 | Defiler | However, line 99 (for example), directly uses CPPFLAGS |
| 21:46:06 | Defiler | I am trying to make it possible to pass in a -arch option from the environment |
| 21:46:11 | Defiler | ..and have it obeyed |
| 21:47:27 | brixen | how are you passing it in? CFLAGS= or something? |
| 21:48:01 | Defiler | However |
| 21:48:07 | Defiler | At the moment, I'm just doing export CFLAGS=blah |
| 21:49:00 | Defiler | setting CPPFLAGS appears to generally work |
| 21:49:21 | Defiler | ..but it isn't obeyed everywhere, so I get warnings from ld |
| 21:49:33 | Defiler | saying that .libs/blah.o is not of required architecture |
| 21:49:43 | Defiler | Presumably because some things are getting the -arch flag and others are not |
| 21:49:49 | brixen | makes sense |
| 21:50:20 | brixen | what does VERBOSE=1 show? |
| 21:50:21 | Defiler | Yeah, and it eventually ends in tears (i.e. a link error) |
| 21:50:31 | Defiler | Let me paste a full build, and you can see what I get |
| 21:50:35 | brixen | k |
| 21:53:12 | brixen | Defiler: tilman had a ticket to merge shotgun/Makefile and shotgun/lib/Makefile |
| 21:53:26 | brixen | Defiler: evan said that was ok to do, maybe that would make this easier for you? |
| 21:53:37 | Defiler | http://rafb.net/p/bHdOR398.html |
| 21:53:49 | brixen | ah, found it #171 |
| 21:53:49 | Defiler | It wouldn't hurt, yeah |
| 21:54:08 | Defiler | ..but you can see in this paste that some things are getting: -arch x86_64, but others are not |
| 21:54:18 | Defiler | So it all ends in tears |
| 21:55:28 | brixen | well, e.g. libzip, it looks like they all get -arch but I see ld complaining |
| 21:56:11 | Defiler | If I remove CPPFLAGS and just set CC to be 'gcc -arch x86_64', it all builds fine |
| 21:56:30 | Defiler | ..but onig's configure script bitches because it is terrible |
| 21:56:44 | Defiler | So, rather than fixing that file, I was hoping to find a better way to insert this option |
| 21:56:45 | brixen | k |
| 21:57:21 | drbrain | bleh, module_function can't do it's thing on an alias of a private method |
| 21:58:36 | Defiler | Really? |
| 21:58:38 | brixen | drbrain: more info? |
| 21:58:52 | brixen | drbrain: e.g. Kernel.sprintf and format |
| 21:59:04 | drbrain | shotgun/rubinius -r fileutils -e 'FileUtils.symlink' |
| 21:59:12 | brixen | format is an alias after module_function :sprintf |
| 21:59:30 | brixen | which marks sprintf private |
| 22:02:57 | brixen | drbrain: ah, in core/kernel the alias is done before the call to module_function |
| 22:03:16 | brixen | but seems we could just fix module_function |
| 22:03:32 | drbrain | shouldn't module_function make things public? |
| 22:03:43 | drbrain | ... in the metaclass? |
| 22:03:56 | drbrain | it looks like everything is still private |
| 22:07:31 | brixen | ri says module_function makes the instance methods private |
| 22:08:02 | drbrain | no, in the metaclass |
| 22:08:12 | brixen | Defiler: did you try using nm to see of the .o files are correct? I think it's an issue with the flag to the linker |
| 22:08:42 | brixen | drbrain: oh, sure, but alias is referring to the instance method |
| 22:10:21 | drbrain | so? |
| 22:10:57 | brixen | so, is the issue with alias or module_function? |
| 22:11:24 | drbrain | all the methods in the metaclass are private |
| 22:11:33 | drbrain | when moved there by module_function |
| 22:11:38 | drbrain | that seems wrong |
| 22:18:23 | brixen | drbrain: http://pastie.org/143563 |
| 22:18:36 | brixen | it's duping the method, which was previously set to private |
| 22:44:20 | evan | i'm back |
| 22:45:13 | evan | drbrain: did my change to alias_method give you trouble? |
| 22:50:02 | brixen | evan: module_function was duping the method, which had been set to private by a previous call to module_function, so everything worked but you couldn't call the method (e.g. F.foo) |
| 22:50:13 | brixen | it's a one line fix in #module_function |
| 22:50:18 | evan | k |
| 22:50:41 | evan | there seem to be some edge cases with alias + vis changes |