Show enters and exits. Hide enters and exits.
| 00:00:11 | Defiler | #define GUARD(predicate_expression) if( ! (predicate_expression) ) { FAIL(); } |
| 00:00:15 | dgtized | evan: what does this do: GUARD(HASH_P(msg->recv)); |
| 00:00:28 | dgtized | is it locking the hash? |
| 00:00:31 | Defiler | Just makes sure that the argument is not null/zero |
| 00:00:36 | agardiner | ensures that recv is a hash |
| 00:00:36 | evan | it fails the primitive if the receiver of the primitive isn't a hash. |
| 00:00:40 | dgtized | ok |
| 00:00:50 | evan | dgtized: go look in cpu_primitives.c |
| 00:00:56 | evan | those are all defined in there. |
| 00:01:22 | Defiler | Most of the BLAH_P macros are in oop.h, as well |
| 00:01:28 | dgtized | right, I see that, what I wanted to avoid was just copy pasting what the boilerplate code on the other hash functions was |
| 00:01:33 | Defiler | but they should be clear without looking at the implementation |
| 00:01:57 | dgtized | yes, but the last time I looked at primitives the object argument wasn't coming out of msg->recv |
| 00:02:09 | evan | the argument isn't. |
| 00:02:13 | evan | it's the receiver |
| 00:02:15 | evan | not any arguments. |
| 00:02:24 | evan | the arguments are still on the stack. |
| 00:03:46 | GMFlash leaves the room. | |
| 00:03:46 | GMFlash enters the room. | |
| 00:03:47 | dgtized | ok, well that's not immediatly clear based on it's usage, since hash_get and hash_set use msg->recv in the place of the hash argument to the C function |
| 00:03:52 | evan | right |
| 00:04:02 | evan | because you send those messages to a Hash object. |
| 00:04:09 | evan | thus, the receiver is a hash. |
| 00:04:23 | evan | hash there is the table. |
| 00:04:25 | Defiler | "fail the primitive if the receiver of this message is not a Hash" is the way to read that |
| 00:04:25 | dgtized | I thought the reciever was the specific hash you were using from the stack? |
| 00:04:42 | evan | it is. |
| 00:04:56 | dgtized | so msg->recv is grabbing that from the stack how? |
| 00:05:02 | evan | it's not. |
| 00:05:23 | evan | the receiver had to be removed from the stack to figure out how to dispatch the method |
| 00:05:37 | evan | before, with primitives, the receiver was pushed back on the stack before the primitive was run |
| 00:05:43 | Defiler | The VM has already populated that 'msg' structure for you by the time this code is run |
| 00:05:47 | evan | I elimenated that |
| 00:06:15 | evan | so the primitive get to see a 'struct message' with all the details about sending the message filled in, including the receiver |
| 00:06:28 | dgtized | ok, that's what I didn't follow, I knew there was some magic about the msg structure, where does that occur? |
| 00:06:42 | evan | at the very beginning of the method lookup |
| 00:06:59 | evan | it's filled with initial details in instructions.rb |
| 00:07:05 | evan | and then passed down |
| 00:07:39 | jero5 leaves the room. | |
| 00:08:39 | dgtized | ok, I see it now -- alright, I mean I think I would have been fine by copy pasting, but I wanted to know why I needed those mantra's |
| 00:08:48 | evan | no problem |
| 00:08:57 | evan | that was reworked to streamline method dispatch |
| 00:09:05 | evan | you'll see that we have SendSite objects now |
| 00:09:18 | evan | which can be specialized with different ways of figuring out how to run a method, based on where it's run from. |
| 00:09:30 | dgtized | oh this was to take care of / or something? |
| 00:09:43 | evan | whats / ? |
| 00:09:52 | Defiler | I love it when I update a Linux kernel, and it renames all of my /dev/sd* disks |
| 00:09:54 | dgtized | from mathn or something like that? |
| 00:09:58 | evan | oh |
| 00:09:58 | evan | no |
| 00:10:00 | evan | unrelated. |
| 00:13:51 | dgtized | ok so since rehash modifies the reciever in place |
| 00:13:55 | evan | yep |
| 00:14:02 | dgtized | can I do a RET(msg->recv); ? |
| 00:14:08 | evan | sure |
| 00:16:12 | wmoxam leaves the room. | |
| 00:19:39 | mernen enters the room. | |
| 00:20:20 | dgtized | and we only need to add a primtive to primitives.rb right, it propegates everywhere else automatically? |
| 00:20:30 | agardiner | and primitive_names.rb |
| 00:21:14 | evan | we could actually probably get rid of primitive_names.rb now |
| 00:21:26 | evan | and just use the instance methods list from primitives.rb |
| 00:21:27 | agardiner | that would be neat |
| 00:21:30 | evan | since order doesn't matter anymore |
| 00:27:09 | dgtized | ugh, alright I think I properly implemented rehash, except I don't think it's going to work since the primitive uses the C routines for find and insert, which means it doesn't respect hash/hash_value differences |
| 00:27:30 | evan | sure it will. |
| 00:27:35 | evan | you only need the details in the table to rehash |
| 00:27:41 | evan | hm |
| 00:27:42 | evan | actually.. |
| 00:27:53 | evan | no, thats true. |
| 00:28:00 | dgtized | those are stored in the table, but it doesn't respect them |
| 00:28:01 | evan | you just need to the details already in the table |
| 00:28:02 | agile enters the room. | |
| 00:28:13 | evan | what is those |
| 00:28:33 | dgtized | the keys, and the hash value are stored in each tuple, it's just not doing object equality on the keys right? |
| 00:29:00 | evan | right |
| 00:29:07 | evan | but you don't need to do that to rehash. |
| 00:29:15 | evan | you just need to the hash value to rehash |
| 00:29:18 | evan | and you already have it. |
| 00:29:30 | dgtized | hmm, alright |
| 00:36:03 | boyscout | 1 commit by Mutwin Kraus |
| 00:36:04 | boyscout | * Adding File#truncate improvements from #325 and #326; 1a78da8 |
| 00:39:12 | mutle | i'm going to sleep now, bye |
| 00:41:10 | dgtized | umm whoever just wrote the File#chown spec it doesn't seem to be working on either 1.8 or rubinius |
| 00:42:45 | mutle | dgtized: i wrote it and only tested on os x 10.5 where it worked in both ruby and rubinius. |
| 00:42:46 | dgtized | evan: did that profile of bin/ci require a specific patch or should that work with current HEAD? |
| 00:43:10 | dgtized | mutle: well it doesn't work on linux |
| 00:43:44 | dgtized | mutle: because the operation is not permitted in the first place |
| 00:44:07 | d2dchat leaves the room. | |
| 00:44:36 | dgtized | mutle: you can't do a chown test without sudo on linux, and most people aren't going to have that |
| 00:45:30 | mutle | dgtized: what should i do instead? no specs on linux? |
| 00:46:35 | dgtized | mutle: well you could check to see if you have the permisions to run that spec? |
| 00:47:17 | dgtized | mutle: I'm really curious how it runs on OSX either, if unless you are running as a superuser? |
| 00:47:42 | jeremydurham_ enters the room. | |
| 00:47:44 | kofno leaves the room. | |
| 00:47:48 | mutle | i am an admin, but not root and i have privs to read /etc/group, so it works fine :) |
| 00:48:13 | mutle | but you are right. i will add a check tomorrow |
| 00:49:02 | dgtized | yea, I mean I can run the specs with sudo, and I'm sure it would work, but that doesn't mean it's a good idea |
| 00:49:12 | mutle | but it would be nice to have the ability to run the spec as a privileged user to ensure everythings working. is there any mechanism in rubinius? or just sudo mspec? |
| 00:50:29 | dgtized | mutle: I think sudo mspec is your only option, so presumably the spec should be excluded if the user running it lacks root? |
| 00:50:59 | boyscout | 1 commit by Charles Comstock |
| 00:51:00 | boyscout | * added hash_rehash primitive so that Hash#set_key_cv can call rehash; 2d7162f |
| 00:53:00 | mutle | dgtized: I will do it tomorrow. bye |
| 01:01:58 | meisdave leaves the room. | |
| 01:02:08 | lstoll enters the room. | |
| 01:03:20 | pauldix enters the room. | |
| 01:06:47 | wmoxam enters the room. | |
| 01:10:38 | imajes enters the room. | |
| 01:11:16 | drbrain | how do we want to support OBJ_INFECT() ? |
| 01:11:58 | drbrain | add Object#infect(other), or Kernel#infect(dst, src)? |
| 01:15:46 | drbrain | I'm partial to the former |
| 01:17:16 | dysinger leaves the room. | |
| 01:19:40 | kofno enters the room. | |
| 01:20:56 | dysinger enters the room. | |
| 01:24:18 | evan | drbrain: infect is for taint, yes? |
| 01:24:52 | drbrain | yes for taint |
| 01:25:06 | evan | however |
| 01:25:11 | evan | i don't think we have a scheme yet. |
| 01:26:58 | drbrain | yeah, I'm pretty sure we don't implement $SAFE yet |
| 01:27:06 | evan | we don't. |
| 01:27:25 | drbrain | I don't know if it would be better to have half-assed taint support, or no taint support |
| 01:27:33 | drbrain | no, the latter would be better |
| 01:27:43 | evan | i think so |
| 01:27:46 | evan | i'd rather get stuff solid |
| 01:27:53 | evan | then add taint in after |
| 01:28:46 | femtowin enters the room. | |
| 01:31:56 | dc_ leaves the room. | |
| 01:33:29 | wycats | didn't we give up on taint altogether like a few months ago |
| 01:33:33 | wycats | with a "we're never doing taint" |
| 01:34:04 | evan | no |
| 01:34:11 | evan | we've never said we wont do something |
| 01:34:12 | wycats | we did that for freeze for sure |
| 01:34:21 | wycats | actually, you said we're never doing freeze |
| 01:34:22 | evan | i said we wont do it right now. |
| 01:34:30 | evan | i think i know what i said. |
| 01:34:32 | evan | thanks though. |
| 01:34:33 | wycats | shit |
| 01:34:39 | wycats | backs away slowly |
| 01:34:53 | evan | don't give if you can't take. |
| 01:35:15 | enebo leaves the room. | |
| 01:35:53 | defunkt enters the room. | |
| 01:37:58 | wycats | I can give fine, but it didn't seem productive for me to continue the conversation |
| 01:38:19 | evan | we know you can give |
| 01:38:28 | evan | you just don't seem to be able to take. :) |
| 01:38:41 | drbrain | almost nobody uses #taint or #freeze |
| 01:38:58 | evan | that was our rational for not doing them now |
| 01:39:01 | drbrain | and most of the people using #freeze aren't doing what they think they're doing |
| 01:39:03 | jero5 enters the room. | |
| 01:39:09 | evan | drbrain: very much so. |
| 01:39:34 | wycats | oh snap |
| 01:39:50 | wycats | evan: there was absolutely some discussion about whether we would ever implement freeze |
| 01:39:56 | wycats | it went beyond immediate pragmatics |
| 01:40:06 | evan | that it did |
| 01:40:09 | evan | i recall. |
| 01:40:30 | meisdave enters the room. | |
| 01:40:32 | serialpinguin enters the room. | |
| 01:40:35 | evan | it was that I didn't see a reason to implement it in the near future |
| 01:40:50 | evan | and that since no one uses it correctly, there is good reason to not do it at all |
| 01:40:58 | evan | thats not saying we wont if we find a case. |
| 01:40:59 | serialpinguin leaves the room. | |
| 01:41:04 | wycats | sure |
| 01:41:09 | evan | saying we absolutely wont do something is stupid. |
| 01:41:25 | wycats | no one said, "we're never doing foo" -- what was said was "it seems likely that we won't do foo, since it seems useless" |
| 01:41:29 | wycats | I will accept the distinction |
| 01:41:39 | wycats | apologizes |
| 01:41:43 | evan | :D |
| 01:41:45 | evan | accepted. |
| 01:41:51 | wycats | :) |
| 01:42:08 | lopex leaves the room. | |
| 01:54:04 | twshelton enters the room. | |
| 01:59:21 | agile leaves the room. | |
| 02:00:44 | jbarnette leaves the room. | |
| 02:06:34 | dysinger leaves the room. | |
| 02:10:28 | fork enters the room. | |
| 02:16:26 | ttmrichter enters the room. | |
| 02:16:53 | ataiar enters the room. | |
| 02:23:16 | fork_ leaves the room. | |
| 02:23:55 | VVSiz_ enters the room. | |
| 02:29:16 | brixen | sweet! port of fnmatch just passed all the jruby specs |
| 02:29:22 | brixen | our old fnmatch failed 3 of them |
| 02:29:48 | brixen | actually ruby_test tests in jruby repo |
| 02:29:58 | brixen | I'll try the jruby tests too |
| 02:31:10 | obvio171 enters the room. | |
| 02:31:24 | brixen | agardiner: hey man, thanks for the debugger, sooo useful! |
| 02:35:14 | vintrepid leaves the room. | |
| 02:39:39 | cored leaves the room. | |
| 02:41:20 | VVSiz leaves the room. | |
| 02:43:47 | Norgg leaves the room. | |
| 02:43:47 | tarcieri leaves the room. | |
| 02:43:47 | matthewd leaves the room. | |
| 02:43:47 | tmpk leaves the room. | |
| 02:43:47 | mass_ leaves the room. | |
| 02:43:47 | maharg leaves the room. | |
| 02:43:47 | crayz_ leaves the room. | |
| 02:43:47 | corundum leaves the room. | |
| 02:43:47 | drbrain leaves the room. | |
| 02:43:47 | fearoffish leaves the room. | |
| 02:43:47 | Ingmar leaves the room. | |
| 02:43:48 | benny leaves the room. | |
| 02:43:48 | shingara leaves the room. | |
| 02:43:49 | benny_ enters the room. | |
| 02:43:50 | tmpk enters the room. | |
| 02:43:50 | mass enters the room. | |
| 02:43:52 | Norgg enters the room. | |
| 02:43:55 | tarcieri enters the room. | |
| 02:43:57 | matthewd enters the room. | |
| 02:43:59 | maharg enters the room. | |
| 02:44:01 | Ingmar enters the room. | |
| 02:44:10 | crayz_ enters the room. | |
| 02:44:17 | drbrain enters the room. | |
| 02:44:19 | benburkert leaves the room. | |
| 02:44:30 | fearoffish enters the room. | |
| 02:44:46 | nicksieger leaves the room. | |
| 02:44:48 | shingara enters the room. | |
| 02:45:39 | benburkert enters the room. | |
| 02:47:34 | _maarten_ leaves the room. | |
| 02:47:34 | smartocci leaves the room. | |
| 02:47:34 | cyndis leaves the room. | |
| 02:47:34 | TheVoice leaves the room. | |
| 02:47:34 | Chrononaut leaves the room. | |
| 02:47:34 | zenspider leaves the room. | |
| 02:47:34 | lenbust leaves the room. | |
| 02:47:34 | flori leaves the room. | |
| 02:47:34 | fearoffish leaves the room. | |
| 02:47:34 | maharg leaves the room. | |
| 02:47:34 | richc leaves the room. | |
| 02:47:34 | rudebwoy leaves the room. | |
| 02:47:34 | wifelette leaves the room. | |
| 02:47:34 | geekounet leaves the room. | |
| 02:47:34 | ko1_away leaves the room. | |
| 02:47:34 | halorgium leaves the room. | |
| 02:47:34 | kevinclark leaves the room. | |
| 02:47:34 | VVSiz_ leaves the room. | |
| 02:48:33 | lenbust enters the room. | |
| 02:48:33 | Chrononaut enters the room. | |
| 02:48:33 | zenspider enters the room. | |
| 02:48:33 | TheVoice enters the room. | |
| 02:48:55 | obvio leaves the room. | |
| 02:49:06 | fearoffish enters the room. | |
| 02:49:06 | maharg enters the room. | |
| 02:49:06 | geekounet enters the room. | |
| 02:49:06 | wifelette enters the room. | |
| 02:49:06 | rudebwoy enters the room. | |
| 02:49:06 | richc enters the room. | |
| 02:49:06 | ko1_away enters the room. | |
| 02:49:06 | halorgium enters the room. | |
| 02:49:06 | kevinclark enters the room. | |
| 02:49:51 | nicksieger enters the room. | |
| 02:51:55 | therealadam leaves the room. | |
| 02:52:33 | VVSiz_ enters the room. | |
| 02:52:37 | flori enters the room. | |
| 02:53:32 | benburkert leaves the room. | |
| 02:54:04 | benburkert enters the room. | |
| 02:55:27 | benburkert enters the room. | |
| 02:57:21 | _mutle enters the room. | |
| 03:01:52 | d2dchat enters the room. | |
| 03:05:42 | mutle leaves the room. | |
| 03:11:30 | agile enters the room. | |
| 03:15:38 | agardiner | brixen: great, glad to hear it! |
| 03:16:35 | jero5 leaves the room. | |
| 03:18:46 | lstoll_ enters the room. | |
| 03:19:04 | lstoll leaves the room. | |
| 03:19:28 | pauldix leaves the room. | |
| 03:21:01 | rubyconsumer enters the room. | |
| 03:22:13 | MenTaLguY enters the room. | |
| 03:22:56 | agardiner | evan: i'm not getting as far as you were running the fusion branch |
| 03:23:34 | agardiner | it seems i've got instruction end addresses that are sometimes less than the start addresses!! |
| 03:24:02 | smtlaissezfaire enters the room. | |
| 03:24:10 | agardiner | do i need to compile with some flag? |
| 03:26:55 | wifelette leaves the room. | |
| 03:27:22 | jeremydurham_ enters the room. | |
| 03:29:50 | benburkert_ enters the room. | |
| 03:32:12 | brixen | agardiner: two things on my wish list, but maybe I can get to them: 1) print the current source line for every step, 2) don't raise an exception if a br is already set, just ignore it |
| 03:32:17 | kamal_fariz | what's the fusion branch? |
| 03:32:22 | brixen | agardiner: of course, 3) step into :) |
| 03:32:33 | brixen | kamal_fariz: an experiment evan start with macro ops |
| 03:32:35 | agardiner | brixen: i'm nearly there with 2) and 3) |
| 03:32:43 | agardiner | and 1) is easy enough to add |
| 03:32:59 | brixen | kamal_fariz: think, taking several ops and squishing all their machine code into one chunk, then caching and running that |
| 03:33:05 | brixen | if I'm not mistaken |
| 03:33:21 | brixen | agardiner: awesome! |
| 03:33:21 | brixen | you da man |
| 03:33:42 | brixen | agardiner: 1 is really nice for orienting yourself while debugging |
| 03:33:46 | brixen | I kept hitting l |
| 03:33:50 | kamal_fariz | sounds cool |
| 03:33:51 | agardiner | yeah, definitely |
| 03:34:12 | kamal_fariz | autolist and autowatch |
| 03:34:12 | brixen | agardiner: it was sooo nice to be able to change values and continue stepping |
| 03:34:21 | brixen | kamal_fariz: yeah, those too |
| 03:34:59 | brixen | the post incr operator in C/C++, Java takes some care in translating to ruby |
| 03:35:12 | agardiner | hehe, changing values and continuing sure is great, but i can't take much credit - it's all possible thanks to eval! |
| 03:35:13 | brixen | the debugger really made finding that oversight easy |
| 03:35:19 | kamal_fariz | and can you set breakpoints given a Class#method, or file:line_no |
| 03:35:39 | agardiner | kamal_fariz: Class#method yes |
| 03:35:51 | agardiner | file:line_no is quite a bit trickier |
| 03:35:59 | agardiner | but something i plan to add |
| 03:36:01 | kamal_fariz | agardiner: sweet .. conditional breakpoints? |
| 03:36:13 | agardiner | yep, shouldn't be hard and its on the list |
| 03:36:23 | agardiner | you can kind of do them now |
| 03:36:33 | agardiner | just do breakpoint if <condition> |
| 03:38:33 | tongueroo leaves the room. | |
| 03:38:36 | ezmobius leaves the room. | |
| 03:38:59 | Yurik leaves the room. | |
| 03:43:11 | brixen | ok, we're not at mri yet, but the glob code can use some opts: http://pastie.org/151130 |
| 03:43:47 | drbrain | yay! |
| 03:44:17 | agardiner | wow, i think that's the nearest we've been! nice one! |
| 03:45:39 | brixen | well, all I did was suffer with some java code for a few hours |
| 03:45:45 | brixen | imagine what those guys went through :P |
| 03:46:03 | benburkert leaves the room. | |
| 03:47:10 | agardiner | shudders |
| 03:49:01 | benburkert_ leaves the room. | |
| 03:49:18 | brixen | can't wait for rue to check in the sort fixes |
| 03:49:39 | boyscout | 1 commit by Brian Ford |
| 03:49:40 | boyscout | * Port of JRuby's File.fnmatch to Ruby (yeah, like writing Java in Ruby).; 1804fda |
| 03:53:51 | vintrepid enters the room. | |
| 03:57:40 | smtlaissezfaire leaves the room. | |
| 04:01:38 | benburkert enters the room. | |
| 04:02:57 | tmpk | agardiner: try compiling it with optimizations off? |
| 04:03:21 | agardiner | -O0? |
| 04:03:22 | pergesu enters the room. | |
| 04:03:25 | tmpk | Yeah. |
| 04:03:41 | agardiner | k |
| 04:07:31 | tmpk | Today we had some strange fun at work where MRIs threads were doing something strange. |
| 04:07:57 | tmpk | So now we have this big THREADS VERBOTEN sign. gg |
| 04:10:54 | tarcieri | good attitude |
| 04:10:58 | tarcieri | threads suck |
| 04:13:22 | tmpk | Well, what it pounded home for me is how shitty the tools are to debug multi-process and multi-threaded apps. |
| 04:14:21 | MenTaLguY | most often if you're debugging concurrency, you've already lost |
| 04:14:35 | MenTaLguY | although some environments like the JVM do have some pretty advanced debugging tools that are useful |
| 04:14:54 | tmpk | Oh, I agree. It's just that MRI is unusually opaque. |
| 04:15:17 | tarcieri | prefers pro-active debugging |
| 04:15:39 | tarcieri | Actors are relatively easy to unit test :) |
| 04:15:50 | tarcieri | At least compared to threads |
| 04:16:35 | MenTaLguY | up to a point |
| 04:16:52 | MenTaLguY | tools like message logging become necessary when you're debugging complex arrangements of actors though |
| 04:17:06 | tarcieri | yeah, I really need a central logger in Revactor :/ |
| 04:17:07 | MenTaLguY | at least actors provide nice choke points to do that at |
| 04:18:11 | tarcieri | I'm trying to decide if I really want to make it yield whenever a message is sent |
| 04:18:24 | tarcieri | There's about one reason to do that: it makes what's going on more intuitive from irb :/ |
| 04:19:48 | MenTaLguY | if it does there, it might also in other contexts |
| 04:20:17 | tarcieri | I really like the idea that the only "blocking" call is receive |
| 04:21:55 | tmpk | Actors in Ruby? |
| 04:22:21 | tarcieri | Actors in general... receive is the only call that throws the current Actor into a sleep state |
| 04:22:34 | tarcieri | The same could be said for processes in a microkernel architecture |
| 04:22:49 | tarcieri | Well, one like Amiga... or DragonflyBSD |
| 04:23:00 | tmpk | Oh, I've puttered around a bit with Erlang and MRI, so I have a general idea. |
| 04:23:06 | tarcieri | Where the only blocking system call gets the next message from the process's message queue |
| 04:23:12 | tmpk | But Revactor is in Ruby? |
| 04:23:16 | tarcieri | Yes |
| 04:23:32 | tarcieri | It uses Fibers for concurrency |
| 04:24:01 | tarcieri | Which seems to confuse people who try it out |
| 04:24:27 | tmpk | Fibers are coroutines? |
| 04:24:32 | tarcieri | I guess I need to explain it better on the web site |
| 04:24:33 | tarcieri | Yeah |
| 04:25:05 | tmpk | I was going to ask why, but I think I get it. |
| 04:25:12 | tmpk | How's that working out? |
| 04:25:38 | tarcieri | The main thing I'm using it for right now is a web spider program, and it's working out great for that |
| 04:26:04 | tmpk | Tell me a bit about the spider? |
| 04:26:06 | tarcieri | I'm getting 250 documents per second sustained, and that's with a single-threaded program |
| 04:27:01 | tarcieri | It's a web spider... it crawls links on web pages |
| 04:27:23 | tarcieri | Right now making 128 concurrent requests |
| 04:27:49 | tmpk | Do the coroutines yield if you make a blocking call? |
| 04:27:55 | tarcieri | Yep |
| 04:28:04 | MenTaLguY | they do? |
| 04:28:18 | tarcieri | As long as it's through the Actor API |
| 04:28:23 | MenTaLguY | well, a socket blocking call using a Revactor socket, I guess? |
| 04:28:28 | tarcieri | Yes |
| 04:29:05 | tarcieri | trunk has an HTTP client which runs on the Actor API |
| 04:29:25 | tmpk | "for building Erlang-like services on top of Actors" <- does this include remote nodes yet? |
| 04:29:29 | tarcieri | response = Revactor::HttpClient.get("http://www.google.com") |
| 04:29:38 | tarcieri | No, but I really, really need to get to that |
| 04:29:42 | tarcieri | Like this weekend probably |
| 04:29:47 | MenTaLguY | it might not really need to be part of Revactor itself |
| 04:30:01 | tarcieri | I'd like to spread my spider application across multiple systems at our colo |
| 04:30:06 | MenTaLguY | since it can all duck-type, remote actors might be better as a distinct library |
| 04:30:52 | tarcieri | MenTaLguY: well, other Actor implementations may allow for pre-emption, in which case all Actor::TCP gets them is asynchronous reception (i.e. active mode) |
| 04:31:23 | tarcieri | But still, that's enough to necessitate an Actor::TCP API, imo |
| 04:31:31 | MenTaLguY | I'm not sure I follow |
| 04:31:49 | tarcieri | In active mode incoming TCP data is delivered as a message |
| 04:32:15 | tarcieri | Rather than through an imperative #read call |
| 04:32:26 | tarcieri | that lets you multiplex incoming messages and incoming TCP data |
| 04:32:45 | tmpk | Let me know how things go with that. I'm particularly curious in how process linking might be implemented if you get around to it. |
| 04:32:53 | MenTaLguY | you mean as a ground to implement a dispatcher for incoming remote messages? |
| 04:32:55 | tarcieri | And Revactor::TCP supports active once semantics too |
| 04:33:09 | tarcieri | Yeah, but one which can get events from other Actors at the same time |
| 04:33:25 | tarcieri | tmpk: It's already implemented |
| 04:33:30 | MenTaLguY | you shouldn't need to do anything special for that |
| 04:33:32 | MenTaLguY | at all |
| 04:33:39 | tmpk | Nice. |
| 04:33:57 | tarcieri | tmpk: Each Actor has a system events queue... when it gets an exception in that queue, it raises it unless it's trapping exceptions |
| 04:33:58 | MenTaLguY | the remote messages should get submitted to the destination actor using << on the receiving end, and it should interleave nicely with whatever else that actor is doing |
| 04:34:02 | tarcieri | Err, trapping exits |
| 04:34:13 | tarcieri | MenTaLguY: that's what happens... in active mode |
| 04:34:37 | MenTaLguY | I just don't see why Revactor needs to have remote actors built in |
| 04:34:45 | MenTaLguY | I think it'd be creating an unnecessary dependency |
| 04:35:01 | tarcieri | MenTaLguY: ohhhh, my bad |
| 04:35:13 | tarcieri | I'm just talking about why Revactor needs Actor::TCP built-in |
| 04:35:35 | tarcieri | And why an Actor API for Ruby needs TCP support in general... |
| 04:35:44 | MenTaLguY | what about IO generally? |
| 04:35:57 | tarcieri | It's hard to generalize IO |
| 04:36:09 | tarcieri | Sockets and files need different semantics |
| 04:36:48 | tarcieri | For operations on files to be sane you really need to include an offset with each read/write |
| 04:37:00 | tarcieri | Since other Actors may be operating on other parts of the file |
| 04:37:14 | tarcieri | And obviously that doesn't apply to streaming I/O like TCP sockets |
| 04:38:04 | MenTaLguY | don't you really need separate file handles if you're going to have multiple users of a file in the same process? |
| 04:38:26 | tarcieri | Not with coroutines |
| 04:38:42 | tarcieri | But with threads... yeah |
| 04:38:55 | MenTaLguY | I don't see that coroutines are any different than threads in that regard |
| 04:38:58 | tmpk | Oh, I've puttered around a bit with... MRI <- whoops, meant MPI |
| 04:39:09 | tmpk | Anyway, good evening. |
| 04:39:18 | tarcieri | MenTaLguY: With Revactor and corouttines you really need some sort of round-robin I/O queue |
| 04:39:35 | tarcieri | MenTaLguY: Since any reads/writes to the file will be asynchronous |
| 04:40:26 | MenTaLguY | I still don't see that it's any different than threads |
| 04:40:37 | tarcieri | One Actor may be doing a gigantic write/read, and unless you have a round-robin I/O queue it will monopolize access to the file |
| 04:40:44 | MenTaLguY | if you've got a bunch of clients thrashing one file descriptor then you're just subverting the OS's IO scheduling and buffering |
| 04:41:09 | tarcieri | MenTaLguY: The whole I/O subsystem of Revactor is driven by asynchronous events |
| 04:41:23 | MenTaLguY | I realize that |
| 04:41:25 | tarcieri | MenTaLguY: But they're not actually doing any reading or writing to the file descriptor directly |
| 04:41:41 | tarcieri | They're telling the I/O subsystem to do that for them |
| 04:41:46 | MenTaLguY | sure |
| 04:42:06 | tarcieri | So there's no reason for the I/O subsystem to have more than one open handle per file... |
| 04:42:10 | MenTaLguY | but you don't want several different actors keeping their own offsets into the same stream |
| 04:42:12 | MenTaLguY | yes there is |
| 04:42:23 | MenTaLguY | you subvert the OS's IO scheduler and buffering |
| 04:42:26 | tarcieri | It sets up some I/O operation, and then uses libev to monitor when that operation completes |
| 04:42:44 | tarcieri | I suppose so... you could multiplex I/O operations with multiple handles per file |
| 04:42:47 | tarcieri | I guess that'd be easier |
| 04:42:51 | hiredman enters the room. | |
| 04:42:54 | tarcieri | But also prone to races... |
| 04:43:23 | MenTaLguY | if races are a concern you need to coordinate through a single actor for that file's IO |
| 04:43:26 | tarcieri | Hard to say how I feel about that one... |
| 04:43:36 | tarcieri | Well, that's what I was saying re: the I/O subsystem |
| 04:43:45 | tarcieri | It can do that coordination |
| 04:44:05 | femtowin enters the room. | |
| 04:44:32 | MenTaLguY | usually races aren't going to be a concern though |
| 04:45:02 | MenTaLguY | unless you're doing very unusual things with files |
| 04:45:04 | tarcieri | yeah, just having redundant file discriptors is probably better from a performance perspective |
| 04:45:26 | tarcieri | I really need multiple inheritence :/ |
| 04:45:38 | MenTaLguY | why? |
| 04:45:52 | tarcieri | All the Revactor I/O stuff is subclassed from Rev |
| 04:46:08 | tarcieri | And pretty much everything in Rev is subclassed from Rev::Watcher, an abstract base class |
| 04:46:20 | MenTaLguY | does Rev::Watcher define any class methods? |
| 04:46:31 | MenTaLguY | if not just make it a module |
| 04:46:35 | tarcieri | I need something which inherits from both Rev::Watcher and something that wraps up all the Actor IO stuff |
| 04:47:03 | tarcieri | It'd be easier to make the Actor IO stuff a module |
| 04:47:13 | femtowin enters the room. | |
| 04:47:18 | MenTaLguY | Rev::Watcher has a specific object representation you rely on then? |
| 04:47:23 | tarcieri | *everything* is subclassed from Rev::Watcher |
| 04:47:29 | tarcieri | Yeah, and core behavior... in C |
| 04:47:47 | femtowin enters the room. | |
| 04:47:50 | MenTaLguY | fair enough |
| 04:47:58 | MenTaLguY | have you considered a to_io-like approach? |
| 04:48:00 | tarcieri | All of the housekeeping in C for watcher management is implemented in the attach/detach/enable/disable methods of Rev::Watcher |
| 04:48:08 | MenTaLguY | so that everything doesn't have to _be_ a Rev::Watcher, just have one |
| 04:49:10 | tarcieri | Heh, it's kind of hard to describe the reasoning for it, but it all centers around atttach/detach/enable/disable |
| 04:49:30 | tarcieri | At various levels of the system certain things do funky modifications to those |
| 04:49:43 | tarcieri | So it's really damn nice when those modifications can easily be wrapped up with super |
| 04:50:10 | MenTaLguY | hm |
| 04:50:53 | tarcieri | To be fair, some of it is nasty because of it all being a gigant subclass hierarchy |
| 04:50:57 | tarcieri | s/gigant/giant/ |
| 04:50:58 | tarcieri | urgh |
| 04:51:06 | tarcieri | Particuarly initialization |
| 04:51:18 | MenTaLguY | often that's a sign that inheritance may be being misused |
| 04:51:30 | MenTaLguY | a really deep hierarchy |
| 04:51:47 | tarcieri | I almost need a TCP socket "factory" that handles DNS lookups :( |
| 04:52:08 | MenTaLguY | that sounds like a good idea to me |
| 04:52:29 | drbrain | resolv.rb has been good to me |
| 04:52:41 | tarcieri | I need asynchronous DNS resolution |
| 04:52:50 | femtowin enters the room. | |
| 04:52:58 | drbrain | yeah, I used resolv.rb for that |
| 04:53:07 | tarcieri | Hmm |
| 04:53:11 | drbrain | I think I had ~ 100 threads resolving DNS |
| 04:53:26 | tarcieri | Does it hand you a socket and go "wait until this is readable"? |
| 04:53:45 | tarcieri | That's what I need |
| 04:53:59 | drbrain | no, resolv.rb just handles DNS lookup |
| 04:54:09 | tarcieri | In addition to timeouts... |
| 04:54:24 | tarcieri | I need DNS lookup that doesn't block... ever |
| 04:54:26 | drbrain | there's also resolv-replace.rb that replaces IPSocket.getaddress and so-on |
| 04:54:31 | tarcieri | So I ended up writing it myself :/ |
| 04:54:39 | drbrain | so you don't block waiting on libc |
| 04:54:55 | tarcieri | It's not blocking waiting on libc, it's blocking on Socket#recvfrom |
| 04:56:15 | tarcieri | My client sends the DNS request, starts a timeout... then I monitor the socket it opened for readability |
| 04:56:37 | tarcieri | When it's readable, I Socket#recvfrom_nonblock to get the response |
| 04:58:02 | tarcieri | My general experience has been that not a lot of stuff is designed to operate that way |
| 04:58:13 | tarcieri | I had to add 4 methods to OpenSSL::SSL::SSLSocket... in C |
| 04:59:01 | cyndis enters the room. | |
| 05:01:50 | MenTaLguY | spawning threads to get "asynchronous" IO operations is terribly expensive on MRI too |
| 05:02:00 | MenTaLguY | real asynchronous is going to really win heavily |
| 05:02:08 | MenTaLguY | s/MRI/1.9/ |
| 05:02:48 | tarcieri | Yeah, it's just... harder |
| 05:03:15 | tarcieri | The only use I see for threads are things which eat up a lot of time but don't ever sleep the thread |
| 05:03:20 | tarcieri | With Revactor anyway |
| 05:03:28 | tarcieri | That's the kind of stuff you really need pre-emption for |
| 05:03:35 | MenTaLguY | totally |
| 05:03:48 | tarcieri | And Erlang has it built-in, but gets rid of the headaches of pre-emption with a shared-nothing system |
| 05:03:56 | tarcieri | Can't really do that in Ruby :/ |
| 05:03:58 | dbussink enters the room. | |
| 05:04:14 | MenTaLguY | sure you _can_, it's just no better than threads at that point |
| 05:04:22 | tarcieri | Yeah, exactly |
| 05:04:49 | MenTaLguY | well, threaded actors are still probably better than raw threads |
| 05:05:12 | MenTaLguY | if you voluntarily restrict their communication to message-passing |
| 05:05:33 | MenTaLguY | that's one reason why I've been interested in the actor object protocol, beyond just remote actors |
| 05:05:41 | tarcieri | Yeah, you can keep all the heavy I/O stuff in a single thread, and just use other threads for compute-heavy tasks that get pre-empted when I/O events occur |
| 05:05:53 | MenTaLguY | I think it'd be nice to be able to treat a spawned thread as just another actor from the Revactor side of things |
| 05:06:22 | tarcieri | It's supposed to be that way now! |
| 05:06:24 | tarcieri | Just... buggy |
| 05:06:27 | tarcieri | Heh |
| 05:06:34 | tarcieri | I'll get it fixed before anothe release |
| 05:06:45 | MenTaLguY | well, that's true |
| 05:07:01 | tarcieri | But now every thread has an Actor scheduler, and each Actor scheduler has an associated Rev::AsyncWatcher |
| 05:07:03 | MenTaLguY | I'm sorry I haven't had more time to poke at the thread-safety stuff |
| 05:07:19 | tarcieri | Those let threads wake each other up |
| 05:08:14 | tarcieri | So if you try to send a message to an Actor in a different thread, it adds it to that thread's (mutex-locked) scheduler queue, then wakes up the thread and lets it know there's no events in its queue |
| 05:08:35 | tarcieri | When the scheduler gets an async event, it runs through its queue and adds the messages to the mailboxes of its actors |
| 05:08:50 | tarcieri | But uhh, yeah, buggy... |
| 05:08:57 | tarcieri | I really need to write a spec for it :) |
| 05:09:40 | tarcieri | It's in the trunk of Rev/Revactor if you want to check it out |
| 05:11:17 | jeremydurham_ leaves the room. | |
| 05:13:06 | tarcieri | MenTaLguY: I'm probably going to do the Revactor remote actor stuff in Revactor to start with... |
| 05:13:23 | tarcieri | It will depend on Actor::TCP, particularly active mode with active once operation |
| 05:13:41 | tarcieri | I mean, the protocol is just going to be asynchronous Marshal, with {packet, 4} framing in Erlang terms |
| 05:14:15 | MenTaLguY | nods |
| 05:15:28 | tarcieri | So I could release it as a gem, but it would depend on Actor::TCP |
| 05:15:54 | wifelette enters the room. | |
| 05:16:58 | MenTaLguY | I think it makes the most sense as its own gem |
| 05:17:02 | MenTaLguY | even with the dependency |
| 05:19:52 | evan | it's the actors! |
| 05:19:58 | twshelton leaves the room. | |
| 05:20:12 | MenTaLguY | Alas, poor Yorick. I knew him, Horatio. |
| 05:21:19 | evan | heh |
| 05:22:03 | dewd leaves the room. | |
| 05:22:30 | evan | gives up on scrolling back to see the conversation |
| 05:23:15 | jeremydurham_ enters the room. | |
| 05:23:28 | evan | you know |
| 05:23:50 | evan | a very interesting program would be one that attempts to figure out when a conversation starts and stops on IRC |
| 05:24:53 | brixen | and pulls out interleaved ones, so you can conversations.each { read } |
| 05:25:03 | evan | heh |
| 05:25:14 | evan | i mean so that a web-base IRC logger to show you conversations |
| 05:25:25 | brixen | yeah, that would be cool |
| 05:25:34 | evan | it could try and show you a sampling of the conversation as the 'topics' |
| 05:29:00 | _ADS enters the room. | |
| 05:30:07 | _ADS leaves the room. | |
| 05:30:53 | femtowin enters the room. | |
| 05:34:08 | rue | Good morning, gentlemen |
| 05:35:04 | rue | evan: I am going to see if I can switch the Array backend this weekend |
| 05:35:19 | evan | switch to what? |
| 05:35:23 | evan | quantum blocks? |
| 05:35:27 | rue | I was looking at it, there are lots of minor optimizations but I think a better backend would work |
| 05:35:38 | evan | cosmic stitches? |
| 05:35:53 | evan | universal containers? |
| 05:36:06 | rue | I was thinking VList-based |
| 05:36:26 | evan | whats VList? |
| 05:36:28 | rue | I will see if there are any other exciting algos out there |
| 05:36:43 | evan | there was talk about having it be block based |
| 05:36:52 | rue | Yeah, this is a variant |
| 05:36:54 | rue | http://en.wikipedia.org/wiki/VList |
| 05:37:02 | evan | allocating a tuple of fixed size each time more storage is needed |
| 05:37:11 | evan | and mapping the index to a [block, slot] pair |
| 05:37:20 | rue | My experience has been it is a bit better than a 2^k scheme |
| 05:38:22 | evan | says that VLists are immutable |
| 05:39:19 | Defiler | We can make it sector-based and then build an Array defragger |
| 05:39:20 | rue | Not necessarily, but the array variant is not |
| 05:39:39 | evan | Defiler: lets license the windowsn 95 defragger |
| 05:39:43 | evan | oh actually |
| 05:39:44 | evan | the DOS one |
| 05:39:47 | evan | just for the graphics |
| 05:39:57 | Defiler | Norton speeddisk |
| 05:40:15 | evan | when someone does |
| 05:40:21 | evan | ary[400] |
| 05:40:33 | evan | I want a window to pop up that shows the array being defragged |
| 05:40:38 | evan | so the 400th element can be returned |
| 05:41:48 | RyanTM leaves the room. | |
| 05:42:55 | femtowin enters the room. | |
| 05:45:55 | srbaker enters the room. | |
| 05:48:02 | Ingmar leaves the room. | |
| 05:48:24 | benburkert leaves the room. | |
| 05:48:35 | ragge enters the room. | |
| 05:49:26 | be9 enters the room. | |
| 05:49:36 | benburkert enters the room. | |
| 05:49:49 | evan | rue: go for it. |
| 05:50:12 | evan | rue: it might be useful to write it up as a new class first |
| 05:50:17 | benburkert leaves the room. | |
| 05:50:21 | evan | RArray, perhaps |
| 05:50:32 | benburkert enters the room. | |
| 05:50:35 | evan | then we can port just the parts we need back into C for the VM to use |
| 05:50:46 | MenTaLguY | that sounds like a good idea to me |
| 05:51:10 | evan | sorta like what I began with Moment |
| 05:52:02 | femtowin leaves the room. | |
| 05:53:14 | srbaker leaves the room. | |
| 05:53:39 | rue | evan: Yeah, ideally we could just implement it relying on Tuple only |
| 05:53:46 | Ingmar enters the room. | |
| 05:54:40 | rue | But it may or may not be possible. Depending on what the perf looks like, I was actually thinking kind of a Strategy using modules if Array extras just rely on #at() etc. That may or may not be feasible |
| 05:54:53 | rue | adds one more "may or may not" for good measure |
| 05:56:28 | srbaker enters the room. | |
| 05:56:46 | femtowin enters the room. | |
| 05:57:44 | evan | hehe |
| 05:58:01 | kofno leaves the room. | |
| 06:01:35 | dbussink leaves the room. | |
| 06:01:54 | tmpk | MenTaLguY: "actor object protocol"? |
| 06:02:29 | MenTaLguY | yeah, protocol in the Smalltalk sense |
| 06:02:36 | MenTaLguY | a set of standard methods an object implements |
| 06:02:49 | dbussink enters the room. | |
| 06:02:53 | MenTaLguY | objects implementing the same protocol are interchangable from a duck-typing standpoint |
| 06:03:59 | agardiner | evan: i'm looking at cpu_compile_method... we allocate space there for the old inline cache, but i'm figuring we don't need that whole field any more, correct? |
| 06:04:04 | tmpk | Gotcha, thanks. |
| 06:04:25 | evan | agardiner: this is in fusion? |
| 06:04:37 | agardiner | nah, i've left that for the moment |
| 06:04:52 | agardiner | trying to get my new step code working |
| 06:05:20 | agardiner | looks like context#set_iseq is broken, which led me to cpu_compile_method |
| 06:05:48 | femtowin enters the room. | |
| 06:06:47 | evan | agardiner: oh, yeah. |
| 06:06:51 | evan | that code should be deleted |
| 06:06:56 | agardiner | ok will do |
| 06:07:04 | agardiner | also, it seems we might be allocating too much space for the compiled filed... |
| 06:07:31 | evan | more than it needs then? |
| 06:07:51 | agardiner | shouldn't line 420 include a / 4 on the end? |
| 06:08:22 | agardiner | seems to be 4* too much |
| 06:10:06 | agardiner | e.g. if the raw bytecode is 20 bytes, we're allocating 20 if not direct-threaded, but 80 if DT is true on 32-bit and 160 on 64-bit |
| 06:10:23 | agardiner | shouldn't it be 20 on 32-bit and 40 on 64-bit? |
| 06:11:27 | evan | hm |
| 06:11:48 | evan | why did i do that... |
| 06:11:50 | evan | oh |
| 06:11:51 | evan | yeah |
| 06:11:53 | evan | it was for 64 bit |
| 06:11:57 | evan | so that should be |
| 06:12:14 | evan | (BYTEARRAY_SIZE(bc) / sizeof(uint32_t)) * sizeof(uintptr_t) |
| 06:12:45 | agardiner | yeah, i guess that's better than " / 4"... :-D |
| 06:12:48 | evan | so on 32bit it comes out the be the same |
| 06:12:53 | evan | and on 64bit, it's 2x |
| 06:12:53 | agardiner | yeah |
| 06:13:13 | evan | so, something we should look into to also |
| 06:13:30 | evan | when doing the fusion code, i noticed that even short methods had like 20 noops on the end |
| 06:13:45 | agardiner | this is probably why |
| 06:13:55 | evan | well |
| 06:13:56 | evan | i doubt it |
| 06:14:03 | evan | because i was looking at the bytecodes |
| 06:14:07 | evan | not a converted version |
| 06:14:10 | agardiner | oh, ok |
| 06:14:20 | evan | i think we're just not clamping the size in the compiler |
| 06:14:45 | agardiner | 20 seems like an odd numbe |
| 06:14:57 | agardiner | bytearray is allocated in 8-byte chunks, no? |
| 06:15:15 | agardiner | so how do we end up with 20 bytes on the end? |
| 06:16:27 | evan | it probably wasn't exactly 20 |
| 06:16:31 | evan | it was just a lot. |
| 06:16:31 | agardiner | speaking of weird results with fusion, i noticed that the code length for no-op was 33 bytes, but for e.g. push_literal it was 27! how does that work?!? |
| 06:16:42 | evan | oh |
| 06:16:49 | evan | thats the wierdness. |
| 06:17:08 | evan | you'll notice that the noop bytecode is actually the code for NEXT_OP |
| 06:17:12 | evan | i reused it |
| 06:17:15 | evan | it's the code that doesn't work. |
| 06:17:35 | agardiner | yeah, i noticed that, but isn't NEXT_OP part of the code for every op? |
| 06:17:41 | agardiner | oh, wait! |
| 06:17:47 | agardiner | der, no how could it be! |
| 06:17:50 | agardiner | :-S |
| 06:18:00 | evan | heh |
| 06:18:01 | evan | yeah |
| 06:18:01 | agardiner | wouldn't be able to fuse them if it was! |
| 06:18:04 | evan | exactly |
| 06:18:13 | agardiner | feels stoopid |
| 06:18:13 | evan | the ending label is after the code, before the NEXT_OP |
| 06:18:15 | evan | :D |
| 06:18:25 | evan | to see the brokeness |
| 06:18:28 | evan | set a breakpoint on cpu_run |
| 06:18:35 | evan | and continue through the first |
| 06:18:36 | evan | then do |
| 06:18:49 | evan | disassemble ins_info[0].start ins_info[0].start + 50 |
| 06:19:04 | evan | thats the code for 'goto **ip_ptr++' |
| 06:19:18 | evan | but for some reason, it's putting a jump in BEFORE the jump to the register |
| 06:19:35 | agardiner | lemme switch back to that and try it... |
| 06:20:04 | rue | Hrm, the median threshold is really tricky |
| 06:22:38 | evan | ok, time to watch project runway |
| 06:22:39 | evan | bbiab. |
| 06:23:20 | rue | Heh |
| 06:24:42 | dbussink leaves the room. | |
| 06:30:22 | tmpk | agardiner: could you put a pastie up of the asm generated if you're working on that? |
| 06:30:50 | tmpk | I'm curious what GCC is actually spitting out. |
| 06:34:33 | agardiner | pastie for tmpk |
| 06:34:48 | agardiner | hmm... no pastie |
| 06:35:29 | agardiner | tmpk: here you go http://pastie.org/152002 |
| 06:35:37 | Yurik enters the room. | |
| 06:37:30 | agardiner | weird... |
| 06:38:22 | agardiner | oh well, go to run |
| 06:38:25 | agardiner | later all |
| 06:38:27 | tmpk | That is bizarre. |
| 06:38:32 | tmpk | Later. o/ |
| 06:38:38 | agardiner leaves the room. | |
| 06:39:27 | femtowin enters the room. | |
| 06:44:15 | rue | Any objections to a toplevel benchmark/ ? |
| 06:49:00 | femtowin enters the room. | |
| 06:52:04 | brixen | rue: I'd much prefer that |
| 06:52:27 | ragge leaves the room. | |
| 06:52:57 | brixen | rue: I was going to advocate removing test and moving benchmark up once we port any (if any) bfts tests |
| 06:54:05 | rue | OK |
| 06:54:24 | rue | I just have some pretty simple Array bms |
| 06:55:16 | brixen | yeah, I've got a number of them I wanted to add |
| 06:56:07 | brixen | I was thinking combine phoenix, comstock, wycats, into rubinius |
| 06:56:59 | brixen | rue: you could move bfts and mri under spec/test for now |
| 06:57:05 | brixen | we'll port them |
| 06:57:29 | brixen | must say, it was some agony using test/unit today working on fnmatch |
| 06:57:49 | brixen | beautifully descriptive method names :P |
| 06:58:26 | pd enters the room. | |
| 07:02:16 | TheVoice | rue: congrats on the job things. Look forward to seeing what you come up with. |
| 07:07:02 | rue | TheVoice: Thanks! Some cool options |
| 07:07:55 | jennyw enters the room. | |
| 07:20:23 | pietia enters the room. | |
| 07:21:56 | evan | rue: hrm |
| 07:22:01 | evan | i moved it to test/ before. |
| 07:22:05 | evan | i guess we can move it back. |
| 07:22:16 | evan | it's more organized now |
| 07:22:52 | maduyb__ enters the room. | |
| 07:24:13 | d2dchat leaves the room. | |
| 07:25:06 | femtowin enters the room. | |
| 07:27:11 | tmpk | Too bad agardiner is gone. This is relevant: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/545177ea53944038/d9b3c2588a66a b71?#d9b3c2588a66ab71 |
| 07:27:59 | tmpk | This as well: http://gcc.gnu.org/ml/gcc-prs/2002-09/msg00520.html |
| 07:31:37 | evan | tmpk: ha! |
| 07:31:42 | evan | the 2nd link is EXACTLY the problem we have. |
| 07:31:59 | evan | the common block reordering |
| 07:32:20 | evan | our fusion is "Piumarta-style interpreter inlining" |
| 07:33:12 | evan | eek |
| 07:33:14 | pergesu leaves the room. | |
| 07:33:14 | evan | 2002. |
| 07:33:19 | evan | maybe if i turn off gcse |
| 07:33:29 | evan | if that works (they indicate it doesn't) |
| 07:35:09 | evan | man. |
| 07:35:14 | evan | gcc is so... complicated. |
| 07:39:22 | brixen | "Some of the other things you mention are likely to be viewed by gcc |
| 07:39:22 | brixen | maintainers as not a bug, in particular the practice of taking code |
| 07:39:22 | brixen | fragments that gcc has generated and copying them elsewhere. I would |
| 07:39:23 | brixen | find it very hard to defend a patch for that." |
| 07:39:30 | brixen | that's nice to hear |
| 07:39:38 | evan | which link is that? |
| 07:39:49 | brixen | it's the reply below the link above |
| 07:39:55 | brixen | Andrew Haley |
| 07:39:59 | evan | the first link? |
| 07:40:11 | brixen | the google link from tmpk |
| 07:40:27 | brixen | yeah, first |
| 07:40:35 | brixen | they blended together for my eye ;) |
| 07:40:42 | evan | gotcha |
| 07:40:44 | evan | i see it. |
| 07:40:45 | evan | yeah |
| 07:41:04 | evan | so piumarta inlining is impossible on gcc |
| 07:41:05 | brixen | they paper is interesting in the first link, you've probably already read it |
| 07:41:40 | brixen | no wonder piumarta calls it horrid C |
| 07:41:45 | evan | i haven't |
| 07:41:49 | evan | preview is openning it now |
| 07:41:58 | evan | it's likely the same idea |
| 07:42:00 | srbaker leaves the room. | |
| 07:42:11 | evan | macro == superinstructions == fusion |
| 07:42:39 | srbaker enters the room. | |
| 07:42:49 | brixen | ok, cool |
| 07:42:53 | brixen | was just going to ask that |
| 07:42:55 | evan | oh |
| 07:42:56 | evan | it's short |
| 07:42:59 | evan | i'm reading it now. |
| 07:43:11 | evan | this is fairly new |
| 07:43:20 | brixen | 06 |
| 07:44:22 | lstoll_ leaves the room. | |
| 07:45:57 | evan | ha! this is perfect |
| 07:46:03 | evan | this is EXACTLY the code i implemented. |
| 07:46:17 | evan | and the problems i've been having. |
| 07:46:46 | tmpk | Is this the ertl+06dotnet.ps.gz? |
| 07:46:46 | srbaker leaves the room. | |
| 07:47:19 | srbaker enters the room. | |
| 07:47:37 | evan | tmpk: yep |
| 07:48:22 | srbaker leaves the room. | |
| 07:48:25 | femtowin enters the room. | |
| 07:48:28 | evan | ha! java VMs have a mode called 'quickening' |
| 07:48:38 | evan | so your code experiences the quickening |
| 07:48:48 | evan | having taken the strength of other fallen code |
| 07:48:49 | evan | :) |
| 07:49:00 | srbaker enters the room. | |
| 07:50:21 | rue | This sounds awful metaphysical |
| 07:50:38 | rue | Although it could get White Wolf back in the game |
| 07:50:45 | rue | VM: The Quickening |
| 07:50:50 | tmpk | There's also an ertlgregg04.pdf floating around out there. I'm not sure if it's also relevant. |
| 07:50:55 | rue | I am going to be a mage anyway |
| 07:51:14 | drbrain | evan: http://www.craigslist.org/about/best/tpa/409930561.html |
| 07:52:05 | rue | Hrm, this takes a while to run |
| 07:52:06 | drbrain | sweeet |
| 07:52:12 | evan | HAHAH |
| 07:52:13 | drbrain | go Zlib::Inflate! |
| 07:52:18 | evan | drbrain: thats so awesome. |
| 07:52:23 | evan | better than the cemete block guy |
| 07:52:27 | evan | cement |
| 07:52:42 | drbrain | I was hoping Wilson posted that, but he did not |
| 07:52:48 | drbrain | something must be in the water in Florida |
| 07:53:13 | evan | double ha! |
| 07:53:27 | evan | this paper uses the proxy technique to call external functions I used. |
| 07:53:37 | evan | they store the address of the code in a local |
| 07:53:41 | evan | i used a struct of function pointers |
| 07:53:44 | evan | same diff though. |
| 07:55:49 | ezmobius enters the room. | |
| 08:02:12 | obvio171 leaves the room. | |
| 08:03:12 | boyscout | 2 commits by Eric Hodel |
| 08:03:13 | boyscout | * Cleanup, move Zlib methods together and sort.; e0ae474 |
| 08:03:14 | boyscout | * Common implementation for Zlib::Inflate and Zlib::Deflate.; 4eb58eb |
| 08:04:28 | drbrain | ha! look what I did to zlib.rb.in! |
| 08:04:33 | drbrain | 472 ++++++++++++++------ |
| 08:04:37 | drbrain | yeah! |
| 08:04:44 | drbrain | (I don't know what that means) |
| 08:06:14 | ezmobius | nice |
| 08:06:59 | w1rele55 enters the room. | |
| 08:07:10 | evan | drbrain: heheh |
| 08:08:51 | MenTaLguY | cool, six more points and you level up |
| 08:09:54 | drbrain | Exception: comparison of Fixnum with String failed (ArgumentError) |
| 08:10:04 | drbrain | Exception: No method 'coerce' on an instance of String. (NoMethodError) |
| 08:10:10 | drbrain | where does that come from? |
| 08:10:17 | drbrain | $DEBUG=true doesn't print line numbers for exceptions |
| 08:11:03 | rue | Fun stuff, two points for whoever can data-mine: http://pastie.org/152020 |
| 08:11:21 | evan | drbrain: i've been seeing that myself. |
| 08:11:38 | evan | drbrain: you can add line numbers to the exception debug output |
| 08:11:53 | drbrain | yeah |
| 08:12:53 | brixen | rue: what happened at 60000 numbers? |
| 08:13:03 | drbrain | but, that would distract me from rubygems |
| 08:13:17 | brixen | drbrain: what code gives you that exception? |
| 08:13:26 | drbrain | brixen: rubygems |
| 08:13:39 | drbrain | and, a metric ho-jillion of them |
| 08:13:50 | brixen | drbrain: that should come from passing other than fixnum, float, bignum to something that subclasses Numeric |
| 08:13:50 | ezmobius | those coerce errors are what i was getting trying to run merb as well |
| 08:14:11 | jero5 enters the room. | |
| 08:14:11 | drbrain | in a second, I will fix $DEBUG's exception printing, and tell you for real |
| 08:14:16 | drbrain | or, several seconds |
| 08:14:21 | drbrain | as rubinius is really slow |
| 08:17:00 | rue | brixen: I SIGINTed it, #sort_by is still untouched :) |
| 08:17:26 | thehcdreamer enters the room. | |
| 08:17:32 | drbrain | Successfully installed rake-0.8.1 |
| 08:17:35 | drbrain | !!!!!! |
| 08:17:38 | rue | Hurray |
| 08:17:42 | brixen | sweet! |
| 08:18:03 | brixen | rue: so, 45000 was using sort, but 60000 was using sort_by? |
| 08:18:23 | drbrain | then it said "Missing or uninitialized constant: Enable" |
| 08:18:30 | drbrain | I don't know what that's about |
| 08:18:32 | ezmobius | holy shit yay |
| 08:18:43 | MenTaLguY | drbrain!!! great! |
| 08:18:55 | rue | brixen: Oh, I thought you meant the bottom :) I think it might be the pivot currently running |
| 08:19:00 | drbrain | I think it took 5 minutes |
| 08:19:14 | drbrain | more like 8 |
| 08:19:17 | rue | does a victory dance |
| 08:20:48 | drbrain | what's the best way to get a line number? |
| 08:21:22 | drbrain | ... of the caller |
| 08:22:53 | drbrain | ok, think I've got it |
| 08:23:07 | wycats | successfully installed rake via rubygems? |
| 08:23:17 | drbrain | wycats: yes |
| 08:23:24 | wycats | that is awesome news |
| 08:23:28 | wycats | I take it zlib is done then? |
| 08:23:36 | drbrain | at least, all the files seem to be in the right spots |
| 08:23:39 | drbrain | haha, no |
| 08:23:47 | drbrain | zlib just works better than it did last week |
| 08:24:56 | wycats | nice |
| 08:25:04 | wycats | any low-hanging fruit? |
| 08:25:32 | drbrain | by the bushel, I am sure |
| 08:26:38 | wycats | nice |
| 08:26:51 | drbrain | like, the rest of Zlib::Zstream could be filled out |
| 08:26:56 | drbrain | those should be easy |
| 08:27:03 | wycats | is there anything else unimpl'ed that is already specced? |
| 08:27:03 | wycats | :P |
| 08:27:17 | drbrain | no |
| 08:27:35 | drbrain | I generated the specs two weeks ago after fixing up bin/mkspec |
| 08:27:54 | wycats | how does mkspec work? |
| 08:29:47 | rue | http://pastie.org/152024 |
| 08:29:55 | rue | Pivot selection, a bit more interesting data |
| 08:30:02 | drbrain | you point it at a class or module, and it figures out what's implemented on it and it's descendent classes/modules and writes out the spec stubs |
| 08:30:42 | drbrain | what happened with 60k? |
| 08:31:04 | drbrain | reherasal has an outliner for 125, second at 175 |
| 08:32:29 | drbrain | you should only have to do it once, and check the (nearly empty) files in |
| 08:32:33 | drbrain | the mkspec |
| 08:34:21 | MenTaLguY leaves the room. | |
| 08:35:45 | rue | drbrain: Good question |
| 08:36:00 | rue | A bit of a S/N issue gathering info |
| 08:36:21 | evan | wow |
| 08:36:26 | evan | the gforth guys are PRO. |
| 08:36:32 | evan | i'm going to go read the gforth VM source |
| 08:37:36 | rue | It is looking like 10 and 505 or so are the sweet-ish spots |
| 08:39:31 | wycats | Tamarin is apparently written in forth |
| 08:39:32 | wycats | who knew |
| 08:43:04 | drbrain | evan: can I move MethodContext#line to bootstrap? |
| 08:44:29 | evan | why? |
| 08:44:31 | evan | probably not |
| 08:44:34 | evan | is the answer |
| 08:44:51 | drbrain | I need the line number for $DEBUG |
| 08:44:55 | drbrain | and raise |
| 08:44:58 | drbrain | so I did: |
| 08:44:59 | evan | no you don't. |
| 08:45:07 | evan | you just need them once core is loaded. |
| 08:45:09 | drbrain | sender = MethodContext.current.sender.method |
| 08:45:20 | evan | who cares about them while bootstrap is loading. |
| 08:45:27 | drbrain | well, something is triggering this early |
| 08:45:47 | evan | you have to move a number of things to bootstrap to get MethodContext#line in bootstrap |
| 08:46:00 | evan | CompiledMethod#line_from_ip |
| 08:46:13 | evan | then all the methods line_from_ip uses |
| 08:46:18 | evan | and all the methods they use. |
| 08:46:45 | drbrain | well, somebody sets it to true, sometime |
| 08:47:02 | evan | replace it with a real noun |
| 08:47:14 | drbrain | sorry, $DEBUG |
| 08:47:20 | drbrain | let me poke at this some more |
| 08:48:23 | evan | so |
| 08:48:27 | evan | it's true by default? |
| 08:48:56 | drbrain | no |
| 08:49:56 | evan | <= confused |
| 08:50:27 | drbrain | oh, I typo'd because it is late |
| 08:50:47 | evan | but ya found it! |
| 08:51:14 | drbrain | ok, that's better |
| 08:54:41 | vintrepid leaves the room. | |
| 08:55:58 | drbrain | yay! found one of the coerce things |
| 08:56:20 | boyscout | 1 commit by Eric Hodel |
| 08:56:21 | boyscout | * Make debug exception printing print file and line number like MRI.; 2bdd7f6 |
| 08:57:35 | evan | drbrain: I thought there was MethodContext#location |
| 08:57:40 | drbrain | shotgun/rubinius -e '$DEBUG = true; Marshal.load(Marshal.dump(Time.now))' |
| 08:57:47 | evan | your change is fine though. |
| 08:57:54 | drbrain | hey! look at that! |
| 08:57:54 | evan | drbrain: eek, who is doing that? |
| 08:58:19 | drbrain | I'm not sure, my brain is woozy |
| 08:58:27 | drbrain | I had a backtrace, but I cleared it |
| 08:58:32 | evan | heh |
| 08:59:58 | boyscout | 1 commit by Eric Hodel |
| 08:59:59 | boyscout | * Hey! Look at that, MethodContext#location, staring me right in the face.; 4adc644 |
| 09:00:03 | evan | HAH |
| 09:00:09 | evan | ^5's drbrain |
| 09:01:44 | drbrain | hrm |
| 09:02:01 | langenberg enters the room. | |
| 09:02:06 | drbrain | String#unpack has an if repeat == '*' |
| 09:02:12 | drbrain | and that is causing this issue |
| 09:02:32 | evan | ug |
| 09:02:37 | evan | the pack/unpack code is.... |
| 09:02:39 | evan | gnarly. |
| 09:02:43 | drbrain | rake && shotgun/rubinius -e '$DEBUG = true; 1 == "*"'( |
| 09:02:57 | drbrain | I don't know why that calls #coerce |
| 09:03:46 | drbrain | so the :equal primitive fails |
| 09:03:48 | evan | because Fixnum#== does |
| 09:03:52 | evan | yep |
| 09:03:56 | evan | then it calls super() |
| 09:04:02 | drbrain | yeah |
| 09:04:06 | evan | and the Numeric#== does a coerce |
| 09:04:06 | brixen | yeah, you need to augment math_coerce in Numeric |
| 09:04:24 | evan | Numeric tower of fun! |
| 09:04:44 | brixen | drbrain: or perhaps write compare_coerce |
| 09:04:46 | drbrain | no |
| 09:04:49 | Arjen_ enters the room. | |
| 09:05:04 | drbrain | return false unless other.kind_of? Fixnum |
| 09:05:09 | drbrain | before super |
| 09:05:11 | evan | but thats wrong. |
| 09:05:19 | evan | 1 == 1.0 |
| 09:05:22 | drbrain | why? |
| 09:05:27 | evan | # => true |
| 09:05:51 | drbrain | oh, I'm reading MRI wrong |
| 09:06:07 | evan | the equal primitive only handles other being a Fixnum |
| 09:06:09 | evan | thats why it fails. |
| 09:06:27 | drbrain | why are we coercing? |
| 09:06:32 | drbrain | num_equal doesn't do that |
| 09:06:42 | evan | yeah it does |
| 09:06:45 | evan | 1 == "*" |
| 09:06:47 | evan | # => false |
| 09:06:49 | drbrain | where? |
| 09:07:01 | evan | which code are you looking at? |
| 09:07:01 | drbrain | (in MRI) |
| 09:07:32 | drbrain | Fixnum#== is fix_equal |
| 09:07:39 | drbrain | which calls num_equal |
| 09:07:58 | drbrain | maybe I'm not following for enough, since it dispatches to rb_funcall |
| 09:07:58 | gnufied enters the room. | |
| 09:08:02 | drbrain | sorry, it is late |
| 09:08:13 | langenberg leaves the room. | |
| 09:08:23 | evan | well |
| 09:08:32 | evan | num_equal flips the comparison |
| 09:08:37 | evan | so you call |
| 09:08 |