Show enters and exits. Hide enters and exits.
| 00:00:57 | evan | funny you should say that |
| 00:00:59 | evan | i'm going to try that now. |
| 00:11:40 | evan | well, atm, i'm just saying "Next send: <name>" |
| 00:12:01 | evan | i'm not sure how to calculate the column on the line by the ip yet |
| 00:12:27 | evan | i guess I could count how many of of <name> come before the one that is about to go |
| 00:12:29 | evan | and gsub it |
| 00:22:02 | evan | |Blaze||: it looks ok |
| 00:22:12 | evan | it's not perfect, but it's better than nothing. |
| 00:26:20 | evan | shouldn't. |
| 00:27:10 | evan | str = str.gsub name.to_s, "\033[0;4m#{name}\033[0m" |
| 00:27:14 | evan | thats all I did. |
| 00:27:24 | evan | a few ANSI escape codes. |
| 01:13:38 | brixen | glad we have total crap specs for String#unpack |
| 01:13:46 | evan | hah |
| 01:13:47 | brixen | because we fail a bunch |
| 01:13:52 | brixen | like if we were to have any |
| 01:14:15 | brixen | liking the new bt format :) |
| 01:14:24 | evan | :) |
| 01:16:41 | jakedouglas | O_o |
| 01:21:44 | evan | btw: http://skitch.com/evanphx/dqecn/evan-kendall-bin-rbx-scratch-step.rb-vm-1 |
| 01:21:50 | evan | you can see that loaded_hook is underlined |
| 01:21:56 | evan | because it's the next send that would be done |
| 01:22:04 | evan | thusly, "step" is likely to take you to it. |
| 01:22:19 | evan | i'll have the highlighting be a variable |
| 01:25:45 | brixen | sweet! |
| 01:25:49 | brixen | that is awesome |
| 02:46:59 | slava | brixen: so I have a really neat solution for the big endian / little endian issue that pretty much solves the whole problem |
| 03:31:30 | brixen | slava: yes? |
| 03:35:41 | slava | brixen: just drop PowerPC support |
| 03:35:43 | slava | HAHA sorry |
| 03:36:02 | slava | but yeah, I'm not maintaining factor's ppc backend anymore because its just a total waste of time |
| 03:36:28 | slava | is arm big or little? |
| 03:37:23 | slava | IIRC arm is little endian, which might leave sparc as the only semi-relevant big-endian platform |
| 03:38:00 | evan | yep. |
| 03:38:04 | evan | PPC and sparc |
| 03:38:08 | evan | are it at this point |
| 03:38:44 | evan | MIPS is too, I guess. |
| 03:38:47 | evan | it's switchable |
| 03:38:50 | evan | not sure what the default is. |
| 03:39:40 | evan | "Linux on MIPS, SPARC, PA-RISC, POWER, PowerPC, and 680x0" |
| 03:39:43 | evan | is big endian |
| 03:40:11 | slava | do you have a significant PPC user base? I guess you still support 10.4 too right? |
| 03:42:48 | evan | at least little endian is gone |
| 03:42:52 | evan | slava: yep. |
| 03:43:06 | evan | brixen is working on code that requires endian-ness no matter what |
| 03:43:11 | evan | so it's not a case of dropping platforms |
| 03:43:14 | brixen | yeah |
| 03:43:20 | evan | because it's code to convert values between endian-ness. |
| 03:43:42 | brixen | and because someone could choose to encode BE on a LE platform |
| 03:43:56 | brixen | it's just that that whole thing is lame |
| 03:44:07 | evan | er. |
| 03:44:09 | brixen | 50's ok, sure, 2010, effen please |
| 03:44:14 | evan | i meant before, at least middle endian is gone |
| 03:44:20 | brixen | heh, yeah |
| 03:44:22 | brixen | what fun |
| 03:44:25 | slava | oh, I thought you were dealing with JIT issues or something |
| 03:44:27 | evan | which was 2nd 1st 3rd 4th |
| 03:44:30 | evan | er. |
| 03:44:33 | evan | which was 2nd 1st 4th 3rd |
| 03:44:38 | slava | is this for pack? |
| 03:44:48 | brixen | slava: yeah |
| 03:44:50 | evan | i think because it was for PDP-11, which favored 16 bit values |
| 04:20:04 | boyscout | Add step to the debugger; begin unification of interrupt checking - 33892db - Evan Phoenix |
| 04:20:16 | evan | step and nexti have landed. |
| 04:24:10 | brixen | awesome! |
| 04:31:45 | evan | brixen: i've started redoing the flag checking in the prologue using a JVM trick |
| 04:32:04 | evan | basically, since you always have to check the stack for an overflow |
| 04:32:10 | evan | you fake an overflow |
| 04:32:17 | evan | and in the overflow handler code, check flags |
| 04:32:27 | evan | and the overflow handler code can detect a fake overflow |
| 04:34:57 | brixen | ahh interesting |
| 04:42:09 | brixen | well, 'lo and behold, it's working |
| 04:43:13 | evan | you working on N and n? |
| 04:43:15 | brixen | ah, probably lo' and behold, since it was likely 'look and behold' |
| 04:43:23 | brixen | unpack with ints, yeah |
| 04:43:28 | brixen | n, v, S, s |
| 04:44:16 | brixen | me and my macro soup, but I don't really see a plain, simple way to handle this otherwise |
| 04:44:26 | evan | :) |
| 04:44:49 | brixen | I suppose I could break with the all caps convention |
| 04:44:55 | brixen | since that just makes stuff hard to read |
| 04:44:59 | evan | yeah |
| 04:45:06 | evan | maybe use some inline functions instead? |
| 04:45:11 | brixen | the macros themselves are just refactorings |
| 04:45:21 | brixen | probably could |
| 04:45:55 | evan | feels like those macros should be methods on some object |
| 04:46:06 | brixen | hmm |
| 04:46:33 | evan | since they have implied state |
| 04:46:37 | evan | which happens to be locals |
| 04:46:46 | evan | make those locals members of a class |
| 04:46:52 | evan | and stack allocate an instance of the class |
| 04:47:06 | evan | and call methods on that object instead |
| 04:48:02 | brixen | that seems kinda weird |
| 04:48:15 | brixen | since these actions get splatted all over this state machine |
| 04:48:31 | brixen | but once I get the logic working, we can experiment with stuff like that |
| 04:48:38 | evan | your macros on macros on macros are hard to follow |
| 04:48:47 | evan | i'm trying to figure out a way to help with that is all. |
| 04:48:52 | brixen | yeah |
| 04:49:11 | brixen | at the action level, they are pretty simple |
| 04:49:15 | evan | that must be a fucking bear to debug |
| 04:49:23 | brixen | nah, not really |
| 04:49:33 | brixen | at the byte, bit level, they are simple |
| 04:49:35 | evan | would be easier as functions/methods though |
| 04:49:41 | evan | at least you can step into and through them. |
| 04:49:44 | brixen | the complexity is in the middle |
| 04:49:47 | brixen | yeah |
| 04:50:23 | brixen | the loop is general, but it needs specific formatters to handle the data |
| 04:50:36 | brixen | eg, pushing 1, 2, 3, etc bytes onto the string |
| 04:50:45 | brixen | while looping over array elts |
| 04:50:46 | evan | mmhmm |
| 04:50:55 | evan | none of that means it couldn't be a class |
| 04:51:04 | brixen | yeah |
| 04:51:06 | evan | imho |
| 04:51:29 | brixen | this is actually rather easier atm |
| 04:52:01 | evan | i worry it won't be once you're not in it everyday |
| 04:52:02 | evan | is all. |
| 04:52:09 | evan | but it's a minor issue |
| 04:52:09 | brixen | and I have specs and benches, so we can play with it |
| 04:52:15 | evan | because, as you say, the actions are short anyway |
| 04:52:36 | brixen | well, I'm not married to this, it's just pretty easy while working out the machine logic actually |
| 04:54:15 | brixen | the meaning of '*' is so arbitrary |
| 04:54:38 | brixen | sometimes it means "the rest", sometimes 1, sometimes 0 |
| 04:56:13 | evan | yaeh |
| 04:56:24 | evan | it's definitely crazy. |
| 04:59:58 | jakedouglas | is it worse than sax parsing in erlang? |
| 05:00:17 | evan | that doesn't sound fun at all |
| 05:00:28 | evan | parsing text in erlang at all doesn't sound fun |
| 05:00:47 | jakedouglas | yea, it's not, so far. |
| 05:01:11 | jakedouglas | luckily im not doing the parsing. just using the parser. |
| 05:01:21 | evan | oh good. |
| 05:01:22 | brixen | I'm pretty sure tarcieri thinks it's fun... oh wait, nvm |
| 05:03:15 | jakedouglas | :p |
| 05:03:35 | evan | tarcieri has a strange definition of fun, we all know that. |
| 05:03:51 | brixen | yeah, and even with all that fun he's complained a fair bit |
| 05:03:59 | evan | brixen: so, do you think peguras fleshed out enough for me to write a marlowe grammar in? |
| 05:04:09 | evan | pegarus, rather. |
| 05:04:11 | brixen | not yet, but very soon |
| 05:04:15 | evan | k |
| 05:04:29 | brixen | I was hoping you'd be interested in that :) |
| 05:04:43 | brixen | I'll write pegarus so you can write marlowe so I can write poison |
| 05:04:45 | brixen | :) |
| 05:04:59 | evan | treetop is just too darn verbose |
| 05:05:03 | brixen | yep |
| 05:05:19 | evan | and there needs to be a better way to parse a damn list |
| 05:05:21 | brixen | and the semantic action facility is terribly broken atm |
| 05:05:26 | evan | in treetop it requires like 3 or 4 rules |
| 05:05:39 | brixen | hmm |
| 05:07:02 | brixen | evan: so one af the things I was pondering is the form of an emitted parser |
| 05:07:25 | evan | a very good thing to ponder. |
| 05:07:27 | brixen | since this emits compiled methods directly, I could write that to a special .rbc and load it |
| 05:07:38 | evan | sure |
| 05:07:48 | brixen | or emit some ruby code that uses Rubinius.asm to tie into the normal compiler |
| 05:08:02 | brixen | so it gets marshalled along with the normal .rbc from a .rb file |
| 05:08:10 | evan | should there be a mode to emit ruby code directly? |
| 05:08:15 | evan | rather than rbx bytecode? |
| 05:08:23 | brixen | could possibly |
| 05:08:30 | brixen | but that rather defeats the purpose |
| 05:08:46 | evan | not to me |
| 05:08:46 | brixen | since this will liberally use gotos in an execution context (method) |
| 05:08:51 | evan | i want a nice parser framework |
| 05:08:52 | evan | :) |
| 05:08:59 | brixen | right, I want a fast one |
| 05:09:00 | evan | ah ok. |
| 05:09:15 | brixen | the parser is now one method |
| 05:09:16 | evan | sure then |
| 05:09:29 | evan | save the CM to a file and reload it. |
| 05:09:44 | brixen | yeah, seems reasonable enough |
| 05:09:47 | evan | load it, put it into the method table |
| 05:09:48 | evan | done and done. |
| 05:09:50 | brixen | yep |
| 05:09:57 | evan | glad I made all that logic generic |
| 05:10:01 | brixen | indeed |
| 05:10:05 | brixen | did you see what I do now? |
| 05:10:08 | evan | that it's just "serialize an CM!" |
| 05:10:11 | evan | any CM |
| 05:10:11 | evan | rather. |
| 05:10:19 | evan | not yet |
| 05:10:20 | evan | just the slides. |
| 05:10:21 | brixen | def match(s); compile s; end |
| 05:10:41 | brixen | where compile writes the bytecode, installs it as #match, and tail calls to it |
| 05:10:51 | brixen | later calls to #match just hit the compiled code |
| 05:10:56 | evan | mmm |
| 05:10:57 | evan | nice. |
| 05:11:02 | brixen | handy :) |
| 05:11:11 | evan | which, then when it heats up, is JIT'd |
| 05:11:12 | evan | :D |
| 05:11:12 | brixen | no, compile() unless compiled? |
| 05:11:18 | brixen | heh, yeah |
| 05:11:53 | evan | we should consider a ruby output mode too |
| 05:12:00 | evan | so it can be used on MRI |
| 05:12:04 | brixen | sure |
| 05:12:09 | brixen | I was thinking about that |
| 05:12:14 | evan | I want the marlowe parser to be a library |
| 05:12:53 | brixen | well, having the pegarus AST basically emit the parsing machine insns means we can implement the insns for whatever platform |
| 05:13:05 | evan | exactly |
| 05:13:09 | brixen | you just get a stream of [any(), char(), etc] |
| 05:13:11 | evan | i figured it wouldn't be too hard |
| 05:13:14 | brixen | yeah |
| 05:14:46 | brixen | could emit Factor, ya know, to share the syntax wealth :) |
| 05:14:56 | evan | :D |
| 05:51:26 | boyscout | Missed a Node in AST grapher. - d695cfc - Brian Ford |
| 05:51:26 | boyscout | String#unpack benchmarks for integer directives. - 6113d5f - Brian Ford |
| 05:51:26 | boyscout | Added String#unpack specs for Ss. - 27241ba - Brian Ford |
| 05:51:26 | boyscout | Specs for String#unpack vn. - b038265 - Brian Ford |
| 05:51:26 | boyscout | Array#pack Xx@, String#unpack Ssnv. - e682a3b - Brian Ford |
| 06:59:38 | dbussink | brixen: you got some cool benchmarks? :) |
| 07:00:34 | boyscout | Build fixes for #pack. - 74fac8e - Brian Ford |
| 07:00:49 | brixen | dbussink: not quite yet, likely tomorrow :) |
| 07:00:52 | brixen | go back to sleep :D |
| 07:01:36 | dbussink | brixen: hehe, i just got into the office :P |
| 07:01:46 | brixen | take a nap then! |
| 07:04:28 | brixen | dbussink: I still have the string directives to do, but I need more specs first |
| 07:04:40 | brixen | anyway, sleep for me, night! |
| 07:04:41 | dbussink | brixen: ah ok, no rush, just curious :) |
| 07:04:45 | dbussink | brixen: night! |
| 15:12:59 | tarcieri | for the record doing anything with "strings" in Erlang is a total nightmare :) |
| 15:13:44 | sbryant | does OTP help at all? |
| 15:13:48 | tarcieri | uhh, no |
| 15:16:14 | tarcieri | [108,111,108] |
| 15:16:48 | tarcieri | yes it's encrypted in Erlang |
| 15:18:57 | tarcieri | Erlang's if expression is almost completely useless :( |
| 15:36:11 | dwaite | stop encrypting stuff in erlang! |
| 15:37:56 | jakedouglas | ????? |
| 15:44:10 | dwaite | hehe |Blaze|| and tarcieri |
| 15:44:27 | dwaite | were chatting with arrays of numbers |
| 15:46:53 | jakedouglas | ah. yea. |
| 15:50:49 | tarcieri | (lists!) |
| 15:50:58 | jakedouglas | heh |
| 15:51:00 | jakedouglas | DO NOT CONFUSE. |
| 15:51:08 | tarcieri | hehe |
| 15:55:33 | jakedouglas | starting the day with: "Engineering Fine-Grained Parallelism Support for Java 7" by Doug Lea |
| 15:55:38 | jakedouglas | im skared. |
| 15:56:29 | brixen | reading paul tyma's nio vs io slides |
| 15:56:46 | brixen | I think everything tarcieri has been telling us is WRONG! |
| 15:56:50 | brixen | :) |
| 15:57:18 | jakedouglas | hah. |
| 15:57:46 | brixen | also, macpro to have 12 cores? wow |
| 15:58:04 | jakedouglas | yea dude. better get some moar threads in rbx. |
| 15:58:15 | tarcieri | lol |
| 15:58:20 | brixen | heh |
| 15:59:31 | evan | MORE POWER! |
| 15:59:54 | tarcieri | moar cores! |
| 16:00:30 | jakedouglas | does rubinius just have a main thread and a jit thread right now? |
| 16:00:52 | evan | no |
| 16:00:57 | evan | Thread.new creates new native threads |
| 16:01:03 | evan | they're just subject to the GIL |
| 16:01:23 | Eebs | 'scuse me, but I was wondering how this site is run: http://donttreadonme.co.uk/rubinius-irc/index.html |
| 16:01:25 | jakedouglas | i meant, assuming you're just running a single ruby thread. |
| 16:01:28 | evan | the JIT thread runs in true parallel |
| 16:01:43 | brixen | Eebs: danlucraft runs that site |
| 16:01:46 | evan | jakedouglas: there is another, the signal handler thread |
| 16:01:54 | brixen | Eebs: he often hangs out in #jruby |
| 16:01:55 | jakedouglas | i see. |
| 16:01:56 | evan | which assists in making sure signals can be delivered properly. |
| 16:02:08 | evan | when more than 1 ruby thread shows up to the party |
| 16:02:14 | evan | the timer thread is also started |
| 16:02:22 | Eebs | brixen, thanks for the info. I like that system of keeping IRC logs. Do you know if it's available? Or is it something he made. |
| 16:02:37 | brixen | Eebs: I don't really know, sorry |
| 16:02:51 | Eebs | brixen, thanks anyway, I shall go see if I can find Dan. |
| 16:02:54 | Eebs | cheers |
| 16:03:04 | jakedouglas | is there any opportunity for parallelism in the gc? |
| 16:03:27 | evan | not without adding read barriers |
| 16:03:28 | evan | so no. |
| 16:03:44 | jakedouglas | i see. |
| 16:03:56 | evan | though, hotspot doesn't have read barriers and it can do some concurrent GC |
| 16:04:00 | evan | so perhaps |
| 16:05:29 | jakedouglas | what does the hotspot gc do concurrently? |
| 16:05:41 | slava | evan: you can use memory protection to simulate read barriers, with some overhead |
| 16:05:42 | evan | i'd have to look |
| 16:05:44 | evan | i don't know off hand. |
| 16:05:54 | evan | slava: yeah, i really don't want to use that. |
| 16:05:58 | slava | if the situations where they're needed are rare (eg, only during compaction) then its fine |
| 16:06:07 | slava | why? interested in non-MMU platforms down the road? |
| 16:06:19 | slava | they're pretty rare anymore |
| 16:06:36 | evan | the ammount of platform dependent code to handle the fault is pretty crazy. |
| 16:07:04 | evan | additionally, the read barriers i'm thinking of are NOT rare. |
| 16:07:07 | evan | so that wouldn't help |
| 16:07:24 | evan | i was thinking of the white/black/grey marks that the read barriers maintain |
| 16:07:44 | evan | to track chunks of the object graph |
| 16:07:49 | slava | remember you were going to abstract out the factor VM's ucontext stuff at some point? |
| 16:07:56 | slava | that's all you need really |
| 16:08:48 | evan | yeah, i know. |
| 16:09:12 | evan | they're still not rare enough to deal with the fault as often as it would happen |
| 16:09:25 | slava | I don't know anything about concurrent GC, except that its really hard |
| 16:09:35 | evan | yep. |
| 16:09:50 | evan | doing it with white/black/grey would kill performance |
| 16:09:52 | evan | absolutely kill it. |
| 16:10:28 | brixen | but but, it would be so concurrent |
| 16:10:39 | brixen | and concurrent == faaaasta, everyone knows that |
| 16:10:52 | brixen | just like async == faaaaasta :) |
| 16:11:41 | evan | there would be concurrent awesome |
| 16:11:45 | evan | which means it's compounded |
| 16:11:49 | evan | you have to be careful though |
| 16:11:55 | evan | too much awesome and it could explode. |
| 16:12:29 | brixen | heh |
| 16:12:55 | brixen | evan: reading through these slides atm http://twitter.com/mentalguy/status/19646595461 |
| 16:13:28 | evan | ok |
| 16:14:20 | brixen | very interesting slide 27 |
| 16:23:02 | evan | brixen: this is quite interesting. |
| 16:24:24 | brixen | yep |
| 16:25:11 | brixen | I wonder if I got java running on rbx, would cliff click hang out with us... :) |
| 16:25:40 | evan | hehe |
| 16:25:51 | evan | we'll need to remove the GIL first I think :) |
| 16:26:41 | slava | cliff click went to my talk at last year's jvm summit, and then a few weeks ago at pldi littledan was talking to him and cliff click asked him what he worked on and he said 'factor' and he didn't remember what it was nor did he have any recollection of my talk |
| 16:27:17 | slava | that's how cool he is |
| 16:27:27 | brixen | heh |
| 16:27:49 | slava | evan: does your JIT do breakpoints? |
| 16:28:13 | evan | slava: for debugging? |
| 16:28:40 | boyscout | Check the GIL lock also - 071edaa - Evan Phoenix |
| 16:28:40 | boyscout | Use VM::check_interrupts, make sure thread_step_ is initialized - 7fc5dcb - Evan Phoenix |
| 16:28:56 | slava | evan: yes |
| 16:29:01 | evan | no. |
| 16:29:14 | brixen | evan: boyscout was hung last night |
| 16:29:25 | evan | seems to be back now |
| 16:29:28 | evan | it was probably github's queue |
| 16:29:29 | brixen | evan: what about running CI with agent enabled? |
| 16:29:33 | brixen | hmm |
| 16:29:45 | brixen | the process seemed to be running the specs on elle |
| 16:29:58 | evan | oh, do you mean CI? |
| 16:30:02 | evan | CI != boyscout |
| 16:30:03 | brixen | anyway, with the agent we could connect and get a bt |
| 16:30:07 | evan | boyscout is just the reporter. |
| 16:30:08 | brixen | yeah, sorry CI |
| 16:30:21 | brixen | boyscout was silent, so I checked CI |
| 16:30:34 | brixen | it was still working on an earlier commit |
| 16:30:42 | evan | yeah, i see it hung |
| 16:30:43 | evan | just killed it |
| 16:30:47 | brixen | k |
| 16:30:48 | evan | yeah, we should run with the agent on. |
| 16:35:56 | evan | hm, there is an agent bug, seems like all of ci's work confuses something |
| 16:48:34 | boyscout | CI: rubinius: 7cf1601 successful: 3498 files, 14416 examples, 42216 expectations, 0 failures, 0 errors |
| 17:31:18 | boyscout | Disable the agent in forks and cleanup before exec - e27f185 - Evan Phoenix |
| 17:31:18 | boyscout | Add and use --agent to mspec - 3015b80 - Evan Phoenix |
| 17:45:43 | boyscout | CI: rubinius: 3015b80 successful: 3501 files, 14497 examples, 42297 expectations, 0 failures, 0 errors |
| 18:08:01 | brixen | ....F.....EEEEEEEEEE..FF.FF.......F.....EEEEEEEEEE..FF.FF... |
| 18:08:07 | brixen | current unpack with new iI specs |
| 18:08:09 | brixen | weee |
| 18:08:37 | evan | O_O O_O o_O |
| 18:09:07 | sbryant | Your face it has contorted to unusual proportions! |
| 18:09:15 | brixen | hah |
| 19:09:33 | tarcieri | should change E to U for Unhandled Exception :) |
| 19:09:42 | tarcieri | ......................FFFFFFFFFUUUUUUUUUUUUUUUUUUU........ |
| 19:14:00 | brixen | heh |
| 19:14:50 | evan | heheh |
| 19:16:28 | boyscout | Refactor the debugger - d2805f1 - Evan Phoenix |
| 19:25:30 | boyscout | CI: rubinius: d2805f1 successful: 3501 files, 14497 examples, 42297 expectations, 0 failures, 0 errors |
| 19:32:47 | Defiler | so, I think I'm finally coming around to Fibers |
| 19:32:55 | Defiler | partly via this http://blog.envylabs.com/2010/07/no-callbacks-no-threads-ruby-1-9/ |
| 19:33:32 | evan | it's an important part of your diet. |
| 19:33:36 | evan | speaking of diet |
| 19:33:38 | evan | => lunch |
| 19:33:51 | Defiler | @_o lunch |
| 19:45:18 | tarcieri | Defiler: ugh, I really need to write a response to that |
| 19:45:44 | Defiler | What don't you like about it? |
| 19:46:15 | tarcieri | retrofitting a purely async I/O model where anything that does any I/O ever must follow the async/fiber-driven I/O contract means you're severely limited in terms of what libraries you can use |
| 19:46:28 | tarcieri | also: exceptions, how do you handle them? |
| 19:46:33 | tarcieri | they're a nightmare in EventMachine to begin with |
| 19:47:04 | tarcieri | let alone when you try to wrap up |
| 19:47:16 | tarcieri | bleh... wrap up EventMachine in a synchronous API with corountines |
| 19:47:35 | tarcieri | and I haven't seen any hard numbers comparing 1.9 to 1.9+EM+Fibers+Synchrony |
| 19:47:51 | tarcieri | in the presentation Ilya gave at Railsconf he compared Ruby 1.8 to the latter |
| 19:48:01 | tarcieri | and 1.8 can't make multiple simultaneous system calls |
| 19:48:17 | tarcieri | so it's apples to oranges |
| 19:48:46 | tarcieri | I can keep going, heh |
| 19:49:05 | Defiler | Yeah those are good points |
| 19:49:40 | tarcieri | unless they've added it recently, EventMachine has no callback for when it's completed emptying its write buffer, which means if you try to write something that proxies to another service and you read faster than you write, it will just continue buffering the request you proxy into RAM transparently |
| 19:50:18 | dwaite | pfft, producer/consumer model is so overrated |
| 19:50:29 | tarcieri | also, if you just switch to JRuby most of those problems go away, and you scale across multiple cores for "free" |
| 19:50:31 | dwaite | you should always produce, even if it cannot be consumed |
| 19:50:56 | Defiler | Yeah, eventmachine is totally useless for daemons and such |
| 19:50:57 | tarcieri | or rbx if you guys added concurrent multithreading :) |
| 19:51:00 | Defiler | because you can't tell when you are done |
| 19:51:02 | jakedouglas | tarcieri: the proxy functionality in EM allows you to specify a buffer size for the proxy connection. if it becomes full, it'll stop reading from the upstream connection until it drains a bit |
| 19:51:16 | tarcieri | jakedouglas: that's cool, glad they did something about that |
| 19:51:35 | tarcieri | it's still ugly compared to what Rev/Revactor did |
| 19:51:41 | tarcieri | which was to expose a write completion callback |
| 19:51:50 | dwaite | I think Proactor pattern is better, and ACTs are even better than that |
| 19:51:58 | dwaite | so there, phhbbt |
| 19:52:03 | tarcieri | which Revactor wrapped up as a duck type to TCPSocket |
| 19:52:33 | jakedouglas | i did it for github when they tried to use EM as a proxy for git clones of 500GB repositories and their processes were running out of RAM :p |
| 19:52:34 | tarcieri | dwaite: the Erlang "active once" model is by far the best solution I've ever seen to that problem |
| 19:52:54 | dwaite | shame its in erlang then :D |
| 19:53:08 | tarcieri | heh |
| 19:53:11 | tarcieri | yes, shame :( |
| 19:53:18 | jakedouglas | s/GB/MB |
| 19:53:23 | dwaite | has decided its only fair for other people if he makes his prejudices against erlang as obvious as possible |
| 19:53:37 | jakedouglas | tarcieri: hows reia coming |
| 19:53:39 | dwaite | don't threads in the JVM use a meg of memory each |
| 19:53:45 | dwaite | for the local copy collector? |
| 19:53:49 | jakedouglas | ok |
| 19:53:53 | jakedouglas | lets not have this discussion lol |
| 19:53:54 | tarcieri | jakedouglas: was going great... been a bit preoccupied lately |
| 19:54:01 | tarcieri | selling my house, Defcon, Hacker Karaoke, heh |
| 19:54:09 | jakedouglas | heh |
| 19:54:29 | tarcieri | also I've been trying to put together a Reia CouchDB view server |
| 19:55:03 | jakedouglas | i see |
| 19:55:36 | jakedouglas | i thought it was pretty asinine that their original strategy was to pipe data out to other processes and back |
| 19:55:43 | jakedouglas | (no wonder views are slow?...) |
| 19:55:48 | tarcieri | heh |
| 19:56:19 | tarcieri | yeah I haven't delved very deep into it, haven't had time |
| 19:56:35 | tarcieri | seems like a view server running inside the same Erlang VM as CouchDB itself would be the way to go |
| 19:56:41 | tarcieri | I need to better research how Erlang views work |
| 19:56:49 | jakedouglas | right |
| 19:57:10 | jakedouglas | well, i met @drkrab here at jvm summit, im going to corner him and make him explain the erjang details to me so i can start playing with it more. |
| 19:57:11 | tarcieri | I think Damien Katz had some concerns about sandboxing or somthing |
| 19:57:16 | tarcieri | heh |
| 19:57:28 | tarcieri | yeah I've pinged him a bit on the features Erjang is missing which would allow it to run Reia |
| 19:57:36 | jakedouglas | which are what |
| 19:57:47 | dwaite | erjang? |
| 19:57:49 | tarcieri | it's some issues with the code server |
| 19:58:01 | dwaite | ooh |
| 19:58:02 | tarcieri | if you dynamically generate modules it doesn't produce .jar files for them |
| 19:58:06 | dwaite | something I can dislike more than straight erlang :D |
| 19:58:10 | jakedouglas | ah. |
| 19:58:28 | jakedouglas | dwaite: http://www.supercity.at/blog/upload/blog/2010/04/haters1.jpg |
| 19:58:35 | tarcieri | I gave him a minimal example to go off of, he said he could fix it |
| 19:58:48 | jakedouglas | tarcieri: cool. |
| 19:58:52 | tarcieri | jakedouglas: http://github.com/tarcieri/reja |
| 19:59:01 | jakedouglas | nice |
| 19:59:22 | jakedouglas | well, i don't know that much about erlang. learning though |
| 19:59:41 | tarcieri | heh |
| 19:59:43 | jakedouglas | seems like the most simple language i've ever learned |
| 20:00:13 | tarcieri | I take it you never learned Scheme |
| 20:00:17 | jakedouglas | nope. |
| 20:00:25 | tarcieri | Scheme sucks :) |
| 20:00:42 | bougyman | i've always thought lisp syntax was the easiest to parse. |
| 20:00:47 | bougyman | cause, you know, lisp code is data. |
| 20:00:56 | slava | forth is easier :) |
| 20:01:01 | tarcieri | heh |
| 20:01:18 | bougyman | you just have to read scheme/lisp inside out. |
| 20:01:22 | bougyman | instead of outside in. |
| 20:01:43 | tarcieri | I prefer languages that don't make me write everything in raw syntax trees |
| 20:02:10 | dwaite | I think someone should make a full turing-complete language modelled after regexp syntax |
| 20:02:18 | tarcieri | brainfuck? |
| 20:02:18 | tarcieri | heh |
| 20:02:57 | dwaite | nah I think brainf**k went the wrong way there |
| 20:03:10 | dwaite | it must be possible for people to read the syntax, otherwise they will lose interest |
| 20:03:19 | dwaite | model it after regex, and they will eventually lose hope |
| 20:03:36 | tarcieri | not sure how you "model it after regex" other than "make it look like line noise" |
| 20:03:39 | tarcieri | heh |
| 20:03:47 | dwaite | a good start! |
| 20:03:49 | tarcieri | make every operator in the language a single character? |
| 20:04:54 | dwaite | well I'm thinking that in addition to named captures you need emitters |
| 20:05:05 | dwaite | which alter the data being matched |
| 20:06:28 | dwaite | through the ability to match and alter data, I'd hope to minimize the number of extensions needed to make it turing complete |
| 20:11:07 | dwaite | actually I'll have to think about erjang; if the community accepts it, it would significantly lessen my repulsion from the erlang ecosystem |
| 20:11:18 | slava | what is erjang? |
| 20:11:28 | jakedouglas | guess |
| 20:11:30 | dwaite | erlang on the jvm! |
| 20:11:31 | jakedouglas | i bet you'll get it right |
| 20:11:54 | dwaite | oh wait, I mean |
| 20:12:02 | dwaite | deletes that message |
| 20:51:13 | dwaite | gah google talk has been so broken the last week |
| 20:54:48 | Defiler | dwaite: are you using it from a gmail address, or a hosted domain? |
| 20:55:00 | Defiler | because there's an important be-less-busted step for the hosted ones |
| 20:58:40 | evan | should we add something like this to rubinius: http://support.microsoft.com/kb/261186 |
| 20:58:40 | evan | ? |
| 20:59:07 | brixen | um... |
| 20:59:09 | Defiler | The best part is that it even happens in Safe Mode |
| 20:59:18 | evan | yep |
| 21:00:10 | brixen | hah, bottom is the best... "How much effort did you personally put forth to use this article?" |
| 21:01:30 | evan | brixen: i'm reorganizing the instruction encoder |
| 21:01:35 | evan | it's a mess. |
| 21:01:38 | brixen | ok |
| 21:01:57 | brixen | you should make it play Fur Elise first |
| 21:02:03 | brixen | cus nothing says mess like Fur Elise |
| 21:02:07 | evan | midi or mp3? |
| 21:02:13 | evan | i could embed the midi into a .rbc file |
| 21:02:17 | brixen | or "your fan has failed" |
| 21:02:43 | brixen | yes, we need a marshal type for "music" |
| 21:02:45 | brixen | :) |
| 21:03:03 | evan | heh |
| 21:05:07 | boyscout | Remove tags for now stable specs - 5a8a745 - Dirkjan Bussink |
| 21:14:03 | boyscout | CI: rubinius: 5a8a745 successful: 3501 files, 14499 examples, 42300 expectations, 0 failures, 0 errors |
| 21:40:34 | evan | brixen: should I just delete InstructionSequence::Encoder |
| 21:40:37 | evan | we're not using it anymore |
| 21:40:41 | evan | i'm inclined to |
| 21:41:17 | brixen | sure |
| 21:41:27 | brixen | I think I never made it that far on cleanups |
| 21:41:53 | brixen | I know that I wanted to revisit a bunch of CompiledMethod methods |
| 21:42:06 | brixen | after working on the bytecode compiler |
| 21:43:07 | evan | k |
| 21:45:21 | evan | brixen: i'm also removing the argument to 'def encode' in generator.rb |
| 21:45:27 | evan | which was talking ISeq::Encoder |
| 21:45:30 | evan | but ignoring it. |
| 21:45:34 | brixen | k |
| 21:46:09 | evan | we've got generator.rb so pimped out now |
| 21:46:17 | evan | there is no reason to be generating bytecode directly. |
| 21:46:44 | brixen | when I need some bytecode, I just write Ruby :) |
| 21:46:53 | evan | yep |
| 21:48:37 | evan | hm, what should I do with Rubinius::Breakpoint |
| 21:49:25 | brixen | ? |
| 21:49:34 | evan | kernel/delta/breakpoint.rb |
| 21:49:40 | evan | the new debugger doesn't use it at all. |
| 21:49:45 | evan | i'm going to go through it now |
| 21:49:49 | evan | and make a decision |
| 21:50:23 | brixen | I'm all for cleaning everything up as much as possible |
| 21:50:32 | evan | yep |
| 21:50:37 | brixen | git has history should we need to resurrect anything |
| 21:51:25 | evan | hm, i think i'm going to just nuke this. |
| 22:43:30 | boyscout | Minor BreakPoint cleanup - 5146e2a - Evan Phoenix |
| 22:43:30 | boyscout | Cleanup a bunch of ISeq/debugger cruft - 083f794 - Evan Phoenix |
| 22:43:34 | boyscout | CI: Commit 083f794 failed. http://github.com/evanphx/rubinius/commit/083f794e18ccb8f244ccae92f777d9e65bc199ed |
| 22:43:58 | evan | oops. |
| 22:44:25 | boyscout | Add missing file - feb133d - Evan Phoenix |
| 22:54:28 | boyscout | CI: rubinius: feb133d successful: 3495 files, 14496 examples, 42294 expectations, 0 failures, 0 errors |
| 23:24:35 | brixen | ugh! |
| 23:24:54 | brixen | unpack with Q doesn't add nil elements but q does |
| 23:25:25 | brixen | eg "".unpack('Q3') => [] vs [nil, nil, nil] |
| 23:25:35 | brixen | like all of IiNnVv |
| 23:28:13 | goyox86 | brixen loves ragel :] |
| 23:28:44 | brixen | goyox86: it's not ragel, it's MRI |
| 23:30:06 | goyox86 | brixen: you mean the current behaviour of unpack in MRI? |
| 23:30:42 | goyox86 | brixen: is that? *eyeroll* |
| 23:30:54 | brixen | goyox86: and it's because they have no tests |
| 23:31:02 | brixen | here are the MRI 1.8.7 unpack tests: http://gist.github.com/493054 |
| 23:31:11 | brixen | and some of those are not even #unpack directly |
| 23:34:25 | brixen | and... it's fixed in 1.9.2 but who knows when that was |
| 23:35:15 | goyox86 | brixen: :s |
| 23:37:02 | goyox86 | fades |