Index

Show enters and exits. Hide enters and exits.

02:53:46dwaiteI think I figured out the newline thing brixen
05:45:45evanbrixen: poke
06:01:58brixenevan: yo
06:02:20brixenI was off reading zedshaw :)
06:02:35brixeninteresting post on epoll vs poll
06:11:03dwaiteyeah both suck ;)
06:17:37brixendwaite: what would you use?
06:18:22dwaite I'm trying to find this amazing article I read where the guy basically made a comit-style server on hardware he borrowed @ facebook
06:18:27dwaiteand got it up to 1 million sockets
06:19:09brixen1 million actual sockets or virtual sockets?
06:19:25evanbrixen: yes, his article is quite interesting
06:19:34evanhis reasoning makes good sense to me as well.
06:19:35dwaitehe had to bind to multiple addresses and have multiple client simulators because ports are only 16 bit
06:19:55brixenevan: yeah, actually running some tests and testing assumptions is a novel thought :)
06:20:04evanthe thing he didn't mention is whether are not his benchmarking included putting active fds into the epoll data structure
06:20:10evanin poll, thats very fast
06:20:16evanin epoll, thats a syscall, like he says
06:20:20brixenyeah
06:20:25evanso i wonder if we're seeing that syscall overhead as well.
06:20:34brixenhe followed up with his test harness and graphing scripts
06:20:40brixenI didn't look through that though
06:20:45evanah cool.
06:20:53evannow, why did I ping you.
06:20:57brixenheh
06:20:58evanthe brownies just came out of the oven
06:21:01evanso i've got brownie brain.
06:21:04brixenyou wanted to share some brownies!
06:21:10evanhah
06:21:14brixen<3 brownies
06:21:17evan /dcc brixen /oven/brownie
06:21:20brixenheh
06:21:27brixen /accept
06:21:48evanwell, anyway
06:21:50dwaitemmm brownies
06:21:52evani'm headed to MT tomorrow.
06:21:56brixenok
06:22:02evanshould be mostly online though.
06:22:14brixencool
06:22:22brixenI'm hoping to finish pack/unpack this week
06:22:25evangoing to be working on hydra more and do a little bit of sorted out for 1.1
06:22:36evanthere is one thing left to finish for the debugger for 1.1
06:22:36brixenwhen do you want to release 1.1?
06:22:48evanwell, i'd said august.
06:22:57evani'd like to get our ducks in a row
06:23:04brixensure
06:23:06evanbig feature wise
06:23:14evanthen look and see if we want/need to pull in little things
06:23:38brixenI was hoping to have rbx doc a bit ready to go with the other dev tools
06:23:45evanfor instance, i'd love for the json thing to be sorted out for 1.1
06:23:45brixenbut I think pack/unpack is more important
06:23:56brixencan't we push a json gem?
06:24:11evanthat would mean either fixing the json gem (possible) or doing a change to our rubygems to redirect people who want json 1.4.3 to our version
06:24:20evanwe can push one, but it won't be named json
06:24:35evancharlie has some privs to push version of json, he got that to push the java version
06:24:38brixenI thought rubygems was allowing jruby to push one
06:24:51brixenhmm
06:24:52evanhe's looking into if they're ok with us changing the gem in non-java ways
06:24:57brixenok
06:25:02evani'm treading lightly there
06:25:11brixenyeah, of course
06:25:14evansince it's easy to start a shit storm.
06:25:17brixenno doubt
06:25:29brixenbut this guy is pretty unreasonably absent
06:25:36brixenfrom the perspective of the gem's users
06:25:45evanyep.
06:26:04evanif the rubygems admins give the thumbs up, it will be easy
06:26:10evansince we've changed a total of 2 lines.
06:26:10brixencool
06:26:37brixenyeah, would be hard to have a fit about that
06:26:48evani guess rails 3 is looking to go gold soon
06:26:59brixenoh awesome
06:27:08evanso we need to do a round of running the rails 3 tests
06:27:30brixenyeah
06:31:18evanok, i have to go pack (aka eat another brownie)
06:31:26brixenhah
06:31:28brixenok!
06:31:28evanhydra is going well
06:31:33evanthread specs running more stable
06:31:34brixenthat is awesome
06:31:37evanstill some crashes
06:31:40brixenso awesome
06:32:37evangoing to work on making LookupTable and MethodTable threadsafe
06:32:45evani've got an idea for lock-less reads
06:32:52brixenah cool
06:33:03brixenI'm reading wait-free synchronization
06:33:09evanoh good.
06:33:24evanbasically, my thinking is to not reuse LookupTable::Entry's much at all.
06:33:58evanso that a reader can tolerate a writer modifying the bin chains
06:34:20evanprobably slightly higher allocation rate, but that should be a big deal.
06:34:31brixencool
06:35:30brixenok, gotta bougie, this place is closing...
06:35:36evanalso got to work on something describing the memory model
06:35:37evanok cool
06:35:38dwaiteoh sorry
06:35:40evantalk to ya tomorrow.
06:36:14brixenok, enjoy the brownies!
06:36:15dwaiteI'm mostly interested in kqueues and aio, kqueues because they seem to be the nicest programming interface, and aio because its the standard
06:36:23dwaitebut I've been unable to really get performance benchmarks on them
06:36:32dwaiteand don't really have server hardware lying around to try it myself
06:37:03dwaitegiven infinite time and some multiplier of my current energy level
06:37:33dwaiteI wanted to try to divide the networking driver between the kernel and user mode, actually much much more in user mode
06:38:01dwaitesee if I can just hand a user process a memory page with a packet in it, or vice versa
06:39:38dwaiteI figure you could still put a posix api on it, but the direct interface would allow for zerocopy reads/writes
06:40:05dwaiteone of the L4 kernels seemed the best testbed for this :)
07:24:14dbussinkevan: is one of the thread crashes when raising an exception in the thread? because i had that as a crash repro
07:28:46evandbussink: yes, it was.
07:29:06dbussinkevan: ah ok, but that one is fixed or still an issue?
07:29:16evanfixed.
07:29:21evanif you still have issue with it, let me know.
07:29:24evanthere might still be one
07:29:31evanbut it seems to work well enough for the thread specs to normally pass
07:33:14dbussinkevan: my repro doesn't crash anymore :)
07:33:49dbussinkevan: hydra is planned to be merged after the 1.1 release i guess?
07:34:49evanif all goes well, yep!
07:36:16evanawesome
07:36:23evanunited now has mobile phone boarding documents.
07:36:35dbussinkevan: klm has had that for quite a while here i think
07:36:39evanok, off to bed with me
07:36:44evangot to be up in 5 hours.
07:36:47dbussinkcolleague of mine tried it last time to the us
07:37:00evani'll let ya know how it works on united tomorrow.
07:37:01dbussinkbut it had some annoyances, it worked better with my paper version :P
07:37:01evan:)
07:37:04dbussinkevan: nite!
07:37:13evannite!
07:37:26evandbussink: please bang on hydra and let me know
07:37:35evanfeel free to fix any bugs
07:37:35dbussinkevan: ok, cool :)
07:37:36evan:)
07:38:17evank
07:38:18evannite.
12:18:18goyox86morning!
12:29:55JamesKiltonyo yo
14:56:13dwaitegood morning
14:59:35dbussinkmorning
14:59:40dbussinkor afternoon ;)
15:00:02kronos_vanoevening...
15:01:58dwaitegoodtimes
15:02:23dwaitehope everyone is well at this particular moment of the day
17:20:41goyox86http://www.youtube.com/watch?v=PtRhID6qs14
17:21:55brixenhaha
17:22:08brixengoyox86: this is a serious channel, we do serious work here
17:22:17brixen:)
17:22:20goyox86:)
19:43:34chanksI just cloned Rubinius and did ./configure and rake, and I got some test failures which I don't really understand
19:43:43chanksI put them in a gist: http://gist.github.com/508664
19:45:17DefilerWhat operating system are you running?
19:47:52DefilerMy guess is that the specs have mis-detected which flavor of unix you are using
19:47:54chanksUbuntu Lucid
19:49:26Defilerhrm
19:49:27Defilerhttp://manpages.ubuntu.com/manpages/maverick/man2/read.2.html
19:49:38DefilerIt really should be giving back EISDIR
19:49:52DefilerShort answer: Don't worry about it
19:50:11DefilerLonger answer: It's probably a bug in Ubuntu Lucid's version of the kernel, etc, etc.
19:50:49chanksHmm, ok
19:50:57DefilerThat's just a guess though
19:51:07Defilerbut definitely those errors don't signify a problem with your rubinius build
19:51:26Defilerat worst they will necessitate some extra if/then action in the rubyspecs
19:53:08brixenor a giant sledge hammer on ubuntu's head
19:53:22Defilerbrixen: is bin/mspec -tr spec/ruby still the right way?
19:53:30Defilerto check that those specs fail identically on 1.8?
19:53:34brixenyeah
19:53:51Defilerchanks: ok, try that then :)
19:54:51brixenI'll load lucid in a vbox instance sometime today
19:55:00brixenprobably shouldn't do that on cafe wifi
19:58:39Defilerbrixen: so, hey.. spec run on OS X.. if I have the firewall, I get prompted for that damn 'allow connections' thing
19:58:50DefilerIs there a way to work around that, other than disabling the firewall before a build?
19:59:11brixenhmm
19:59:15DefilerIt's fairly irritating because every time the 'vm' binary signature changes it comes back
19:59:36brixenI don't know about a workaround
19:59:49brixenwhich specs are causing it?
19:59:56Defilerone of the socket ones I presume
20:00:04Defilersomething that needs to connect to localhost
20:00:14brixenI could try to make a without_firewall do ... end guard
20:00:16brixen:P
20:00:19Defilerhehe
20:00:28Defilerthat could get skeevy on your, say, coffee shop wifi
20:00:58brixenevery network/socket spec needs to be audited frankly
20:01:36brixenthe w/o_fw guard would try to detect if you have a firewall running and avoid yielding ;)
20:01:48brixenaccepting patches for the "try to dectect" parrt
20:01:59brixenI've got the yielding covered
20:04:36chanksI tried bin/mspec -tr spec/ruby, and it spat out some failures, and now it looks hung
20:04:50chanksAnd now it's sucking down 1.1GB of my memory :-o
20:06:03DefilerNow I finally believe you that you are running Ubuntu. :)
20:06:58chanksWonderful
20:07:46Defilerbrixen: We should list Ubuntu in the 'supported operating systems' at the same level of the hierarchy as 'Linux' and 'Mac OS'
20:08:32brixenchanks: some specs get committed that expose bugs in mri
20:08:52brixenchanks: kill it and run with mspec -tr -V spec/ruby if you can
20:08:57brixenand tell me which file it hangs in
20:09:09brixenDefiler: because Ubuntu is its own system?
20:09:18DefilerYeah
20:09:26chanksCould RVM be messing it up?
20:09:39DefilerShouldn't be; I use rvm myself and I just completed a clean run of the specs
20:10:06chanksI have my default ruby set to REE, and it starts off the spec run with that
20:10:06brixenchanks: run rvm reset in your terminal before running that command
20:10:12brixenok
20:10:59brixenthen perhaps it exposes a bug in ree
20:13:51chanksWell, they ran all the way through that time
20:13:55chanks45 errors
20:14:11DefilerDoes REE regression-test with rubyspec?
20:14:17brixenprobably not
20:14:21Defilerfail
20:17:39brixenI think hongli got pissed when I thinned the rubyspec commit bits
20:18:50Defilerwelp
20:19:47brixenI haven't lost any sleep over it
20:20:09brixenbut I sure enjoy fixing all these terrible specs
20:20:52DefilerMan you should just let the Stockholm Syndrome kick in
20:21:28brixenI should just delete rubyspec.org and keep them in rbx :)
20:21:45DefilerFully
20:22:05DefilerNow that the pan has flashed, it can go back to being efficient
22:53:57tarcierievan: ping?
23:01:30evanallo.
23:04:16brixenevan: so, the CAS intrinsic is not in gcc 4.0.1
23:04:22evanyep.
23:04:27brixenI've been running hydra on ubuntu
23:04:38evangcc 4.1 is when they were added.
23:04:41brixenbut we should probably address that for eg compiling with clang
23:04:52evanI think clang supports those.
23:04:57brixenoh
23:05:11brixendoesn't os x have one too?
23:05:23brixenthat can be used in place of the intrinsic?
23:05:31evanbut either way, yes, we fix it for non-gcc 4.1
23:06:02evanCAS for x86 is easy with inline assembly
23:06:08evanthen it will work on all gcc's
23:06:10evanand clang.
23:06:21brixenis that what we should do?
23:06:21evansince they use the same inline assembly format.
23:06:29evanthats pretty much the only option.
23:06:32brixenok
23:07:54evanI knew about these going in
23:08:00evanbut ignored them on purpose for now.
23:08:08brixensure, no biggie
23:08:20brixenjust curious about how to generalize it
23:08:38brixenI know you can do it with asm, wasn't sure if you had another plan
23:09:00evanwell, depends on the platform/os
23:09:13evangeneralizing it for x86 gets us a long way.
23:09:27evanand it's easy to find the assembly for this for arm, ppc, etc.
23:09:33evanbecause it's a quite common thing.
23:12:19brixencool
23:14:10evani was going to abstract it soon
23:14:14evani'll go ahead and do that next.
23:14:34evanand I'll introduce a generic x86 version.
23:17:04brixensweet
23:20:01evani'm abstracting Mutex and SpinLock a little bit now
23:20:09evanto track the ruby thread that locked them
23:20:15evanand be able to report the file:line that they were locked on
23:20:39evannext is to register them with the thread that locked them to be able to dynamicly report why a deadlock occured.
23:20:48brixenexcellent
23:20:56brixenthat's what I get running the specs, a deadlock
23:21:33evanoh? still?
23:21:35brixenit's not deterministic, but I was pondering that very question
23:21:36evanok
23:21:50evanyeah, pthread can sort of report a deadlock
23:22:36evanit usually does it by just reporting EDEADLK if you lock a mutex that the current thread has already locked.
23:23:00brixenwell, I was hitting an assert
23:23:11evanyeah
23:23:20evanthread::Mutex aborts on deadlock
23:24:12evanwe're not going to use thread::Mutex directly, but rather rubinius::Mutex which will have this extra info.
23:24:34brixenok
23:29:56evanbrixen: see im.
23:35:24goyox86evan: hi man!, is just me?, running ci specs give me a Terminated: signal SIGHUP, and the runner gets hung before exiting
23:35:36evanon the main branch or hydra?
23:36:23goyox86evan: omg good question let me check i'm pretty sure it's in master
23:36:36evanif it's master, it's just you.
23:36:40evani haven't heard of that.
23:36:44goyox86evan: k
23:52:26evanok, off for a jog
23:52:29evangoing to be fun
23:52:32evani'm at 6k feet.
23:54:23brixenwow, I didn't realize you were that high
23:56:34evan:D
23:56:36evani'm here: http://en.wikipedia.org/wiki/Quake_Lake
23:58:16brixenwow, cool
23:58:59evanmore specificly: http://maps.google.com/maps?f=q&source=s_q&hl=en&geocode=&q=quake+lake,+mt&sll =34.085506,-118.331316&sspn=0.011729,0.019226&ie=UTF8&hq=&hnear=Quake+Lake&ll=44 .825294,-111.461642&spn=0.002511,0.004807&t=h&z=18