Show enters and exits. Hide enters and exits.
| 00:28:32 | goyox86 | i've frescloned and i got this http://gist.github.com/509028 while running ci specs, what do you think it could be? :s |
| 00:28:51 | goyox86 | er fresh-cloned |
| 00:36:32 | brixen | you got 0 failures, 0 errors... what could what be? |
| 00:39:13 | goyox86 | brixen: but after sending a SIGINT, before itb was completely hung |
| 00:39:21 | goyox86 | e it |
| 00:40:08 | goyox86 | :s i'm leving office, i'll rebuild there and give you feedback :) |
| 00:41:05 | goyox86 | probably it's me, but i just cloned the repo, that's what makes me curious :), see ya! |
| 00:41:18 | goyox86 | leaves office |
| 01:06:10 | goyox86 | brixen: there is a problem there at work :s everything is fine here at home :) |
| 01:12:05 | brixen | goyox86: hmm, ok |
| 01:12:20 | brixen | goyox86: you can run bin/mspec ci -V to see which file it hangs on |
| 01:12:28 | brixen | then maybe investigate further |
| 01:12:55 | goyox86 | brixen: k, is really weird never happened to me before |
| 01:13:18 | goyox86 | brixen: how is the pack/unpack deal? |
| 01:14:16 | brixen | goyox86: it's going |
| 01:14:21 | brixen | I'm fixing specs |
| 01:17:38 | goyox86 | brixen: nice, talking about other things i saw your tweets about http://rubybenchmark.com/, you were pretty upset |
| 01:17:56 | brixen | well, yes |
| 01:18:17 | brixen | we have plenty of shitty code |
| 01:18:27 | goyox86 | brixen: i noticed that |
| 01:18:39 | brixen | and those benchmarks were totally clueless |
| 01:19:00 | brixen | but the site did not say, here's an easy way to share clueless shit |
| 01:19:19 | goyox86 | brixen: heh |
| 01:19:30 | brixen | it said, "here is a place to discover idioms and ruby best practices" |
| 01:19:48 | goyox86 | brixen: seriuosly? |
| 01:19:48 | brixen | "my ass it is", was my response :) |
| 01:20:09 | goyox86 | brixen: haha! |
| 01:20:26 | brixen | yeah, it did |
| 01:20:37 | brixen | then the author removed the ruby best practice part |
| 01:20:45 | brixen | and now the site just goes to his blog |
| 01:27:21 | goyox86 | gives brixen 5! |
| 01:34:24 | brixen | anyway, benchmarks are a tough subject |
| 01:34:31 | brixen | just ask zed shaw |
| 01:36:12 | goyox86 | brixen: zed zed, he is working pretty hard in mongrel2 |
| 01:36:44 | brixen | yeah, looks pretty interesting |
| 01:39:26 | goyox86 | yep |
| 02:17:14 | dwaite | brixen you would prefer the tagline "better living through microbenchmarks"? |
| 02:28:19 | brixen | dwaite: well, yes, but only if it has financial backing from BigCorp™ |
| 02:28:27 | brixen | so that, you know, we can trust it |
| 05:32:37 | srbaker | hey everyone. |
| 05:40:18 | brixen | hey srbaker |
| 05:49:06 | srbaker | brixen: heya |
| 05:49:23 | srbaker | so Defiler tells me you get debian-specific bug and problem report |
| 05:49:23 | srbaker | ss |
| 05:49:31 | srbaker | from time to time (he indicated it's rather often) |
| 05:49:37 | srbaker | i'm going to be your debian support person now |
| 05:50:30 | brixen | ok |
| 05:50:43 | brixen | I'm not sure we've seen a lot of debian issues |
| 05:50:55 | srbaker | well, either way |
| 05:50:56 | brixen | our main CI platform is debian |
| 05:50:59 | srbaker | goodie |
| 05:51:14 | brixen | we see some ubuntu issues |
| 05:51:16 | srbaker | well, either way. i want to keep on top of things, so i'm going to havng out here |
| 05:51:21 | brixen | sweet |
| 05:51:22 | srbaker | ah, yes. he said they're mostly ubuntu. |
| 05:51:43 | srbaker | but ubuntu issues are often users not really "getting it" |
| 05:51:48 | srbaker | and they translate to debian |
| 05:52:09 | brixen | weird one earlier today with ubuntu lucid http://gist.github.com/508664 |
| 05:52:32 | brixen | seems like glibc isn't behaving the same as we'd expect from earlier versions |
| 05:52:40 | srbaker | okay |
| 05:52:43 | brixen | I haven't installed it yet to check though |
| 05:52:50 | srbaker | i'm about to hit bed, but i can definitely check thqt tho |
| 05:52:56 | brixen | ok, cool |
| 05:53:02 | srbaker | i keep vms running of everything recent from debian and ubuntu |
| 05:53:08 | brixen | nice |
| 05:55:09 | brixen | wow, ubuntu.com is totally different |
| 05:55:14 | brixen | when did they do that? |
| 05:56:42 | brixen | oh hm, I have a lucid install |
| 07:05:27 | dbussink | good morning :) |
| 08:31:05 | dbussink | brixen: do those specs fail in the same way on mri? |
| 13:54:42 | Defiler | brixen: I guess I'm thinking back to the debian gcc fun we had. I guess there haven't been recent equivalents? |
| 13:55:19 | goyox86 | morning! |
| 13:57:41 | Defiler | morning |
| 14:30:00 | carllerche | are there any debian packages maintained for rbx? |
| 15:58:12 | evan | morning boys and girls. |
| 16:02:27 | brixen | morning |
| 16:02:49 | brixen | carllerche: not that I know of |
| 16:03:09 | Defiler | god I hope not |
| 16:03:10 | brixen | dbussink: those specs don't fail at all for me on Lucid, so dunno |
| 16:03:27 | carllerche | evan: so, how would you handle a gem that depends on ffi in mri? |
| 16:03:48 | brixen | Defiler: not sure what was up with that yesterday, I can't repro it |
| 16:03:51 | evan | well, we should put an ffi.rb into lib/ |
| 16:03:55 | evan | as a stub. |
| 16:03:57 | brixen | we already have it |
| 16:04:00 | brixen | that works fine |
| 16:04:12 | brixen | the gem that depends on ffi and tries to install it is the problem |
| 16:04:17 | evan | oh, but when you install it.. right. |
| 16:04:26 | evan | well, we can preinstall a gem called ffi |
| 16:04:27 | evan | a stub gem. |
| 16:04:34 | Defiler | The problem is stuff like this: http://github.com/perplexes/m2r/blob/master/connection.rb |
| 16:04:41 | brixen | IMO, rubygems needs to have better dependency info |
| 16:04:55 | carllerche | that won't work if people depend on a specific version of ffi |
| 16:04:56 | brixen | because, we really shouldn't need to maintain a list of stub gems |
| 16:05:01 | brixen | exactly |
| 16:05:01 | Defiler | we've offered to expose an api for it several times, but nobody wants to decide what |
| 16:05:26 | Defiler | someone write a failing spec for what rubygems is missing and I will have it done by monday |
| 16:06:15 | Defiler | Personally I think it is the library author's job to understand the dependencies and treat them gently |
| 16:06:16 | evan | carllerche: then we won't support that. |
| 16:06:16 | carllerche | rubygems needs the concept of providing something |
| 16:06:30 | carllerche | so, that, rubinius can say, "we provide ffi >= 0" |
| 16:06:50 | Defiler | ok; what happens if there's a gem with the same name as that? |
| 16:06:53 | carllerche | and json pure 1.4.0 can say "i provide json ~> 1.0 |
| 16:07:17 | Defiler | so basically an 'interfaces' notion needs to be added |
| 16:07:17 | carllerche | Defiler: what do you mean? |
| 16:07:25 | Defiler | that is unrelated to gems except by declaration |
| 16:07:38 | carllerche | "interfaces" is just saying "I am equivalent to gem X at these versions" |
| 16:07:52 | Defiler | Yes but there needs to be an 'I' to say that. |
| 16:08:00 | carllerche | in the gemspec of a gem |
| 16:08:04 | Defiler | right |
| 16:08:09 | carllerche | (or, rbx would need to be able to do it some other way) |
| 16:08:25 | Defiler | That's the trick; things that aren't gems need to be able to satisfy it |
| 16:08:29 | evan | we can add some extra code to handle ffi in rubygems |
| 16:08:57 | Defiler | My gut feeling is that it should be based on the presence/absence of constants |
| 16:09:02 | evan | def is_system_gem() |
| 16:09:02 | Defiler | so it would be more like provides :JSON |
| 16:09:18 | carllerche | then you can't specify version constraints |
| 16:09:26 | Defiler | yep |
| 16:09:36 | Defiler | but without that everything needs to be a gem |
| 16:09:41 | carllerche | json_pure 0.0.1 will not provide json > 1.4 |
| 16:09:46 | carllerche | sure |
| 16:09:53 | Defiler | and that is unacceptable. |
| 16:10:19 | Defiler | Unless we, as a community, want to deprecate setup.rb |
| 16:10:34 | Defiler | and say that it is gems or GTFO |
| 16:11:18 | carllerche | well, you need to be able to figure out when you do gem install vagrant |
| 16:11:27 | carllerche | that you don't need to fetch ffi, because rbx already provides it |
| 16:11:35 | carllerche | you won't actually be requiring ffi |
| 16:11:43 | Defiler | sure, but rbx has to provide it as a gem |
| 16:11:47 | Defiler | in order for it to have a version |
| 16:12:09 | Defiler | I'd rather say you have to provide a VERSION or Version constant under the constant you provide |
| 16:12:21 | Defiler | to be an 'interface provider' |
| 16:12:58 | brixen | Defiler: how do you handle the needed 'require "ffi"' to get the constant in the first place? |
| 16:13:12 | carllerche | that's the main problem |
| 16:13:24 | carllerche | gem install vagrant will never require ffi, so the constant is not there |
| 16:13:33 | Defiler | Yeah that is a dealbreaker I guess |
| 16:14:01 | Defiler | let's say I want to use ffi in a setup.rb situation. |
| 16:14:20 | brixen | instead of making a gem, there should simply be a way for rubygems on rbx to provide synthetic "gem" info |
| 16:14:47 | carllerche | versions and dependencies are a package manager's thing |
| 16:14:50 | Defiler | I guess that doesn't solve the json_pure problem but personally I don't care about that case. |
| 16:15:04 | carllerche | if you want dependency management, you need to use something that knows about it |
| 16:15:11 | brixen | samething that would say: ffi, :any_verson, and rubygems would say "I've already got ffi" when a gem installs that depends on it |
| 16:16:10 | Defiler | Should it be legal to have json_pure and json installed at the same time? |
| 16:16:15 | carllerche | no |
| 16:16:19 | evan | brixen: right, thats easy. |
| 16:16:39 | evan | brixen: I can add that in as some custom logic for us no problem. |
| 16:16:58 | carllerche | json_pure and json are basically the same gem but different versions |
| 16:17:03 | brixen | evan: well, I was hoping for it to work with any impl |
| 16:17:15 | evan | brixen: i can push the patch back into rubygems also. |
| 16:17:16 | evan | no problem. |
| 16:17:32 | brixen | so, what would be the issue with this sort of solution? |
| 16:17:48 | evan | not to me |
| 16:17:58 | evan | it's a solution for implementers primarily |
| 16:18:11 | brixen | right |
| 16:18:12 | evan | it doesn't solve the general interface compatibility idea that Defiler and carllerche are discussing |
| 16:18:13 | evan | but thats ok. |
| 16:18:36 | brixen | well, yeah, I'm not interested in the setup.rb case |
| 16:18:43 | brixen | what year is this? :) |
| 16:18:46 | evan | i guess i missed that |
| 16:18:49 | evan | what setup.rb problem? |
| 16:19:05 | brixen | providing functionality outside of gems |
| 16:19:06 | evan | someone trying to run the ffi gem's setup.rb on rubinius and use it outside rubygems? |
| 16:19:21 | brixen | Defiler: what is the issue exactly? |
| 16:19:26 | evan | thats not something we need to solve |
| 16:19:39 | evan | the user is directly involved, so we can simply tell them "you don't need that." |
| 16:20:39 | brixen | well, there are also 2 cases I'm thinking of: ffi is "we provide that", line-cache is "you can't have that" |
| 16:20:56 | brixen | or whatever that gem that ruby-debug uses is named |
| 16:22:12 | evan | well, the code to allow any version of ffi can also disallow any version of line-cache |
| 16:22:22 | brixen | cool |
| 16:22:24 | evan | ["linecache", :no_version] |
| 16:22:44 | brixen | [:linecache", :forbidden] :) |
| 16:22:47 | Defiler | OK, so we should define an API in rubygems |
| 16:22:53 | Defiler | that lets the platform declare such restrictions |
| 16:23:14 | brixen | s/^:/"/ |
| 16:23:16 | evan | why do we need an API for rubygems? |
| 16:23:25 | Defiler | well, we're not the only ones with this issue, right? |
| 16:23:25 | evan | or rather, who is going to use this API? |
| 16:23:33 | Defiler | jruby has the json_pure thing going on |
| 16:23:41 | evan | they've solved that. |
| 16:23:45 | Defiler | ok |
| 16:23:46 | evan | but sure |
| 16:23:50 | evan | other implementations |
| 16:23:59 | Defiler | It just seems like a common complaint about rubygems, and hey, why not fix it |
| 16:24:09 | evan | I'd prefer to just write it in a way thats easy to use for us |
| 16:24:15 | evan | then it will be easy for others |
| 16:24:22 | evan | don't really need to design the API standalone. |
| 16:26:19 | Defiler | sounds good |
| 16:26:42 | Defiler | That's what I meant, really.. do it in rbx, see what worked, see if there is something to put into rubygems to make it easier or whatever |
| 16:26:50 | Defiler | If not, fine |
| 16:27:27 | evan | sure |
| 16:28:18 | Defiler | I never want to need to type 'bundle' again |
| 16:31:27 | carllerche | so, is the current solution to always have an empty ffi gem on rbx? |
| 16:32:33 | evan | something you can do right now? yes. |
| 17:09:29 | brixen | srbaker: what are you doing at columbia? |
| 17:09:42 | srbaker | brixen: debconf |
| 17:09:47 | brixen | ahh |
| 17:10:13 | evan | columbia the country? |
| 17:10:32 | evan | btw, on the ubuntu issue |
| 17:10:43 | brixen | columbia.edu |
| 17:10:45 | evan | elle, the machine we run linux CI on, is my personal debian unstable box. |
| 17:10:56 | evan | that I don't distupgrade often (once every few years maybe) |
| 17:11:04 | evan | since ubuntu is on the "cutting edge" |
| 17:11:23 | evan | those errno related errors are probably because glibc changed the errno for those functions in newer glibc |
| 17:11:39 | brixen | evan: I can not repro those errors on Lucid |
| 17:11:46 | evan | k |
| 17:11:49 | brixen | at least, lucid 32bit |
| 17:12:20 | evan | srbaker: the #1 thing we could use help with on for debian/ubuntu is making debs for rubinius |
| 17:12:33 | brixen | CI is clean as a whistle on lucy lucid and kranky koala |
| 17:12:38 | evan | k |
| 17:12:38 | srbaker | evan: on it |
| 17:12:48 | srbaker | i'll iTP this afternoon |
| 17:12:50 | evan | srbaker: thanks big guy! |
| 17:12:57 | evan | iTP? |
| 17:18:05 | boyscout | Use an internal mutex for Thread.critical, redo Lockable. - 5db4c11 - Evan Phoenix (hydra) |
| 17:20:32 | srbaker | evan: Intent To Package |
| 17:20:37 | evan | k |
| 17:21:55 | brixen | evan: if you consider a name change in the future, Evan Phoenix-Hydra would be an iteresting choice |
| 17:22:07 | evan | ha@! |
| 17:22:11 | brixen | heh |
| 17:22:11 | evan | i'll keep it in mind. |
| 17:25:34 | evan | brixen: A whole file full of fun: http://www.opensource.apple.com/source/xnu/xnu-1228.15.4/osfmk/i386/commpage/atomic.s |
| 17:26:22 | brixen | ahh cool |
| 17:29:29 | srbaker | in fact, i'm ITPing now, before i forget |
| 17:29:42 | srbaker | i could probably have testable packages up by the end of the week |
| 17:29:46 | evan | rad. |
| 17:45:38 | chanks | brixen: hey, I saw that you couldn't reproduce my Ubuntu Lucid errors |
| 17:45:54 | chanks | I'm still getting them. Is there any other information I can give you? |
| 17:46:45 | brixen | do you have any mods to a vanilla system? |
| 17:46:51 | brixen | is it 32 or 64bit? |
| 17:47:05 | brixen | what's your glibc version |
| 17:47:20 | chanks | 32 bit. I hacked on Wine a bit, but otherwise everything is standard |
| 17:47:29 | chanks | I installed fresh just a week ago |
| 17:47:38 | chanks | Hmm, how do I check the glibc version? |
| 17:47:46 | chanks | Sorry, still new-ish to Unix |
| 17:54:58 | brixen | looks like vanilla should be 2.11.1 |
| 17:55:12 | brixen | you can do: /lib/libc-2.11.1.so at the terminal |
| 17:55:26 | carllerche | brixen: apparently the FFI::Struct API is different on rbx and the MRI gem |
| 17:55:40 | brixen | carllerche: yes, there are some differences still |
| 17:55:44 | carllerche | mitchellh has been trying to get vagrant to run on rbx :P |
| 17:55:55 | carllerche | (been bugging him about it since i try to use rbx has my only ruby ;)) |
| 17:55:56 | chanks | GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.2) stable release version 2.11.1, by Roland McGrath et al. |
| 17:55:58 | chanks | Looks like it |
| 17:56:15 | srbaker | is the license MIT? |
| 17:56:19 | brixen | evan: what's the status of the great FFI Reconciliation Project |
| 17:56:22 | brixen | srbaker: yeah |
| 17:56:23 | mitchellh | specifically the virtualbox gem, there is difference in the FFI::Struct API |
| 17:56:41 | brixen | chanks: I'm not sure what would be the issue |
| 17:57:05 | brixen | chanks: you'll have to dig in a bit, or can you give me remote access to your box? |
| 17:57:10 | srbaker | evan: should i list you as upstream author? or "The Rubinius Team" and put a mailing list? |
| 17:57:22 | mitchellh | Does rbx FFI support callbacks now? I was unable to find a straight answer through google |
| 17:57:29 | chanks | Ok, how would I do that? |
| 17:57:29 | mitchellh | I was just cloning the rbx source tree myself to look |
| 17:59:30 | srbaker | brixen: README says BSD |
| 18:01:01 | brixen | srbaker: sorry, looks like BSD yeah |
| 18:01:16 | srbaker | no biggie. i need to know what to put for "Upstream Author" |
| 18:01:25 | brixen | put evan for now |
| 18:01:30 | srbaker | okay |
| 18:01:36 | evan | yeah, thats fine. |
| 18:01:44 | srbaker | evan: what's your email? |
| 18:01:54 | evan | ephoenix@engineyard.com |
| 18:02:01 | evan | is what you should use |
| 18:02:38 | srbaker | done |
| 18:02:51 | srbaker | filed |
| 18:02:59 | srbaker | now i'll work on getting a nice package out the door |
| 18:03:21 | brixen | chanks: could you gist me the failures again? |
| 18:03:43 | brixen | evan: what's the status of reconciling the FFI API? |
| 18:03:49 | evan | I started on it |
| 18:03:55 | evan | we're closer now. |
| 18:04:02 | chanks | http://gist.github.com/510115 |
| 18:04:03 | evan | I need to work on Struct |
| 18:04:08 | evan | which is probably what you're seeing |
| 18:04:21 | evan | ffi-gem's Struct will calculate the offsets |
| 18:04:23 | evan | ours doesn't. |
| 18:04:25 | evan | is the big difference. |
| 18:04:27 | brixen | ok |
| 18:04:29 | mitchellh | ah hah |
| 18:04:31 | brixen | mitchellh: ^^ |
| 18:04:38 | brixen | evan: do we have callback support yet? |
| 18:04:41 | evan | yep. |
| 18:04:43 | evan | thats in. |
| 18:04:45 | brixen | ok |
| 18:04:52 | brixen | we need docs |
| 18:05:24 | mitchellh | evan: in regards to that callback support, any reason this would be happening: https://gist.github.com/8ed27be6a14ce5ac5e02 |
| 18:05:31 | mitchellh | evan: It looks like its not finding the callback type I defined for some reason |
| 18:05:41 | mitchellh | (which works fine with the ffi gem) |
| 18:05:43 | evan | yeha |
| 18:05:45 | evan | i expect that |
| 18:05:55 | evan | the ffi gem looks up types in a different place |
| 18:06:04 | evan | i didn't wire in exposing callback types and looking them up |
| 18:06:37 | mitchellh | mind pointing me in the right direction for making this work for both the ffi gem and rbx ffi? |
| 18:06:49 | evan | rbx ffi needs to be changed |
| 18:06:50 | evan | to support it. |
| 18:06:59 | evan | there is nothing else to do. |
| 18:07:10 | mitchellh | Gotcha. I'll take a look at the rbx FFI code and see whats going on. Maybe I can help out |
| 18:07:21 | evan | sure |
| 18:07:24 | mitchellh | Are the needed changes documented anywhere? |
| 18:07:29 | evan | nope. |
| 18:07:36 | evan | because they didn't document what they changed. |
| 18:08:03 | mitchellh | of course |
| 18:08:04 | mitchellh | ;) |
| 18:08:25 | evan | what is the 0's in the layout? |
| 18:08:57 | mitchellh | Just bandaids to get past the error of not specifying offsets |
| 18:09:12 | mitchellh | I didn't expect them to work, I was just trying to see what happened if I appeased the fbx struct API |
| 18:09:14 | evan | :/ |
| 18:09:22 | evan | ah. |
| 18:09:23 | mitchellh | since the ffi gem has the offsets as optional |
| 18:09:26 | evan | right. |
| 18:09:42 | evan | well take a look |
| 18:09:42 | mitchellh | well, I'll take a look tonight and setup ffi gem on one monitor and rbx on another |
| 18:09:44 | evan | and submit a ptach |
| 18:09:45 | mitchellh | and see if I can help out |
| 18:09:48 | mitchellh | indeed sir |
| 18:09:49 | evan | i'll take a look at this in the next few days |
| 18:09:54 | mitchellh | thanks |
| 18:09:56 | evan | would be nice to have FFI closer in 1.1 |
| 18:10:02 | mitchellh | :) |
| 18:11:22 | brixen | chanks: in your terminal, type irb, then File.read(".") |
| 18:11:27 | brixen | chanks: and gist me that |
| 18:12:04 | chanks | http://gist.github.com/510125 |
| 18:13:29 | brixen | chanks: ok, no idea, I get EISDIR |
| 18:14:02 | brixen | chanks: is this a virtual machine (vbox, vmware, etc) or on hardware? |
| 18:14:54 | chanks | Hardware |
| 18:15:09 | chanks | The only unusual thing I'm using is RVM, I think. |
| 18:15:35 | Defiler | and REE, right? |
| 18:15:36 | brixen | hm, I can't see that being an issue |
| 18:15:46 | Defiler | oh, right, but it has the same problem on everything |
| 18:15:46 | chanks | Yeah, REE |
| 18:16:02 | chanks | I just tried it in Rubinius and got the same thing |
| 18:16:08 | Defiler | What does File.read(".") do on 1.8.7 on that machine? |
| 18:17:51 | brixen | chanks: do you perhaps have a special fs type? |
| 18:17:53 | chanks | I just tried it on the system ruby (ruby 1.8.7 (2010-01-10 patchlevel 249) [i486-linux]) and got Errno::EINVAL again. |
| 18:17:58 | brixen | file system |
| 18:18:23 | chanks | When I installed Ubuntu, I picked the option of the encrypted home directory |
| 18:18:38 | chanks | That's the only thing I can think of |
| 18:18:38 | Defiler | oh what does File.read("/tmp") do? |
| 18:18:41 | chanks | It's Ext4 |
| 18:18:58 | chanks | Errno::EISDIR: Is a directory - /tmp |
| 18:19:03 | Defiler | aha |
| 18:19:03 | brixen | yay |
| 18:19:06 | evan | bingo. |
| 18:19:14 | evan | your home directory encryption thing is wrong. |
| 18:19:28 | evan | you should file a bug with ubuntu about it. |
| 18:20:05 | Defiler | "read(2) EINVAL instead of EISDIR with encrypted home directory" |
| 18:20:08 | Defiler | is my proposal :) |
| 18:20:14 | evan | :D |
| 18:20:38 | brixen | Defiler: you and your liquid tongue :) |
| 18:20:49 | Defiler | sure makes it hard to drink milkshakes |
| 18:20:52 | Defiler | but other than that, it's handy |
| 18:20:53 | brixen | haha |
| 18:21:23 | Defiler | or you could title it "porblem with the Ubunutus" |
| 18:21:50 | chanks | Well, that more accurately reflects my understanding of it |
| 18:22:38 | brixen | heh |
| 18:34:12 | chanks | Ok, there: https://bugs.launchpad.net/ubuntu/+bug/613962 |
| 18:34:16 | chanks | Any other information I should add? |
| 18:36:57 | Defiler | that should be fine, I would think |
| 18:39:04 | chanks | Ok, good |
| 19:09:51 | brianmario | evan: yo |
| 19:10:09 | brianmario | want to add rb_obj_dup, trying to find how that's done with the CPP api |
| 19:10:18 | brianmario | er, want to add it to the capi |
| 19:11:41 | brianmario | guess I could just wrap rb_funcall2(self_handle, rb_intern("dup"), 0, NULL) ? |
| 19:22:49 | brixen | brianmario: should be fine |
| 19:22:56 | brianmario | cool |
| 19:23:04 | brianmario | where is dup implemented anyhow? |
| 19:25:22 | brixen | generic one is in kernel/alpha.rb:220 |
| 19:33:10 | evan | it's easier to dispatch out to the ruby version |
| 19:33:15 | evan | becuase the ruby version also needs to call initialize_copy |
| 19:33:45 | evan | I have an idea to improve the speed of capi too |
| 19:34:02 | evan | add a rb_static_funcall |
| 19:34:16 | evan | which would look up the method once and dispatch to it always |
| 19:34:30 | brixen | ah cool |
| 20:02:50 | dwaite | Defiler, you around? |
| 20:10:53 | Defiler | yeah |
| 20:36:22 | dbussink | evan: i have a faily reliable crash with hydra running ci, dunno if you have that too? |
| 20:36:30 | evan | gist it up |
| 20:36:34 | dbussink | the thread deadlock issue |
| 20:36:37 | dbussink | ok, coming up |
| 20:36:41 | dbussink | got it in gdb :) |
| 20:36:48 | evan | k |
| 20:36:55 | evan | is it running the whole spec suite? |
| 20:37:03 | evan | or can you isolate it to a particular file? |
| 20:38:02 | dbussink | evan: it's not happening running the spec files individually :( |
| 20:38:13 | evan | k |
| 20:38:15 | evan | thats fine. |
| 20:39:05 | dbussink | evan: https://gist.github.com/29a6eeca272ffd3ec73c |
| 20:39:14 | evan | i haven't even tried to run the whole suite yet. |
| 20:39:17 | dbussink | hmm, my gdb seems to hang too :S |
| 20:39:28 | dbussink | ah, wait, it continued |
| 20:39:36 | evan | aah |
| 20:39:41 | evan | thats an easy fix! |
| 20:40:34 | dbussink | evan: what's the easy fix then? |
| 20:40:47 | evan | ObjectMemory's lock is held while GCing |
| 20:40:58 | evan | and it's trying to be held again inside running the finalizers. |
| 20:41:14 | evan | need to manage it's locking differently |
| 20:41:17 | evan | i'll check it out now |
| 20:42:17 | boyscout | Introduce the atomic namespace, implement CAS for x86 by hand. - da12e62 - Evan Phoenix (hydra) |
| 20:42:20 | evan | brixen: hydra should work on older gcc's now (for x86 at least) |
| 20:42:29 | brixen | awesome |
| 20:45:45 | evan | I think now that i've got some code rearranged, i'll go ahead and allow a form of recursive locking |
| 20:45:53 | evan | that will solve your deadlock dbussink |
| 20:46:11 | dbussink | evan: w00t |
| 20:46:23 | dbussink | evan: other than that it was getting pretty far along :) |
| 20:46:29 | evan | :D :D |
| 20:50:13 | dbussink | evan: btw, i was curious about 8d6875d30ee26d9309f7f3902fd18bc6dd4248dc, since i think all the pthread_ stuff was in the util, not directly used, any reason that was changed? |
| 20:50:33 | evan | that was me working on a bug. |
| 20:50:56 | dbussink | evan: wonder if it's something you'd want to change in the future? |
| 20:50:57 | evan | basically, allocating NativeThread seperately and managing it was a thread situation |
| 20:51:40 | dbussink | evan: how do you mean? |
| 20:51:41 | evan | so I isolated the bug by removing having to create a NativeThread |
| 20:52:22 | evan | well |
| 20:53:03 | evan | one sec, talking to my dad. |
| 20:53:53 | dbussink | evan: for if you're back, is NativeThread still needed then? |
| 20:57:51 | evan | dbussink: i haven't decided yet |
| 20:58:00 | evan | the situation is that NativeThread deletes itself when the thread exists |
| 20:58:02 | evan | exists |
| 20:58:03 | evan | gr. |
| 20:58:05 | evan | exits |
| 20:58:25 | evan | which created a condition where another thread could have a pointer to a NativeThread that was just deleted from memory |
| 20:58:43 | evan | NativeThread isn't needed either, it was just a helpful abstraction |
| 20:58:51 | evan | i'd prefer to have fewer objects |
| 20:59:05 | evan | so i'll likely make some platform agnostic functions to start threads |
| 20:59:18 | dbussink | well, maybe a smaller pthread abstraction is better then yeah |
| 20:59:26 | evan | and only have a VM* and it's ruby Thread* to represent a running thread |
| 20:59:33 | evan | thats easier. |
| 20:59:43 | dbussink | because there's also vm/util/thread |
| 20:59:53 | evan | well |
| 21:00:06 | evan | NativeThread used thread::Thread from util/thread |
| 21:00:20 | evan | thread::Thread is what has the delete on exit abstraction |
| 21:00:30 | evan | i was debugging the issue when I did this |
| 21:00:39 | evan | i wasn't sure if it was a dangling NativeThread* |
| 21:00:45 | evan | but i needed to isolate things to find out. |
| 21:02:29 | dbussink | can imagine yeah, but just wondering how it could be cleaned up |
| 21:03:14 | evan | dbussink: ah |
| 21:03:17 | evan | pretty easy |
| 21:03:25 | dbussink | since it's a bit confusing atm :) |
| 21:03:48 | evan | have thread::Thread::start_running(info, func) |
| 21:03:54 | evan | well |
| 21:03:56 | evan | delete NativeThread |
| 21:04:02 | evan | that will make it less confusing |
| 21:07:00 | evan | dbussink: unless you want to, i'll clean it up now. |
| 21:07:35 | dbussink | evan: well, if you're working on it too now, go ahead, i might play a bit with trying to it myself too |
| 21:07:48 | evan | k |
| 21:07:59 | evan | i'm about to push a fix for your deadlock |
| 21:09:46 | dbussink | evan: ok, cool :) |
| 21:11:08 | dbussink | evan: looks like nativethread can be removed pretty easily |
| 21:11:14 | evan | yep |
| 21:11:19 | boyscout | Allow LockableScopeLocks to be used recursively - 212f45d - Evan Phoenix (hydra) |
| 21:14:54 | dbussink | evan: hmm, does it now ever get unlocked if it's recursively locked? |
| 21:15:14 | evan | the top one unlocks it |
| 21:15:24 | evan | because the top ScopeLock object isn't recursive |
| 21:15:26 | evan | since it's the top. |
| 21:15:52 | evan | LockableScopedLock are created with the SYNC() macro |
| 21:15:58 | evan | they're C++ objects that live on the stack |
| 21:15:59 | dbussink | ah ok, these are then popped? |
| 21:16:06 | evan | to lock and unlock in the constructor/destructor |
| 21:18:24 | dbussink | evan: didn't realize it would be a different lock object :) |
| 21:18:42 | dbussink | evan: dunno if stuff like this would be useful in comments or not? |
| 21:23:03 | dbussink | evan: hmm, it now seems to hang at the point where it crashed before |
| 21:23:28 | dbussink | evan: https://gist.github.com/d30c300e577ba398ad18 |
| 21:29:38 | boyscout | Cleanup unused NativeThread class - c05e76c - Dirkjan Bussink (hydra) |
| 21:44:57 | brixen | ECLT is just a terrible way to develop software |
| 21:45:54 | evan | dbussink: oh, thats another good one! |
| 21:46:11 | evan | ok. |
| 21:46:11 | evan | ECLT? |
| 21:47:16 | brixen | edit compile link test |
| 21:47:31 | brixen | especially when one edit to eg lock.hpp requires recompiling everything |
| 21:47:46 | brixen | evan: I did this to get it to build on leopard http://gist.github.com/510433 |
| 21:48:18 | brixen | it builds and promptly segv's in ?? |
| 21:48:33 | evan | no backtrace? |
| 21:48:39 | brixen | nope |
| 21:48:52 | brixen | oh, well yes |
| 21:48:54 | evan | :/ |
| 21:48:57 | brixen | but not in gdb |
| 21:49:19 | brixen | http://gist.github.com/510442 |
| 21:49:45 | evan | hrm. |
| 21:49:46 | evan | weird. |
| 21:49:52 | evan | can you run -v |
| 21:49:53 | evan | ? |
| 21:50:05 | evan | rbx -v |
| 21:50:07 | brixen | what was that command to bt all threads |
| 21:50:10 | evan | i assume that segfault is running all the specs. |
| 21:50:15 | brixen | rbx -v gives that gist |
| 21:50:16 | evan | which is something i'm not doing. |
| 21:50:21 | evan | odd. |
| 21:50:25 | evan | thread apply all bt |
| 21:50:31 | evan | you can do |
| 21:50:36 | evan | thread apply all <anything> |
| 21:51:05 | brixen | ok, better http://gist.github.com/510446 |
| 21:51:44 | evan | :/ |
| 21:51:54 | evan | perhaps try compiling with DEV=1 |
| 21:51:57 | evan | thats the only way i'm doing it now. |
| 21:52:17 | brixen | ok, -Xint -v runs, so that bt from the jit appears valid |
| 21:52:41 | brixen | I'll rebuild DEV=1 |
| 21:53:50 | evan | k |
| 21:54:34 | dbussink | evan: i'm not doing DEV=1 btw |
| 21:54:41 | evan | k |
| 21:54:45 | dbussink | evan: but i'm going to get some sleep, need more info on that hang? |
| 21:54:49 | evan | nope |
| 21:54:51 | evan | i'm no it. |
| 21:54:52 | evan | on it. |
| 21:55:02 | dbussink | ok, cool :) |
| 21:55:14 | dbussink | i'll check tomorrow morning how far it goes then :) |
| 21:56:36 | evan | k |
| 21:56:49 | brixen | evan: do you want me to commit that diff, or are you working on that stuff? |
| 21:59:07 | brixen | gist after compiling with DEV=1 http://gist.github.com/510458 |
| 22:10:09 | brixen | tarcieri: what did you do to twitter |
| 22:10:18 | tarcieri | lol |
| 22:10:29 | brixen | I need to complain about my back hurting |
| 22:10:37 | tarcieri | I want to complain about Twitter being down |
| 22:10:39 | brixen | how the hell am I supposed to do that? :) |
| 22:10:48 | tarcieri | I got a tweet in earlier |
| 22:10:52 | tarcieri | when they were just starting to have problems |
| 22:10:54 | brixen | I saw |
| 22:10:58 | brixen | it's all your fault |
| 22:11:03 | brixen | you started a domino effect |
| 22:11:04 | tarcieri | heh |
| 22:11:46 | brixen | you'd think twitter would take some cues from IRC |
| 22:12:00 | brixen | "where do you go when Twitter breaks? IRC" |
| 22:12:07 | tarcieri | heh |
| 22:12:27 | tarcieri | it's just weird, because most large scale services I use are pretty damn stable, then there's Twitter and Reddit |
| 22:12:37 | tarcieri | and yeah, same solution in the case of Reddit |
| 22:12:41 | tarcieri | go to #redditdowntime |
| 22:12:46 | tarcieri | Twitter needs something like that |
| 22:12:54 | tarcieri | /join #twitterisdown |
| 22:13:08 | tarcieri | heh |
| 22:13:11 | brixen | heh |
| 22:13:52 | brixen | tarcieri: you should make a twitter client that fails over to #twitter when Twitter is down |
| 22:13:58 | tarcieri | lol |
| 22:14:18 | brixen | not sure how you'd do the protected feeds, but oh well |
| 22:14:21 | tarcieri | MONOCLESMILE ಠ◡ರೃ |
| 22:14:27 | brixen | haha |
| 22:15:50 | tarcieri | like I don't even know what to say about Twitter, except it pisses me off when it's down and similar services operating at a similar scale don't seem to have similar problems *shrug* |
| 22:15:58 | tarcieri | all I can do is drama queen bitch bitch bitch |
| 22:16:14 | brixen | do a talk show :) |
| 22:16:21 | tarcieri | oh, and certain values of "similar scale" are an order of magnitude larger |
| 22:16:27 | brixen | glenn beck style |
| 22:16:36 | brixen | or is it glen beckke |
| 22:16:42 | brixen | or glen beckie |
| 22:16:58 | tarcieri | lol @ aniero's response to Twitter downtime: "means i can focus on work more" |
| 22:17:01 | tarcieri | maybe I should do that |
| 22:17:09 | brixen | heh |
| 22:17:19 | tarcieri | this is just drugery though |
| 22:17:43 | tarcieri | tracking down nasty bugs in this horrible legacy mismanaged codebase... so far I've created a failing spec and that's it :/ |
| 22:17:55 | tarcieri | our traffic light is red |
| 22:17:59 | brixen | progress! |
| 22:18:07 | tarcieri | yes, marginal progress |
| 22:18:17 | tarcieri | I made the traffic light turn red |
| 22:18:18 | tarcieri | now what |
| 22:18:19 | tarcieri | :/ |
| 22:18:24 | brixen | beers? |
| 22:18:28 | tarcieri | already on it |
| 22:18:31 | brixen | heh |
| 22:19:02 | brixen | I seriously fucked up my back getting something out of the fridge to make a sandwich |
| 22:19:07 | brixen | I'm :( |
| 22:19:21 | tarcieri | what the hell were you getting out of the fridge that fucked up your back? |
| 22:19:22 | brixen | not sure I can do this sitting thing |
| 22:19:30 | tarcieri | wades through horrible API docs written in broken english |
| 22:19:30 | tarcieri | ugh |
| 22:19:34 | brixen | one of those weird bend/twist things |
| 22:33:29 | tarcieri | lol jeezus |
| 22:33:51 | tarcieri | after two hours of scrutinizing this problem, pairing on it, going up to the whiteboard and trying to diagram it, we traced it down to this bug in this French API we're using |
| 22:35:17 | brixen | you need more fluent programming |
| 22:35:41 | tarcieri | we need this customer to go away |
| 22:35:42 | tarcieri | heh |
| 22:37:05 | tarcieri | I wanted to ask Gary Vaynerchuk at Railsconf "What do you do when you're dealing with a customer who's so bitchy and high maintenance that servicing their unreasonable demands starts to hurt your other customer relationships?" |
| 22:39:16 | brixen | you fire them |
| 22:39:31 | brixen | unless they are bigger than those other customers |
| 22:39:55 | tarcieri | we've tried... repeatedly... but unfortunately the requirement to work with this customer has come down from on hi |
| 22:41:20 | tarcieri | +gh |
| 22:41:23 | brixen | :( |
| 22:41:36 | tarcieri | they're barely even paying us |
| 22:43:09 | tarcieri | one of my friends just IMed me "You just use Twitter to complain about Twitter" |
| 22:43:12 | tarcieri | heh |
| 22:44:28 | brixen | must mean twitter is back |
| 22:44:51 | tarcieri | heh |
| 22:44:59 | tarcieri | yeah Tweetdeck just started popping shit up again |
| 22:45:45 | brixen | like nothing ever happened |
| 22:45:50 | brixen | what was all the fuss? :) |
| 22:46:11 | tarcieri | I guess, whatever |
| 22:49:43 | tarcieri | http://techcrunch.com/2010/08/05/twitter-down/ |
| 22:51:22 | brixen | heh, "go outside" |
| 22:51:31 | brixen | I think IRC is a good failover |
| 22:51:46 | carllerche | fucking rubinius, how does it work? |
| 22:51:54 | brixen | haha |
| 22:52:01 | tarcieri | heh |
| 22:52:02 | brixen | there are knobs, you twist them |
| 22:52:31 | brixen | twitter down time spreads bad moods |
| 22:52:41 | brixen | carllerche: what seems to be the problem, bro? |
| 22:52:42 | tarcieri | I ended up drinking a bit too much |
| 22:52:48 | tarcieri | and git reverted one of my coworkers commits |
| 22:52:52 | tarcieri | then git reverted my revert commit |
| 22:52:53 | brixen | hah |
| 22:53:03 | carllerche | nothing |
| 22:53:09 | carllerche | you're out of date w/ your memes |
| 22:53:17 | tarcieri | lol |
| 22:53:22 | tarcieri | FUCKIN' MIRACLES |
| 22:53:23 | brixen | what do you expect? all I do is rubinius |
| 22:53:28 | tarcieri | lol |
| 22:53:36 | carllerche | rubinius is a fuckin' miracle |
| 22:53:41 | mitchellh | lol |
| 22:53:58 | tarcieri | brixen: does this make any sense to you? http://www.hockeydrunk.com/wp-content/uploads/2010/04/fucking_miracles.png |
| 22:54:17 | brixen | um... no? |
| 22:54:24 | tarcieri | lol |
| 22:54:30 | brixen | heh |
| 22:54:34 | tarcieri | brixen: http://www.youtube.com/watch?v=_-agl0pOQfs |
| 22:55:58 | brixen | heh |
| 22:56:33 | brixen | goes back to pack specs |
| 22:57:34 | tarcieri | MAGIC EVERYWHERE IN THIS BITCH |
| 22:57:36 | tarcieri | SHIT'S CRAZY |
| 22:58:02 | mitchellh | Now that's not a very flattering drawing of carllerche |
| 22:58:09 | mitchellh | hahahah jk ;) |
| 22:58:33 | brixen | wait, that's *not* carllerche?! |
| 22:58:38 | tarcieri | heh |
| 22:58:45 | carllerche | fail |