Da
Show enters and exits. Hide enters and exits.
| 00:01:20 | Maledictus enters the room. | |
| 00:07:46 | asap18 leaves the room. | |
| 00:09:57 | joearnol_ enters the room. | |
| 00:11:06 | joearnold leaves the room. | |
| 00:18:16 | rue | Heh. Should just have split Message in the summer. |
| 00:19:39 | brixen | depending on gestation, spring is more a time for splitting and summer a time for joining |
| 00:21:25 | macournoyer enters the room. | |
| 00:22:11 | macournoyer leaves the room. | |
| 00:27:16 | brynary leaves the room. | |
| 00:35:55 | rue | Alright, tarcieri, I am getting more Reia e-mail than all my Ruby stuff combined |
| 00:36:06 | qbproger enters the room. | |
| 00:36:08 | tarcieri | haha really? |
| 00:39:06 | slava | is there a lot of interest in Reia these days? |
| 00:54:23 | jarib enters the room. | |
| 00:58:27 | jarib leaves the room. | |
| 00:58:30 | jarib enters the room. | |
| 01:00:05 | enebo leaves the room. | |
| 01:00:21 | rue | tarcieri: Granted I am only on -core, rubinius-dev and the Waves list but still |
| 01:00:24 | joearnol_ leaves the room. | |
| 01:00:37 | rue | Oh, and ffi |
| 01:00:46 | joearnold enters the room. | |
| 01:03:32 | ezmob leaves the room. | |
| 01:04:50 | ezmob enters the room. | |
| 01:07:24 | enebo enters the room. | |
| 01:10:01 | enebo leaves the room. | |
| 01:14:47 | djb leaves the room. | |
| 01:16:24 | headius leaves the room. | |
| 01:17:08 | stepheneb leaves the room. | |
| 01:20:41 | brynary enters the room. | |
| 01:26:37 | cored enters the room. | |
| 01:33:44 | lopex leaves the room. | |
| 01:50:41 | outerim leaves the room. | |
| 01:53:32 | ezmob leaves the room. | |
| 01:57:23 | slava | evan: http://paste.factorcode.org/paste?id=535 |
| 02:00:27 | benny leaves the room. | |
| 02:01:37 | joearnold leaves the room. | |
| 02:04:33 | ryanlowe enters the room. | |
| 02:08:18 | benny enters the room. | |
| 02:10:08 | asap18 enters the room. | |
| 02:11:07 | binary42 leaves the room. | |
| 02:16:42 | brixen | slava: sweet |
| 02:16:46 | harryv enters the room. | |
| 02:17:07 | brixen | slava: I think there's a t in scratch |
| 02:17:37 | slava | I know |
| 02:17:41 | slava | it was a typo in my listener |
| 02:17:50 | brixen | yeah, I figured :) |
| 02:18:08 | brixen | just taking the opportunity to needle you |
| 02:19:04 | jashmenn leaves the room. | |
| 02:26:12 | mernen enters the room. | |
| 02:27:30 | rue | OK, yeah rm Twitterrific |
| 02:28:45 | rue | This Lounge thing is still on some cuneiform version and it is still by far better |
| 02:28:58 | SoreGums enters the room. | |
| 02:30:42 | harryv | what's up with people and un-googleable names. sigh |
| 02:31:27 | rue | http://loungeapp.com/mac if that was the one you were oogling |
| 02:32:15 | rue | Via avibryant |
| 02:32:17 | harryv | oi, that looks nice, yes. |
| 02:33:20 | harryv | sheesh. even more 10.5-only apps. |
| 02:33:37 | slava | 10.5 is a nice improvement over 10.4 API-wise |
| 02:34:13 | harryv | yeah. I woud probably do 10.5-only apps too, if I had anything interesting to do |
| 02:35:56 | rue | >> >>> vVv -> VVV >> V -> |
| 02:36:07 | rue | "PREALPHA" in cuneiform :) |
| 02:36:39 | rue | evan: Can we make that our version string? |
| 02:38:02 | rue | Suppose it could just be "U", too, being their last: _VVV |
| 02:43:15 | joearnold enters the room. | |
| 02:50:00 | joearnold leaves the room. | |
| 02:55:08 | chris2 leaves the room. | |
| 03:01:00 | cored leaves the room. | |
| 03:16:31 | evan | slava: cooool |
| 03:16:47 | evan | just got a crazy big cashiers check for the condo! |
| 03:16:53 | evan | and signed all the docs! |
| 03:17:04 | brixen | evan: yay! congrats! |
| 03:17:14 | brixen | that's awesome |
| 03:17:20 | evan | yeah |
| 03:17:26 | evan | it's a bit surreal |
| 03:17:28 | binary42 enters the room. | |
| 03:17:32 | evan | it will be more real when we move in |
| 03:17:34 | evan | and get keys |
| 03:17:51 | brixen | yes, you should have the keys before moving in |
| 03:18:26 | evan | probably. |
| 03:18:40 | evan | it's such a wierd day to do this on |
| 03:18:41 | evan | abby being sick |
| 03:18:46 | evan | me leaving on wednesday |
| 03:18:59 | brixen | ohh yeah, forgot about your trip |
| 03:19:36 | headius enters the room. | |
| 03:22:09 | tongueroo leaves the room. | |
| 03:22:38 | evan | i've been working on a Message refactoring today as well |
| 03:22:44 | evan | should have it pushed later tonight. |
| 03:22:53 | evan | Message is going away and being split into 3 parts |
| 03:23:05 | evan | Dispatch, Arguments, and LookupData |
| 03:23:23 | brixen | cool |
| 03:23:30 | evan | this way, the inline cache can actually just be a Dispatch C++ objects thats used over and over again |
| 03:23:52 | evan | and LookupData is only created when you actually need to do a more extended lookup of a method |
| 03:24:07 | evan | Arguments is slim and trim, only containing recv, args, and block |
| 03:24:17 | brixen | sweet |
| 03:25:09 | brixen | sounds like you're getting ready for some serious jit work |
| 03:25:39 | evan | yep. |
| 03:26:05 | brixen | when do you get back from SA? |
| 03:26:09 | enebo enters the room. | |
| 03:26:28 | evan | the 8th |
| 03:26:39 | brixen | k |
| 03:28:29 | enebo leaves the room. | |
| 03:29:17 | evan | brixen: you can help us move in when you're here :D |
| 03:29:33 | evan | brixen: i'm actually going to move my office there before we move the rest of the furniture |
| 03:29:37 | evan | so we'll have an office |
| 03:31:03 | brixen | sure |
| 03:31:11 | brixen | I'm good at moving |
| 03:31:14 | evan | hehe |
| 03:31:30 | brixen | I might just move it :D |
| 03:31:32 | evan | did you get travel and hotel worked out? |
| 03:31:36 | evan | hah |
| 03:31:39 | evan | i'm not going to force you to move |
| 03:31:40 | brixen | oh yeah |
| 03:31:41 | evan | trust me. |
| 03:32:00 | evan | in college, people used to get me to help them a lot |
| 03:32:04 | brixen | 115 S Fairfax Ave |
| 03:32:09 | evan | so i'll never do that to anyone else |
| 03:32:13 | brixen | is that the right farmers daughter? |
| 03:32:18 | evan | farmer's daughter? |
| 03:32:22 | brixen | hotel |
| 03:32:25 | evan | yeah, there is only one :) |
| 03:32:28 | brixen | ok |
| 03:32:31 | brixen | I should be set then |
| 03:33:17 | brixen | hah, I meant to type, I might just move *in* |
| 03:33:29 | brixen | damn, ruined the joke |
| 03:33:30 | evan | oh ha! |
| 03:33:30 | evan | :D |
| 03:33:32 | evan | nah |
| 03:33:34 | evan | both are good! |
| 03:33:39 | evan | 2 for 1! |
| 03:33:48 | brixen | sunny so cal is looking better every day |
| 03:33:54 | brixen | I'm tired of rain and snow |
| 03:34:01 | brixen | and the suburbs |
| 03:34:09 | brixen | those are the pits |
| 03:34:45 | evan | well, i'll get ya out of both of those! |
| 03:34:51 | brixen | almost have the mspec specs passing on 1.9 |
| 03:35:05 | brixen | started with 123 failures, down to 9 |
| 03:35:15 | evan | nice! |
| 03:43:36 | tongueroo enters the room. | |
| 03:46:20 | imajes leaves the room. | |
| 03:51:29 | tongueroo leaves the room. | |
| 03:52:30 | tongueroo enters the room. | |
| 03:53:43 | macournoyer enters the room. | |
| 03:53:44 | gnufied enters the room. | |
| 03:59:54 | SoreGums leaves the room. | |
| 04:04:19 | SoreGums enters the room. | |
| 04:04:23 | stepheneb enters the room. | |
| 04:07:28 | yipstar leaves the room. | |
| 04:10:25 | tongueroo leaves the room. | |
| 04:23:02 | mdalessio enters the room. | |
| 04:25:54 | outerim enters the room. | |
| 04:30:11 | imajes enters the room. | |
| 04:53:08 | stepheneb leaves the room. | |
| 04:53:26 | binary42 leaves the room. | |
| 04:57:10 | macournoyer leaves the room. | |
| 04:59:52 | aotearoa leaves the room. | |
| 05:01:28 | asap18 leaves the room. | |
| 05:01:56 | mdalessio leaves the room. | |
| 05:10:52 | krawek enters the room. | |
| 05:22:59 | tongueroo enters the room. | |
| 05:27:56 | qbproger leaves the room. | |
| 05:28:07 | wycats_ enters the room. | |
| 05:32:50 | shoe leaves the room. | |
| 05:33:14 | wycats_ leaves the room. | |
| 05:33:17 | wycats_ enters the room. | |
| 05:37:21 | brynary leaves the room. | |
| 05:51:20 | shoe enters the room. | |
| 06:02:13 | wycats_ leaves the room. | |
| 06:05:13 | tongueroo leaves the room. | |
| 06:32:08 | brixen | 1.9 appears to be about 15% faster running the mspec specs than 1.8 |
| 06:32:22 | brixen | but that's ~0.85s vs ~1.0s |
| 06:32:28 | brixen | so who knows :) |
| 06:47:54 | somebody_ leaves the room. | |
| 06:56:23 | mediogre enters the room. | |
| 07:09:53 | mernen leaves the room. | |
| 07:17:05 | headius_ enters the room. | |
| 07:17:05 | headius leaves the room. | |
| 07:17:27 | naeu enters the room. | |
| 07:44:04 | benny leaves the room. | |
| 07:49:31 | naeu leaves the room. | |
| 07:51:07 | boyscout | Updated MSpec source to a3362728. - 3ba7371 - Brian Ford |
| 07:52:31 | boyscout | CI: 3ba7371 success. 1438 files, 7097 examples, 23344 expectations, 0 failures, 0 errors |
| 07:56:41 | naeu enters the room. | |
| 08:01:17 | naeu leaves the room. | |
| 08:03:28 | headius leaves the room. | |
| 08:12:08 | kronos_vano enters the room. | |
| 08:23:07 | bitsweat leaves the room. | |
| 08:33:17 | krawek leaves the room. | |
| 08:55:21 | benny enters the room. | |
| 08:56:21 | JonathanT enters the room. | |
| 08:59:21 | dbussink leaves the room. | |
| 09:05:08 | naeu enters the room. | |
| 09:08:16 | mutle_ enters the room. | |
| 09:24:09 | mutle leaves the room. | |
| 09:24:42 | botanicus enters the room. | |
| 09:42:11 | antares_ enters the room. | |
| 09:49:07 | antares_ leaves the room. | |
| 10:01:51 | botanicus_ enters the room. | |
| 10:03:14 | botanicus leaves the room. | |
| 10:26:51 | dbussink enters the room. | |
| 11:18:25 | imajes leaves the room. | |
| 11:50:51 | botanicus_ leaves the room. | |
| 11:52:52 | botanicus enters the room. | |
| 11:56:21 | asap18 enters the room. | |
| 12:04:13 | botanicus_ enters the room. | |
| 12:04:49 | botanicus leaves the room. | |
| 12:10:22 | naeu_ enters the room. | |
| 12:10:45 | naeu leaves the room. | |
| 12:33:41 | asap18 leaves the room. | |
| 12:36:12 | gnufied leaves the room. | |
| 12:42:56 | asap18 enters the room. | |
| 12:56:07 | asap18 leaves the room. | |
| 13:08:01 | jarib_ enters the room. | |
| 13:13:36 | gnufied enters the room. | |
| 13:32:31 | cypher23 leaves the room. | |
| 13:33:56 | mernen enters the room. | |
| 13:46:06 | cypher23 enters the room. | |
| 13:58:04 | JonathanT leaves the room. | |
| 13:58:18 | JonathanT enters the room. | |
| 14:02:06 | JonathanT leaves the room. | |
| 14:03:50 | brynary enters the room. | |
| 14:23:16 | wmoxam enters the room. | |
| 14:32:55 | chris2 enters the room. | |
| 14:37:03 | botanicus_ leaves the room. | |
| 14:37:05 | botanicus enters the room. | |
| 14:38:08 | macournoyer enters the room. | |
| 15:01:17 | botanicus leaves the room. | |
| 15:04:00 | stepheneb enters the room. | |
| 15:13:23 | yipstar enters the room. | |
| 15:18:47 | Maledikt enters the room. | |
| 15:32:48 | stepheneb leaves the room. | |
| 15:33:42 | botanicus enters the room. | |
| 15:36:47 | Maledictus leaves the room. | |
| 15:49:47 | asap18 enters the room. | |
| 15:51:24 | chris2 leaves the room. | |
| 15:53:26 | stepheneb enters the room. | |
| 16:03:08 | stepheneb leaves the room. | |
| 16:09:00 | binary42 enters the room. | |
| 16:09:59 | therealadam enters the room. | |
| 16:27:18 | kronos_vano leaves the room. | |
| 16:28:19 | jashmenn enters the room. | |
| 16:40:06 | lopex enters the room. | |
| 16:41:37 | mwesterb enters the room. | |
| 16:55:43 | outerim leaves the room. | |
| 17:17:07 | outerim enters the room. | |
| 17:27:52 | joearnold enters the room. | |
| 17:37:55 | mwesterb | If i wanted to start contributing to rubinius where would you recommend i start? |
| 17:40:02 | botanicus | BTW how is it going with rubinius? From the time you guys start to work in EY it doesn't seems there are much updates, is it? |
| 17:40:33 | brixen | mwesterb: have a look at doc/contributing.txt |
| 17:40:44 | mwesterb | I did |
| 17:40:57 | brixen | botanicus: you might have a look at the commit rss on the github repo |
| 17:41:03 | mwesterb | ahh |
| 17:41:09 | brixen | botanicus: there's a ton of activity |
| 17:41:36 | mwesterb | i am just wondering if there is a part of the standard library that needs some help or something else i am currently reading the cpp code, but it is currently outside of my full understanding |
| 17:42:18 | brixen | mwesterb: we'll there are lots of failing specs for the core libs |
| 17:42:42 | botanicus | brixen: I'm looking at it now, you're right. Just the last release is a bit old. |
| 17:42:48 | mwesterb | ahh i see, i shall start there |
| 17:42:58 | brixen | mwesterb: have a look at doc/howto |
| 17:43:21 | botanicus | Rubinius works with ruby 1.8 or 1.9 syntax? |
| 17:43:24 | brixen | you can do bin/mspec tag --list fails core |
| 17:43:27 | brixen | for instance |
| 17:43:32 | brixen | botanicus: 1.8 |
| 17:43:35 | evan | botanicus: yeah, we haven't done a release in a while |
| 17:43:51 | tongueroo enters the room. | |
| 17:44:15 | botanicus | OK, I must try it again |
| 17:44:31 | naeu_ leaves the room. | |
| 17:44:46 | botanicus | How is it fast? Of course faster than MRI 1.8, but what about 1.9? |
| 17:44:54 | brixen | basically, since we are in dev, every day master is a release |
| 17:45:00 | brixen | we tend not to break master |
| 17:45:04 | brixen | almost ever |
| 17:45:20 | evan | botanicus: we're faster than 1.8 on a lot of micro stuff |
| 17:45:26 | evan | but perhaps a little bit slower overall |
| 17:45:33 | evan | because our core classes are written in ruby |
| 17:46:25 | botanicus | evan: I love the idea of core classes in Ruby |
| 17:49:32 | evan | me too |
| 17:53:26 | kronos_vano enters the room. | |
| 17:53:44 | brixen | man, that 1.9 change to float sucks |
| 17:53:52 | brixen | there's a ton of specs like |
| 17:53:54 | brixen | Expected "0.5..2.3999999999999999" to equal "0.5..2.4" |
| 17:54:14 | brixen | round trip your ff with marshal |
| 17:54:53 | brixen | I want my friendly floats back |
| 18:00:19 | botanicus | BTW when would you like to support 1.9 syntax? |
| 18:01:58 | jero5 leaves the room. | |
| 18:02:08 | rue | Well, it is Floats. It seems the spec itself is broken |
| 18:05:46 | jero5 enters the room. | |
| 18:11:10 | brixen | the spec is not broken, ruby had deterministic friendly output of floating points that "round-tripped" for humans |
| 18:11:17 | brixen | they changed that |
| 18:11:25 | brixen | the spec will have to change too |
| 18:11:39 | ezmob enters the room. | |
| 18:12:01 | brixen | to be some stupid x.should == computed_value |
| 18:12:14 | brixen | instead of an easy to read and understand literal |
| 18:12:53 | evan | floats suck |
| 18:12:54 | evan | in general. |
| 18:12:58 | brixen | indeed |
| 18:13:01 | evan | I so rarely use them |
| 18:13:13 | evan | i like things that either are or are not. |
| 18:13:16 | scoopr | I hardly use anything else, each to their own I guess ;) |
| 18:13:29 | brixen | scoopr: you like the new behavior? |
| 18:13:46 | scoopr | what behaviour?, sorry I just jumped in |
| 18:14:01 | brixen | do p 2.4 in ruby19 head |
| 18:14:34 | brixen | the point is, not everything round-trips via to_s or inspect, so use marshal, that's what it is for |
| 18:14:46 | brixen | and leave the output for humans friendly |
| 18:15:25 | jarib_ leaves the room. | |
| 18:15:38 | brixen | it's a gratuitous change that will lead to endless headaches |
| 18:17:49 | warren_s leaves the room. | |
| 18:18:24 | brixen | 2543 files, 9016 examples, 105055 expectations, 79 failures, 99 errors |
| 18:18:34 | brixen | that is rubyspec *ci* with 1.9 head |
| 18:18:43 | brixen | they're going in the wrong direction |
| 18:19:42 | scoopr | hm, I don't think I have 1.9 installed anywhere |
| 18:19:43 | brixen | hrm, and something blew up the expectation count, should be ~30k |
| 18:20:14 | brixen | scoopr: no worries, just fire up python and type 2.4 |
| 18:20:20 | brixen | that's what you'll see in ruby now |
| 18:24:44 | rue | The spec was just based on inaccurate assumptions |
| 18:25:28 | scoopr | brixen, ah |
| 18:26:11 | stepheneb enters the room. | |
| 18:26:21 | rue | brixen: The ruby-core archive has the thread, it was within the last month |
| 18:27:26 | scoopr | hm |
| 18:27:52 | bitsweat enters the room. | |
| 18:28:19 | scoopr | I would actually expect the same result as "%f" % 2.4 would give .. |
| 18:29:42 | evan | thats yet another representation |
| 18:31:43 | headius enters the room. | |
| 18:32:11 | brixen | rue: that thread has (almost) no justification for changing the representation |
| 18:32:32 | brixen | it meanders all over the accuracy of fp terrain |
| 18:32:40 | brixen | this really has nothing to do with that |
| 18:33:12 | brixen | matz's only input is "can you commit please" |
| 18:36:15 | rue | brixen: Well, maybe this statistical masterpiece will cheer you up: http://musicthatmakesyoudumb.virgil.gr/index.php |
| 18:38:14 | brixen | interestingly, 1.9 does not appear to be much faster than 1.8 running rubyspec |
| 18:38:31 | brixen | could be the zillion exceptions in 1.9 though |
| 18:39:05 | rue | 1.9 is something like 75% 1.8 runtimes on average |
| 18:40:04 | warren_s enters the room. | |
| 18:47:45 | headius | once execution is no longer an issue rubyspecs are pretty dependent on core class perf, which is probably a wash between 1.8 and 1.9 |
| 18:47:49 | headius | some slower, some faster |
| 18:49:39 | evan | yep. |
| 19:01:56 | lopex | IO |
| 19:02:30 | lopex | how does rspec perform on 1.9 ? |
| 19:05:29 | rue | For IO? |
| 19:05:54 | evan | well, SendSites are getting a much needed scrubbing |
| 19:06:00 | evan | we had a lot of dead code in there. |
| 19:09:33 | rue | Yeahh |
| 19:11:35 | antares_ enters the room. | |
| 19:31:25 | imajes enters the room. | |
| 19:31:42 | joearnold leaves the room. | |
| 19:38:43 | libc_ enters the room. | |
| 19:38:49 | somebody_ enters the room. | |
| 19:46:26 | libc leaves the room. | |
| 19:46:29 | kronos_vano leaves the room. | |
| 19:50:18 | joearnold enters the room. | |
| 19:54:05 | stepheneb leaves the room. | |
| 19:54:32 | therealadam leaves the room. | |
| 19:55:52 | stepheneb enters the room. | |
| 19:57:52 | brynary leaves the room. | |
| 20:05:22 | krawek enters the room. | |
| 20:09:56 | ezmob leaves the room. | |
| 20:11:04 | tongueroo leaves the room. | |
| 20:13:37 | mernen leaves the room. | |
| 20:14:50 | tongueroo enters the room. | |
| 20:24:16 | mernen enters the room. | |
| 20:29:31 | rue | Think I shall watch "Quantum of Solace" |
| 20:45:02 | crayz_ enters the room. | |
| 20:46:17 | wmoxam | rue: it's pretty decent. Not as good as the last Bond film though |
| 20:47:01 | rue | You mean "Never Say Never Again"? :) |
| 20:51:18 | stepheneb leaves the room. | |
| 20:51:29 | stepheneb enters the room. | |
| 20:52:55 | crayz__ leaves the room. | |
| 21:02:43 | benny leaves the room. | |
| 21:03:18 | imajes leaves the room. | |
| 21:05:19 | crayz_ leaves the room. | |
| 21:06:34 | benny enters the room. | |
| 21:11:57 | antares_ leaves the room. | |
| 21:12:08 | qbproger enters the room. | |
| 21:13:26 | mediogre leaves the room. | |
| 21:18:28 | stepheneb leaves the room. | |
| 21:22:28 | botanicus leaves the room. | |
| 21:38:08 | evan | so last night |
| 21:38:21 | evan | I had the idea for another kind of VM code structure |
| 21:38:28 | evan | the "service routine" |
| 21:38:58 | evan | a bad name, perhaps, but I was thinking they could be a kind of code between instructions and primitives |
| 21:39:05 | brixen | yes! |
| 21:39:13 | brixen | I was just thinking about this... |
| 21:39:20 | brixen | reading that array bounds paper |
| 21:39:31 | evan | they'd be staticly dispatched |
| 21:39:32 | brixen | what were you thinking about it for? |
| 21:39:40 | evan | and referenced via name |
| 21:40:00 | evan | so that the VM itself could fix that up to be a direct function call to the routine |
| 21:40:16 | brixen | how would you use them? |
| 21:40:33 | evan | well, i was pondering if they would be our first real translated code |
| 21:40:46 | evan | they'd be written in ruby, and be translated to run in the VM |
| 21:41:08 | brixen | ok |
| 21:41:23 | evan | you'd use them for non-flow control logic |
| 21:41:37 | evan | that you still want to be low and fast |
| 21:41:56 | brixen | my concern with prims is that they are too big in a sense |
| 21:42:12 | brixen | big chunks of code |
| 21:42:18 | evan | sure |
| 21:42:24 | evan | so what were you thinking? |
| 21:42:32 | brixen | and for doing opts, it would be nicer to have smaller composable chuncks |
| 21:42:41 | brixen | because the bounds checking is done in the primitive |
| 21:42:45 | evan | i was thinking that, for instance, the tuple operations would be these service routines |
| 21:42:49 | evan | rather than primitives |
| 21:43:02 | brixen | yeah, I think I'm following |
| 21:43:08 | evan | we could introduce a compiler escape to call them |
| 21:43:25 | evan | they'd kind of let us drop down a half a level |
| 21:43:36 | evan | to a little bit faster, more static set of execution |
| 21:43:53 | evan | i worry that they confuse things |
| 21:43:57 | evan | though |
| 21:44:11 | brixen | I was trying to think how to do this as an instruction, but being able to call eg String.new is needed (String.new being a primitive) |
| 21:44:47 | evan | you can do that in instructions now |
| 21:45:01 | evan | but it complicates the instruction, obviously |
| 21:45:05 | brixen | right |
| 21:45:17 | evan | the idea I was thinking is that instructions are just for control flow |
| 21:45:27 | brixen | k |
| 21:45:34 | evan | stack manip, jump, send, etc. |
| 21:45:40 | imajes enters the room. | |
| 21:45:55 | evan | maybe even the meta_ instructions would go away |
| 21:46:01 | evan | moving them to be service routines |
| 21:46:11 | brixen | yeah |
| 21:46:24 | brixen | almost seems we could ditch a number of primitives this way |
| 21:46:24 | evan | we'd introduce a new instruction call_routine |
| 21:46:25 | evan | or something |
| 21:46:46 | evan | call_routine :tuple_put, 3 |
| 21:46:52 | evan | fixed argument count |
| 21:46:54 | brixen | I was going to look at how I could compose the array prims from more primitive stuff |
| 21:46:57 | brixen | right |
| 21:47:03 | evan | they'd be passed the data and return a result |
| 21:47:35 | evan | slava is probably laughing right now |
| 21:47:42 | evan | because this is basically adding static word dispatch to rubinius |
| 21:47:45 | brixen | I think Tuple or Array would be a good experiment |
| 21:49:36 | evan | hm |
| 21:49:42 | evan | ok, well, how would these be called? |
| 21:49:47 | evan | what were you thinking? |
| 21:50:40 | brixen | basically like you showed above |
| 21:50:53 | brixen | something that is visible in our bytecode |
| 21:51:03 | evan | right |
| 21:51:06 | evan | i mean in the ruby code |
| 21:51:08 | brixen | rather than opaque behind a primitive dispatch |
| 21:51:13 | brixen | hm |
| 21:51:27 | brixen | well, we talked about the Type.method syntax before |
| 21:52:01 | brixen | class Array; def [](n); Tuple.get n; end; end |
| 21:52:03 | brixen | something like that? |
| 21:52:13 | brixen | well, passing the tuple |
| 21:52:26 | brixen | I'm curious how you handle "fall back" type code |
| 21:52:38 | rue | Errors |
| 21:52:53 | evan | they'd be allowed to throw exceptions, etc. |
| 21:53:05 | evan | or signal an error however they want |
| 21:53:10 | evan | no fall back code like primitives |
| 21:53:19 | evan | it's up to the caller and the routine to figure it out |
| 21:53:27 | brixen | seems we'd need a simple non-expensive way to say "can't help ya here bub" |
| 21:53:41 | evan | well, why would it not be able to help? |
| 21:53:44 | brixen | so other code can be run |
| 21:54:01 | brixen | I suppose it could |
| 21:54:19 | brixen | the caller is then responsible for understanding and guarding the dispatch |
| 21:54:36 | brixen | can't just dispatch and clean up like with prims |
| 21:55:03 | brixen | but with Array#[] for instance, you can only call if you know n is a fixnum |
| 21:55:08 | brixen | is that what you're thinking? |
| 21:55:24 | evan | well, like all things |
| 21:55:27 | evan | dynamicly typed |
| 21:55:37 | evan | that routine is going to have to check types and throw TypeErrors |
| 21:55:47 | evan | before doing any work |
| 21:56:18 | brixen | I guess I'm thinking lower level then |
| 21:56:35 | evan | ok, could ya explain? |
| 21:56:35 | brixen | I want the check to be composable with the actual data fetch, in the tuple example |
| 21:56:55 | brixen | so if there are multiple fetches, we could optimise the bounds check in one place |
| 21:57:01 | brixen | that sort of idea |
| 21:57:16 | brixen | potentially optimize I should say |
| 21:57:32 | brixen | things like reading chars from a string |
| 21:57:56 | brixen | that we do totally behind a primitive or with a bunch of full primitive dispatches now |
| 21:58:07 | evan | ok, what would the smallest unit of execution be in your case? |
| 21:58:23 | evan | something like setting a byte in a String? |
| 21:58:31 | brixen | yeah, something like that |
| 21:58:43 | brixen | my concern is bundling up the checks with the operations |
| 21:58:52 | brixen | so it becomes opaque in the bytecode |
| 21:59:38 | evan | ok |
| 21:59:42 | evan | so how would you build up? |
| 21:59:48 | evan | would it be explicit or implicit? |
| 22:00:03 | evan | ie, would you create a new unit thing thats a composite over other units |
| 22:00:10 | brixen | well, I was imagining a ruby-like method that is tranlated |
| 22:00:25 | evan | or would that composite be realized by the compiler |
| 22:00:46 | brixen | I was thinking explicit, but it could be decomposed by the compiler |
| 22:00:53 | brixen | explicitly written |
| 22:01:41 | brixen | how were you thinking for the service methods? |
| 22:01:59 | evan | not sure |
| 22:02:04 | evan | just an idea bouncing around |
| 22:02:08 | brixen | ok |
| 22:02:09 | evan | thought i'd spit it out, see what happens |
| 22:02:35 | evan | so you were thinking units would be written a dialect |
| 22:02:39 | evan | and they could be composed together |
| 22:02:42 | brixen | I'm looking at Tuple::copy_from for instance |
| 22:02:52 | brixen | it's a shame that's a primitive |
| 22:02:52 | evan | with the compositing being a new unit |
| 22:02:57 | evan | that could be translated |
| 22:03:02 | brixen | yeah |
| 22:03:12 | brixen | more like lists of operations |
| 22:03:20 | brixen | than anything that needed flow control |
| 22:03:32 | brixen | the control is more just "bail" |
| 22:03:36 | brixen | do_one |
| 22:03:39 | brixen | do_two |
| 22:03:50 | brixen | do_three -> eeks can't continue |
| 22:03:59 | evan | what about conditionals? |
| 22:04:12 | brixen | then higher code has to make the conditional decision |
| 22:04:17 | rue | Got inline assembly already |
| 22:04:19 | brixen | maybe that doesn't make sense |
| 22:04:22 | evan | or would the invoking of do_one implicitly check if do_one failed |
| 22:04:28 | evan | and if do_one fails, the caller fails |
| 22:04:36 | brixen | evan: yeah, like that |
| 22:04:45 | brixen | well, they just run |
| 22:04:49 | evan | rue: yeah, but we don't have many instructions |
| 22:04:54 | evan | rue: so inline assembly is of limited use |
| 22:04:59 | brixen | but if one fails, the "unit" fails |
| 22:05:24 | evan | so, what would the composition for Tuple::copy_from look like? |
| 22:05:49 | stepheneb enters the room. | |
| 22:05:53 | brixen | well, here's the idea |
| 22:05:54 | evan | just the simpliest case |
| 22:06:09 | rue | Just start on the simplified Ruby |
| 22:06:14 | brixen | the bounds checks in copy_from are abstractable across all of tuple |
| 22:06:22 | brixen | but they are bound up in that primitive |
| 22:06:27 | brixen | so, it would be a list of |
| 22:06:32 | brixen | check_lower_bound |
| 22:06:36 | brixen | check_upper_bound |
| 22:06:41 | brixen | fetch |
| 22:06:44 | brixen | assign |
| 22:06:45 | evan | what are the arguments to those? |
| 22:07:08 | brixen | the args to copy_from, which is the "unit" |
| 22:07:55 | brixen | maybe another way to think of this would be: what would our insns look like if we wrote some just for Tuple |
| 22:08:01 | brixen | maybe that's what I'm thinking |
| 22:08:25 | brixen | there's a pretty small set of things you to in a primitive way with tuple |
| 22:08:30 | brixen | but at the Ruby level |
| 22:08:37 | brixen | those are collections of things |
| 22:08:40 | evan | so if we had an instruction set that operated on a tuple? |
| 22:08:54 | brixen | well, as a thought experiment |
| 22:09:34 | brixen | but rather than putting these in the compiler, I thought we'd write the "methods" that are these collections of tuple insns |
| 22:09:37 | brixen | that sort of thing |
| 22:09:44 | brixen | is this making any sense? |
| 22:10:13 | evan | hm |
| 22:10:15 | evan | i don't follow that. |
| 22:10:58 | brixen | well.. |
| 22:11:22 | brixen | using the compiler analogy |
| 22:12:10 | brixen | say Tuple.copy_from(this, other, start, length, dest) |
| 22:12:35 | brixen | then looking at each operation in the primitive now |
| 22:13:12 | brixen | the compile would emit stuff like check_lower_bound start |
| 22:13:18 | brixen | etc |
| 22:13:43 | brixen | if we had such insns for tuples |
| 22:15:34 | evan | so it's more that just an extensible instruction set |
| 22:15:44 | evan | because the compiler is aware of the implementation for the insns |
| 22:16:08 | brixen | basically |
| 22:16:38 | evan | so the compiler and act like a compiler and composite them together |
| 22:17:09 | evan | s/and/can/ |
| 22:17:31 | brixen | the thing is, if you called something else and then copy_from right now with a fixnum, that can't change, it's still going to check that olend > 0 |
| 22:18:08 | brixen | the only way to optimize this is with interprocedural opts |
| 22:18:12 | brixen | afaik |
| 22:18:13 | evan | right |
| 22:18:31 | evan | so we're talking really about a dispatch layer below methods |
| 22:18:42 | evan | that the compiler can reason about |
| 22:18:47 | brixen | yeah |
| 22:19:07 | brixen | seems to me about 150 lines of tuple.cpp could be in this form |
| 22:19:30 | brixen | the gc mark, weakref, size would still be cpp methods |
| 22:19:42 | brixen | cus they're used by the vm |
| 22:20:12 | evan | well |
| 22:20:21 | evan | to a certain extent yes |
| 22:20:35 | evan | but the real plus would to be to tie the C++ methods into these |
| 22:20:46 | brixen | but if we could do this *without* an isns set just for tuple, that'd be cool |
| 22:20:49 | evan | so we're starting to translate parts of the VM too |
| 22:20:54 | brixen | right |
| 22:22:25 | brixen | seems like it's possible to do without a full-fledged language |
| 22:22:36 | brixen | just a list of operations with a start and end point |
| 22:22:54 | brixen | you can catch a failure that happens midway at the start |
| 22:23:15 | evan | hm |
| 22:23:35 | brixen | like a really simple state diagram |
| 22:23:43 | rue | Why do it without a full-fledged language? |
| 22:23:49 | brixen | where things either end in yes or no, or just yes |
| 22:24:06 | brixen | if it ends in no, the "unit" ends in no |
| 22:24:49 | gnufied leaves the room. | |
| 22:27:33 | yipstar leaves the room. | |
| 22:28:18 | yipstar enters the room. | |
| 22:28:19 | macournoyer leaves the room. | |
| 22:29:21 | brixen | evan: I guess this is why that equality saturation approach seems so interesting |
| 22:29:26 | brixen | tuples don't change is size |
| 22:29:45 | brixen | so that's more info to add when it's optimizing bounds checks |
| 22:30:16 | brixen | if the tuple is the same and the index is the same, there's only one check for a bunch of operations |
| 22:30:28 | evan | sure |
| 22:30:31 | brixen | you could add the info with a domain axiom |
| 22:30:53 | brixen | but arrays can change |
| 22:30:56 | evan | but my worry is we don't want to be writing the whole core in these routines |
| 22:31:03 | brixen | yeah |
| 22:31:22 | evan | so stuff like optimizations that assume tuple size and index would be better applied to normal ruby code |
| 22:31:35 | evan | so that it could be used without having to drop down to a specific dialect |
| 22:31:45 | brixen | gotcha |
| 22:32:37 | evan | at the same time, having a dynamic set of intrinsic operations that the bytecode and compiler can use might be useful |
| 22:32:47 | botanicus enters the room. | |
| 22:33:30 | brixen | to ruby code it would look like a method call, but to our compiler it would not be an opaque primitive |
| 22:33:38 | brixen | I guess that's basically what I'm thinking |
| 22:33:58 | stepheneb leaves the room. | |
| 22:34:17 | brixen | which sounds like what you were thinking, but.. |
| 22:34:24 | brixen | I'm not sure |
| 22:34:28 | evan | me neither. |
| 22:34:32 | brixen | heh |
| 22:34:34 | evan | after talking with John Rose |
| 22:34:43 | evan | i've begun thinking about how we could have intrinsics |
| 22:34:52 | evan | with a staticly typed language, thats easy |
| 22:35:04 | evan | because the compiler can see that you're performing operation X of type Y |
| 22:35:36 | brixen | interesting http://www.digitalmars.com/d/2.0/phobos/std_intrinsic.html |
| 22:35:46 | evan | where as the best we can do up front is that you're calling method X on something that the user called Y |
| 22:36:19 | brixen | right |
| 22:37:05 | joearnold leaves the room. | |
| 22:37:07 | evan | you can "pull the veil" back on the instrinics by requiring a specific syntax for calling them |
| 22:37:15 | joearnold enters the room. | |
| 22:37:19 | evan | Rubinius.intrinsic :tuple_copy, self, other |
| 22:37:48 | evan | but thats really ugly to litter the code with |
| 22:37:56 | brixen | yeah |
| 22:37:58 | evan | and it breaks portability |
| 22:38:16 | brixen | but if that were behind a "normal" method call |
| 22:38:22 | brixen | like primitives are now |
| 22:38:48 | evan | right |
| 22:39:00 | evan | the the calling code is shielded from the implementation |
| 22:43:05 | crayz_ enters the room. | |
| 22:43:07 | brixen | you know, what I am thinking is really just intrinsics too |
| 22:43:19 | brixen | I was trying to think of how to abstract writing them |
| 22:43:28 | brixen | but I don't think that makes much sense |
| 22:44:28 | seydar enters the room. | |
| 22:45:23 | brixen | sey.dar n. random visitor from the land of mibbit |
| 22:46:20 | seydar | i started my compilers course today |
| 22:46:26 | brixen | sweet! |
| 22:46:39 | seydar | it's in matlab, but i'm going to do it in c++ as well (maybe) so i can get glasses and be extra nerdy |
| 22:46:57 | evan | brixen: we may just have to play around with a couple of things |
| 22:47:01 | evan | see what works and doesn't |
| 22:47:06 | brixen | evan: indeed |
| 22:48:51 | evan | i'm still cleaning up SendSite atm |
| 22:48:59 | evan | had to gut a lot of code |
| 22:49:27 | genericpenguin enters the room. | |
| 22:49:36 | brixen | I keep forgetting about scholar.google.com |
| 22:49:46 | evan | I'm thinking about using a few macros and such to reduce the ammount of changed needed for this in the future |
| 22:50:28 | dgtized | there are a couple more routines that could share those "intrinsics" of tuple in Array, delete comes to mind |
| 22:51:30 | rue | seydar: Touching your C++ does not make you blind |
| 22:51:52 | evan | dgtized: sure |
| 22:51:54 | brixen | evan: I think the idea would be to put the intrinsic 'signature' into the class and use something like our sendsite |
| 22:52:09 | brixen | evan: I think you mentioned something like this |
| 22:52:15 | evan | signature? |
| 22:52:40 | brixen | basically, the sendsite, or guard could say, I've got an intrisic for this method on this type |
| 22:52:46 | brixen | by looking in the type's class |
| 22:52:59 | brixen | and maybe patch |
| 22:53:03 | brixen | just thinking out loud |
| 22:53:13 | evan | sure |
| 22:53:15 | brixen | rather than having intrinsic calls in the ruby code |
| 22:53:17 | evan | thats actually super easy |
| 22:53:52 | evan | in that case, we'd be building a way of taking highlevel, ruby like code and translating it to code that we could compile into the VM |
| 22:54:01 | brixen | yeah |
| 22:54:05 | evan | in many ways, it's better to view those as 2 different things anyway |
| 22:54:25 | evan | HOW to call the intrinsic should be seperated from WHAT it is |
| 22:54:36 | brixen | yeah |
| 22:55:03 | seydar | rue: i'm not sure whether that was deliberately confusing or you were making a one-testicled joke |
| 22:55:51 | evan | i've had this idea many times |
| 22:56:07 | evan | at one point, i'd considered having something akin to a GPU in the VM |
| 22:56:18 | evan | which a completely different instruction set |
| 22:56:24 | seydar | a GPU in the VM? |
| 22:56:24 | evan | that was highly specialized |
| 22:56:31 | brixen | heh, neat |
| 22:56:46 | evan | the main VM would ask the 'GPU' to perform some operation |
| 22:56:56 | seydar | why would you want to model a GPU instead of a CPU? |
| 22:56:57 | evan | with the operation expressed as a DSL in the ruby code |
| 22:57:06 | evan | seydar: i don't mean an actual GPU |
| 22:57:11 | evan | i just mean a specialized coprocessor |
| 22:57:14 | dgtized | one GPU, or a GPU for numerics, a GPU for arrays, a GPU for strings? |
| 22:57:20 | evan | maybe |
| 22:57:21 | evan | dunno |
| 22:57:27 | evan | it was an idea I had on an airplane |
| 22:58:25 | evan | it provides an interesting abstraction |
| 22:58:31 | seydar | can you explain what you mean by having the operation expressed as a DSL? |
| 22:58:42 | dgtized | I mean we sort of have one for Regexp right? |
| 22:58:43 | evan | sure |
| 22:58:54 | evan | say we have a String GPU |
| 22:59:17 | evan | that supports an operation called move_byte(from, from_idx, to, to_idx) |
| 22:59:47 | evan | if you needed to move bytes between to strings a and b, you'd do |
| 22:59:59 | evan | String::GPU.perform do |g| |
| 23:00:24 | evan | g.move_byte a, 0, b, 0 |
| 23:00:25 | evan | end |
| 23:00:31 | evan | thats just one byte, obviously |
| 23:00:44 | evan | but the compiler would see you doing that |
| 23:01:00 | evan | and rather than running that as normal ruby code |
| 23:01:14 | rue | I am not sure I see the benefit for something like that except for "plugins" |
| 23:01:18 | evan | it would do the work of creating a GPU instruction stream at compile time |
| 23:01:33 | evan | and at runtime it would use some normal VM instruction to call out to the GPU |
| 23:01:42 | evan | rue: yeah, i'm not sure either. |
| 23:01:49 | evan | never did it. |
| 23:02:33 | rue | It would be a good way to allow some unknown code to perform faster, but it does not seem there is anything there for internal stuff |
| 23:02:49 | rue | Unless you actually run it on the GPU :P |
| 23:02:51 | mernen leaves the room. | |
| 23:03:29 | slava | hi evan |
| 23:03:31 | evan | which would be awesome |
| 23:03:34 | evan | slava: allo |
| 23:03:54 | evan | rue: maybe we should actually build a DSL for performing VM operations by a GPU |
| 23:04:03 | evan | as OpenGL instructions or something |
| 23:04:04 | evan | :D |
| 23:04:24 | slava | I think I can get method dispatch down to 5 instructions |
| 23:04:31 | slava | in the cache hit case |
| 23:04:33 | evan | hm, can you model method lookup as texture mapping and collision detection.... |
| 23:04:46 | drbrain | use wilson |
| 23:05:00 | dgtized | is this what slang does in smalltalk? |
| 23:05:24 | evan | drbrain: we'd need a wilson for at least ppc then too |
| 23:05:39 | drbrain | minor issue :) |
| 23:05:40 | evan | dgtized: not really. |
| 23:06:02 | evan | slang looks at smalltalk code and translates it using a completely different set of assumptions |
| 23:06:02 | tarcieri | lol @ using collision detection to perform method dispatch |
| 23:08:58 | rue | I would totally play Array#reject implemented as a FPS |
| 23:09:06 | evan | hah |
| 23:21:53 | seydar leaves the room. | |
| 23:29:34 | botanicus leaves the room. | |
| 23:30:42 | gnufied enters the room. | |
| 23:34:31 | naeu enters the room. | |
| 23:41:31 | ezmob enters the room. | |
| 23:42:12 | stepheneb enters the room. | |
| 23:44:33 | stepheneb leaves the room. | |
| 23:45:59 | stepheneb enters the room. | |
| 23:49:05 | wmoxam leaves the room. | |
| 23:50:31 | stepheneb leaves the room. |