|
07:21
zakharyas joined
07:41
brrt joined
07:57
zakharyas joined
09:00
donaldh_ joined
10:57
donaldh_ joined
12:55
jnap joined
13:47
colomon joined
13:54
btyler joined
14:22
jnap joined
14:44
FROGGS joined
14:53
colomon joined
17:05
jnap1 joined
18:05
jnap joined
19:48
FROGGS joined
20:14
brrt joined
20:16
jnap joined
20:52
brrt left
21:25
donaldh joined
|
|||
| timotimo | i wonder how brrt is doing? :) | 21:50 | |
| jnthn was wondering that | 21:52 | ||
| I suggested we do some planning together the other day, but didn't hear back... | |||
| Still, I guess a spesh post is in the works | |||
| timotimo | that's the last i heard | 21:54 | |
| also, someone had contacted me via mail who was interested in fixing up the sort thing where we generate a list of integers, sort that and splice the values back together | 21:56 | ||
| and then they kinda disappeared | |||
| the grid thing works | 21:58 | ||
| first attempt already worked | |||
| this makes me happy | |||
| jnthn | \o. | 22:04 | |
| */ | |||
|
22:06
cognominal joined
|
|||
| japhb | Limb reattachment? | 22:10 | |
| timotimo | jnthn: how impossible do you rate a perl debugger frontend based on GTK::Simple? | ||
| jnthn | "fun" :) | 22:11 | |
| I don't see any immediate blockers to writing one. | |||
| timotimo | it could even debug multi-threaded applications | 22:12 | |
| jnthn | yes :) | ||
| timotimo | because you can show multiple things side by side | ||
| jnthn | Well, also because can make the navigation more obvious | ||
| graphical tools have better discoverability-through-use. | 22:13 | ||
| timotimo | aye, that they do | ||
| japhb | jnthn: Is there currently anything functionality wise (and not JVM specific) that r-j can do that r-m cannot anymore? | 22:26 | |
| timotimo | well, moar sometimes stumbles over its own feet when doing multithreaded stuff | ||
| who did that mandelbrot example recently? | 22:27 | ||
| japhb | From the clog search, I see colomon talking about it | 22:29 | |
| timotimo | OK | ||
| it gave wrong results when run under moar and correct under jvm | |||
| also, the results were correct on moar when only single-threaded | |||
| so there's obviously something stability-wise we're missing | 22:30 | ||
| japhb | *sigh* | ||
| jnthn | japhb: Well, I think r-j beat r-m to getting async sockets doing binary I/O too, but that's a small patch nobody got around to writing for Moar. | 22:32 | |
| timotimo | oh | 22:33 | |
| i wonder why we don't have a (proper) web server demo using async I/O yet | |||
| like perhaps something with PSGI? | |||
| jnthn | I wish folks would have some perspective on Moar threading stuff. The amount of time it's had spent on it is miniscule compared to what the JVM has had. Hell, it's miniscule compared to effort that's been expended on Perl 5 threading over the years, and in various ways it's already more capable. | 22:34 | |
| timotimo | oh | ||
| right :) | |||
| i'm just kinda itching to proclaim perl6 the winner of the race to many cores :P | |||
| jnthn | I did tell y'all I expected getting this stuff stable to take O(months), not O(weeks) | 22:35 | |
| timotimo is going to adjust his expectations | 22:36 | ||
| jnthn | We don't have a better-than-my-crappy-one demo of a async I/O web server 'cus nobody wrote it yet ;-) | ||
| timotimo | i hear that excuse way too often :P | ||
| we need more newbies to join our project and do the fun stuff | 22:37 | ||
| jnthn | Well, sometimes my "throw a crappy one out there and hope" strategy works. | ||
| See Gtk::Simple :D | |||
| timotimo++ # picking that one up | |||
| timotimo | i wonder how well we'll be able to do with Cairo | ||
| jnthn | Anyway, I've no more conf talks to do until August now. ;) | ||
| timotimo | 60fps games on GTK with Cairo rendering? :) | ||
| jnthn | So once I get done showing family around this weekend, I should be back to writing code. :) | 22:38 | |
| My task list is inlining, fix the promises explosions lizmat++ found, and work on the holes in async cancellation. | 22:39 | ||
| I *may* do OSR | 22:40 | ||
| timotimo | on-stack-replacement! ooooh :) | ||
| jnthn | My initial light reading on escape analysis has mostly told me I need to read a bunch more. | ||
| timotimo | mhm | ||
| jnthn | It's a little bit trickier than I anticipated. | 22:41 | |
| jnthn needs to brush up on lattices... | 22:42 | ||
| Seems abstract interpretation is gonna be involved too. | 22:43 | ||
| Or maybe I've just yet to find the "here's the easy, effective way" paper :) | |||
| I suspect I'm just going to have to use my brane though. | 22:44 | ||
| timotimo | does abstract interpretation mean we'll have to annotate all our OPs with what effects they have on things? | 22:45 | |
| jnthn | Oh, I already expecting to add escape information to oplist | 22:46 | |
| timotimo | mhm | ||
| jnthn | Whatever approach we take. | ||
| timotimo | well, it does sound reasonable that we'll need it | ||
| japhb | jnthn: FWIW, I *do* have perspective on the threading stuff. My sigh was more one of "Darn, I still have to keep r-j around" than "Why isn't this perfect yet?" | 23:07 | |
| And as for why *I* haven't done an async I/O demo ... well, because I've been putting all my spare time into my why-perl6 talk. Unfortunately it appears I produce slide decks by something approximating the Douglas Adams method. :-( | 23:08 | ||
| jnthn | japhb: Ah, I see. Well, I'm happy to have somebody continuing to use r-j for stuff, so... :P | 23:10 | |
| colomon | note that, while the moar threaded mandelbrot results were *almost* correct. like maybe 1% of the pixels calculated were wrong. | ||
| jnthn | colomon: Yeah...I'll need to play hunt the data race. :) | ||
| timotimo | yeah, that makes it even more dangerous | ||
| because you can sort of think everything's fine unless you look at something as clear as the resulting image | |||
| jnthn | I kinda prefer the SEGVs rather than the subtly wrong things... :/ | ||
| timotimo | if you have only numbers and no clue what the exact result should look like ... | 23:11 | |
| yeah | |||
| colomon | afk # headed to pub | 23:12 | |
| japhb | Oh, that reminds me ... while preparing github.com/japhb/japhb-talks/blob/...s/channels I discovered that forgetting the two .close calls resulted in death at program exit, one of three ways: backtrace, segfault, or (IIRC) a GC error. It would work just fine until exit and then reliably boom!, but the method of death changed from run to run. | 23:14 | |
| jnthn | Hmmm | 23:18 | |
| I was gonna say "ooh, global destruction fail"... | |||
| ...but we just let the OS tear down the world now by default... | |||
| japhb is reminded yet again of how much he likes jnthn's threading primitives ... by reviewing some threaded Python code. | 23:42 | ||