Da
Show enters and exits. Hide enters and exits.
| 00:39:05 | brixen | git st |
| 00:39:12 | brixen | well, close |
| 00:39:16 | brixen | just one tab away |
| 00:43:50 | evan | i'm back. |
| 00:45:28 | brixen | dammit, kernel panic |
| 00:47:34 | evan | brixen: :( :( |
| 00:53:14 | krainboltgreene | Sup, E. |
| 00:53:54 | evan | yo. |
| 00:58:35 | krainboltgreene | Looks like the ruby community is shifting slowly to Sinatra. See: Heroku's team. |
| 01:01:21 | evan | nah. |
| 01:01:36 | evan | heroku has been sinatra focused since the beginning. |
| 01:02:52 | krainboltgreene | And Heroku's gotten a lot more popular. |
| 01:04:44 | evan | sintra and rails solve vastly different things, imho. |
| 01:04:48 | evan | sinatra, rather. |
| 01:04:48 | brixen | I don't know of any huge sites on heroku |
| 01:05:10 | brixen | not that there are not any, but I don't know of them |
| 01:05:20 | brixen | nor do I know of huge sites using sinatra |
| 01:07:05 | boyscout | Spec for C API rb_str_buf_new and rb_str_set_len - 75e07e7 - Jeremy Evans |
| 01:07:05 | boyscout | Fixed specs for rb_str_buf_new, rb_str_set_len. - 8951890 - Brian Ford |
| 01:07:05 | boyscout | Initial version.h for C-API. - 0a165cb - Brian Ford |
| 01:07:05 | boyscout | Fixed some C-API rb_str functions. - 2944654 - Brian Ford |
| 01:09:25 | evan | krainboltgreene: i guess we just have different perspections of it. |
| 01:11:41 | krainboltgreene | evan: I know I do. Ruby was my first language, Sinatra my first web DSL, etc. |
| 01:11:57 | evan | aah |
| 01:12:13 | evan | stick around, it's been a long ride :) |
| 01:13:03 | brixen | ruby as a first language must be pretty fun |
| 01:13:09 | evan | totally. |
| 01:13:49 | brixen | but I wonder if I would have ever tried python, tcl, or other odd languages if I had started with ruby |
| 01:14:13 | evan | a good question |
| 01:14:25 | evan | it's hard for me to say what my first was. |
| 01:14:38 | evan | TI basic, perl, C++ were all about the same time. |
| 01:14:50 | brixen | ah cool |
| 01:15:02 | brixen | I had a few years of pure apple basic |
| 01:15:24 | brixen | well, maybe 2 |
| 01:15:29 | evan | I wrote minesweeper on my TI-82 |
| 01:15:33 | evan | that was fun. |
| 01:15:35 | brixen | but that was just at school, no home computer |
| 01:15:43 | brixen | heh, nice |
| 01:15:59 | evan | thats what got me thinking i could do it more |
| 01:16:16 | evan | I had tried linux, but didn't really program. |
| 01:17:23 | brixen | I was actually using SCO before linux :) |
| 01:17:33 | evan | ha! nice. |
| 01:17:41 | brixen | using linux was so nice by comparison |
| 01:17:44 | brixen | sco sucked |
| 01:17:53 | evan | I downloaded the slackware disk sets |
| 01:17:59 | brixen | heh, yep |
| 01:18:00 | evan | man that took a long time |
| 01:18:05 | brixen | indeed! |
| 01:18:28 | evan | those were the days. Nowadays, people have it easy. |
| 01:18:31 | evan | HEY KIDS GET OFF MY LAWN |
| 01:18:31 | brixen | I think the first slackware install I did was from 13 floppies |
| 01:18:38 | brixen | no kidding |
| 01:18:46 | evan | yeah, same here. |
| 01:18:56 | evan | the X set was like 7 disks by itself. |
| 01:19:03 | brixen | heh yeah |
| 01:19:11 | evan | i remember going through all that |
| 01:19:13 | evan | and getting X booted |
| 01:19:19 | evan | and it was twm with xeyes |
| 01:19:23 | brixen | nice |
| 01:19:24 | evan | and i was like "ok... what now?" |
| 01:19:29 | brixen | hah |
| 01:20:40 | evan | so, the first big hydra hickup has been hit. |
| 01:20:56 | brixen | caches? |
| 01:21:02 | brixen | classes? |
| 01:21:03 | evan | I'm going to have to tear up the execute / cacheing protocols |
| 01:21:09 | brixen | ahh |
| 01:26:56 | evan | thats ok |
| 01:27:01 | evan | the Dispatch concept was a bit long in the tooth. |
| 01:29:58 | krainboltgreene | Back. |
| 01:30:17 | krainboltgreene | Brixen: I actually picked up a little python to help me learn Ruby. |
| 01:38:04 | boyscout | CI: rubinius: 2944654 successful: 3512 files, 15088 examples, 42924 expectations, 0 failures, 0 errors |
| 03:21:41 | brixen | argh |
| 09:36:51 | dbussink | morning |
| 18:33:28 | dbussink | evan: so, read you hit the first road block in hydra? |
| 18:42:44 | brixen | dbussink: if by road block you mean someone left a stick in the road, yes :) |
| 18:42:58 | brixen | I'm guessing evan already has the solution 1/2 implemented |
| 18:43:14 | brixen | but I could be wrong, he might have it 3/4th implemented :) |
| 18:43:31 | dbussink | brixen: isn't evan some action movie hero who just jumps over it? :P |
| 18:43:39 | brixen | heh |
| 18:43:40 | brixen | pretty much |
| 18:43:46 | dbussink | brixen: it was more in comparison so how easy it was going so far : |
| 18:43:47 | dbussink | :) |
| 18:44:02 | dbussink | brixen: btw, did you see this? http://blog.bithug.org/2010/8/benchmarking-rdiscount |
| 18:44:17 | dbussink | i doubt whether that's actually true or that it fails in some way and that isn't detected |
| 18:44:17 | brixen | yep |
| 18:44:29 | brixen | that's exactly what I wondered |
| 18:44:29 | dbussink | brixen: or did you check it out? |
| 18:44:32 | brixen | nope |
| 18:44:44 | brixen | all benchmarks should have veracity built in |
| 18:45:09 | brixen | but since most test code is 100x worse that app code, and most benchmarks are 1000x worse than test code... |
| 18:45:15 | brixen | you can see where this is leading... |
| 18:47:19 | dbussink | brixen: hehe, yeah, this most likely can't be true |
| 18:47:42 | dbussink | too good to be true |
| 19:14:16 | slava | hi brixen |
| 19:15:00 | brixen | hey slava |
| 20:00:59 | evan | brixen / dbussink: this is why I don't release benchmarks |
| 20:03:35 | dbussink | evan: yeah, this isn't really making sense anyway |
| 20:04:47 | dbussink | evan: so what are the hydra issues? creating inline caches simultanuously? |
| 20:05:50 | evan | using them in parallel. |
| 20:06:02 | evan | one cache being used exactly at the same time by 2 different threads. |
| 20:10:25 | dbussink | evan: ah ok, creating it already thread safe then? and when using them goes wrong in updating them etc? |
| 20:10:31 | dbussink | just curious about the details :) |
| 20:11:25 | evan | well |
| 20:11:30 | evan | creating them is pretty easy |
| 20:11:33 | evan | that happens really early |
| 20:11:36 | evan | so thats no issue. |
| 20:11:53 | evan | but I check a cache, and then pass the cache down and read out of it |
| 20:12:05 | evan | but if another thread changes the cache between the check and the read |
| 20:12:09 | evan | then we read the wrong info. |
| 20:12:57 | dbussink | evan: creating is already thread safe then? or you didn't add locks there yet? |
| 20:13:12 | dbussink | if updates info like hit counters etc. right? |
| 20:16:59 | evan | did I say that? |
| 20:17:02 | evan | yeah, creating is thread safe. |
| 20:17:10 | evan | er. |
| 20:17:11 | evan | yeah. |
| 20:17:20 | evan | creating is not at all the issue |
| 20:17:51 | dbussink | but i can imagine adding locks for each method call is a big overhead :) |
| 20:18:02 | dbussink | evan: how do you plan on solving it then? |
| 20:18:07 | evan | well |
| 20:18:09 | evan | there are 2 things |
| 20:18:17 | evan | i have to remove Dispatch from being passed down |
| 20:18:37 | evan | so that an InlineCache hold the info only, and it's read, checked, and passed down. |
| 20:18:56 | evan | i'm going to try and use a spinlock around both the read and update sections |
| 20:19:04 | evan | i'm not sure what the performance will be. |
| 20:20:13 | dbussink | evan: ah, so inlinecache itself isn't updated anymore? |
| 20:20:19 | evan | huh? |
| 20:21:24 | dbussink | evan: hmm, nvm, i think i read you wrong :) |
| 20:22:29 | dbussink | evan: if you look at what the jvm does, you might get oracle on your tail too ;) |
| 20:22:57 | evan | i won't then! |
| 20:23:01 | evan | ok, off to take a shower. |