Show enters and exits. Hide enters and exits.
| 00:00:58 | antares leaves the room. | |
| 00:01:28 | lstoll leaves the room. | |
| 00:02:23 | stepheneb leaves the room. | |
| 00:04:48 | trythil leaves the room. | |
| 00:05:16 | dlee leaves the room. | |
| 00:06:20 | stepheneb enters the room. | |
| 00:07:54 | dlee enters the room. | |
| 00:11:20 | Skip leaves the room. | |
| 00:11:23 | jayWHY leaves the room. | |
| 00:11:51 | srbaker leaves the room. | |
| 00:13:10 | trythil enters the room. | |
| 00:21:57 | imajes enters the room. | |
| 00:25:42 | therealadam leaves the room. | |
| 00:26:06 | rue | Kernel#p prints nothing if it has no argument, Kernel#puts prints a newline only |
| 00:26:19 | rue | No argument is not the same as nil argument |
| 00:27:22 | rue | Our #p is incorrect, I think. Fixing |
| 00:27:56 | Maledictus | confirmed here |
| 00:29:19 | gnufied_ leaves the room. | |
| 00:30:21 | wmoxam leaves the room. | |
| 00:33:14 | trythil leaves the room. | |
| 00:34:29 | obvio leaves the room. | |
| 00:36:51 | Maledictus leaves the room. | |
| 00:38:19 | demisone | rue, Maledictus (he left) : i guess you're right about p, but what about the ArgumentError when calling (1..100).map(&:to_s) for example? |
| 00:38:57 | demisone | sorry, i meant "[(1..10).to_a, (1..10).to_a].map(&:to_s) " |
| 00:39:18 | anteaya enters the room. | |
| 00:45:56 | lopex leaves the room. | |
| 00:47:30 | naeu leaves the room. | |
| 00:48:56 | stepheneb_ enters the room. | |
| 00:49:36 | AndrewO enters the room. | |
| 00:50:48 | crayz_ leaves the room. | |
| 00:51:18 | rue | Hrm |
| 00:53:43 | rue | Weird, I cannot seem to pin down the record separator |
| 00:55:13 | drbrain | try nails |
| 00:55:15 | brixen | perhaps a large pair of tweezers and some chloroform |
| 00:55:36 | brixen | or nails |
| 00:56:05 | demisone | chloroform is good |
| 00:56:12 | demisone | :) |
| 00:59:30 | benstiglitz leaves the room. | |
| 01:00:17 | lstoll enters the room. | |
| 01:01:53 | ezmobius leaves the room. | |
| 01:02:59 | dewd leaves the room. | |
| 01:03:46 | stepheneb leaves the room. | |
| 01:04:20 | rue | Ah, it uses the system record separator, I think |
| 01:04:26 | rue | Stupid-ass behaviour |
| 01:07:18 | gnufied enters the room. | |
| 01:12:12 | peeja enters the room. | |
| 01:12:54 | boyscout | 2 commits by Eero Saynatkari |
| 01:12:55 | boyscout | * Fixed Kernel#p to not print anything given no arguments.; 19dc390 |
| 01:12:56 | boyscout | * Specs for Kernel#p behaviour.; e1406b1 |
| 01:13:23 | demisone | hmm... gonna check it out |
| 01:13:45 | agardiner enters the room. | |
| 01:14:31 | rue | Morning, agardiner |
| 01:14:36 | agardiner | hiya rue |
| 01:14:39 | headius enters the room. | |
| 01:19:53 | wmoxam enters the room. | |
| 01:22:40 | demisone leaves the room. | |
| 01:23:30 | stepheneb enters the room. | |
| 01:25:11 | agardiner | so, i hit a problem with TCPSocket last night... i dunno if its related to the MySQL problem, but i'm getting an error due to an attempt to seek on a pipe when doing a puts |
| 01:29:10 | agardiner | Defiler: i saw in the logs you were hitting problems with the debugger... care to elaborate? |
| 01:29:45 | rubuildius_ppc | Eero Saynatkari: 19dc39052; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181446 |
| 01:31:06 | headius leaves the room. | |
| 01:31:26 | obiejuan leaves the room. | |
| 01:32:52 | headius enters the room. | |
| 01:33:12 | chris2 leaves the room. | |
| 01:33:37 | seydar enters the room. | |
| 01:35:10 | wdperson enters the room. | |
| 01:35:17 | stepheneb_ leaves the room. | |
| 01:36:40 | Defiler | agardiner: Oh, I was just saying that I hadn't had a lot of luck using it to debug this particular issue |
| 01:37:07 | Defiler | agardiner: re: your error with puts.. do you have a reproduction? I'd like to look at t |
| 01:37:11 | Defiler | it |
| 01:37:17 | dysinger leaves the room. | |
| 01:38:32 | dysinger enters the room. | |
| 01:39:58 | headius | btw, bigdecimal won't be a general blocker, but it's used for DECIMAL fields in most of the DB drivers |
| 01:40:14 | cored enters the room. | |
| 01:40:31 | Defiler | I intend to have it implemented soon, so it shouldn't be a problem |
| 01:40:55 | Defiler | *crosses fingers* |
| 01:41:06 | headius | say a little prayer |
| 01:41:07 | rubuildius_ppc | a little prayer |
| 01:41:16 | wycats_ enters the room. | |
| 01:41:22 | headius | say I hate running rubinius builds |
| 01:41:22 | rubuildius_ppc | I hate running rubinius builds |
| 01:41:28 | headius | quote of the week |
| 01:41:46 | Defiler | Odin, send thy ravens with decimal-related inspiration |
| 01:41:54 | headius | can you just wrap libtom? |
| 01:42:13 | Defiler | I'm going to do it in Ruby |
| 01:42:26 | headius | *cough* |
| 01:42:27 | headius | ok |
| 01:42:42 | Defiler | which is a yes, really |
| 01:42:56 | Defiler | since it means I can just use bignums behind the scenes |
| 01:43:01 | bricolage leaves the room. | |
| 01:43:07 | Defiler | That's essentially what the new decimal implementation does, and I like it |
| 01:43:25 | headius | ok |
| 01:43:27 | Defiler | Unfortunately it uses rb_ensure, which I am told is problematic to implement |
| 01:43:51 | Defiler | So I can either fork the C version, or port it to ruby.. evan prefers the latter, so that's what I will do |
| 01:46:19 | agardiner | Defiler: hmm... i'm not getting the seek error now, since i changed my code. Let me see if i can reproduce it... |
| 01:46:47 | seydar | this is is no way related to decimals, but has anyone toyed with the idea of doing optional static typing? |
| 01:47:17 | headius | seydar: the power of christ compels you! |
| 01:47:29 | Defiler | We don't plan on changing the language semantics, but it has been discussed here approximately 637 times. |
| 01:47:30 | seydar | shrinks away |
| 01:47:38 | Defiler | So you are in good company. :) |
| 01:48:13 | seydar | ok. because _my friend_ thinks it'd be cool to have the option |
| 01:48:14 | headius | a longer answer is that ideally the duby type decl and inference logic could eventually be used by any ruby impl to add typing smarts, if there were such a desire |
| 01:48:24 | brixen | seydar: www.cs.umd.edu/~jfoster/ruby.pdf |
| 01:48:42 | seydar | headius: but how does type checking really work when ruby is all about message passing? |
| 01:48:59 | seydar | i'm about to quote someone here.... |
| 01:49:04 | headius | typing is just another characteristic of the message |
| 01:49:23 | headius | send to X with arg types Y and Z |
| 01:49:26 | Defiler | http://portal.acm.org/citation.cfm?id=118014.117964&coll=GUIDE&dl=GUIDE&CFID=9596217&a mp;CFTOKEN=52599924 |
| 01:49:37 | seydar | http://talklikeaduck.denhaven2.com/articles/2007/10/17/you-cant-judge-a-book-some-mental-traps-in- learning-ruby |
| 01:49:42 | headius | but a more important question is what you'd hope to accomplish with said typing |
| 01:50:03 | agardiner | Defiler: ok, i can reproduce it... |
| 01:50:05 | headius | if it's performance, you would get none since you're still dynamically binding |
| 01:50:24 | headius | if it's type-safety, you'd get a bit more than you have now, but not much |
| 01:50:52 | Defiler | I think it would be better to make a new language with the intended characteristics |
| 01:50:55 | foysavas enters the room. | |
| 01:50:59 | Defiler | Rather than try to mangle Ruby into something else |
| 01:51:11 | seydar | with performance, couldn't shotgun (in some future rewrite) use completely compiled mini-blocks and put the blocks together as needed? |
| 01:51:22 | Defiler | We can do that without static typing |
| 01:51:26 | seydar | Defiler: thats probably a better idea than any in my head |
| 01:53:40 | seydar | whoa! what happened to #to_sexp? |
| 01:54:03 | brixen | we're too_sexp for our code |
| 01:54:36 | seydar | roflcopter down, send aid |
| 01:54:56 | seydar | so really, what happened to it? |
| 01:55:03 | Defiler | Nothing? |
| 01:55:03 | dysinger leaves the room. | |
| 01:55:06 | brixen | heh |
| 01:55:16 | seydar | its not there in 'shotgun/rubinius irb' |
| 01:55:19 | brixen | seydar: what happened to *your* to_sexp? |
| 01:55:32 | seydar | its not anywhere! |
| 01:55:38 | seydar | i cant find my to_sexp! |
| 01:55:39 | Defiler | "5".to_sexp works for me |
| 01:55:45 | brixen | "pirb(main):001:0> "p 1".to_sexp |
| 01:55:45 | brixen | => [:newline, 1, "(eval)", [:fcall, :p, [:array, [:lit, 1]]]] |
| 01:55:50 | brixen | mine too |
| 01:55:50 | headius | limited inlining is possible without static typing, though it's harder |
| 01:55:54 | seydar | ok its here |
| 01:56:01 | headius | and you need to install guards and fallbacks all along |
| 01:56:40 | Defiler | Yeah. You have to figure out that it's OK to optimize at runtime, and be prepared to deoptimize it when someone adds methods, etc |
| 01:56:54 | wycats leaves the room. | |
| 01:57:08 | drbrain | yay! Tinderbox works again (on MRI, at least) |
| 01:57:15 | Defiler | awesome |
| 01:57:17 | drbrain | just in time for dinner |
| 01:57:21 | evan | huzzah! |
| 01:57:28 | headius | hooplah! |
| 01:57:33 | Defiler | squeee!! |
| 01:57:39 | Fobax | Do methods get added so often that you can't just recompile lots of stuff when any method is added? |
| 01:57:47 | Defiler | Yes |
| 01:57:49 | chop3 enters the room. | |
| 01:57:55 | Fobax | and not have any of those guards most of the time? |
| 01:58:04 | Defiler | What guards? |
| 01:58:11 | Fobax | <headius> and you need to install guards and fallbacks all along |
| 01:58:28 | Defiler | Oh, right. Well, we don't do this concept at all yet |
| 01:58:34 | Defiler | So this is all hypothetical |
| 01:58:55 | Fobax | it would make adding a method slow, and cause everything to slow down for a bit afterwards, but should be faster in general, right? |
| 01:58:56 | Defiler | but you have to make sure you don't invoke the wrong method |
| 01:59:11 | headius | always need guards, or you end up stopping the world to recompile everything |
| 01:59:21 | Defiler | We would have to design some benchmarks to know for sure which way makes sense |
| 01:59:21 | Fobax | what's wrong with that? |
| 01:59:43 | headius | well, nothing, if you don't mind stopping the world fairly often :) |
| 01:59:58 | Fobax | startup time would suffer, but wouldn't runtime be much better |
| 02:00:06 | headius | the complexity arises from not knowing what limited subset you have to recompile, so you end up having to recompile almost everything |
| 02:00:13 | Defiler | Intuition is useless when it comes to this kind of stuff |
| 02:00:15 | headius | runtime would still need to recompile because of metaprogramming, etc |
| 02:00:38 | headius | 90% of activerecord doesn't exist at startup, for example |
| 02:00:46 | headius | and may not exist until some indeterminate time in the future |
| 02:00:49 | Fobax | that's true, but after a minute, it does |
| 02:01:01 | headius | until you hit a rarely used code path that calls a new finder |
| 02:01:08 | Defiler | Also, it is potentially challenging for the VM to figure out when 'startup' is over |
| 02:01:14 | headius | there's not really any moment in time you can freeze everything easily with ruby |
| 02:01:20 | Defiler | It isn't like there is a Ruby construct that says "OK done defining things now go for it" |
| 02:01:40 | Fobax | Could you add one? |
| 02:01:46 | evan | no. |
| 02:01:50 | VVSiz_ enters the room. | |
| 02:01:57 | headius | evan and I talked about using class.freeze as an indicator once |
| 02:01:57 | Defiler | Well.. yes, but we won't |
| 02:01:59 | stepheneb leaves the room. | |
| 02:02:16 | Defiler | We are not forking Ruby |
| 02:02:19 | headius | anything that requires people to fundamentally change the way they use ruby would never fly |
| 02:02:35 | Defiler | We would design something with fewer rough edges, if we were. :) |
| 02:02:59 | jptix leaves the room. | |
| 02:03:45 | Defiler | This stuff is fun to talk about, but we have a huge list of basic things that need to work before we can consider such tweakery |
| 02:04:08 | Defiler | like x.shift(*x) for example |
| 02:04:25 | Defiler | well, s/shift/something_like_that/ |
| 02:04:47 | d2dchat leaves the room. | |
| 02:05:07 | headius | in evan we trust |
| 02:05:57 | Defiler | If only he hadn't called us bitter... |
| 02:06:08 | evan | i called you bitter? |
| 02:06:21 | Defiler | Bad political joke |
| 02:06:28 | brixen | hah |
| 02:06:46 | evan | ah. |
| 02:07:13 | agardiner | Defiler: ok, i've hacked up a cut-down test case showing the seek problem... |
| 02:07:24 | agardiner | want me to put it in a ticket, or just pastie? |
| 02:07:55 | Defiler | ticket please, and assign it to me if you would be so kind |
| 02:07:59 | Defiler | Also, this is amazing http://www.matasano.com/log/1032/this-new-vulnerability-dowds-inhuman-flash-exploit/ |
| 02:08:00 | agardiner | np |
| 02:09:31 | VVSiz leaves the room. | |
| 02:09:34 | wmoxam leaves the room. | |
| 02:11:36 | stepheneb enters the room. | |
| 02:12:04 | brixen | Defiler: wow |
| 02:12:32 | Defiler | I didn't realize that ActionScript ran on a register-based VM, actually |
| 02:12:43 | brixen | me neither |
| 02:12:55 | headius | yeah |
| 02:17:00 | brainopia leaves the room. | |
| 02:18:41 | evan | that guy is intense. |
| 02:21:35 | agardiner | eww... how do you format a code block on LH? |
| 02:21:51 | rue | Poorly |
| 02:22:10 | rue | @@@\ncode\n@@@ still probably works |
| 02:22:11 | agardiner | he chose... poorly! |
| 02:22:14 | Defiler | @@@ ruby |
| 02:22:21 | Defiler | and then @@@ on a line by itself to end the block |
| 02:22:23 | agardiner | k, thanks |
| 02:22:25 | Defiler | (I think) |
| 02:22:55 | rue | Damn it |
| 02:23:12 | agardiner | ok, much better |
| 02:23:22 | agardiner | Defiler: ticket is 497 |
| 02:23:27 | Defiler | Thanks |
| 02:24:23 | Defiler | Looks clean. Good stuff |
| 02:24:23 | rue | I should probably give up on this but I keep getting drawn in. Apache and libtool both suck. |
| 02:29:25 | evan | rue: hows the doc coming? |
| 02:29:50 | Defiler | http://www.matasano.com/log/1038/dowds-flash-report-what-have-we-learned/ |
| 02:30:05 | Defiler | The follow-up article is also extremely interesting and has some good thoughts that we should probably keep in mind as we work on the VM |
| 02:31:11 | Defiler | Has Mark Dowd simply outclassed us? Should we pack it up and quit? |
| 02:31:12 | Defiler | Yes. But don’t feel bad about that. You’re a human being, and he’s a remorseless killing machine. |
| 02:31:32 | headius | I suppose all new VMs will have to deal with such things |
| 02:34:15 | gnufied leaves the room. | |
| 02:35:46 | evan | hehehe |
| 02:35:49 | evan | thats so awesome. |
| 02:37:55 | agardiner | yeah... i'm off to take up interpretive dance! (whatever the heck that is!) |
| 02:38:02 | Defiler | The reviews of his book at Amazon are awesome |
| 02:38:05 | Defiler | "The longer you wait to read this book, the further you will fall behind" |
| 02:41:31 | brainopia enters the room. | |
| 02:42:31 | headius | evan: your opinion on something, if you have a moment |
| 02:43:09 | evan | certainly my friend |
| 02:43:11 | headius | http://pastie.org/181129 |
| 02:43:35 | headius | those are two examples of backtraces generated not from Ruby frames but from cleverly-decorated Java method names by the compiler |
| 02:43:46 | evan | oh nice. |
| 02:43:47 | headius | so it mines the Java stack trace to produce that |
| 02:43:54 | evan | cool |
| 02:44:07 | headius | I was curious what you thought of the __rescue__ etc...it could be collapsed with a little smarter mining, but I think it's kinda nice |
| 02:44:38 | evan | yeah, I think __rescue__ is fine |
| 02:45:09 | headius | it shows up this way because in JRuby's compiler they are emitted as separate Java method bodies |
| 02:45:18 | evan | yeah |
| 02:45:23 | evan | we've talked about that |
| 02:45:52 | headius | this is part of an attempt to take perf to the next level...to be able to reliably omit artificial call frames and still have e.g. accurate stack traces |
| 02:46:18 | headius | fib, for example, is another 50% faster without call frames...twice 1.9's performance |
| 02:46:32 | _VVSiz_ enters the room. | |
| 02:46:38 | tarcieri | nice |
| 02:47:01 | headius | it's mostly safe now, but things like $_ are a bitch |
| 02:47:04 | Defiler | Cool |
| 02:47:20 | headius | any methods that modify those will be tagged as "frame-wanting" |
| 02:47:24 | rue | Goddamnit, now it cannot find main(), *sigh* |
| 02:47:40 | rue | evan: Alright, I ended up trying to refine my plans for the backend |
| 02:48:23 | headius | anyway...as I refine the general mechanism I'll keep y'all posted. I think it would be useful for rubinius as well, to reduce per-call methodcontext cost when possible |
| 02:48:35 | headius | and it will certainly help when jit enters the picture |
| 02:48:38 | evan | yeah |
| 02:48:45 | evan | i HATE $~ and $_ |
| 02:49:10 | headius | they're by far my least favorite of the frame escapees |
| 02:49:13 | evan | surely |
| 02:49:43 | headius | logically though, they're of limited impact...if you see that code may be calling methods that modify or access them, you fall back on slower paths |
| 02:49:59 | headius | the worst side effect is that you slow down unrelated calls with the same name |
| 02:50:02 | Defiler | To go back to the earlier discussion.. if we were going to make significant compatibility-breaking changes to Ruby, we would for sure rip those out. Heh |
| 02:50:14 | headius | that can be ameliorated by gathering runtime information on what's *actually* compatible |
| 02:50:17 | headius | er |
| 02:50:23 | headius | changed thought in mid sentence |
| 02:50:27 | headius | *actually* being called |
| 02:50:36 | evan | yeah |
| 02:50:48 | evan | i saw Kresten's presentation on HotRuby at rubyfools |
| 02:50:51 | wycats enters the room. | |
| 02:50:57 | evan | he's got some cool shit |
| 02:51:00 | Cosmos95 enters the room. | |
| 02:51:02 | headius | ahh yes, I only heard a bit about that |
| 02:52:18 | agardiner | evan: i had a question for you the other day, but i think you'd gone... |
| 02:52:40 | brainopia leaves the room. | |
| 02:53:09 | antares enters the room. | |
| 02:53:30 | evan | oh |
| 02:53:33 | evan | i'm just running out |
| 02:53:40 | evan | it's ezmobius's birthday |
| 02:53:59 | seydar | happy birhtday ezmobius |
| 02:54:02 | antares leaves the room. | |
| 02:54:05 | antares enters the room. | |
| 02:54:19 | agardiner | it was: is there a reason why e.g. SendSite.create takes an OBJECT instead of a SYMBOL |
| 02:54:39 | antares leaves the room. | |
| 02:54:43 | agardiner | (in the C++ code) |
| 02:54:46 | antares enters the room. | |
| 02:55:12 | evan | i've since changed that |
| 02:55:21 | evan | i'm still backproping specific types |
| 02:55:34 | agardiner | cool then! :-) |
| 02:55:38 | evan | changing OBJECT to specific OBJECT subtypes |
| 02:55:41 | evan | ok, off i go. |
| 02:55:42 | evan | laters! |
| 02:55:47 | agardiner | later |
| 02:59:47 | nicksieger leaves the room. | |
| 02:59:54 | agile enters the room. | |
| 03:02:27 | cored leaves the room. | |
| 03:03:29 | VVSiz_ leaves the room. | |
| 03:04:03 | headius | ahh, found hotruby stuff |
| 03:04:26 | headius | I love when people show benchmark numbers for early stages of Ruby...you just have to shake your head and say "they'll learn soon enough" |
| 03:04:34 | agardiner | hehe |
| 03:04:38 | agardiner | got the link handy? |
| 03:05:10 | headius | http://hotruby.accelart.jp/ |
| 03:07:26 | headius | I'm not sure where he got the number for JRuby in his little benchmark |
| 03:07:45 | headius | on my machine it takes about 6 seconds, and that's from startup with no warmup time |
| 03:08:21 | agardiner | early stages is an understatement! they've got what - 50 methods implemented, no exceptions... embryonic may be more accurate! :-) |
| 03:08:23 | tarcieri | haha someone wrote a YARV bytecode interpreter in ECMAScript? |
| 03:08:24 | headius | his ruby 1.9 number is about what I get |
| 03:08:24 | drbrain enters the room. | |
| 03:08:26 | tarcieri | that's lolz |
| 03:08:32 | drbrain | oops |
| 03:08:53 | headius | not sure if this is the same thing kresten presented or not |
| 03:09:00 | Defiler | Wow this is pretty intense |
| 03:09:05 | Defiler | http://hotruby.accelart.jp/test-web/pinball.html |
| 03:09:25 | tarcieri | whoaaaaaaa |
| 03:09:30 | seydar | it keeps breaking on my machine. it stalls if the blocks touch certain things |
| 03:09:34 | headius | yeah flash stuff |
| 03:09:47 | tarcieri | that's... awesome |
| 03:10:26 | madsimian_ enters the room. | |
| 03:12:12 | rue | I think his figure is pretty much JS performance |
| 03:12:58 | agardiner | not a bad approach, taking bytecode to execute rather than source... |
| 03:13:11 | agardiner | solves having to parse ruby |
| 03:13:29 | headius | yeah, we have a yarv machine we want to revisit some day |
| 03:13:35 | headius | though we also wrote a compiler |
| 03:13:58 | agardiner | is the yarv bytecode documented somewhere? |
| 03:14:11 | Defiler | Pretty much |
| 03:14:19 | tarcieri | man, we've always had some douchebag working on our Flash crap who wrote totally unmaintainable monstrosities |
| 03:14:31 | tarcieri | if you could get full access to the Flash API in Ruby... |
| 03:15:36 | headius | pseudo-ruby |
| 03:15:44 | tarcieri | well yeah |
| 03:15:50 | seydar | i want DOM acess from Ruby |
| 03:15:57 | Defiler | I'm trying to find the link, though, and not having a lot of luck |
| 03:15:57 | tarcieri | A Ruby-esque language which has full access to Flash's APIs |
| 03:16:19 | agardiner | yeah, i didn't find anything with a quick google search... |
| 03:16:23 | headius | I made a JRuby applet that had access to the DOM at one point |
| 03:17:08 | seydar | ugh. building rubinius on 10.4 needs env MACOSX_DEPLOYMENT_TARGET to be set to 10.4 |
| 03:17:08 | KirinDav leaves the room. | |
| 03:17:21 | Defiler | configure should do that for you |
| 03:17:30 | Defiler | That used to work, at least |
| 03:18:18 | seydar | not working anymore |
| 03:21:46 | antares leaves the room. | |
| 03:27:39 | benburkert leaves the room. | |
| 03:29:39 | benburkert enters the room. | |
| 03:32:20 | benburkert_ enters the room. | |
| 03:32:20 | benburkert leaves the room. | |
| 03:33:33 | MenTaLguY enters the room. | |
| 03:34:22 | benburkert_ leaves the room. | |
| 03:35:38 | benburkert enters the room. | |
| 03:36:28 | benburkert leaves the room. | |
| 03:36:35 | MenTaLguY | hey guys |
| 03:36:46 | seydar | howdy |
| 03:36:46 | benburkert enters the room. | |
| 03:37:41 | benburkert leaves the room. | |
| 03:38:00 | benburkert enters the room. | |
| 03:38:22 | headius leaves the room. | |
| 03:40:31 | benburkert leaves the room. | |
| 03:40:45 | benburkert enters the room. | |
| 03:42:12 | imajes leaves the room. | |
| 03:42:20 | KirinDav enters the room. | |
| 03:46:05 | benburkert leaves the room. | |
| 03:46:23 | benburkert enters the room. | |
| 03:46:23 | djwhitt enters the room. | |
| 03:48:15 | dysinger enters the room. | |
| 03:54:14 | srbaker enters the room. | |
| 03:54:30 | seydar leaves the room. | |
| 03:54:53 | fbuilesv enters the room. | |
| 04:19:29 | trythil enters the room. | |
| 04:19:37 | GMFlash leaves the room. | |
| 04:19:42 | GMFlash enters the room. | |
| 04:35:45 | wmoxam enters the room. | |
| 04:37:45 | chop3 leaves the room. | |
| 04:40:35 | srbaker leaves the room. | |
| 04:48:11 | KirinDav leaves the room. | |
| 04:49:12 | srbaker enters the room. | |
| 04:50:44 | headius enters the room. | |
| 04:50:58 | be9 enters the room. | |
| 04:54:21 | headius_ enters the room. | |
| 04:55:24 | headius leaves the room. | |
| 04:56:53 | srbaker leaves the room. | |
| 04:57:02 | d2dchat enters the room. | |
| 04:57:41 | srbaker enters the room. | |
| 04:58:23 | stepheneb leaves the room. | |
| 05:01:48 | KirinDav enters the room. | |
| 05:13:49 | tarcieri | hmm, if this is correct, there's a register-based virtual machine more popular than Rosetta |
| 05:14:16 | MenTaLguY | mm? |
| 05:14:33 | Defiler | turns out ActionScript is a register-based VM |
| 05:14:37 | tarcieri | yes |
| 05:14:39 | tarcieri | exactly |
| 05:14:45 | tarcieri | "Tamarin" |
| 05:14:46 | MenTaLguY | ah, yeah |
| 05:14:49 | headius enters the room. | |
| 05:14:54 | Defiler | I would give a lot to see the source for it |
| 05:15:04 | MenTaLguY | hasn't it been released to Mozilla at this point? |
| 05:15:14 | MenTaLguY | it's supposed to be the basis of the next-generation Javascript stuff in Moz |
| 05:15:14 | Defiler | I am fascinated by the idea that that design could possibly be simpler than anything else |
| 05:15:39 | Defiler | http://www.mozilla.org/projects/tamarin/ |
| 05:15:54 | MenTaLguY | also some people at Adobe have asked me about porting Rubinius to Tamarin |
| 05:16:04 | Defiler | Really? |
| 05:16:08 | tarcieri | Unless they've written another ActionScript virtual machine in the meantime... |
| 05:16:09 | MenTaLguY | nothing official |
| 05:16:09 | Defiler | What did you say? |
| 05:16:41 | MenTaLguY | Well, I'll rephrase that |
| 05:16:44 | srbaker leaves the room. | |
| 05:16:54 | MenTaLguY | they asked me about the best way to get a Ruby implementation for Tamarin |
| 05:16:54 | headius_ leaves the room. | |
| 05:17:01 | MenTaLguY | and I recommended porting the Rubinius kernel to it |
| 05:17:15 | Defiler | aah |
| 05:17:41 | MenTaLguY | it is a project I'd be sort of interested in trying |
| 05:18:30 | Cosmos95 leaves the room. | |
| 05:18:44 | MenTaLguY | again, it wasn't an official thing |
| 05:18:54 | MenTaLguY | so I don't know if anything will actually come of that recommendation |
| 05:19:05 | Defiler | Still, cool that there is even one person interested in it |
| 05:25:16 | MenTaLguY | for the moment I can't really think about blue sky things like that though, I need to find time to finish fixing that actor code that got committed recently :/ |
| 05:26:54 | rue | Development-driven development |
| 05:27:25 | MenTaLguY | the thing that's blocked on right now is adding an argument to send_in_milliseconds so that it can be used to send a specific object instead of only nil |
| 05:29:56 | srbaker enters the room. | |
| 05:30:33 | trythil | hmm, can someone run (1..1001).to_a.reverse.sort in irb under rubinius and let me know if they also see anomalous output near the beginning of the array? |
| 05:31:38 | brixen | trythil: indeed |
| 05:31:57 | agardiner | ditto |
| 05:31:58 | trythil | ahh, ok, so it's not just me :) |
| 05:32:13 | brixen | up to 81 to be exact, in my case |
| 05:32:21 | trythil | interestingly, I can't trigger it using just (1..1000) |
| 05:32:36 | agardiner | yeah, there's a tipping point reached in qsort at 1001 elements |
| 05:32:39 | brixen | perhaps boundary condition on the pivot |
| 05:32:43 | trythil | hmm |
| 05:32:43 | agardiner | yeah |
| 05:32:54 | agardiner | i already fixed a bug there... |
| 05:33:10 | agardiner | was manifesting in the profiler |
| 05:33:32 | MenTaLguY | is qsort that tricky? |
| 05:33:42 | brixen | MenTaLguY: we have a custom version |
| 05:33:48 | Defiler | MRI's semantics are hard to recreate |
| 05:33:56 | Defiler | It's pretty far from the textbook behavior |
| 05:34:00 | brixen | does some heuristics on the pivot iiuc |
| 05:34:18 | MenTaLguY | I find this a little bit distressing. |
| 05:34:19 | Defiler | Well, that and it has to work even when people do .sort_by { -1 } |
| 05:35:58 | trythil | hmm |
| 05:36:02 | stepheneb_ enters the room. | |
| 05:36:11 | trythil | I wrote up a spec for enumerable that fed (1..1001).to_a.reverse to an EnumerableSpecs::Numerous instance, and that (interestingly) passed |
| 05:36:18 | trythil | I wonder what splat is doing there |
| 05:36:33 | Defiler | something very simple, in comparison to 'sort' |
| 05:36:48 | Defiler | This is surely a sort bug, it seems to me |
| 05:37:06 | trythil | right, but I mean |
| 05:37:07 | trythil | http://pastie.caboo.se/181530 |
| 05:37:12 | trythil | that passed, which makes me wonder |
| 05:37:46 | trythil | if I omit EnumerableSpecs::Numerous.new(*numbers) and just operate using numbers, the spec fails |
| 05:38:01 | trythil | I dunno, maybe this is a red herring |
| 05:41:02 | srbaker leaves the room. | |
| 05:41:06 | Defiler | Maybe we have a 'reverse' problem, actually, where it isn't duping |
| 05:41:51 | brixen | Enumerable#sort is doing something different from Array#sort |
| 05:41:54 | brixen | it takes way longer |
| 05:41:59 | MenTaLguY | where is struct ev_timer defined? |
| 05:42:18 | MenTaLguY | on, never mind |
| 05:42:18 | MenTaLguY | duh |
| 05:42:28 | trythil | I get similar behavior running (1..1024).map { |i| (rand*i).to_i }.sort, so I'm not sure if it's reverse |
| 05:42:31 | trythil | (or just reverse) |
| 05:43:53 | srbaker enters the room. | |
| 05:44:13 | tarcieri | MenTaLguY: what are you looking at? (besides libev timers) |
| 05:44:36 | tarcieri | MenTaLguY: I thought of a way to fix timeouts given the present Scheduler semantics, btw |
| 05:45:05 | brixen | trythil: Enumerable has it's own quicksort |
| 05:45:06 | RyanTM leaves the room. | |
| 05:45:17 | MenTaLguY | tarcieri: oh? |
| 05:45:49 | trythil | brixen: yeah, I just passed over that one, I guess that explains why the spec using Numerous worked |
| 05:45:49 | tarcieri | MenTaLguY: you can process Channel messages without doing Channel#receive |
| 05:46:06 | trythil | it also appears to be using the first element of each subset as the pivot |
| 05:46:07 | tarcieri | so... have Actor.receive completely flush the channel until empty, discarding any timeout messages |
| 05:46:10 | tarcieri | then call Channel.receive |
| 05:46:22 | tarcieri | (after it matches a message) |
| 05:47:07 | MenTaLguY | well, not until empty |
| 05:47:16 | MenTaLguY | just until a marker object which you inserted is reached |
| 05:47:36 | MenTaLguY | that should actually work I think |
| 05:47:54 | tarcieri | well, until you've encountered the timeout message, or the Channel is empty... |
| 05:48:22 | MenTaLguY | you can't test for an empty channel |
| 05:48:31 | tarcieri | are you sure? |
| 05:48:38 | MenTaLguY | yes. |
| 05:48:44 | loincloth enters the room. | |
| 05:48:49 | MenTaLguY | it's kind of deliberate |
| 05:48:59 | MenTaLguY | there isn't really a way to do it that doesn't involve races |
| 05:49:23 | crafterm enters the room. | |
| 05:49:27 | MenTaLguY | (think about it carefully) |
| 05:49:40 | KirinDav leaves the room. | |
| 05:51:38 | MenTaLguY | you can only safely test whether you've extracted all the messages written before a particular point in time in the frame of reference of the reading thread (by using a marker object in the manner described) |
| 05:51:52 | tarcieri | ok, yeah that works |
| 05:51:53 | loincloth leaves the room. | |
| 05:51:54 | MenTaLguY | (although it does rely on you being the only reader, that's a safe assumption for mailbox) |
| 05:52:25 | MenTaLguY | I've got mixed feelings really, I think I see how to implement the modified send_in_milliseconds now |
| 05:52:35 | tarcieri | to send an arbitrary object? |
| 05:53:13 | MenTaLguY | yes |
| 05:53:16 | tarcieri | nice |
| 05:53:23 | MenTaLguY | it's not really that involved |
| 05:53:28 | tarcieri | ok |
| 05:53:36 | MenTaLguY | the only thing is going to be compatibility between the "frozen" kernel and the modified one |
| 05:53:55 | brixen | MenTaLguY: changing the semantics of a primitive? |
| 05:54:09 | MenTaLguY | yes. |
| 05:54:19 | brixen | I would suggest making a new one |
| 05:54:26 | brixen | and phase out the old |
| 05:54:35 | MenTaLguY | yeah, you have to do it gradually |
| 05:55:12 | boyscout | 1 commit by Adam Gardiner |
| 05:55:13 | boyscout | * Add basic Debugger::Server class for remote debugging; 0ffd16c |
| 05:55:25 | brixen | agardiner: woot! |
| 05:55:34 | agardiner | hehe! |
| 05:55:43 | agardiner | *very* basic, but works |
| 05:55:52 | brixen | awesome |
| 05:56:07 | AndrewO leaves the room. | |
| 05:57:10 | agardiner | first step to getting rubinius debugger hooked into netbeans/radrails... |
| 05:57:26 | brixen | oh interesting |
| 05:57:33 | brixen | didn't realize you had that in your sights |
| 05:57:35 | MenTaLguY | question |
| 05:57:38 | agardiner | yeah |
| 05:57:46 | MenTaLguY | how are the fields of thread_info made visible to the garbage collector? |
| 05:57:56 | MenTaLguY | I admit I've not looked at the rbx GC stuff at all yet |
| 05:58:11 | evan | allo. |
| 05:58:12 | wycats_ leaves the room. | |
| 05:58:13 | agardiner | i need to implement the debug_commons protocol |
| 05:58:20 | evan | MenTaLguY: which? |
| 05:58:28 | MenTaLguY | struct thread_info |
| 05:58:43 | MenTaLguY | has several OBJECT references which must be accessible from the root set somehow |
| 05:59:08 | evan | oh, in Channel. |
| 05:59:20 | MenTaLguY | cpu_event.c yes |
| 05:59:30 | evan | the cpu_event_each_channel |
| 05:59:34 | evan | is called with a callback |
| 05:59:42 | evan | to let the GC see them. |
| 05:59:56 | evan | thats a hack thats being cleaned up in the new VM |
| 05:59:59 | MenTaLguY | aha |
| 06:00:09 | MenTaLguY | I was wondering what that was about, now I know |
| 06:00:16 | evan | yep. |
| 06:00:29 | MenTaLguY | what's the status of the new VM at this point? |
| 06:00:58 | evan | going good |
| 06:01:22 | evan | if i'd been as productive as i've been the last 5 days for the last 3 weeks, it would be done. |
| 06:01:23 | wycats_ enters the room. | |
| 06:01:33 | evan | it's coming along. |
| 06:01:39 | evan | should be running code by the end of the week |
| 06:02:03 | MenTaLguY | ok |
| 06:02:28 | MenTaLguY | be advised that I'm going to be poking at redoing CPU waits to be able to send specific objects, not just nil |
| 06:02:59 | MenTaLguY | otherwise there's no way to multiplex waits on a single channel |
| 06:03:09 | MenTaLguY | (since you can't distinguish which event you got) |
| 06:03:17 | evan | yeah, i'd planned on doing that in the new VM off the bat |
| 06:03:20 | evan | so if you want, you can wait. |
| 06:03:26 | evan | otherwise, poke away. |
| 06:03:29 | MenTaLguY | hm |
| 06:03:32 | tarcieri | nice |
| 06:04:33 | MenTaLguY | how is that going to work with respect to the existing primitives? |
| 06:04:42 | MenTaLguY | are you introducing new primitives with the new VM? |
| 06:04:47 | evan | no |
| 06:05:03 | evan | just going to modify the existing ones |
| 06:05:04 | evan | was my plan |
| 06:05:14 | evan | were you thinking of adding an extra arg to all primitives? |
| 06:05:38 | evan | all scheduler primitives |
| 06:06:03 | MenTaLguY | well, for now just send_in_milliseconds, but that's the idea |
| 06:06:10 | MenTaLguY | obviously I'd want to track what you're doing though |
| 06:06:35 | evan | don't worry about tracking. |
| 06:06:43 | evan | feel free to make the change now |
| 06:06:52 | evan | and we'll pull stuff across when need be |
| 06:06:58 | MenTaLguY | okay |
| 06:07:12 | MenTaLguY | per earlier conversation with brixen, are there any gotchas with just changing this particular primitive directly? |
| 06:07:35 | evan | primitives can't have optional args |
| 06:07:54 | headius | why not |
| 06:07:57 | MenTaLguY | wasn't thinking of an optional argument in this case |
| 06:08:02 | rubuildius_ppc | Adam Gardiner: 0ffd16ca9; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181548 |
| 06:08:05 | evan | headius: because of how they're executed. |
| 06:08:24 | evan | MenTaLguY: then just change the call sites of send_in_milliseconds to contain the extra arg first |
| 06:08:25 | MenTaLguY | or did you mean using an optional argument for back-compatibility? |
| 06:08:33 | jtoy enters the room. | |
| 06:08:34 | MenTaLguY | I guess I could do that |
| 06:08:43 | evan | thats one option |
| 06:08:56 | evan | i think there is just one call site of that primitive |
| 06:09:08 | evan | so you could abstract it behind a real ruby method to have an optional |
| 06:09:12 | MenTaLguY | yep. |
| 06:09:15 | evan | but that doesn't help the stables |
| 06:09:28 | MenTaLguY | ah, yes... |
| 06:09:30 | evan | the main thing is that you need to change the call sites, then update the stables. |
| 06:09:36 | evan | then make the change the primitive. |
| 06:09:48 | evan | that way, the stables will expect the new primitive |
| 06:09:52 | evan | and everything will be fine. |
| 06:10:02 | MenTaLguY | hm |
| 06:10:28 | evan | i'm working on some procedures for easing the pain with this |
| 06:10:37 | MenTaLguY | yeah... |
| 06:10:45 | MenTaLguY | I feel a little nervous doing this |
| 06:10:50 | evan | using either MRI or an installed rbx |
| 06:11:07 | tarcieri | looked at the code and realized he was in way over his head :/ |
| 06:11:07 | evan | ie, a different, stable environment |
| 06:11:11 | MenTaLguY | I think I'll just add the capability to cpu_event for now |
| 06:11:15 | evan | ok |
| 06:11:31 | MenTaLguY | from there it's pretty trivial to expose via the primitive, all the stable juggling notwithstanding |
| 06:11:49 | wycats_ leaves the room. | |
| 06:11:51 | evan | eah |
| 06:11:57 | MenTaLguY | any aesthetic considerations against using thread_info.buffer for the object to write? |
| 06:12:11 | evan | thats fine. |
| 06:12:16 | MenTaLguY | ok |
| 06:12:18 | evan | it's unused in the time case |
| 06:12:21 | MenTaLguY | yes. |
| 06:12:59 | MenTaLguY | vaguely wondering if it ought to be renamed in that case |
| 06:13:11 | MenTaLguY | since it is no longer specifically a buffer |
| 06:13:56 | wycats_ enters the room. | |
| 06:14:15 | MenTaLguY | I will leave it as buffer for now for the sake of small patches |
| 06:14:29 | evan | ok |
| 06:14:42 | evan | if you look at the new c++ version of that code |
| 06:14:50 | evan | it's much more straightforward |
| 06:14:51 | evan | whats going on |
| 06:14:56 | MenTaLguY | nods |
| 06:15:59 | evan | inkscape is C++, isn't it? |
| 06:16:20 | MenTaLguY | Yes, though there's still a lot of C/GObjectisms left |
| 06:16:40 | evan | ah |
| 06:16:48 | evan | yeah, i'm not a big fan of the gobject stuf |
| 06:16:49 | evan | f |
| 06:17:00 | MenTaLguY | C++ is a step up in a sense, but honestly I feel like it's still the wrong language for writing that kind of software at this point |
| 06:17:25 | MenTaLguY | we're working on embedding the JVM for scripting now |
| 06:17:53 | MenTaLguY | if that works out I'm going to be tempted to just push the whole damn thing over the JVM boundary and do it in Scala or something that's sufficiently close to Java but doesn't suck like Java |
| 06:18:24 | MenTaLguY | (I don't think C++ is necessarily a bad choice for writing different sorts of software like, say, VMs) |
| 06:18:36 | MenTaLguY | (though I'm still a bit dismayed as to how large the language really is) |
| 06:18:55 | MenTaLguY | I've been doing C++ for about ... I dunno, 15 years at least |
| 06:19:10 | MenTaLguY | and I still run into new corners of the language I've never explored before every few months |
| 06:19:18 | rue | trythil: Probably the stack handling; I am sure it is actually getting sorted once |
| 06:19:37 | MenTaLguY | Perl is the only other language that seems close in that regard |
| 06:19:44 | MenTaLguY | I bottom out in most other languages pretty quickly |
| 06:20:21 | tarcieri | what other languages let you implement UTMs on top of the compiler? |
| 06:20:23 | MenTaLguY | well, there's also Haskell, but they have the excuse that they're actively adding research features all the time |
| 06:20:32 | tarcieri | besides Perl and C++ |
| 06:20:43 | MenTaLguY | Perl doesn't really let you do that |
| 06:20:49 | tarcieri | there's Acme::Turing |
| 06:20:58 | MenTaLguY | oh, I guess it does |
| 06:23:00 | MenTaLguY | evan: hm. you know, as far as wait_writable goes, I think it might be sufficient to have it write the fd rather than a tag object instead of nil |
| 06:23:23 | evan | ok |
| 06:23:37 | MenTaLguY | at least, I can't think of a case where you really need a tag argument at the moment |
| 06:24:00 | evan | there may not be |
| 06:24:00 | MenTaLguY | "writable" events for the same fd aren't quite distinct in the same way that timeouts are |
| 06:24:09 | evan | my idea is once the new VM is in |
| 06:24:21 | evan | to have the Scheduler send Scheduler::Value objects do the channels |
| 06:24:24 | MenTaLguY | each individual timeout is basically its own event source, whereas an fd is a event source in its own right |
| 06:24:30 | evan | which would contain the real values |
| 06:24:35 | evan | then you'd easily be able to tell |
| 06:25:23 | MenTaLguY | hm |
| 06:25:28 | MenTaLguY | maybe |
| 06:25:35 | MenTaLguY | that seems more heavyweight than necessary for simple cases though |
| 06:25:45 | evan | perhaps |
| 06:26:12 | MenTaLguY | I think a basic API which dealt in raw objects would be nice |
| 06:26:17 | MenTaLguY | more or less like what we have now |
| 06:26:23 | evan | ok |
| 06:26:36 | evan | i'm basically completely open for comment/commit on that API |
| 06:27:18 | MenTaLguY | at some point I'd like to realign the Scheduler gem with whatever we do in Rubinius, or vice-versa |
| 06:27:24 | MenTaLguY | so that it could be supported on Rubinius |
| 06:27:28 | evan | on the topic of C++, yes, i don't think i'd want to write in C++ normally |
| 06:27:38 | evan | there are parts of it that are making the VM better than it was in C |
| 06:27:48 | evan | MenTaLguY: sounds good. |
| 06:30:49 | trythil | rue: ah, cool |
| 06:33:42 | rue | trythil: It is consistently breaking in the 550-559 segment |
| 06:37:42 | thehcdreamer enters the room. | |
| 06:46:57 | rue | trythil: Got it |
| 06:47:03 | trythil | rue: ? |
| 06:47:17 | trythil | I've been teaching myself how to use the Rubinius debugger just for this, so I haven't really even gotten to the code yet :) |
| 06:47:47 | wmoxam leaves the room. | |
| 06:51:39 | trythil | rue: what was the bug? (or at least a hint :) ) |
| 06:52:25 | rue | trythil: The problem is (presumably) the threshold for the heuristic, right? |
| 06:52:42 | trythil | rue: yeah, that seems like a good place to begin |
| 06:52:59 | rue | So debugging from when it fires would be a good place |
| 06:53:25 | headius | is there a way to turn off GC currently? |
| 06:54:01 | boyscout | 1 commit by MenTaLguY |
| 06:54:02 | boyscout | * add tag object argument to cpu_event_wake_channel; 42e4c4e |
| 06:54:22 | MenTaLguY | tarcieri: have a look at that commit; the plumbing turned out to be pretty trivial |
| 06:54:33 | MenTaLguY | tarcieri: there's just the small matter of the primitive transition :P |
| 06:55:05 | rue | trythil: There are actually two things that could be fixed |
| 06:55:44 | brixen | headius: no |
| 06:56:26 | headius | damn thee! |
| 06:57:15 | evan | my feeling on that is the same as the JVM |
| 06:57:20 | evan | it's far too dangerous. |
| 06:58:57 | headius | you can turn it off in the JVM for experimental purposes |
| 06:59:02 | headius | that's all I'm looking for |
| 06:59:12 | evan | ah |
| 06:59:29 | evan | i could expose a way to turn it off |
| 06:59:31 | evan | why do you want to? |
| 06:59:38 | tarcieri | MenTaLguY: ok |
| 07:00:34 | evan | tarcieri: btw, my problem with libev is that if you poll (ie, NONBLOCK), no timer events fire. |
| 07:00:44 | evan | it actually resets all timer events |
| 07:00:56 | evan | because the code in libev gets confused and thinks there was a time skew |
| 07:00:56 | headius | I wanted to see what performance would look like with GC out of the picture, for small benchmarks |
| 07:01:02 | tarcieri | weird... you're busy waiting? |
| 07:01:02 | headius | have you done such tests? |
| 07:01:10 | evan | it's in my tests |
| 07:01:12 | evan | i want to poll |
| 07:01:14 | evan | then sleep myself |
| 07:01:16 | evan | then poll again |
| 07:01:21 | evan | and the 2nd poll should fire the timer events |
| 07:01:45 | evan | i fixed it in libev by making it so that only one of the calls to timer_update() performs skew check |
| 07:01:46 | tarcieri | yeah I'm sure that confuses the hell out of libev... and may be the result of the skew I was experiencing |
| 07:02:07 | tarcieri | err, may be the cause... |
| 07:02:09 | evan | polling it now works for timer events |
| 07:02:41 | evan | headius: ah. no, not really. |
| 07:02:57 | tarcieri | I don't ever use ev_loop in non-blocking mode |
| 07:03:05 | thehcdreamer leaves the room. | |
| 07:03:27 | headius | done any profiling of memory churn? any idea of relative overhead from GC versus execution? |
| 07:03:57 | evan | i did some a long time ago |
| 07:04:08 | evan | to decide that i need to add an additional way to allocate MethodContext objects |
| 07:05:07 | MenTaLguY | oh, speaking of GC and channels |
| 07:05:25 | headius | so other than that you didn't see any gross overload in the memory/GC department eh? |
| 07:05:30 | MenTaLguY | it's probably going to be worth optimizing channels to store sequences of nil and single objects not to require allocations |
| 07:05:40 | rubuildius_ppc | MenTaLguY: 42e4c4e44; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181559 |
| 07:05:58 | MenTaLguY | so that they can be used as semaphores and mvars without incurring GC overhead beyond what we get from the waitlist |
| 07:06:12 | headius | the reason I ask is because it occurred to me that along with normal execution work, we've gotten much of our perf gains from reducing object churn |
| 07:06:13 | evan | headius: i don't think so |
| 07:06:16 | MenTaLguY | s/sequences of nil/sequences of all nil/ |
| 07:06:18 | evan | but that was a while ago. |
| 07:06:24 | headius | seems like that could also be the case for rubinius |
| 07:07:29 | headius | hard to know what actual gain we've gotten though...perf on single-core systems has never been worse than dual-core systems, like you'd expect if GC was a bottleneck and ran in parallel |
| 07:07:34 | evan | MenTaLguY: not sure what ya mean |
| 07:07:39 | headius | so maybe more allocation cost than collection cost |
| 07:08:20 | evan | headius: could be |
| 07:08:30 | MenTaLguY | evan: well, in the case of using a channel as a semaphore, you're using the number of nils written as your semaphore count |
| 07:08:38 | tarcieri | MenTaLguY: hmmm |
| 07:08:48 | evan | MenTaLguY: ok |
| 07:08:52 | tarcieri | MenTaLguY: not sure if I'd be comfortable trying to add that to send_on_readable/send_on_writable :/ |
| 07:08:52 | MenTaLguY | evan: if the only thing written to the channel were nil, you could optimize the internal representation to use a count rather than a list |
| 07:08:59 | evan | ah |
| 07:09:04 | evan | sure |
| 07:09:15 | MenTaLguY | tarcieri: I think it's less critical there |
| 07:09:23 | tarcieri | it's certainly critical there |
| 07:09:29 | MenTaLguY | tarcieri: though I think send_on_writable needs to be adjusted to send the fd rather than nil |
| 07:09:36 | tarcieri | how do you multiplex readable and writable events on a single channel? |
| 07:09:40 | tarcieri | along with timeouts |
| 07:09:44 | evan | sweeeet Dazed and Confused is on |
| 07:09:48 | tarcieri | heh |
| 07:09:51 | MenTaLguY | well, readable already sends the fd or the buffer |
| 07:09:52 | tarcieri | Dazed and Confused rocks |
| 07:09:57 | tarcieri | so does writable |
| 07:10:08 | MenTaLguY | does it? it looked like writable wrote nil to me |
| 07:10:15 | tarcieri | it sends the fileno |
| 07:10:27 | MenTaLguY | static void _cpu_wake_channel_for_writable(EV_P_ struct ev_io *ev, int revents) { |
| 07:10:27 | MenTaLguY | struct thread_info *ti = (struct thread_info*)ev->data; |
| 07:10:27 | MenTaLguY | ti->state->pending_events--; |
| 07:10:27 | MenTaLguY | cpu_channel_send(ti->state, ti->c, ti->channel, Qnil); |
| 07:10:27 | MenTaLguY | _cpu_event_unregister_info(ti->state, ti); |
| 07:10:28 | MenTaLguY | } |
| 07:10:52 | drbrain | gaaah C on my screen! |
| 07:11:17 | MenTaLguY | it sends nil |
| 07:11:20 | MenTaLguY | as implemented right now |
| 07:11:22 | evan | drbrain: rub some ointment on it |
| 07:11:24 | tarcieri | really? |
| 07:11:25 | tarcieri | ok |
| 07:11:29 | MenTaLguY | see above |
| 07:11:39 | tarcieri | well I need to multiplex readable/writable events for multiple desriptors on a single channel |
| 07:11:44 | tarcieri | descriptors... |
| 07:11:47 | drbrain | amazon-ec2 disappoints me |
| 07:11:51 | tarcieri | drbrain: why? |
| 07:11:53 | MenTaLguY | oh, I see |
| 07:11:58 | MenTaLguY | more than one descriptor to an fd? |
| 07:12:11 | tarcieri | no, multiple descriptors |
| 07:12:17 | tarcieri | (for a Reactor) |
| 07:12:18 | MenTaLguY | well, and you need to discriminate between readable and writable for the same fd regardless |
| 07:12:23 | tarcieri | yes |
| 07:12:24 | tarcieri | that too |
| 07:12:29 | MenTaLguY | I hadn't considered that |
| 07:12:40 | drbrain | tarcieri: I had to write a wrapper that I'm sure has been similarly written a half dozen times |
| 07:12:51 | tarcieri | drbrain: for what? |
| 07:13:20 | tarcieri | drbrain: the whole system is aching for wrappers to do high level demand-based instance management |
| 07:13:25 | tarcieri | several already exist |
| 07:13:31 | d2dchat leaves the room. | |
| 07:13:42 | MenTaLguY | tarcieri: still thinking about the object wrapper thing btw |
| 07:13:54 | tarcieri | object wrapper? |
| 07:14:05 | drbrain | "create my key, list keys, spawn an instance, list instances, shut down my instance" |
| 07:14:08 | MenTaLguY | tarcieri: I think the two issues I'm still concerned with is the lack of genericity of the object factory, and being able to actor-call arbitrary methods on the wrapped object |
| 07:14:23 | drbrain | the other gems just looked like alternate implementations |
| 07:14:26 | tarcieri | oh, that |
| 07:15:04 | drbrain | for my uses, I don't need to do anything fancier than that |
| 07:15:06 | MenTaLguY | I think there really does need to be some discretion about which methods can be proxied as actor messages |
| 07:15:19 | boyscout | 2 commits by Adam Gardiner |
| 07:15:20 | boyscout | * Fix current line number calculation when a breakpoint is hit; 77b263f |
| 07:15:21 | boyscout | * Fix bug with stepping to a target IP/line; dfed56b |
| 07:15:41 | tarcieri | MenTaLguY: ideally YourObject.call would handle that... |
| 07:16:05 | tarcieri | raise NameError if the remote procedure isn't valid |
| 07:16:11 | MenTaLguY | hm |
| 07:16:11 | tarcieri | or something liket hat |
| 07:16:18 | MenTaLguY | I'll need to think about this some more |
| 07:17:01 | rue | trythil: Let me know if you need any further pointers, by the way. I am semi-afk but if you find it too, you are most welcome to make the patch ;) |
| 07:17:02 | anteaya leaves the room. | |
| 07:17:04 | mentz_ enters the room. | |
| 07:17:34 | trythil | rue: heh, no problem :) right now I'm trying to figure out why I keep getting a VMAssertion whenever I hit a breakpoint |
| 07:18:06 | trythil | in cpu_channel_has_readers_p(state, dbg) (cpu_instructions.c:1382) -- I haven't dug much into the VM code, but this sort of error really seems like I'm invoking the debugger incorrectly, or my installation is just messed up |
| 07:18:17 | agardiner | trythil: hmmm |
| 07:18:35 | agardiner | you might want to pull the patches i just made to the debugger |
| 07:18:59 | agardiner | what were the debugger commands you were using? |
| 07:19:19 | trythil | agardiner: executed debugger in irb, then break Array#qsort!:1666 |
| 07:19:58 | agardiner | interesting! i've never tried running the debugger from irb! :-) |
| 07:20:02 | trythil | I can step into the debugger just fine, as well as set the debugger |
| 07:20:03 | trythil | oh, hah |
| 07:20:10 | trythil | how should I be doing this? :P |
| 07:20:47 | trythil | if there's a link to this on rubinius' lighthouse page I'd greatly appreciate that |
| 07:20:56 | agardiner | if you have a file that calls code you want to debug, run it with shotgun/rubinius -debug <filename> |
| 07:21:02 | trythil | oh |
| 07:21:06 | trythil | well that's easy |
| 07:21:18 | agardiner | i'm not sure if there is... i need to write up some instructions |
| 07:22:21 | agardiner | the assertion you were seeing means that a breakpoint has been hit, but there is no listener blocked on a read on the debug_channel |
| 07:22:35 | trythil | ahh |
| 07:22:45 | trythil | hey neat, it works now :) |
| 07:22:46 | trythil | thanks |
| 07:22:47 | agardiner | that shouldn't happen, basically |
| 07:22:56 | brixen | agardiner: hm, I've used the debugger in irb |
| 07:22:59 | agardiner | so it may be something to do with the way you were running it from irb |
| 07:23:17 | agardiner | ok... so how are you running it from irb? let me see if i can reproduce it |
| 07:23:41 | agardiner | trythil: great! |
| 07:24:41 | brixen | agardiner: was that Q to me or trythil ? |
| 07:24:59 | agardiner | well... both? :-) |
| 07:25:03 | brixen | heh |
| 07:25:08 | trythil | oh |
| 07:25:15 | agardiner | maybe you're doing it the same way, maybe not?! |
| 07:25:21 | trythil | basically I just did rbx then typed debugger |
| 07:25:29 | trythil | er, sorry |
| 07:25:29 | brixen | well, e.g.: class F; def f; puts 'f'; end; end ; debugger; b F#f; F.new.f |
| 07:25:30 | trythil | rbx -debug |
| 07:26:18 | agardiner | brixen: your way should work |
| 07:26:40 | agardiner | trythil: not sure about that... you are setting a breakpoint at the start of irb, doing that... |
| 07:26:51 | trythil | agardiner: yeah, it does seem a little fishy |
| 07:27:07 | agardiner | trying it now... |
| 07:27:34 | brixen | hmm, shotgun/rubinius -debug just gives me irb prompt |
| 07:27:45 | brixen | debugger give me debug prompt |
| 07:27:53 | brixen | b Kernel#puts works fine |
| 07:28:03 | brixen | puts "hello" drops me into debugger |
| 07:28:07 | brixen | and so on |
| 07:28:20 | agardiner | yeah, it seems to work for me too |
| 07:28:38 | agardiner | trythil: did the problem go away after you pull-ed? |
| 07:28:46 | trythil | agardiner: haven't pulled yet, I'll do that now |
| 07:28:52 | brixen | trythil: when you say "rbx -debug" are you running an installed version? |
| 07:28:56 | trythil | brixen: yeah |
| 07:29:05 | rubuildius_ppc | Adam Gardiner: 77b263ff8; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181567 |
| 07:29:06 | brixen | hm, ok, didn't try that |
| 07:29:13 | agardiner | me either... |
| 07:29:15 | brixen | doesn't install rbx |
| 07:29:21 | agardiner | either |
| 07:29:23 | agardiner | :-) |
| 07:29:26 | brixen | heh |
| 07:30:24 | agardiner | trytil: ok, it wasn't what i just fixed then... |
| 07:30:51 | trythil | agardiner: I guess that's ok; I think what I was doing was something bizarre |
| 07:31:10 | agardiner | yeah, but its worth understanding... |
| 07:31:48 | jennyw enters the room. | |
| 07:31:53 | brixen | that exception looks vaguely familiar from a long time ago |
| 07:32:07 | brixen | I think I saw that when it would hit a breakpoint again |
| 07:32:28 | agardiner | yeah - that should be fixed with the recent breakpoint management cleanup |
| 07:32:42 | agardiner | trythil: how old was your installation? |
| 07:32:43 | brixen | yeah, I remember when you fixed it |
| 07:33:03 | trythil | agardiner: pretty recent; I can't remember exactly but no less than a couple days old |
| 07:33:08 | trythil | er, no more |
| 07:33:09 | evan | heheheh, oh Dazed and Confused... |
| 07:33:09 | agardiner | hmm.. ok |
| 07:33:54 | agardiner | i think all the issues with having multiple breakpoints set at the same location should now be resolved... |
| 07:34:00 | trythil | I did a rake clean and rake install from 77b263ff8, so this should be newest |
| 07:35:40 | agardiner | ok, i've got an rbx install now to test... |
| 07:35:43 | wycats leaves the room. | |
| 07:35:57 | agardiner | after you do rbx -debug, what do you do next? |
| 07:36:29 | trythil | agardiner: I set the breakpoints I'm looking for, and then execute a code snippet that I think will hit those breakpoints |
| 07:36:55 | agardiner | whoa there... you must be skipping some steps, i think |
| 07:37:16 | agardiner | rbx -debug leaves me at an irb prompt |
| 07:37:19 | trythil | eh? |
| 07:37:21 | trythil | hmm |
| 07:37:22 | agardiner | do you then type debugger? |
| 07:37:47 | trythil | when I type rbx -debug I get http://pastie.caboo.se/181572 |
| 07:38:54 | agardiner | strange... i go straight to an irb prompt |
| 07:39:32 | trythil | hmm |
| 07:40:02 | rue | Check previously installed Rubiniuses |
| 07:41:20 | trythil | oh, whoa |
| 07:41:29 | trythil | actually, hmm |
| 07:41:54 | trythil | rbx -v reports it as being from revision 77b263ff8 |
| 07:42:10 | trythil | I might have some stray files from old Rubinius installations, I can look around for those |
| 07:50:24 | naeu enters the room. | |
| 07:53:48 | wycats enters the room. | |
| 07:54:36 | KirinDav enters the room. | |
| 07:59:07 | cypher23 enters the room. | |
| 07:59:32 | qwert666 enters the room. | |
| 08:04:25 | KirinDav leaves the room. | |
| 08:09:06 | stepheneb_ leaves the room. | |
| 08:13:49 | boyscout | 1 commit by MenTaLguY |
| 08:13:50 | boyscout | * Use a counter rather than a list until a non-nil write is enqueued.; 79cccc3 |
| 08:16:07 | evan | MenTaLguY: nice |
| 08:18:20 | thehcdreamer enters the room. | |
| 08:19:31 | MenTaLguY | thanks |
| 08:21:34 | tarcieri | ? |
| 08:21:36 | tarcieri | looks |
| 08:22:10 | tarcieri | oh |
| 08:22:10 | tarcieri | cool |
| 08:22:33 | MenTaLguY | semaphores are just channels where you don't care about the specific value written |
| 08:22:43 | MenTaLguY | (or alternately whose value type is unit) |
| 08:23:34 | MenTaLguY | (if we were in a typed language) |
| 08:23:53 | tarcieri | 31172.31 messages per second |
| 08:23:57 | tarcieri | between Actors |
| 08:24:21 | agardiner | hehe... glad you didn't omit the .31! :-) |
| 08:24:32 | tarcieri | heh |
| 08:24:35 | MenTaLguY | I wouldn't expect it to have a significant affect on actor messaging unless you're only sending nils between them |
| 08:24:39 | MenTaLguY | s/affect/effect/ |
| 08:24:41 | tarcieri | aah |
| 08:24:47 | tarcieri | hadn't run that benchmark in awhile |
| 08:25:03 | MenTaLguY | (and actually nils run afoul of the current timeout code) |
| 08:25:09 | rubuildius_ppc | MenTaLguY: 79cccc322; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181577 |
| 08:26:19 | tarcieri | just for shits and grins, Erlang: |
| 08:26:20 | tarcieri | 3391715 messages per second |
| 08:26:21 | tarcieri | heh |
| 08:26:41 | tarcieri | only two orders of magnitude to go! |
| 08:26:45 | evan | :) |
| 08:27:23 | bricolage enters the room. | |
| 08:28:23 | agardiner | hmm... is Thread.list not implemented? |
| 08:33:03 | Maledictus enters the room. | |
| 08:33:41 | boyscout | 1 commit by MenTaLguY |
| 08:33:42 | boyscout | * take advantage of the semaphore optimization; 6e52ab7 |
| 08:34:30 | headius leaves the room. | |
| 08:35:41 | agardiner leaves the room. | |
| 08:37:41 | trythil leaves the room. | |
| 08:41:11 | dlee enters the room. | |
| 08:41:33 | kw leaves the room. | |
| 08:42:17 | naeu leaves the room. | |
| 08:43:16 | benburkert leaves the room. | |
| 08:44:10 | octopod enters the room. | |
| 08:45:26 | rubuildius_ppc | MenTaLguY: 6e52ab7e1; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181582 |
| 08:48:14 | Skip enters the room. | |
| 08:53:46 | octopod leaves the room. | |
| 08:54:08 | octopod enters the room. | |
| 09:02:23 | boyscout | 1 commit by MenTaLguY |
| 09:02:24 | boyscout | * simplify and d-r-y; 35125e5 |
| 09:03:22 | mutle enters the room. | |
| 09:09:32 | Arjen_ enters the room. | |
| 09:11:52 | MenTaLguY leaves the room. | |
| 09:12:49 | scoopr | hm, lighthouse is all different now |
| 09:13:08 | scoopr | perhaps somewhat faster |
| 09:13:27 | drbrain | it's Lighthouse 2! |
| 09:13:38 | scoopr | yeah :) |
| 09:13:44 | rubuildius_ppc | MenTaLguY: 35125e5aa; 1995 files, 6512 examples, 22660 expectations, 0 failures, 0 errors; http://pastie.caboo.se/paste/181587 |
| 09:14:03 | scoopr | shouldn't it now have a git integration? |
| 09:16:58 | drbrain | no clue |
| 09:18:23 | BlackEdder enters the room. | |
| 09:19:00 | naeu enters the room. | |
| 09:24:22 | rue | One would expct |
| 09:24:40 | crafterm leaves the room. | |
| 09:30:18 | lstoll leaves the room. | |
| 09:30:20 | dlee leaves the room. | |
| 09:31:46 | zenspider leaves the room. | |
| 09:34:48 | antares enters the room. | |
| 09:36:52 | VVSiz leaves the room. | |
| 09:38:13 | antares leaves the room. | |
| 09:40:08 | jennyw leaves the room. | |
| 09:43:21 | antares enters the room. | |
| 09:43:46 | antares leaves the room. | |
| 09:48:49 | crafterm enters the room. | |
| 09:48:55 | crafterm leaves the room. | |
| 09:49:41 | dewd enters the room. | |
| 09:55:50 | demisone enters the room. | |
| 09:56:20 |