Show enters and exits. Hide enters and exits.

00:01:13boyscout1 commit by Benjamin Andresen
00:01:14boyscout * initial rubuildius commit, read tools/rubuildius/README; 23f4753
00:01:26evanthere ya go!
00:01:34bennyyay, my 2nd time the name came up... I get super internets credits ;-)
00:04:24rubuildiusEvan Phoenix: 346abe2f8; 4507 examples, 16867 expectations, 0 failures, 0 errors
00:05:16agardinerand there it is > 4500 examples!
00:08:01evani unexcluded a bunch of kernel ones today
00:08:06evanthey're stupid specs
00:08:11evanthey just test that some methods exist
00:08:13evanbut not what they do
00:08:16evanso i just made them exist.
00:08:28evandef trace_var(*args)
00:08:32evan raise NotImplementedError
00:08:51agardinerand still the specs pass... stoopid! :-D
00:09:36agardinerwe should fill out all the missing specs the same way, and be done! :-P
00:09:56drbrainevan: see Hash#clone's spec
00:10:05evanhaving the method exist in the first step to passing!
00:10:06drbrainI fully implemented it, but the spec is awesome
00:10:21zenspiderfucking HUP
00:10:34evanzenspider: more process specs.
00:10:42evandrbrain: HA!
00:10:48evannot as bad as trace_var's spec.
00:11:02zenspiderright... well.. I'm running bin/ci bunch_o_files and they're not excluding
00:11:11zenspiderdo we have file level excludes as well?!?
00:11:26evani don't think so.
00:11:48zenspiderhuh... I'm not sure why this is happening then
00:14:01brixenthis specs were that the methods are private, not that they exist
00:14:14brixenwhether that's a critical thing to spec remains to be seen
00:14:19evanbrixen: well, it's a spec for both
00:14:21rubuildiusBenjamin Andresen: 23f4753ff; 4507 examples, 16867 expectations, 0 failures, 0 errors
00:14:24evancan't be private if it doesn't exist.
00:14:33brixenbut it can't pass if it's not private ;)
00:15:15brixenevan: are we implementing trace_var?
00:15:24evanis it just for globals?
00:15:24zenspiderbrixen: I'd rather us have zero specs on a method than a single private spec
00:15:33zenspidereasier for use to know we've not done a damn thing on it
00:16:04brixenevan: yeah, looks like it
00:16:04brixenzenspider: any specs are fine
00:16:04evanthen sure.
00:16:11evansince globals are all in the GlobalVariables class
00:16:20brixenzenspider: we know when we've done something by the ones that pass
00:16:36evanhm. bugger.
00:16:49evanthis Hash#[]= code was never rehashing
00:16:57evani'll bet thats why we've had bad performance for Hash
00:17:13zenspiderbrixen: yes, but that means that bin/completeness will say that is has coverage, right?
00:17:28brixenzenspider: no one should use that script
00:17:34brixenlaments the day he wrote it
00:17:44brixenzenspider: why would you pay attention to that script?
00:17:45zenspiderthen delete it... because they are
00:17:56zenspiderthe fact that I can pass with def blah; end; private :blah is a false positive
00:18:11zenspiderif I'm not supposed to run it, it shouldn't be there
00:18:12brixenwell, what would you suggest?
00:18:21brixenthe fact it tells you if there is *no* spec is useful
00:18:49evanin the future
00:18:50brixenwell, why don't you run shotgun/compile to compile shotgun?
00:18:56evanhaving specs that just test a method exists is not useful
00:19:01evanno reason to delete the ones we have though.
00:19:02brixenuse the script for what it's useful for
00:19:17brixenit's not, it's testing that it's a private method
00:19:23evanperhaps we should go in and add a 'fail' spec to the ones that just test for private
00:19:28brixenwhat would we do, wait to test that until it's implemented?
00:19:33evanie, they don't test the behavior of the method
00:19:41brixenno, we just need more specs
00:19:45brixenbut we can't have them all at once
00:19:52evanzenspider is saying that people might not realize that we need them
00:20:03zenspiderbrixen: 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:04evanbecause they'd notice that we SOME coverage on those
00:20:07brixenwell, you can't know everything by the summary dots
00:20:07drbrainwhat's up with the regex once flag?
00:20:09evanwhen what we have is not really specing the behavior
00:20:28evanthe fact that it's private isn't really it's behavior.
00:20:42evandrbrain: not working?
00:20:48brixenif a spec is describing any significant aspect of behavior, it should be there
00:20:49zenspiderdrbrain: what do you mean?
00:20:49evandrbrain: i debugged it a while back.
00:20:50drbrainnot working
00:21:06evanit doesn't do it once?
00:21:07brixenif whether a method is private is not significant, then we don't need a spec for it
00:21:11evanyou get a nil back?
00:21:32zenspiderbrixen: NOBODY is arguing with that... a spec that only checks the visibility is NOT a behavioral spec
00:21:32evanbrixen: it's not that, it's that it's the only spec
00:21:38drbrainit's in a case, and it's falling through to the else which raises
00:21:43drbrainso, I must be getting nil
00:21:54brixenevan: I know, but we have to start somewhere, right?
00:22:03drbrainlet me poke harder
00:22:17zenspiderwalks away
00:22:24brixenunless we want to start imposing guidelines on the order of specs to write
00:31:06drbrainit's complicated :(
00:31:12drbrainthat first match needs to be there
00:32:17drbrainevan: simpler:
00:32:40drbrainchanging RE to a local causes it to go away, removing o causes it to go away
00:33:44drbrainoh, and removing the first failing match causes it to go away
00:33:54drbrainor, making the first match match makes it go away
00:34:11zenspiderAttempted to access field of non-reference?
00:34:18zenspiderdoes that translate to "run again" ?
00:34:41evanthat translates into "something did something bad"
00:38:08drbrainha! ok
00:38:24drbrainso, /#{X}/o is grabbing the previous regexp
00:38:47evanthats what it does.
00:38:50drbrainif I add p self => str to Regexp#=~, I see {/x/=>"y"} twice
00:39:00evanthe previous one...
00:39:01drbrainno, that's not what it does
00:39:07drbrainit should be /=/
00:39:10evanyou mean the one on the line before it?
00:39:14drbrainyes, it's grabbing the previous one
00:39:15evanor the last time it was run
00:39:22evanit's not a yes/no question
00:39:25drbrainthe previous line
00:39:43drbraininstead of the interpolated one
00:40:00evanit's pulling from the wrong literal then.
00:43:30drbrainwhere should I go looking for this?
00:43:37agardinerstrange... looks like only a single literal slot was allocated for the regex
00:43:46agardinerthis was the same issue i fixed before
00:44:03agardinerdrbrain: its in the compiler
00:45:32drbrainin RegexLiteral#bytecode, I'm seeing @source having the correct value
00:46:03drbrainoh, I need to look at both, yes?
00:46:42agardinerits to do with the allocation of a slot to hold the literal regex once its been instantiated
00:47:09agardinerit looks like both RE literals are being given the same index into the literals tuple
00:48:16zenspiderevan: hrm. it is repeatable. All I'm doing is running bin/ci -c
00:48:42evanwhat is?
00:48:58zenspidermy non-reference bug
00:49:16evanhappens in the same spec everytime?
00:49:53zenspiderhuh... it SEEMS to have done what I want, which is add the exclusions I need for the parser specs
00:50:00zenspiderso it obviously died afterwards
00:50:07zenspiderno output when I run with -c, so I dunno
00:50:15zenspiderlemme try changing the format
00:50:20evan-c runs everything
00:50:22zenspiderhrm. no. there is ZERO output from -c
00:50:24evanas I recall
00:50:34brixengive it a path to the file
00:50:39brixenbin/ci runs everything
00:50:43zenspiderit didn't seem to, given how many passing specs I found
00:50:45evanso maybe it's hitting some specs that are very bad.
00:50:48brixenif you give it -c, it will run everything
00:50:56brixenyeah, most likely
00:51:08evanzenspider: you're running 'bin/ci -c <files>' or 'bin/ci -c'
00:51:08brixenbin/ci -c path/to/spec/to/exclude
00:51:11zenspiderok. so it should be the same as bin/mspec spec, right?
00:51:20zenspiderevan: latter
00:51:35brixenzenspider: you will surely die if you run the latter
00:51:40zenspiderok... well then it is no big deal
00:51:40evanyeah, run it only for a certain subpath
00:51:54evani should take a look at what is blowin' shit up though.
00:52:08zenspiderso no worries. I misunderstood what -c did because I've uncovered so many specs that pass as-is
00:52:19zenspiderI thought it was additive only
00:52:19brixenzenspider: yes, that's the problem
00:52:25brixenmany pass in isolation
00:52:38brixenalthough, far fewer than before have this issue
00:52:43zenspiderno, I checked that they passed in combo too
00:52:53zenspiderthe only one that went wonky evan fixed in parallel
00:52:53brixenbin/mspec spec/ruby will tell you a lot
00:53:01zenspideroh, and I fixed Symbol::all_symbols
00:53:30zenspiderreally we should not allow :"" into the symbol table, but I added a TODO
00:53:36evani wonder if some Symbol spec is trying :""
00:53:41evan:"" is allowed in 1.9
00:53:43evanas I recall.
00:53:47zenspideryeah... something is
00:54:12zenspiderwell... can we decide what we're targeting and stick to it?
00:54:26evan1.8, and i'm just saying.
00:54:48zenspideranyone understand shell/buffer limitations?
00:55:07evanyou passing to many things on the command line with autotest?
00:55:30zenspiderthe way autotest currently works, it blows up on rubinius. we've got a 70ish Kb string being passed to -e
00:55:38evanno way around that.
00:55:43zenspiderwhen I make them plain args instead of -e "blahblah", it runs
00:55:43evansave it to a file
00:55:46evanor load via stdin
00:55:51brixenzenspider: why can't you ran a script instead?
00:56:00evanzenspider: hm
00:56:03zenspideris that a token size limitation, or is that a command line length limit?
00:56:11evani think it's a command line length limit
00:56:15zenspiderif it is token size, then I'm fine
00:56:19evanbut it depends entirely on the shell
00:56:20drbrainagardiner: I changed DynamicOnceRegex from push_literal to add_literal
00:56:26drbrainbut that didn't fix it
00:56:30zenspiderif I happened to remove JUST ENOUGH to slip under, then I'm screwed in a day. :)
00:56:33evani know bash handles this different than zsh
00:57:04agardinerdrbrain: yeah, just looking at this...
00:57:07evanzenspider: echo list | rubinius -e "STDIN.readlines.each { |l| require l }"
00:57:31evanthe 'echo list'
00:57:37evanmay have the same problem
00:57:44brixencat list ?
00:57:54evanI think you have to go to file
00:58:09brixenI wish someone would explain why running a script doesn't work
00:58:10zenspiderevan: yeah. we thought of that... it should have the same problems
00:58:17drbrainagardiner: I get a new slot, but I think the wrong thing is going into it
00:58:40zenspiderbrixen: because I don't want to if I don't have to
00:58:43evanbrixen: i think they just wanted to avoid making temp files
00:58:44agardinerdrbrain: i'm not sure if a dregx ought to go into a literal slot...
00:59:00drbrainagardiner: it's a dregx once
00:59:02zenspiderok. one more bin/ci question...
00:59:11zenspiderI'm running bin/ci lots_of_specs
00:59:15agardinerahh - ok
00:59:17zenspiderand getting failures
00:59:23drbrainso, it only gets compiled once, then stored and reused after that
00:59:24zenspidermy bin/ci by itself runs clean
00:59:33evanzenspider: go look at the code for bin/ci
00:59:42evanbin/ci DOESNT run everything
00:59:44brixenzenspider: most likely ordering issues
00:59:44zenspiderwhere else should I be looking to see what it is doing differently?
00:59:49evanonly runs everything under certain directories
00:59:53brixenspecs are dependent in an order
01:00:02brixenand right now they are run alphabetical
01:00:13drbrainagardiner: also, changing RE to a local variable makes this work
01:00:14zenspiderevan: ah. poopy. yeah. I'm running a lot more right now
01:00:19drbrainif it's a constant, it won't work
01:00:27evanzenspider: since ci is via exclude, not include
01:00:39evanzenspider: you're running ALL the library specs and stuff
01:00:45evanthat we don't normally run currently
01:00:48zenspiderbrixen: dependent in a certain order? does that imply that some specs won't run in isolation?
01:00:55brixenand, we are not going to be able to run the library specs with everything else, because of stuff like rational and date
01:01:00agardinerdrbrain: looking at the sexp, this is showing as a dregx, not a dregx_once
01:01:18brixenzenspider: not necessarily, it more likely means that A, B runs but B, A doesn
01:01:32drbrainagardiner: I'm definitely hitting DynamicOnceRegex in lib/compiler/bytecode.rb
01:01:37zenspiderbrixen: hrm... ok. I'll mull on that
01:01:42drbrainagardiner: it's the second regex that's screwed up
01:01:56evandrbrain: which is the file you're working on?
01:02:03brixenzenspider: spec/ruby/1.8/library runs fine in isolation but blows things up when run together
01:02:18evanbrixen: oh, thats because library introduces code that screws with other shit
01:02:20evanlike mathn
01:02:21evanand friends.
01:02:22brixenzenspider: just add spec/ruby/1.8/library to bin/ci CI_SPEC_FILE or whatever
01:02:32brixenevan: no, I don't think so
01:02:36brixenruns fine by itself
01:02:53agardinerweird... i don't seem to be hitting it on that simple example you pasted
01:03:19brixenevan: just run: bin/ci spec/ruby/1.8/core spec/ruby/1.8.language spec/ruby/1.8/library
01:03:23brixenand you should see stuff
01:03:26drbrainI'm running it like this:
01:03:38drbrainruby once_test.rb && rake && rm -f once_test.rbc && echo '---' && shotgun/rubinius once_test.rb
01:03:45drbrainsomething's up with recompilation
01:04:54brixenevan: actually, library specs were running ok, they now fail for me in isolation
01:05:40drbrainevan: the auto-recompile seems broken too
01:05:40evan# => :started
01:05:53brixenstrange object detected as exception: nil (NilClass)
01:07:13agardinerdrbrain: the two examples you pastied are different... the simpler example does not use dregx_once
01:07:48drbrainagardiner: maybe I pasted wrong
01:07:56drbrainadd the o flag to the second regex
01:08:16drbrainagardiner: wait, what?
01:08:23drbrainno, this has three regex
01:08:30drbrain /y/, /x/, /#{RE}/o
01:08:37agardinersorry, you're right...
01:08:38evandrbrain: a better test is
01:08:47agardineri must have had a copy/paste error
01:08:49evanthat shows the bug nicely
01:08:51evani get "x" for both
01:10:13evanthis code is doing
01:10:16drbrainRE = /y/; def doit() p /x/; p /#{RE}/o.source; end; doit
01:10:16evang.push_literal nil
01:10:17evanthats the bug.
01:10:21evanone sec
01:10:22evaneasy fix.
01:11:09zenspiderbrixen: do you mean that the directory order is maintained but the files found within that directory are alphabetized?
01:11:38boyscout1 commit by Evan Phoenix
01:11:39boyscout * Process /ao#{o}/o properly; dbacd99
01:11:41evandrbrain: there ya go.
01:12:29brixenzenspider: yeah
01:12:39agardinerevan: you beat me to it :-P
01:13:14agardinerdidn't help i was looking at something that wasn't showing the problem! :-O
01:14:05zenspiderbrixen: do you know why we can't run any specs in any combination and have them pass?
01:14:18brixenzenspider: no
01:14:43drbrainevan: now URI is broken
01:14:48drbrainshotgun/rubinius -r uri -e 0
01:14:57brixenideally they'd be independent, but they're running on the same vm
01:15:10zenspiderI'm not gonna worry about it atm, but it is something we should look at
01:15:14evandestabilization specs
01:15:24evandrbrain: works here.
01:15:24brixenyeah, we should have a randomize mode
01:15:36evandrbrain: i did 'rake pristine' first too.
01:15:47drbrainlet me try that
01:16:07drbrainfixed it, thanks
01:16:18drbrainso, something really is up with the compiler check
01:16:33brixendrbrain: did you change that file?
01:16:38zenspiderbrixen: randomize would be awesome. I've been meaning to add it to autotest
01:16:56drbrainbrixen: it got changed by git
01:17:13brixendrbrain: uri I mean
01:17:30brixenwell, then the compiler wouldn't recompile it
01:17:42brixenassuming the change to the compiler fixed something
01:17:47brixenor is that different now?
01:17:49drbrainit should check the version and recompile it
01:18:18brixenyeah, I've been using pristine too much then ;)
01:18:50drbrainit's supposed to be different now
01:19:28drbrainI had the compiler two minutes newer than my once_test.rb file, and it wasn't rebuilding the .rbc
01:20:28evanlets see if i can repro that quickly.
01:20:44agardineri saw the same thing too... i made changes to bytecode.rb, but it didn't recompile my rb_test file
01:21:10evanthat was easy
01:21:15evanlets see why now...
01:21:32agardinerevan: do you use max of compiler times?
01:22:01agardinerer.. compiler file times?
01:23:54evanit's not pulling in the version number...
01:23:59evanthere is a race.
01:24:04evanTHATS why.
01:24:23rubuildiusEvan Phoenix: dbacd996d; 4507 examples, 16867 expectations, 1 failure, 0 errors;
01:24:51evanah crap.
01:24:54evanit's the regex change.
01:24:56agardinerlooks like a compiler spec needs updating
01:25:05evani'll fix this race first.
01:31:48boyscout1 commit by Evan Phoenix
01:31:49boyscout * Fix race in compiler version number, fix regex spec; 9cca76a
01:31:50evanok, recompiling is fixed.
01:32:00evanthe problem was that if everything was already compiled
01:32:05evanit never loaded the compiler
01:32:13evanand thus always had the version number at 0
01:32:25evanthe compiler is now forced to load, even if it's not needed
01:32:39evanso the proper version number is calculated.
01:32:59agardinerah - makes sense
01:35:04evanwhats funny about
01:35:18evanthe case when you mostly like WANTED it to run (you have everything compiled already)
01:35:21evanit wouldn't.
01:40:24agardinerhmmm... is there anyway to put a timeout on a channel.receive?
01:41:53zenspiderjust got my first clean run via autotest
01:41:58zenspider... and I have to run
01:42:13evani want to use!
01:42:21agardinerzenspider: nice!
01:42:54drbraintoo late, he'll commit later
01:44:22rubuildiusEvan Phoenix: 9cca76acb; 4507 examples, 16867 expectations, 0 failures, 0 errors
01:44:55drbrainwoo! down below 4000 lines of failure for RubyGems
01:45:22drbrainI'll retry the DependencyInstaller tests when I get home, that's a huge chunk of it
01:48:59evandrbrain: and slow.
01:49:31evanno ARGF specs.
01:54:10brixenhah, the pirate specs
01:54:29evani think i'm going to do it the dumbest way possible
01:54:31evancommit it
01:54:34evanand let someone else write specs.
02:23:49shoeis "defined?" a keyword or a method?
02:25:59shoeI guess it's a keyword.
02:26:41agardineryeah, i believe so - it converts to :defined or something in the sexp
02:33:15shoeSomehow, I never realized that until today - I just figured it was a method on Kernel or something.
02:57:56Defilershoe: Sadly no. defined?(exit) doesn't exit the process. Heh
02:58:28DefilerCan someone explain to me how ARGF is meant to work in MRI?
02:58:35DefilerI tried to understand it, and it isn't clicking
02:58:40DefilerIt seems to just do.. things..
02:58:49drbrainit's the concatenation of the input files
02:59:00drbrain... I'll expand
02:59:13drbrainit's the concatenation of the contents of the input file names
02:59:37DefilerCan you give me a sample command-line that it would be used with?
02:59:46Defilerruby your_program.rb some_file.dat ?
02:59:56drbrainecho x > x; echo y > y; ruby -e 'p' x y # => "x\ny\n"
02:59:59drbrainI think
03:00:29DefilerOK, that seems sane. The behavior when no file was passed seems bizarre, though
03:00:34DefilerIt seems like sometimes it just blocks forever?
03:01:06drbrainit's reading from stdin
03:01:19drbraintype some stuff and hit ^D
03:02:26drbrainprobably, ARGF = $stdin if ARGV.empty?
03:02:27Defilerclever girl *dies*
05:14:35boyscout1 commit by Adam Gardiner
05:14:36boyscout * Fix bug retrieving local names in CompiledMethod#decode; 5dd9c69
05:24:24rubuildiusAdam Gardiner: 5dd9c69f1; 4507 examples, 16867 expectations, 0 failures, 0 errors
05:49:26tomtt /join mephisto
06:42:59craftermhi rue
06:59:48rueevan: *pong
07:01:28brixenrue: talking with evan today, I'm adding general tag files that shadow the spec files
07:01:53brixenrue: so, e.g. excluded(This is why):Kernel#callcc returns ...
07:02:19brixenrue: I'm curious how the guard stuff you're working on needs to be integrated with the runner scripts
07:05:02rueHm, there really is not much needed in the way of integration, I suppose
07:06:20rueAnything not considering failing runs completely normally
07:07:24rueAny 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:58brixenI'm generalizing running or not running specs based on these tags
07:08:20rueI made a few exception subclasses so that if needed the output can be altered, like not printing backtraces or whatever
07:08:31brixenand hopefully a more general/useful way of creating the tags based on the specs passing or failing
07:08:33rueAltered without touching the runner
07:08:53brixenso, instead of a formatter?
07:08:58brixenwhere does the logic go?
07:09:18rueHm, let me pastie the guards.rb file
07:10:51rueIn VERBOSE_GUARDS mode, if a guard determines it needs to fail, it creates a GuardFailure instance with the appropriate exception
07:11:29rueThe GF then instance_evals the block it gets to weed out the #its
07:12:33brixenwhat's the :host_only, :target_only?
07:13:42rueThis goes to the terminology difference but :host_only means that the attribute, e.g. :version, only matched against the host (impl running)
07:14:21rue:target_only means :version matched against the target version (1.8.6) but not the host version (say, ruby 1.8.5)
07:14:24brixenwell, we have to resolve this terminology difference
07:14:33brixenbecause this is hella confusing
07:14:56brixenthere's only one thing running the specs at any given time, right?
07:15:26rueYes.. sort of split between platform (OS, hardware) and host (Ruby impl)
07:15:45brixenwell, yes, different facets of one thing
07:16:06brixenso, whatever you are, you either match that guard or not, right
07:16:09brixenit's binary
07:16:19brixenmatch, no match
07:16:26brixenhost, target is just so confusing
07:16:52brixenbecause the "target" could be a composite set of attributes that matches multiple impl
07:17:40brixennot to mention the "legacy" meaning of these two terms
07:18:08rueI was thinking other nomenclature
07:18:25brixenI just want to keep the (match/no match) thing clear
07:18:44brixenbecause on the set of attributes side, there's no single impl necessarily being referenced
07:18:48rueI 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:00brixenyeah, but do you see what I mean?
07:19:09rueWell, target is always a single implementation
07:19:39brixenI'm saying the way you specify the attributes on a guard
07:19:47brixenit's not necessarily a single impl
07:20:00rueMultiple hosts could match it, yes
07:20:11brixenso, lhs (a set of attributes) == rhs (a single impl that is currently running the specs)
07:20:15brixen^^^ agree?
07:20:40brixenif lhs == rhs, then run the specs else do not
07:20:43rueFor normal mode, yes
07:20:56brixenwell, for either mode, right?
07:21:04brixenthe diff is what you do about it
07:21:08brixenor with it
07:21:15ruePerhaps I misunderstand
07:22:05rueIf 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:43rueIn failure mode, if target_version != 1.8.5, that is an invalid spec
07:23:04brixenit's still binary, unless I'm misunderstanding
07:23:14brixenmatch in normal mode, run normally
07:23:22brixenno match in failure mode, fail
07:24:17rueEssentially, 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:19brixenmy 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:45brixenso, what are the possible failure types?
07:25:58brixenI want to say, "if guard X matches the implmentation, then A happens in Y mode"
07:26:07brixendoesn't that seem more clear?
07:26:50rueAt 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:27rueComplianceFailure is something that either does or does not execute on host (while the target does the opposite)
07:28:02brixencan we use more generally, "implementation matches or does not match the guard" ?
07:28:21brixenimplementation means "the impl running the specs"
07:28:31brixenthe guard is whatever guard?
07:28:57brixenlike PlatformMismatch seems overkill to me
07:29:04rueYeah, I kind of would like to have something that says specifically "currently running implementation" but I am coming up short
07:29:22brixenwell, that's what I'm saying, there can be only one :P
07:29:27brixenso, that's redundant
07:29:44brixenthe implementation is all there is, the guard is the set of attributes that matches or does not match
07:29:59rueThere is sort of a dichtomy: ComplianceFailures indicates broken implementation, the other two broken specs
07:30:13brixenbecause the guard doesn't necessarily designate a single impl
07:30:41brixenwell, let's keep those two really, really, really far apart
07:30:51brixen"broken spec" can mean a zillion things
07:31:03brixenI'd rather that be part of the audit process, not a guard logic
07:31:32brixenthe tags file will provide for: incomplete(This needs to do foo):Class#method blah blah
07:32:00brixenso, we can actually document the audit process, rather than embedding not_compliant_on :ruby as some sort of exception
07:33:49brixenrue: this has to be considered like set membership, the guard is the set, the "current"ly running impl is an element
07:34:10brixenso, in general, you have a binary truth value: x el of S or x not el of S
07:34:26brixenI don't want to confuse S with a single impl any more than a set with an element
07:34:55rueThis 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:19rueSpecifically, you absolutely do not want to *intentionally* write a spec that raises a SpecTargetFailure
07:35:50brixenbut I think trying to encode all that in the guards is a rabbit hole
07:35:55brixenand really unnecessary
07:36:21rueIt is a byproduct. The information is already produced
07:37:24rueBut 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:21brixenyeah, it's a generalization of the existing excludes file
07:38:25brixenbut it has 2 parts
07:38:35brixen<tag>:<spec description string>
07:38:58brixen<tag> : <name> [ '(' <any text> ')' ]
07:39:44brixenrue: I just don't want to encode stuff like: not_compliant_on :ruby as an error
07:40:25rueOh, 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:34brixenlike GuardFailure, that seems so over the top
07:40:58rueWithin any given single run, that entity can either match or not match
07:40:59brixensure, the guard is both those
07:41:15brixenbut there is no target, host
07:41:28brixenimpl matches/does not match guard
07:41:38brixenx el of S, etc
07:41:56rueCorrect, impl will either match or not
07:41:57brixenI think that will be less confusing
07:42:25brixenso, "implementation" or (redundantly) "current implementation" is the ruby impl running the specs
07:42:25rueHowever, whether the guard itself is considered matched depends on its semantics
07:42:29brixendoes that work?
07:42:59brixenwell, the "guard" being a set of attributes and a meaning assigned to those attributes either matches or not?
07:43:16brixenI'm not following the "semantics" part of the guard
07:43:25rueProbably terminology
07:43:40brixenyou're saying a guard has a context?
07:43:43rueLet us call 1.8.6-p111-2007/09/24 collectively the "standard"
07:44:20rueFor a guard like #compliant_on, the standard is a part of its semantics
07:45:11brixenahh, so you're saying, you will encode a single "implementation" into the guards as "the standard"?
07:45:11rueSo 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:24brixenoh lordy
07:45:37rueNow, mind you, this IS an audit tool
07:45:53rueNormally, you always always run without -G
07:46:11brixenjust trying to find a sentence to express this idea
07:46:35brixenit's really modal
07:46:40rueThe semantics are a bitch to get exactly right.
07:47:05brixenso, normal mode: a guard is a set of attributes that matches/does not match the implementation
07:47:16brixenwhat's the other mode called?
07:47:25rueYes. Any guard is only considered in relation to the implementation
07:47:40brixenexception mode?
07:48:09rueI started with just "verbose guards" or "guard failure reporting"
07:48:26brixenverify mode?
07:48:37rueSounds good
07:49:23brixenok, 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:30brixenare those two accurate?
07:49:46rue(Completely OT right now but cool hash algos:
07:50:22brixenrue: did you check out the revactor site? nice stuff
07:50:41rueI would stress the standard, perhaps
07:51:26brixenso, our glossary has these terms: implementation, guard, standard, normal mode, verify mode ?
07:53:14brixencool beans, I think those are much clearer
07:53:30brixenOT, I wish restoring from time machine was better
07:53:45brixenI have to reinstall everything from macports to xcode
07:53:51rue"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:13brixenrue: yeah, I got it now, but I really like "standard" better
07:54:20brixensince we're talking about a spec :)
07:54:37rueIt is probably simpler
07:54:46rue"Reference," too
07:55:05rueToo technical
07:56:33brixenmy 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:33rueOK, so the tags give us a way to set up excludes and explain why they are excluded
07:56:44brixenany tag
07:56:59brixenbut for now, "incomplete" and "excluded" will have special meaning
07:57:02rueWhat do you mean by other helpers?
07:57:14brixennot sure, that's the point :P
07:57:26brixenmethods called in a block that aren't in the special list
07:58:51brixenit just seems to me that this could be way simplified by using a different #describe method on the runner for verify mode
07:58:58brixenand dispense with all the exceptions
07:59:09rueAh. 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:37brixenalso #before, #after
07:59:40rueIt is possible that it might turn out simpler, definitely, definitely
08:00:00rueThose three need no special processing
08:00:02brixenI'd rather guard a whole #before, #after for e.g. windows than have the guard inside
08:01:53brixenrue: it just seems that they could all be fashioned like #quarantine!, normal mode: do one thing, verify mode, do another
08:02:15brixenand in the #describe block, normal mode: handle exception one way, verify mode: handle it another
08:02:28brixenbut maybe using the exception classes is the simplest way to encapsulate that
08:04:41brixenMSpec.verify_mode? is much easier on the eyes than MSpec::VERBOSE_GUARDS ;)
08:05:27rueMm, I like constants
08:05:41brixenwell, it's a predicate
08:05:48brixenor it should be
08:06:11brixenwe'll get there
08:06:17brixenanyway, must sleep, very early class
08:06:30rueOkaydoke, progress :)
08:17:39ruetarcieri: Nice work on the docs for Revactor
08:21:14tarcierirue: thanks
08:23:08rueNo, thank you! ;)
08:25:56tarcierirue: Now if only I can figure out why trunk is 16 thousand messages per second slower than the release...
08:34:50dbussinkevan: i saw some of the 64 bit fixes, but i'm still able to produce segfaults
08:35:01dbussinkevan: or did you notice that too?
08:37:20evanit went away for me.
08:38:23dbussinkrunning in gdb right now
08:40:38evansame place
08:49:08dbussinki see some places where byte_array_address is cast to a uint32 and i have seen the error occur during string ops
08:49:12dbussinkmaybe there is a link?
08:49:35dbussinkdunno about the exact details of bytearray_byte_address though
08:50:01evanit should be cast to a uint8*
08:50:16evanunless the cast as for the inside of the object
08:50:31dbussinkbut shouldn't it be a uint_ptr in that case?
08:51:09evanwhere did you see that cast?
08:51:12evani'd have to see it to tell ya
08:51:26dbussinkshotgun/lib/bytearray.c: ibuf = (uint32_t*)bytearray_byte_address(state, self);
08:51:46dbussinkshotgun/lib/instruction_funcs.gen: insn = (uint32_t*)bytearray_byte_address(state, iseq);
08:52:02dbussinkand the instructions file, but the .gen is generated from that
08:52:24evanthose are because a compiled ISeq contains runtime specific data
08:52:37evanmainly, a uint32 array
08:52:40evanbut good call
08:52:45evanthat needs to be changed
08:52:48evanmaybe thats the problem.
08:52:55dbussinki can test with it
08:53:31evanlook at cpu_compile_method
08:53:50evanit takes an ISeq and processes it to run
08:55:42dbussinkyeah, but there it is an OBJECT pointer
08:56:18dbussinkor am i looking at the wrong thing?
08:58:54evanwhat are you looking at
08:59:19dbussinki was looking at the cpu_compile_method in cpu_instructions.c
08:59:31dbussinkbut i guess i'm getting the point
09:40:50TheVoicerue: what code bits are you working on?
09:45:08rueTheVoice: Right now, finishing up the verification guard system for MSpec
09:50:26rueAfter that, I think we need to hit IO specs pretty hard
09:50:29TheVoiceI'd like to contribute if I could.
09:51:07rueI am sure you can! Did you have something in mind, an area of interest?
09:52:15TheVoicewell 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:32evan(he could use help)
09:52:36evan(yes, he's still awake)
09:52:36drbrainI need IO#fsync, so if somebody could take care of that while I sleep, it would be awesome
09:52:53TheVoiceevan: got any ideas how I could help in that area?
09:53:12evancan we talk tomorrow
09:53:15evani really should be in bed
09:53:41TheVoiceok I'll do what I do best. Tell people what to do. Evan, go to bed.
09:54:35rueTheVoice: Actually, you know where we could really use some management? Patches
09:54:58TheVoiceyou want me to tell people that they arn't worthy?
09:55:11TheVoicesweet, right up my alley
09:55:56TheVoiceso what do the patches need exactly, reviewing?
09:56:02rueUnfortunately right now there just is not enough discipline in checking and committing patches timely
09:56:42rueYeah, reviewing or even just flat-out making someone do it
09:57:40TheVoiceI could also do some organizational stuff, keeping track of which patches are relevant to whats going on in
09:57:43TheVoicethat kind of thing
09:58:44rueWe 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:45rueTheVoice: 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:58rueIt definitely is not the most glamorous thing out there, I admit
10:00:19TheVoiceare there any issues right now with 2 developers working on the same thing? Or something organizational like that?
10:00:59rueIt has not been too bad, definitely every now and then two people start doing the same thing
10:01:20rueUsually they figure it out early enough though fortunately
10:01:59zimbatmyeah, sync happens on this channel
10:02:03rueRight 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:13TheVoiceyeah thats what I've noticed
10:02:33zimbatmwe could also much more benefit of the decentralized features of git
10:02:49TheVoiceit 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:03zimbatminstead of pushing in the main repo, each dev would have it's own, and there would be a merger
10:03:06rueAnd we have floated ideas like trying to keep a roster of who is doing what but that requires maintenance
10:03:36zimbatma proper wiki would be nice too, the current one is a bit painful
10:04:01TheVoicerue: thats not a whole lot of maintenance
10:04:27TheVoiceI think I'll start by asking evan tomorrow what management tasks are pissing him on that I could take over.
10:05:30rueTheVoice: To a programmer, taking the Mt. Dew cans out is too much maintenance :)
10:05:42rue </stereotype>
10:06:05TheVoiceI only drink water, the first sign I don't know how to code.
10:06:23TheVoicethats the name of my blog actually
10:06:30TheVoiceits called I can't code, now what?
10:06:43rueI stick with water mostly myself too. Some milk, and that Simply Apple juice
10:07:39rueTheVoice: Definitely talk to him, though, I am sure there is plenty that needs a steady hand
10:08:45rueTheVoice: 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:44TheVoiceok I'll ping him for info on whats going on with that.
10:10:09TheVoiceanother simple thing I noticed was most of the main committer's blogs arn't registered with
10:10:35rueThere is, I bet, a lot in the processes that can be improved
10:10:35TheVoiceso there could be more code monkeys out there that arn't aware of rubinius
10:11:05rueThe project is pretty organic right now, contrast it with headius' methodical approach ;)
10:11:08TheVoiceI find it hard to believe that any person who uses ruby daily doesn't know about it but who knows.l
10:11:37TheVoicewhen headius is in the channel its like UFC, really fun to watch and you learn a bunch
10:11:47headiusmethodical, eh?
10:11:55TheVoicewell I'm not sure how much you learn from UFC but you get the drift
10:11:58rueHeh, I am sure there are at least folks with outdated info
10:12:39rueheadius: Yep! There, I said it, you are methodical :D
10:13:13TheVoicenot a bad trait for a language implementer
10:15:16rueheadius: Did you put the IO stuff in spec/test form, by the way?
10:15:26headiusI think vv started to do some
10:15:32headiusI haven't yet
10:16:56rueheadius: 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:44rueI hope I can get started with the IO stuff shortly
10:17:57headiuswell, reopen and initialize_copy are pretty complicated, but mostly because they encapsulate a lot of behavior
10:18:05TheVoicethats all going to built ontop of libev right?
10:18:12headiusthe pipe stuff I don't entirely understand yet, but the rest of it isn't unusual
10:18:30headiusand all the other operations are mostly thin wrappers around libc
10:18:49headiusif you aren't using FILE* you'll end up doing what I had to do, implement your own buffered IO logic
10:19:31headiusgods, op element assignment is a lot of operations
11:35:23boyscout1 commit by Vladimir Sizikov
11:35:24boyscout * Adjusted socket specs, so they pass on MacOS (MRI/JRuby).; 907081d
11:49:21rubuildiusVladimir Sizikov: 907081db8; 4507 examples, 16867 expectations, 0 failures, 0 errors
11:58:51rueBedtime, be back in a couple
12:42:34boyscout1 commit by Vladimir Sizikov
12:42:35boyscout * New specs for String#unpack with 'Q/q' patterns.; 0ef7d55
12:54:21rubuildiusVladimir Sizikov: 0ef7d55eb; 4509 examples, 16873 expectations, 0 failures, 0 errors
13:32:36boyscout1 commit by Vladimir Sizikov
13:32:38boyscout * New specs for IO#seek, IO#pos=, StringIO#seek and non-fixnum args.; 3af242c
13:44:22rubuildiusVladimir Sizikov: 3af242cc1; 4509 examples, 16873 expectations, 0 failures, 0 errors
15:31:08pateok, sign me up as excited for mod_rubinius
15:55:18ruepate: Alrighty, you are all signed up
15:55:31rueYou will be deployed February 6th
16:10:06dbussinktoo bad i get the idea i'm the only one having problems with rubinius on 64 bit :(
16:10:14dbussinki'm not the guy for fixing this :P
16:14:06djwhittyou're not the only one, but I don't feel up to trying to fix them either
16:16:27djwhittif anyone needs any amd64 debugging output though, let me know
16:16:52dbussinki gave mine to evan already, he did fix some things but there is still something
16:17:51djwhittDefiler was working on some changes I thought
16:19:09dbussinkyeah, but he was focussing on getting rid of the warnings and clear errors
16:19:18dbussinkhe didn't know al about it too
16:25:24djwhittdbussink: what error are you getting now?
16:25:39dbussinkstill the attempted to access field errors
16:25:41djwhittI'm getting: Attempted to access field 3 in an object with 0 fields.
16:26:05djwhittyou running amd64 as well?
16:26:31dbussinki have a server i can use with it
16:26:39dbussinknot really mine, but i manage the thing
16:27:45djwhitthmm... I could probably give someone a login to my box if they wanted to try to track the issue down
16:27:51ruedbussink: Was it a consistent or intermittent issue?
16:28:13djwhittrue: it's consistent for me
16:28:20dbussinkwell, it's not consistent as in that it occurs at the exact same moment every time
16:28:21rueGoogle slow for anyone else?
16:28:36dbussinkbut it will fail during a ./bin/ci run
16:28:47djwhittI see the same behavior
16:28:58djwhittnot the same spec everytime, but it always fails running ./bin/ci
16:29:51dbussinksomething corrupts during gc, probably because of a overflowing pointer
16:29:56dbussinkbut i can't find it
16:30:45rueCan you try with RUBINIUS_OMSIZE=8388608 ?
16:30:56dbussinkrunning or compiling?
16:32:20dbussinki just ran RUBINIUS_OMSIZE=8388608 ./bin/ci and it shows the same problem
16:32:52rueOMSIZE, as you may guess, is the object memory size
16:33:14dbussinkwhat is the default right now?
16:33:45rueThis would indicate that we are definitely dealing with corruption rather than allocation issues
16:36:46rueMan, I should really sleep longer than three hours one of these nights
16:37:20ArjenSleep is for the weak.
16:37:49dbussinkArjen_: hey, another dutchman
16:38:04rueCareful, he could be an impostor!
16:38:07Arjendbussink, hi. :)
16:38:18dbussinkrue: i know his company :P
16:38:29Arjendbussink, and I know yours. :)
16:38:39dbussinkwhich one? :)
16:39:03dbussinkyeah, them too
16:58:52ruebrixen: 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:01rueI guess implementation is a bit more generic
17:09:06dbussinkhow do i forse an exclude for certain specs?
17:10:21rueYou can create an exclude set with -c against a specific directory, for example
17:10:41dbussinkbut i want to exclude a set of specs that doesn't fail
17:10:54patew00t! it's announced ... I can let the cat out of the bag ...
17:11:05ruedbussink: Why? It would probably be a guard
17:11:21pateEzra and Evan are going to be the opening keynote at the MountainWest RubyConf in March
17:11:28patedoes a happy dance
17:11:35ruepate: Did we not have a talk about animal cruelty?
17:11:35dbussinkrue: i have an idea what the culprit might be that causes the 64 bit faults
17:11:44ruepate: Oh, very nice!
17:12:06dbussinkrue: so i want to exclude a set of specs and run all others, to see whether the bug is triggered
17:12:08rueThe conf is definitely looking good otherwise too
17:12:13paterue, thanks
17:12:44ruepate: And no more holding cats hostage! I am sure evan can be persuaded without kittynapping :)
17:13:30ruedbussink: You could manually add them to the exclude file, I suppose unless a guard is sufficient
17:15:23rueIt is just describe_text + ' ' + spec_text, I think
17:17:16boyscout1 commit by Vladimir Sizikov
17:17:17boyscout * Added a guard for undefined AF_UNIX in Socket specs.; 1834801
17:17:18dbussinkrue: i just removed some spec files from tmp/last_ci.rb, it's ugly but the quickest way
17:17:33dbussinkrue: i really hope i found it...
17:18:01rueWhat are you looking at?
17:18:33dbussinki'm suspecting that the onigurama library is one of the main causes of the 64 bit issues
17:18:58VVSizdbussink: you could use -x switch to exclude some tests from running
17:19:21rueStupid Google being slow
17:19:31dbussinkrue: yeah, looks like it's completely 64 bit unsafe
17:19:50dbussinkweird xmallocs that return an int instead of a pointer
17:21:01dbussinkrue: and we're gonna need to fix some things in libmquark to
17:21:04rueOh, wait.. something on ruby-core I saw
17:23:04dbussinkrue: looks like another issue
17:23:49dbussinkrue: argh
17:24:10rueJust found that too
17:24:16rueI am actually *really* surprised
17:27:57dbussinkand a lot of things use regexp
17:29:21rubuildiusVladimir Sizikov: 183480122; 4509 examples, 16873 expectations, 0 failures, 0 errors
17:37:37dbussinkwhat is the actual difference between xmalloc and malloc?
17:41:14rueI think xmalloc() checks for OOM
17:42:36dbussinkbut it's strange that it returns an int and not a pointer
17:42:43dbussinkbut this only happens for onig
17:42:50boyscout1 commit by Vladimir Sizikov
17:42:51boyscout * Better detection of AF_INET6 support in socket specs.; fe8433c
17:54:20rubuildiusVladimir Sizikov: fe8433cda; 4509 examples, 16873 expectations, 0 failures, 0 errors
17:54:56zimbatmvlad is frenzy today
18:51:14ruebrixen: Also, #verify_mode? or #verification_mode?
19:02:02evani've been trying to figure out if we're going skydiving tomorrow or not
19:02:38evanhm, /i on regex's seems to be broken
19:02:53evanditto with calling it with ::IGNORECASE)
19:03:06rueHehee, morning! That is one of the things you want to know about before it is too late
19:03:38evanyeah, it's about an hour and a half drive to the place
19:03:46evanso hopefully we'll know whats up tomorrow morning
19:03:48evanbefore we drive out.
19:04:54rueReally? "foo" =~ /FOO/i matches here
19:05:22evansomething is up with this regex then...
19:05:32rueCould it be the #=~ itself?
19:05:41evani'm calling match
19:05:45evani guess it could be...
19:05:53evanlet me try something
19:06:24evanr ="[^-+',.\/:0-9@a-z]+", Regexp::IGNORECASE)
19:06:29rueWhat are you calling it on?
19:06:31evanr.match "Wednesday"
19:06:34goodneyevan:send me a text...
19:06:38evanp m[0]
19:06:42evanon 1.8
19:06:48evan" "
19:06:50evanon rubinius
19:07:03evanthe next is actually "Wednesday <more stuff>"
19:07:19evangoodney: sent
19:08:06rueHum, I am actually seeing an error in MRI :P
19:08:48rueDoes \w work instead?
19:09:03rueOr not work, I suppose it might be here
19:09:28evan\w doesn't seem to work either.
19:09:47goodneytext recieved...
19:09:51evanif i make it just
19:09:52goodneythat seemed to take awhile
19:10:06evanMRI gets " ", rbx gets "W"
19:10:41evani'm starting to think it's onig...
19:11:08ruedbussink located what looks like a 64-bit issue with onig earlier
19:11:53evanOH HO
19:11:55evanlook at that.
19:12:03evanMRI trunk uses a different regex.
19:12:20evanand no /i
19:12:29evani wonder if onig behaves differently for this...
19:12:41rueIs Onig not applying /i to the character classes?
19:12:52rueErm, is rather
19:13:12ruetizianobis is going to have a long tail if this keeps up
19:14:22brixenrue: verify_mode? seems nice, it's shorter ;)
19:14:23rueHeh--so trunk differs here, what is this Date code?
19:14:35evanrue: Date._parse
19:14:41evanTime.parse calls it.
19:14:49ruebrixen: OK, what about 'implementation' vs. 'engine'?
19:15:12rueevan: Aha, yep. I was actually just writing a little parser for that
19:15:30evani think i'm going to copy in the trunk versions
19:15:34evansee if they work as is.
19:15:34brixenrue: 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:42evanit looks like they've got a lot of fixes
19:16:09ruebrixen: OK
19:17:34rueevan: 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:47rueOr patching it or whatever
19:18:27evanfor a total rewrite, we have to have a really good reason
19:18:40rueSure, that was probably a bad choice of words
19:18:41evansmall patches are fine, so long as they don't change functionality
19:19:30rueOK, 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:54rueHopefully it will not be an issue, Stdlib just seems a bit neglected though.
19:20:23VVSizbrixen: a few questions for you... we struggling a bit with running/filtering specs for Unix sockets under JRuby
19:20:32brixenVVSiz: ok
19:20:51brixenVVSiz: btw, generalized tagging is coming, so can add a comment for why you have something excluded
19:20:53VVSizI can mark them as non_compliant_on :jruby, but that's not the best option
19:21:24VVSizalso, MRI on Windows also does not support unix sockets
19:21:37VVSizand sooner or later, the specs will be tried under windows... :)
19:22:20VVSizI 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:22brixenVVSiz: so, why do you need the non_compliant... is it just behaving badly, can't impl, etc?
19:22:46VVSizit's completely not supported and might never be supported in JRuby
19:23:02VVSizit also not supported in MRI on Windows (but that's not really critical for me now :) )
19:23:15brixenVVSiz: so, you're saying something that says #not_supported_on ?
19:24:03VVSizI dunno... how do you express that not supported on MRI under Windows, but not if under Cygwin? :)
19:24:17brixenyeah, I see the issue
19:25:07VVSizfor 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:52brixenbut non_compliant_on takes multiple implementations
19:25:57brixenis that not the issue?
19:26:08brixennon_compliant_on :jruby, :mswin
19:26:26VVSizoh, you can do that? :)
19:26:27brixenI'm ok adding #not_supported_on
19:26:33brixenyeah, 'course ;)
19:27:05VVSizheheheeh, you seems to be anticipating everything! ;)
19:27:12VVSizI like #no_supported_on
19:27:28VVSizthe intent is clear, and much better than just non_compliant_on
19:27:37brixenok, makes sense, some things there is just no way to do, so you shouldn't be penalized I guess
19:28:26ruebrixen, VVSiz: Actually #compliant_on requires an implementation name currently although that can be changed
19:28:52rueBut #not_supported_on sounds better to me
19:29:40VVSizthere 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:51brixenVVSiz: yep, agreed
19:31:20brixenrue: #compliant_on wouldn't require an impl name?
19:31:48brixenVVSiz: you want to add the #not_supported_on ?
19:32:25VVSizsure I can. it will be just a different name for not_compliant_on, right?
19:32:46brixensame semantics, yes
19:32:58VVSizOK, will do (right now)
19:33:07ruebrixen: Sure
19:33:19ruebrixen: I meant that #compliant_on cannot use a platform
19:34:01brixenrue: ah, right
19:34:18brixenso the guards except for #platform take an implementation (engine)
19:34:54brixenI toyed with the idea of adding engine to #platform, but seems like it would just be abused
19:35:22evanMRI has a cut off for 2 digit years
19:35:42evan0..39 => means 2000+
19:36:00evan69..139 => 1900+
19:36:15evanoh actually
19:36:23evan40..68 is 1900+ too
19:36:43drbrain2039 makes sense
19:36:56drbrainI've never seen it used, though
19:36:58evani've making that change to our code
19:37:05evanbut then i'm going to fix Time.parse
19:37:12evanit's emitting 2 digit dates
19:37:16evanyear wise
19:37:16ruebrixen: Probably
19:37:57ruebrixen: Aargh with the premature carriage returns today! I would actually like to move :version etc. out of #platform for that matter
19:38:31brixenrue: remove it, or move it to the impl guards?
19:40:03rueMoving it to something like #engine_is is what I was thinking
19:40:16rueAlthough it could certainly go to the guards too
19:40:53ruenot_compliant_on :version => '0.9' or whatever
19:41:22brixenwell, the primary reason for :version was because we were trying to track more than one MRI
19:41:34brixenis there a good reason to track another impl's version?
19:43:20rueWell, I think that *having* :version et al. available is good even though we should not be using them, really
19:43:21brixenrue: 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:49rueWhether it goes into a new guard or old not sure
19:43:57brixenrue: ok, I'd rather add :version to those other guards than make a #engine_is guard
19:44:19ruebrixen: Oh, you have an example/use case for the output?
19:44:34ruebrixen: Roger roger
19:44:47brixensure, 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:50VVSizI just confirmed that not_supported/compliant_on :mswin won't work
19:44:51brixenso, excludes would be...
19:45:04brixenpass: nothing, fail, write out the exclude tag
19:45:12brixencreating excludes that is
19:45:21brixenVVSiz: why's that?
19:45:35ruebrixen: 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:40VVSizI guess that's what rue tried to say earlier
19:46:08brixenyes, mswin isn't an engine
19:46:15brixenit's a rusty old bicycle :P
19:46:30ruebrixen: At which point is the exclude checked for skipping anyway?
19:46:40VVSizon a bright side, mspec can run on windows (doing it right now) :)
19:46:43rueOp, need to head out in a bit.. semi-AFK
19:46:44brixenrue: well, that's a different layer
19:46:52brixenrue: ok, le'me think on this
19:47:02brixenVVSiz: nice :)
19:47:33ruebrixen: By all means put your ideas on the channel, I will catch up
19:47:34evan //inox
19:47:39VVSizand I could have nice MacOS X instead of this crappy Vistax64!!! :)
19:47:46ruen is no multibyte
19:47:53rueo is once, x extended
19:48:12ruebrixen: But yeah, I am not sure if you can use the same "technique" I did
19:48:35evanrue: danke
19:48:42brixenrue: well, generally, the idea is you would associate a tag with whether to execute or not
19:49:10brixenrue: so for *running* excludes, tag == excluded, don't run
19:49:14ruebrixen: Right, so how you implement the messaging, I think, would depend on when you can determine the spec is excluded right?
19:49:40rueOR, if you want to be lazy, just exclude like you do now and just fake the output
19:49:46brixenrue: well, think of it as a pre-action, post-action
19:49:54brixenpre-action could be: don't run if it has this tag
19:50:04brixenpost-action would be: write exclude tag if it fails
19:50:25brixenor think of it as filters and triggers
19:50:42brixenfilters say yes or no to executing the spec, pass/fail triggers some other action
19:51:05rueOK, so the exclude itself causes the filter to reject which can be detected in the post-action?
19:51:20brixenno, just prevents the spec from running
19:51:44brixenbin/ci -i would be an opposite filter, run those tagged with excluded
19:51:48brixenthat sort of thing
19:51:53brixenthe triggers are separate
19:52:31brixenVVSiz / rue: so, I think we'll have to generalize what get's passed to the normal guards (excluding #platform)
19:52:42brixenbecause :mswin should really be it's own thing
19:53:41brixenor composite them? #not_supported_on :ruby, :under => :mswin ?
19:54:00brixenwindows complicates everything under the sun, ugh
19:55:37rueThat quickly gets into AND/OR requirements from users
19:56:34rueWhich is fine, but needs to be decided
19:56:36brixenwe could simply allow the engine? and platform? there: e.g. not_supported_on :jruby, :mswin
19:57:15brixenfor a particular symbol, if it matches engine? or platform? it's not run
19:57:51brixenmakes sense for :msdos too, I suppose
19:58:33brixenor for :palm perhaps
20:05:52rueI have no problem getting it all implemented once we know what we are going to do
20:06:06drbrainshotgun/rubinius -rfileutils -e FileUtils.symlink
20:06:15drbrainbut, ln_s "works" (reponts ArgumentError)
20:06:42rueevan, brixen: I will probably not be back until around 11pm PST
20:06:53brixenrue: ok
20:07:01evanno problem.
20:07:10brixenrue: I'm thinking I'm going to implement this machinery in SpecRunner itself
20:07:14brixenrather than the scripts
20:07:26brixenrue: you should be able to hook into it easily for the verify_mode guards
20:07:42ruebrixen: Out the door now but elaborate in the buffer if you can
20:08:01rueI have no particular attachment to current design so we will figure it out
20:08:10brixenrue: ok
20:09:22boyscout1 commit by Vladimir Sizikov
20:09:23boyscout * Added not_supported_on guard.; 041e5e3
20:11:26VVSizbrixen: 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:12brixenVVSiz: ok, sure
20:13:51evandoes output() take a regex?
20:14:02evani want to match the not directly
20:14:06evani fixed warn
20:14:09evanso it prints the file and line
20:14:11brixenI think headius added that
20:14:13evannow the warn specs fail
20:14:31dgtizedevan: should we replace Globals and Thread locals with the LookupTable?
20:14:37brixenso, lambda { .. }.should output(/this/)
20:14:38evandgtized: already did
20:14:42evandgtized: Globals at least
20:14:44evanabout to commit it.
20:14:53evanThread locals though, yes.
20:14:56dgtizedit's a single line change for Thread locals too
20:15:16evanyeah, go for it.
20:15:46evani might move LookupTable#[] as a primitive only
20:15:52evanwe'll see.
20:17:00dgtizedI haven't had a chance to do a performance regression on it though it certainly would be expected to speed things up
20:19:25rubuildiusVladimir Sizikov: 041e5e3f3; 4509 examples, 16873 expectations, 0 failures, 0 errors
20:20:59boyscout1 commit by Evan Phoenix
20:21:00boyscout * A couple of easy fixes, fix Time to handle 2 digit dates, pull in trunk date; 78ca098
20:24:19dgtizedthat's pretty unfinal
20:24:23boyscout1 commit by Charles Comstock
20:24:24boyscout * switched Thread local variable storage to use a LookupTable instead of a Hash for ...; 02e1e6e
20:26:50VVSizpastie: gimme?
20:27:07pastie by VVSiz.
20:27:27VVSizthe crash I get with the latest rbx running ci
20:28:26VVSizdoing full clean-rebuild now, just to make sure...
20:32:28dgtizedSo does LookupTable automatically store everything as a symbol?
20:32:44evanthats the callers duty.
20:33:07dgtizedk, 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:45dgtizedor at least a module to include into specific instances
20:34:06evana module that does what?
20:34:20rubuildiusCharles Comstock: 02e1e6ed2; 4509 examples, 16873 expectations, 0 failures, 0 errors
20:36:07dgtizeda module that swaps out [], []=, and store so that they automatically change the keys to symbols
20:36:26dgtizedpresumption being your hashing on a string or symbol
20:36:34dgtizedor number I guess
20:37:49evanwho would use that?
20:37:55evanwhat would be the API?
20:38:06evanmaybe add
20:38:32evanthat causes the Table to have SymbolsConvert mixed into the object
20:39:31VVSizevan: nope, after full rake clean, rake pristine, rake, still a SIGABRT when running ci
20:39:40evanwhat platform?
20:39:47VVSizubuntu linux
20:40:04VVSiztrying to narrow down to particular spec
20:40:11evanit's in the GC
20:40:24evanso it's likely not going to be a specific spec.
20:40:56VVSizbin/ci -V -t x spec/ruby/1.8/library/digest/md5/digest_spec.rb
20:40:59VVSizthat's the one
20:41:35VVSizpastie: for evan
20:41:50pastieevan: by VVSiz.
20:42:03evannot the same
20:42:07evanbut still valid
20:42:08evanone sec
20:42:27evandrbrain is free'ing memory twice.
20:48:20boyscout1 commit by Vladimir Sizikov
20:48:21boyscout * Updated not_compliant_on --> not_supported_on, where appropriate.; ecd3ee8
20:48:27evandrbrain: you around?
20:59:19rubuildiusVladimir Sizikov: ecd3ee8a0; 4509 examples, 16873 expectations, 0 failures, 0 errors
20:59:31VVSizhey, it seems that the default ci completely igrones the whole spec/ruby/1.8/library dir!!!
21:00:12dgtizedVVSiz: I'm not getting a SIGABRT on ubuntu
21:00:38VVSizdgtized: how do you run? by the command line above?
21:02:45VVSizand there are a lot of failures when library specs are run in CI
21:04:06Defilerevan: Around?
21:06:54Defilerezmobius: ping, when you have a minute
21:07:46Defilerezmobius: So, I'm using merb to rewrite my paste site..
21:08:19Defilerezmobius: 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:22ezmobiushmm good question. i havent used AR in a long time. let me ask some of the guys that are using it
21:09:38DefilerCool. Thanks.
21:09:49DefilerWhat are you using now instead of AR?
21:10:56ezmobiussequel or datamapper. but i;ve mainly been workign with entrepot which is our ejabberd/mnsesia heirarchal xmpp database thinguy
21:20:30dgtizedVVSiz: 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:45dgtizedVVSiz: when I run the cmd you posted above it fails, but there is no SIGABRT
21:24:26boyscout1 commit by Evan Phoenix
21:24:27boyscout * Fix Enumerable#sort_by, fix memory error in digest; 105bad5
21:24:27evanVVSiz: update and try that ^^^^
21:28:42evanok, lunch.
21:34:18rubuildiusEvan Phoenix: 105bad5f1; 4509 examples, 16873 expectations, 0 failures, 0 errors
21:43:37DefilerAny Makefile hackers around?
21:43:41DefilerI need an extra pair of eyes
21:44:47brixenI can take a look
21:45:06DefilerOK.. so, shotgun/lib/Makefile
21:45:22Defilerline 73 sets the CFLAGS variable based on CPPFLAGS
21:45:52DefilerHowever, line 99 (for example), directly uses CPPFLAGS
21:46:06DefilerI am trying to make it possible to pass in a -arch option from the environment
21:46:11Defiler..and have it obeyed
21:47:27brixenhow are you passing it in? CFLAGS= or something?
21:48:07DefilerAt the moment, I'm just doing export CFLAGS=blah
21:49:00Defilersetting CPPFLAGS appears to generally work
21:49:21Defiler..but it isn't obeyed everywhere, so I get warnings from ld
21:49:33Defilersaying that .libs/blah.o is not of required architecture
21:49:43DefilerPresumably because some things are getting the -arch flag and others are not
21:49:49brixenmakes sense
21:50:20brixenwhat does VERBOSE=1 show?
21:50:21DefilerYeah, and it eventually ends in tears (i.e. a link error)
21:50:31DefilerLet me paste a full build, and you can see what I get
21:53:12brixenDefiler: tilman had a ticket to merge shotgun/Makefile and shotgun/lib/Makefile
21:53:26brixenDefiler: evan said that was ok to do, maybe that would make this easier for you?
21:53:49brixenah, found it #171
21:53:49DefilerIt wouldn't hurt, yeah
21:54:08Defiler..but you can see in this paste that some things are getting: -arch x86_64, but others are not
21:54:18DefilerSo it all ends in tears
21:55:28brixenwell, e.g. libzip, it looks like they all get -arch but I see ld complaining
21:56:11DefilerIf I remove CPPFLAGS and just set CC to be 'gcc -arch x86_64', it all builds fine
21:56:30Defiler..but onig's configure script bitches because it is terrible
21:56:44DefilerSo, rather than fixing that file, I was hoping to find a better way to insert this option
21:57:21drbrainbleh, module_function can't do it's thing on an alias of a private method
21:58:38brixendrbrain: more info?
21:58:52brixendrbrain: e.g. Kernel.sprintf and format
21:59:04drbrainshotgun/rubinius -r fileutils -e 'FileUtils.symlink'
21:59:12brixenformat is an alias after module_function :sprintf
21:59:30brixenwhich marks sprintf private
22:02:57brixendrbrain: ah, in core/kernel the alias is done before the call to module_function
22:03:16brixenbut seems we could just fix module_function
22:03:32drbrainshouldn't module_function make things public?
22:03:43drbrain... in the metaclass?
22:03:56drbrainit looks like everything is still private
22:07:31brixenri says module_function makes the instance methods private
22:08:02drbrainno, in the metaclass
22:08:12brixenDefiler: 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:42brixendrbrain: oh, sure, but alias is referring to the instance method
22:10:57brixenso, is the issue with alias or module_function?
22:11:24drbrainall the methods in the metaclass are private
22:11:33drbrainwhen moved there by module_function
22:11:38drbrainthat seems wrong
22:18:36brixenit's duping the method, which was previously set to private
22:44:20evani'm back
22:45:13evandrbrain: did my change to alias_method give you trouble?
22:50:02brixenevan: 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.
22:50:13brixenit's a one line fix in #module_function
22:50:41evanthere seem to be some edge cases with alias + vis changes