Index

Show enters and exits. Hide enters and exits.

00:00:18boyscoutRemove old, stale minitest - 76d5300 - Evan Phoenix
00:00:19boyscoutDon't expand -I paths. Fixes #434. - d518663 - Evan Phoenix
00:03:00evanbrixen: thoughts on http://github.com/evanphx/rubinius/issues/#issue/431
00:03:02evanezmobius: sup ez.
00:04:02ezmobiussup bro
00:04:19ezmobiushows trix?
00:04:37evangood, good.
00:04:44evanworkin' on some 1.1 stuff.
00:04:49ezmobiusnice
00:06:01brixenevan: x.each { |z| z.class.should == String or NilClass}
00:06:09brixennot good
00:06:15evanhuh?
00:06:21brixenevan: just tag that ticket me and I'll look at it
00:06:26evank
00:06:43evanoh yeah
00:06:46evanwtf is that!?
00:06:49brixenhahah
00:06:51brixendunno
00:07:02evanhe clearly didn't see these tests fail
00:09:55boyscoutCI: rubinius: d518663 successful: 3512 files, 15101 examples, 42941 expectations, 0 failures, 0 errors
00:12:54evangeez, macruby doesn't support fork()
00:13:17BrianRice-workI can see how that would be a problem to implement
00:14:01evani guess CF and libauto don't support forking
00:23:02boyscoutRemove failure obscuring code, change prio to safe value. Fixes #380. - 9346a50 - Evan Phoenix
00:40:54philohi
00:51:34boyscoutCI: Commit 9346a50 failed. http://github.com/evanphx/rubinius/commit/9346a50a188e4814b328ea10cbebc28bef37a3e2
01:02:26evan:/
01:06:40evanbrixen: you around?
01:07:44brixenyah
01:07:50evanoh good
01:07:50evanok
01:07:58evanso this process/setpriority_spec.rb
01:08:06evanit needs to only run if the user is root
01:08:17evanit really can't run properly on any OS unless thats true
01:08:24evanthe spec is a mess basically dealing with that fact
01:08:31brixenah yeah, as_superuser do
01:08:38evanit should just not run
01:08:39evanok
01:08:43evandoes that use sudo?
01:08:49brixennope
01:08:51evanor just ignore the spec unless the specs are running as root
01:08:53evanok good.
01:15:02boyscoutOnly run Process.setpriority spec as root - c8a2f69 - Evan Phoenix
01:15:02boyscoutAdd specs for block arg Array unwrapping behavior - 699f47b - Evan Phoenix
01:15:02boyscoutCheck for and run #to_ary when passed to yield with 2+ args. Fixes #374. - 1968a40 - Evan Phoenix
01:26:39boyscoutCI: rubinius: 1968a40 successful: 3512 files, 15103 examples, 42947 expectations, 0 failures, 0 errors
01:59:49boyscoutAdd option to use single quotes to ruby_exe - 711fad4 - Evan Phoenix
01:59:49boyscoutAdd specs for CLI options -n, -p, and -a - d05a0b7 - Evan Phoenix
01:59:49boyscoutImplement support for -n, -p, and -a. Fixes #353. - 8d88819 - Evan Phoenix
02:28:25boyscoutCI: Commit 8d88819 failed. http://github.com/evanphx/rubinius/commit/8d888196dc62b8412bfb6ef16abd460ac1e38ae2
03:46:39dwaitewaves
04:16:14postmodernhttp://github.com/evanphx/rubinius/issues/issue/439
04:16:16postmodernnew bug
05:27:36dbussinkmorning
05:41:13evanmorning
05:41:16evani'm just headed up to read.
05:41:31dbussinkevan: ah, well, good night then :)
05:41:49dbussinkevan: wasn't able to find that issue from yesterday (or earlier today for you) ;)
05:42:11evanok
05:42:22slavahi evan
05:42:28slavaheading to SF any time soon?
05:43:07evanseptember probably
05:43:29evani'll def be there the 16th to 20th for gogaruco
05:43:55slavahit me up mang
05:44:57evanword.
05:45:09evanyou in SF or down south in the valley?
05:45:42evanwell anyway
05:45:44evanoff to bed
05:45:44evannite.
05:45:46slavanite
05:45:49slavaI'm in the south bay
15:03:45boyscoutUse same function signature as MRI for rb_reg_new - e60b382 - Jeremy Evans
15:03:45boyscoutMake a completely new copy of string when testing rb_str_set_len - 14bc963 - Jeremy Evans
15:15:01boyscoutCI: rubinius: 14bc963 successful: 3515 files, 15106 examples, 42950 expectations, 0 failures, 0 errors
16:37:10dwaitewhat was up with json?
16:42:26brixenthe gem was released, should be fine
16:42:36brixenare you having an issue dwaite?
16:46:03dwaitenah just curious about the /topic
16:46:08dwaitemr. brixen
16:46:36brixenjeremyevans: could you explain 14bc963 ?
16:46:43brixenok mr. waite
16:50:04jeremyevansbrixen: Try reverting it and adding a p @str after that line
16:50:24jeremyevansbrixen: rb_set_str_len changes the stored literal string
16:50:57jeremyevansbrixen: It doesn't have an affect in the current state, but if more tests are added it could definitely cause a problem
16:51:05brixenwhat?
16:51:19brixenthe before runs every time, you get a new string every time
16:51:23jeremyevansbrixen: At first I thought this was a bug, but MRI has the same behavior
16:51:31brixenwhat behavior?
16:51:32jeremyevansbrixen: That's what you think, isn't it :)
16:51:41jeremyevansbrixen: Try reverting it and adding a p @str after that line
16:51:41brixenit's what I see, yes
16:51:52brixenI added a STDERR.puts @str.object_id
16:53:03jeremyevansbrixen: I didn't check if the object_it was the same, I was checking the content of the string, which apparently can get reused
16:53:21brixenjeremyevans: show me actual behavior, not "what might happen if more tests are added"
16:53:35jeremyevansbrixen: Sure, give me a sec
16:55:23dwaiteooh ruby 1.9.2 final. good thing I came back from vacation!
16:57:22jeremyevansbrixen: http://pastie.org/1100285
16:58:34jeremyevansbrixen: I didn't include the MRI output, but it's the same. The stored literal string gets modified.
16:59:21jeremyevansbrixen: The reason it doesn't cause problems is just an accident due to how the tests are written
17:00:20evanif the literal string is changed
17:00:25evanthats a bug in C-API
17:00:28evannot in your test.
17:00:29brixenyeah
17:00:41jeremyevansevan: Even if the behavior matches MRI?
17:00:44evannamely that rb_str_set_len doesn't unshare a COW'd String
17:00:57evanimho, yes.
17:01:03evansounds like MRI might have the same bug.
17:01:15evanwhich i'll check right now.
17:01:29evanand yes, it does.
17:01:36evanrb_str_set_len has the same bug as rbx
17:01:49evannamely that it doesn't unshare a COW'd String before changing it.
17:01:57dwaiteoops
17:02:10evanjeremyevans: thats why you had to do [0..-1]
17:02:12evanand not just .dup
17:02:22evanmost likely.
17:02:36evanso the MRI behavior matches because they both have the bug.
17:02:38brixenand why you'd get a new object id
17:02:52jeremyevansevan: Don't get me wrong, it sounds like a bug and quacks like a bug, but since MRI had the same behavior I thought it was intentional
17:02:56evanthen new object id is there to throw you off.
17:03:01brixenyeah
17:03:05evanjeremyevans: sure, i can see why you'd think that.
17:03:12evanand after all this analysis
17:03:19evanit appears to be a bug in both runtimes.
17:03:33evanthe test therefore can deal with that
17:03:38dwaiteit seems to be a problem in your expectations of correct behavior
17:03:42evanbut should include a comment about why it's compensating.
17:03:56brixenwait
17:04:06brixenthe bug should be filed and the test should not be changed
17:04:15jeremyevansevan: OK. I didn't know the cause, only the symptom :)
17:04:21brixenunless MRI says, rb_str_set_len should have this behavior
17:04:29evanbrixen: ok
17:04:38evanso it should fail on MRI for now?
17:04:39brixenI'm checking 1.9 right now
17:04:57evan1.9 fixes it.
17:04:59evanjust checked.
17:05:00brixenwell, nothing fails yet because there is not a specific spec for this
17:05:08brixenok good
17:05:11evan1.9 has " str_modifiable(str); " at the top
17:05:25brixeneasy then!
17:05:31brixenwe just fix it in rbx
17:06:04evanalso fun (ug) is that 1.9 uses rb_bug() if the requested len is greater than the capacity
17:06:11evanand rb_bug() calls abort(2)
17:06:30evanthaht it checks is good, that it doesn't just throw an exception: bad.
17:06:42evanbrixen: what should the test look like?
17:06:42jeremyevansWell, I'm glad I brought it to attention, though I probably should have asked first
17:06:45evanuse ruby_begu?
17:07:07evanjeremyevans: no prob. you've had on an interesting property of rubyspec
17:07:12brixenevan: yeah
17:07:17evannamely, we can't assume that MRI is always correct.
17:07:26evaner. ruby_bug.
17:07:58dbussinkevan: would you know any other place that could perhaps corrupt that global threads list in hydra/
17:07:58dbussink?
17:08:05evanoh oh actually
17:08:17evan1.9 raises a RuntimeError if you try and use rb_str_set_len on a shared string
17:08:25evanso if you run that test on 1.9
17:08:30evanyou'll probably get an exception.
17:08:40evansorry, that probably complicates things.
17:08:55evandbussink: i'd have to go look
17:08:57evani don't kno off hand.
17:12:55evanI think the reason that rb_str_set_len doesn't unshare is because it would change ->ptr which would break some extensions maybe?
17:13:11evansince people are dumb and they cache ->ptr in a C local sometimes
17:13:30brixenhmm
17:13:42brixenbut they "fixed" it in 1.9...
17:13:55evan"fixed" in so far as they detect the issue and raise an exception, sure.
17:14:21evanthis is a great example of why RSTRING_PTR() sucks ass actually
17:14:26evanwhen you use it on COW'd strings
17:14:36evanyou get the char* used by 2 different objects
17:18:05brixenyeah, unfortunate API for sure
17:20:56jeremyevansevan: Yeah. You pretty much have to call str_modifiable yourself if you want to write to a string you didn't create
17:21:23brixenonly if you are working behind MRI's back really
17:21:33brixenwhich again, is an unfortunate consequence of C
17:22:07brixenif you use the "Ruby" functions, it's handled
17:22:08evanjeremyevans: I assume you mean rb_str_modify()
17:22:20bougymani've kinda been waiting on 1.9.2
17:22:27brixenif you use MRI's utility functions, you're on your own and need to act like MRI
17:22:28evanwhich makes the the string independent if it's not.
17:22:35bougymanbut why the hell do they release it using /1.9.1/ as the dir for the stdlib?
17:22:38bougymanthat's nonsensical.
17:22:44evanbougyman: yeah, i thought so too.
17:22:45brixenbougyman: yeah, that is crazy
17:22:47evanweird.
17:22:57brixenit's probably a bug
17:23:04bougymanit's intended.
17:23:13bougymanbug dressed in a tuxedo, call it a feature!
17:23:18brixenyep
17:28:50evanbrixen: so, given all of this
17:29:01evanhow should the spec for rb_str_set_len be written?
17:29:18evanshould we assume that 1.8's bug would be fixed by raising an exception, 1.9 style?
17:30:58brixenwell, good question
17:31:18brixenI'm trying to find info about this change in 1.9
17:31:22evank
17:32:58dbussinkevan: where does this __lsl_guard__ come from that SYNC uses?
17:33:10evanSYNC defines it.
17:33:12evanit's a local variable.
17:33:25evanSYNC creates makes a C++ object on the stack
17:33:30evancalled __lsl_guard__
17:33:41dbussinkah, doh, i just totally glanced over the LockableScopedLock
17:33:52evan:D
17:33:54evangotta read the whole thing!
17:37:23brixenstuff like this makes me :( http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=28871
17:38:07brixenthey raise an exception above, why not on the overflow
17:38:23evanexactly.
17:39:43brixenheh http://redmine.ruby-lang.org/repositories/diff/ruby-19?rev=28856
17:39:50brixennice commit msg
17:40:21evan@_O
17:40:25evanthat makes no sense.
17:40:26brixenyo dawg, I hear you like preconditions in your preconditions so I added...
17:40:33evanyou have to create a string to use rb_str_set_len
17:40:35evanand when you create a string
17:40:37evanyou set the length.
17:42:32brixenthere is no bug associated with any of these changes afaics on ruby redmine
17:42:38brixenevan: so, what do you want to do here?
17:42:51brixenwe can mimic 1.8.7 behavior, or call it a bug
17:43:00jeremyevansbrixen: http://redmine.ruby-lang.org/issues/show/3652
17:43:20jeremyevansbrixen: Not use why 28856 isn't listed there, though
17:43:42evanbrixen: well, I suppose we should go with the weird 1.8.7 behavior
17:43:56evanand the spec needs to detail the behavior in a comment probably
17:44:07brixenjeremyevans: that doesn't have to do with this behavior in set_len
17:44:21brixenevan: ok, I'll fix up the spec
17:44:31jeremyevansbrixen: True, but it's undoubtedly related
17:44:51brixenjeremyevans: I don't follow
17:48:05dbussinkevan: hmm, i see a Mutex class in lock.hpp, which uses a thread::Mutex right?
17:48:15evanyes
17:48:20evanit augments thread::Mutex
17:48:28evanto contain a pointer to the ManagedThread that locked it
17:48:41evanthe stuff in thread:: is rubinius independent
17:48:51dbussinkevan: ok, and constructors are ran too then right?
17:48:59evan..
17:49:01evanyeah..
17:49:28evanin C++, if you have a superclass and you don't invoke the superclass constructor explicitly
17:49:39evanit's implicitly invoked without any arguments.
17:51:30jeremyevansbrixen: I suppose it's not technically related, but nobu was working on rb_str_resize in the commit before and after, and his advice to use rb_str_set_len in the redmine ticket probably alerted him to the condition the ticket describes (calling it on a 0 length string)
17:51:49dbussinkevan: ok, and how does that work together exactly with the SYNC statements, don't they create a new lock object each time then?
17:52:07evanok
17:52:08evanback up.
17:52:17evanthe SYNC statement is creating what?
17:52:20jeremyevansbrixen: I'm not sure what the change made in 28856 actually does, though
17:52:35evandbussink: a LockableScopedLock is the answer
17:52:42evanit's not creating a new Mutex or a new Lockable
17:52:54evanso go look at definition of LockableScopedLock
17:53:48dbussinkevan: ah ok, yeah, so it uses this
17:54:11dbussinkevan: i wonder if passing in a 0 as the managedthread could cause a potential issue?
17:54:35evana LockableScopedLock locks the Lockable in it's constructor (ie, when SYNC is run) and unlocks the lockable in the destructor (when the function returns)
17:54:41evanpass in where?
17:55:41dbussinkevan: well, that parameter to sync marks the owner right?
17:55:53dbussinkthe owning managed thread
17:56:14evanthat pointer isn't deref'd
17:56:21evanso if you pass in 0, it shows up without issue.
17:58:07dbussinkevan: i'm trying something now, shooting in the dark though :S
17:58:15evanok
17:58:23evani thought you couldn't duplicate the problem
17:59:23dbussinkhow do you mean? i can pretty reliably cause the problem, but i can't find any place where the threads global list is used outside a lock
17:59:25dbussinkor in the gc
17:59:33evanhold up.
17:59:40dbussinkreproducing it is pretty easy
17:59:41evanii thought you told me you couldn't make it happen again
18:00:00dbussinkevan: nope, i can't find anything that could cause it
18:00:12evanhuh?
18:00:20evanyou're nope is confusing
18:00:25evanyou're negating a negative statement
18:00:29dbussinkok, back to square one
18:00:31evanplease indicate the situation in full.
18:00:39dbussinki can reliably cause it to crash
18:00:51dbussinkthe global threads list in shared_state seems to be corrupt
18:01:00dbussinkbecause it contains an invalid reference in the list
18:01:14dbussinkso i was looking for thread unsafe usage of that global threads list
18:01:17dbussinkwhich i can't find
18:02:21evanwhat is your repro
18:02:26evanhow do you make it happen
18:03:43dbussinkevan: https://gist.github.com/13f250d409e41a2d7448
18:03:51dbussinkthat's what i'm running
18:04:10evanok
18:04:22evanyou'll have to keep poking
18:04:24evanbut i'll run that here
18:04:28evanand see what i get.
18:05:02dbussinkevan: doesn't crash each time for me, but about one in two runs
18:05:12evank
18:11:17brixenI'd really like to know if MRI core devs problems with rubyspec are laziness or inability to recognize decent code
18:11:24brixenhttp://github.com/nurse/rubyspec/commit/8617114ba6200d4eee9330ecd0ed20092df6c3bc
18:11:48brixenwhy duplicate all the expectations when all you need to do is conditionalize the before :each
18:12:13brixenand separate these massive specs
18:12:39brixenmay it's "not my problem, I didn't write these"
18:12:44brixenI wish I knew
18:16:31Defilerbrixen: MRI core wouldn't know decent code if it tied them up in a basement and read them bad poetry
18:17:46evanbrixen: maybe they don't know you can conditionalize the before :each
18:17:56evani can't say i'd know off hand what you mean
18:19:56brixenruby_version_is
18:19:58brixen:(
18:22:56evanhm
18:23:33evanah i see.
18:24:30dbussinkevan: the hydra crash?
18:24:37evannot on it yet
18:24:38evanshortly.
18:25:35brixenlulz (a = mock('nil')).should_not_receive(:method_missing).with(:<=>, b).and_return(nil)
18:25:57brixenI guess such code just looks dandy to someone
18:26:01brixenwhoever wrote it
18:26:04brixen:'C
18:26:19brixenfortunately, I have a hefty napkin here for my tears of frustration
18:27:27evan:(
20:01:13dbussinkevan: any luck? or working on something else?
20:01:20evanjust got back from lunch
20:01:32evanyeah, trying to speed up Kernel#` a little
20:02:32evanshark is giving me really weird results
20:08:33dbussinkevan: shark weirdness or perhaps pointer at a bigger issue?
20:08:37dbussinkpointing
20:09:10evanwell, this benchmark is running `echo 1` in a loop
20:09:26evanso shark shows me mainly kernel functions related to starting a process
20:14:56evanmmmm, ok, i figured it out.
20:15:09evanwe always start ever command passed to `` under /bin/sh
20:15:18evanbut MRI runs it directly if it can
20:15:28evanturns out thats a big performance difference.
20:22:31Defilerwhat does 'directly' mean for that? fork something minimal and then exec?
20:22:44evanfork + execl(2)
20:22:57evanwell, execl(str)
20:22:58evanrather than
20:23:06evanexecl("/bin/sh", "sh", "-c", str)
20:23:18Defilergotcha
20:39:38dbussinkevan: so adding that trick too?
20:40:23evanyep.
20:51:17dbussinkevan: adding that file / line thing to a mutex is really nice :)
20:51:31evan:D
20:51:38evanyeah, helps debugging a bunch.
20:54:41dbussinkevan: i see there's a lock around CompiledMethod::default_executor, isn't that a pretty big impact or is it not so bad?
20:54:59evannot bad at all
20:55:06evandefault_executor is only used the first time a method is invoked
20:58:28dbussinkevan: ah ok, and then replaced by something more specialized?
20:59:03evanyeah
20:59:12evanthe execute_specialized in VMMethod
20:59:15evanto be precise.
21:04:43dbussinkevan: ah, yeah, walking through it a bit
21:05:17dbussinkevan: just playing around a bit to see what it does and why there were some recursive lockings occuring, just for my knowledge :)
21:05:39evanok
21:22:48boyscoutSpeed up Kernel#` by using a specialized primitive - 7a928de - Evan Phoenix
21:30:50dbussinkevan: can stuff like system() also benefit from this?
21:31:00evancould yes.
21:31:15evanwe need to add a little more to spawn to tell it to not always redirect stdout
21:31:26evanto have it used in system()
21:35:16dbussinkah ok, but anyway, i'm off to be
21:35:17dbussinkbed
21:35:28evannite.
21:35:28dbussinkevan: were you able to repro that crash with hydra or not?
21:35:35evannot when compiled with DEV=1
21:35:39evantrying without now.
21:35:45dbussinkhmm, i have it compiled with DEV=1 too :S
21:36:30boyscoutCI: rubinius: 7a928de successful: 3515 files, 15106 examples, 42950 expectations, 0 failures, 0 errors
21:38:58evandbussink: got it.
21:39:18dbussinkevan: you can probably fix it in like 5 mins :P
21:39:31evani've got a lot of practice
21:39:32evan:D
21:39:49evani've made a career out of being the guy that fixes shit.
21:40:20evandbussink: i'm going to start a screencast now
21:40:28evanso you can watch me debug it.
21:41:02dbussinkevan: ah, cool :)
21:41:06dbussinkevan: should blog that too
21:41:12dbussinkwould be pretty nice for people to watch
21:44:50dbussinkevan: anyway, really night time!
21:44:57evannite!
21:48:46brixenyay, screencasts
22:01:55dwaitescreencasts would be neat
22:47:35evanyay!
22:47:38evanfixed the bug
22:47:46evanAND got the 30 minute screencast of me fixing it
22:48:20brixenawesome!
22:48:32brixenso, 1.9.2 -v gives 1.9.2p0
22:48:50evanso in other words, the p is always there now.
22:48:55brixenI guess
22:49:32evanwow, this is funny.
22:49:36evani'm watching the screencast
22:54:26evanoh rad
22:54:30evanonly 175M
22:54:54Defilercan't wait to see it haha
22:55:41evani'm uploading it to my public dropbox now.
23:02:45evanthis is really quite enlightening.
23:02:57evani never get to see/hear myself discover
23:03:03evanbecause i'm too busy discovering.
23:12:51evanalmost there
23:12:56evanfor those who are going to watch it
23:13:06evanyou can skip minutes 21 to 26 if you want
23:13:14evanthats just us watching Rubinius compile and listening to music.
23:13:24evanby us i mean me and whoever is watching the video.
23:14:08evanhttp://dl.dropbox.com/u/384131/debugging-thread-list.mov
23:15:14evan:)
23:15:16evanthat was fun!
23:18:02brixensweet!
23:30:45evananyone watching the video?
23:31:37kronos_vanoevan, yes
23:31:55evanok, so it's working
23:31:56evangood.
23:32:44boyscoutIgnore recursive locking if the ManagedThread is null. - d97059f - Evan Phoenix (hydra)
23:32:44boyscoutRemove a VM from the thread list while still GC dependent - 1ca43b1 - Evan Phoenix (hydra)
23:49:23boyscoutMerge branch 'master' into hydra - edb5f4a - Evan Phoenix (hydra)
23:51:59evanHRM
23:52:10evanhttp://www.manning-sandbox.com/thread.jspa?threadID=39154
23:53:48Defilerwhat is Lift?
23:54:09Defileraah
23:54:12Defilerscala web framework
23:54:43DefilerPollak also felt that it was very difficult to effectively conduct a skills or knowledge transfer between teams that were working on any given Rails project; the lack of static typing and other such developer conveniences meant that the team would need to document all their working practices and styles in minute detail to ensure that no understanding was lost by the new team. This was a huge draw on resources and added more time and bloat to the project li
23:54:51Defilerhilarious
23:54:59Defiler"This was a huge draw on resources and added more time and bloat to the project lifecycle than could easily be avoided.
23:55:05Defilerfox news meets technical books