Show enters and exits. Hide enters and exits.
| 00:01:33 | VVSiz_ enters the room. | |
| 00:03:50 | edwardam leaves the room. | |
| 00:03:50 | antares leaves the room. | |
| 00:03:50 | gramos leaves the room. | |
| 00:03:50 | joachimm_ leaves the room. | |
| 00:03:50 | wycats leaves the room. | |
| 00:03:50 | rubuildius_ppc leaves the room. | |
| 00:03:50 | rudebwoy leaves the room. | |
| 00:03:50 | VVSiz leaves the room. | |
| 00:03:50 | smparkes leaves the room. | |
| 00:03:50 | mass leaves the room. | |
| 00:03:50 | Illocution leaves the room. | |
| 00:03:50 | jp_tix leaves the room. | |
| 00:03:50 | ko1_away leaves the room. | |
| 00:05:12 | jp_tix enters the room. | |
| 00:05:22 | dgtized | dbussink: you still about? |
| 00:05:29 | dgtized | oh you left, shoot |
| 00:05:39 | edwardam enters the room. | |
| 00:05:39 | gramos enters the room. | |
| 00:05:39 | antares enters the room. | |
| 00:05:39 | joachimm_ enters the room. | |
| 00:05:39 | wycats enters the room. | |
| 00:05:39 | rubuildius_ppc enters the room. | |
| 00:05:39 | rudebwoy enters the room. | |
| 00:05:39 | smparkes enters the room. | |
| 00:05:39 | mass enters the room. | |
| 00:05:39 | Illocution enters the room. | |
| 00:05:39 | ko1_away enters the room. | |
| 00:06:17 | dgtized | evan: I have two big patches to fix compiler warnings but I can't run the test suite because of the VM** bug, should I delay commiting these changes till then or just try and see if it works? |
| 00:06:22 | zenspider | ok. I think we're 100%. tho I have some residual things to clean up in the compiler to be complete. |
| 00:06:35 | evan | dgtized: yes |
| 00:06:37 | evan | delay |
| 00:06:43 | evan | see if you can fix the VM** thing |
| 00:07:24 | zenspider | one last boom... looks like Defiler's "No current exception" bomb |
| 00:07:33 | dgtized | I don't get what is going wrong for the VM** problem at all, I mean I guess most places use the G() macro to use state but other then that it seems no different from anything else |
| 00:07:34 | evan | crap. |
| 00:07:58 | evan | zenspider: thats not going to be easy to fix |
| 00:08:24 | ezmobius leaves the room. | |
| 00:09:25 | ezmobius enters the room. | |
| 00:10:41 | zenspider | evan: that's ok... I'll make defiler do it. ;) |
| 00:12:04 | eventualbuddha leaves the room. | |
| 00:13:22 | rudebwoy leaves the room. | |
| 00:13:24 | joachimm_ leaves the room. | |
| 00:13:53 | joachimm enters the room. | |
| 00:15:25 | rudebwoy enters the room. | |
| 00:16:35 | imajes leaves the room. | |
| 00:18:55 | foysavas leaves the room. | |
| 00:19:36 | foysavas enters the room. | |
| 00:22:10 | shame leaves the room. | |
| 00:22:26 | cezarsa leaves the room. | |
| 00:28:28 | edwardam_ enters the room. | |
| 00:30:14 | edwardam_ leaves the room. | |
| 00:30:14 | rudebwoy leaves the room. | |
| 00:30:14 | mass leaves the room. | |
| 00:30:14 | rubuildius_ppc leaves the room. | |
| 00:30:14 | gramos leaves the room. | |
| 00:30:14 | smparkes leaves the room. | |
| 00:30:14 | Illocution leaves the room. | |
| 00:30:14 | ko1_away leaves the room. | |
| 00:30:14 | wycats leaves the room. | |
| 00:30:14 | antares leaves the room. | |
| 00:30:14 | edwardam leaves the room. | |
| 00:31:39 | boyscout | 2 commits by William Morgan |
| 00:31:40 | boyscout | * fix spectralnorm.rb so that it works on rubinius; ba0d4df |
| 00:31:41 | boyscout | * whitespace somehow mangled in the format-patch->am route; e0401af |
| 00:32:15 | wmoxam leaves the room. | |
| 00:34:59 | zenspider | brain. melting. |
| 00:35:19 | edwardam_ enters the room. | |
| 00:35:19 | rudebwoy enters the room. | |
| 00:35:19 | edwardam enters the room. | |
| 00:35:19 | gramos enters the room. | |
| 00:35:19 | antares enters the room. | |
| 00:35:19 | wycats enters the room. | |
| 00:35:19 | rubuildius_ppc enters the room. | |
| 00:35:19 | smparkes enters the room. | |
| 00:35:19 | mass enters the room. | |
| 00:35:19 | ko1_away enters the room. | |
| 00:36:42 | anteaya enters the room. | |
| 00:39:18 | boyscout | 1 commit by Evan Phoenix |
| 00:39:19 | boyscout | * Switch away from submodules to rsync copies; a9255bf |
| 00:39:27 | wycats leaves the room. | |
| 00:40:14 | wycats enters the room. | |
| 00:40:27 | ezmobius_ leaves the room. | |
| 00:40:35 | evan | wtf. |
| 00:40:54 | Illocution enters the room. | |
| 00:41:04 | zenspider | fatal: Untracked working tree file 'mspec/LICENSE' would be removed by merge. |
| 00:41:12 | zenspider | should I just nuke spec/frozen and mspec? |
| 00:41:20 | evan | yeah |
| 00:41:27 | evan | i'm removing them as submodules right now. |
| 00:41:32 | evan | everything went ok initially |
| 00:41:38 | evan | i'm getting an error in another clone |
| 00:41:39 | evan | standby |
| 00:42:59 | evan | ok. |
| 00:43:11 | evan | rm -rf mspec spec/frozen; git merge origin |
| 00:43:22 | evan | if you get any errors doing a git:pull |
| 00:44:12 | evan | sorry for the guff. |
| 00:44:12 | zenspider | too late. :P |
| 00:44:12 | zenspider | I didn't do the git merge part |
| 00:44:13 | zenspider | just the rm and a repull |
| 00:44:31 | evan | and your top commit is a9255bf14? |
| 00:44:53 | zenspider | something like that |
| 00:45:01 | evan | k |
| 00:45:12 | evan | well, things should be smoother now. |
| 00:45:13 | zenspider | ah crap. I'm in master |
| 00:45:16 | evan | no more submodules. |
| 00:45:16 | zenspider | fuck |
| 00:45:21 | evan | ack. |
| 00:45:29 | evan | i was afraid of that. |
| 00:45:39 | edwardam leaves the room. | |
| 00:45:43 | michaellatta_ enters the room. | |
| 00:47:15 | enebo enters the room. | |
| 00:47:44 | rubuildius_ppc leaves the room. | |
| 00:49:04 | zenspider | god damnit... |
| 00:49:08 | enebo leaves the room. | |
| 00:49:10 | zenspider | stupid git |
| 00:49:13 | evan | is it blown up again? |
| 00:49:35 | zenspider | I'm back on my branch... the top stash is my deletions |
| 00:49:44 | zenspider | apparently I have a lot of old stashes |
| 00:49:51 | evan | ah |
| 00:49:52 | evan | ack. |
| 00:49:55 | zenspider | and I can't get it to apply the ones with my changes for this commit |
| 00:50:01 | zenspider | git stash apply --index 1 |
| 00:50:04 | evan | did you comimt hem or just stash them? |
| 00:50:05 | zenspider | doesn't work |
| 00:50:09 | evan | oh |
| 00:50:14 | zenspider | I committed |
| 00:50:21 | evan | they're not stashed then. |
| 00:50:30 | evan | if you committed them. |
| 00:50:44 | zenspider | hrm. |
| 00:50:53 | zenspider | ok. I'll just nuke all of these then |
| 00:51:01 | evan | if you want to check |
| 00:51:03 | evan | you can do |
| 00:51:15 | evan | git diff stash@{1} |
| 00:51:18 | evan | git diff stash@{2} |
| 00:51:19 | evan | etc. |
| 00:51:27 | evan | you can see whats in them. |
| 00:51:53 | zenspider | diff? yeah. that makes total sense... *sigh* |
| 00:52:11 | evan | or show |
| 00:52:14 | evan | git show stash@{1} |
| 00:55:46 | mernen enters the room. | |
| 00:58:57 | zenspider | gd? |
| 00:59:01 | zenspider | where is gd? |
| 00:59:03 | boyscout | 4 commits by Ryan Davis |
| 00:59:04 | boyscout | * Patched up complier to call __ versions of methods for defined; 11ae430 |
| 00:59:05 | boyscout | * Updated miniunit for latest rails atrocities; 79735d7 |
| 00:59:06 | boyscout | * Moved bigdecimal/util.rb from stdlib for AWDWR tests; 1c5e161 |
| 00:59:07 | boyscout | * I cheated... rescue false on YAML.load; 19db304 |
| 01:00:02 | benstiglitz leaves the room. | |
| 01:01:11 | evan | no clue |
| 01:01:11 | michaellatta leaves the room. | |
| 01:01:45 | lopex | evan: last question, aren't rubinius primitives considered somewhat intrinsics ? |
| 01:01:49 | evan | I added a fixup system to the Rakefile as well |
| 01:01:59 | evan | so that future things like this can be handled better. |
| 01:02:21 | evan | the Rakefile calls back 'rake git:post_update' after the new code has been brought in |
| 01:02:28 | evan | so the updated Rakefile can perform whatever fixups are needed |
| 01:02:56 | evan | lopex: not sure what ya mean by intrinsics |
| 01:03:14 | lopex | evan: just like memcpy, memset in gcc |
| 01:03:28 | evan | hm. no then. |
| 01:03:36 | evan | they perform primitive operations |
| 01:04:09 | lopex | an they're direct path to the vm api ? |
| 01:04:21 | lopex | er, vm runtime |
| 01:04:32 | evan | still unclear what you're saking |
| 01:04:34 | evan | asking |
| 01:05:14 | lopex | evan: just thinking about propagation of internall calls into vm |
| 01:05:41 | lopex | evan: but's just newbie question here |
| 01:05:50 | Fullmoon enters the room. | |
| 01:06:23 | antares leaves the room. | |
| 01:06:31 | crafterm enters the room. | |
| 01:08:08 | evan | ah |
| 01:08:08 | evan | ok |
| 01:08:11 | evan | i think i see what you're asking |
| 01:08:14 | evan | they do both |
| 01:08:17 | evan | so |
| 01:08:24 | evan | there are some like fixnum_add, that just add 2 numbers together. |
| 01:08:46 | evan | but object_send is also a primitive |
| 01:08:55 | evan | that manipulates the internal structure of the VM |
| 01:09:01 | evan | to call the specified method. |
| 01:09:06 | lopex | ah |
| 01:09:15 | lopex | er, mhm, I meant |
| 01:11:29 | lopex | evan: sorry me for comparing again to hotspot, but I'd like to get familatiar with rubinius challenges |
| 01:11:41 | evan | ah |
| 01:11:42 | evan | no problem. |
| 01:11:48 | evan | i like talking about that kind of thing |
| 01:11:56 | evan | just trying to be sure i'm answering the right question. |
| 01:12:16 | lopex | there's number of core java apis that's always consdered as intrinsics, so no native signature needed |
| 01:12:41 | evan | does hotspot create just a C api call to them then? |
| 01:12:44 | lopex | they always rewritten in term of vm |
| 01:12:49 | lopex | er, terms |
| 01:13:00 | lopex | evan: depends |
| 01:13:12 | evan | or inline the content of them |
| 01:13:21 | lopex | evan: it can either compile the call, or just generate the stub |
| 01:13:35 | lopex | depends how complex the tast is |
| 01:13:39 | lopex | er, taks |
| 01:13:44 | evan | sure. |
| 01:14:18 | santana_ enters the room. | |
| 01:14:21 | yipstar leaves the room. | |
| 01:14:23 | santana | hi |
| 01:14:31 | santana | I've got the cpp branch |
| 01:14:36 | santana | how do I build it |
| 01:14:43 | santana | the vm |
| 01:14:43 | lopex | evan: but is really strikes how similar the challenges are |
| 01:14:47 | evan | santana_: 'rake' |
| 01:14:51 | evan | lopex: yeh, very much so. |
| 01:15:00 | santana | I got some errors |
| 01:15:13 | santana | In file included from ar.cpp:1: |
| 01:15:13 | santana | ar.hpp:6:23: sys/cdefs.h: No such file or directory |
| 01:15:13 | santana | rake aborted! |
| 01:15:17 | evan | santana_: could you pastie them? |
| 01:15:22 | santana | ok |
| 01:15:26 | evan | santana_: you don't have libc6-dev installed |
| 01:15:36 | santana | it's Solaris |
| 01:15:42 | evan | arg. |
| 01:15:51 | drbrain | haha |
| 01:16:09 | evan | maybe solaris doesn't have cdefs.h? |
| 01:16:09 | santana | so, it requires glibc? |
| 01:16:10 | evan | i guess not. |
| 01:16:11 | evan | no |
| 01:16:12 | evan | it doesn't. |
| 01:16:30 | evan | what is ar.hpp using cdefs.h for... |
| 01:16:42 | evan | just remove it |
| 01:16:47 | evan | it's not needed i don't think |
| 01:16:54 | santana | ok, let's try |
| 01:17:17 | santana | more errors, I'm pastie-ing them |
| 01:17:56 | santana | http://pastie.caboo.se/201263 |
| 01:18:55 | evan | ack. |
| 01:19:00 | evan | the symlink isn't being made. |
| 01:19:25 | santana | hmm |
| 01:19:28 | evan | do |
| 01:19:36 | evan | cd vm; ln -s ../shotgun/external_libs . |
| 01:19:41 | evan | that will fix the ffi.h one |
| 01:19:44 | evan | looking at the other |
| 01:19:58 | evan | oh |
| 01:20:00 | evan | thats my mistake |
| 01:20:03 | evan | i'll fix them both |
| 01:20:03 | evan | one sec. |
| 01:20:11 | santana | sure |
| 01:20:36 | santana | by the way, is there a "building instructions" for the C++ vm? |
| 01:20:43 | evan | not currenly. |
| 01:20:44 | santana | I admit it, I haven't read one |
| 01:20:48 | santana | oh, ok |
| 01:23:09 | rubuildius_ppc enters the room. | |
| 01:24:43 | evan | santana_: ok, pushed |
| 01:24:49 | evan | i fixed the ar.hpp error too. |
| 01:24:51 | santana | pulling |
| 01:25:20 | boyscout | 1 commit by Ryan Davis |
| 01:25:21 | boyscout | * More rails hacks:; 5673309 |
| 01:26:10 | santana | should I still make the symlink? |
| 01:27:00 | twbray leaves the room. | |
| 01:27:08 | evan | no |
| 01:27:13 | evan | i moved the directory over. |
| 01:27:22 | santana | it's telling me about ffi.h missing |
| 01:27:36 | santana | ok, let me check again |
| 01:28:37 | evan | hm |
| 01:29:25 | santana | the includes? |
| 01:29:41 | evan | huh? |
| 01:30:02 | santana | somehow it's finding <ffi.h>, which I suppose is located under external_libs |
| 01:30:09 | evan | yep |
| 01:30:12 | santana | then, a -I flag is missing |
| 01:30:17 | evan | it's not. |
| 01:30:30 | santana | checking again |
| 01:30:50 | zenspider | evan: awdwr runs |
| 01:30:56 | evan | yay! |
| 01:31:13 | evan | how much of rails does it exercise? |
| 01:31:14 | evan | just curious |
| 01:31:15 | zenspider | they're chock full of stupid bugs, but that's the book's fault, not ours |
| 01:31:24 | zenspider | (escaping <p> and stuff in the product descriptions){ |
| 01:31:44 | zenspider | dunno... we ran the last depot, so it should be mostly complete if not totally |
| 01:32:15 | zenspider | should we check this in somewhere? |
| 01:32:22 | zenspider | or pop a tarball somewhere? |
| 01:32:28 | zenspider | or is this throwaway? |
| 01:32:37 | evan | lets check it in |
| 01:32:45 | evan | perhaps under benchmark? |
| 01:32:51 | evan | that seem like a logic place? |
| 01:33:08 | evan | or maybe |
| 01:33:12 | evan | test/demo/awdwr |
| 01:33:46 | zenspider | k. |
| 01:33:59 | zenspider | what about the rest of the tarball? |
| 01:34:05 | evan | whats in it? |
| 01:34:06 | zenspider | there are a ton of depots and stuff |
| 01:34:15 | zenspider | and then a lot of other stuff |
| 01:34:20 | zenspider | I didn't bother with the other stuff |
| 01:34:29 | zenspider | since I knew the depot was the book exercise |
| 01:34:29 | evan | check in the one that you ran as files |
| 01:34:33 | evan | and the rest as the tar.gz |
| 01:34:43 | evan | so we can reference if we need to |
| 01:34:50 | ShayArnett enters the room. | |
| 01:34:55 | zenspider | k |
| 01:36:40 | cezarsa enters the room. | |
| 01:38:16 | santana | I have deleted and re-checked out the cpp branch |
| 01:38:27 | MenTaLguY leaves the room. | |
| 01:39:02 | santana | and get this |
| 01:39:03 | santana | http://pastie.caboo.se/201280 |
| 01:39:21 | evan | could you paste more |
| 01:39:25 | santana | sure |
| 01:39:32 | evan | the lines before will tell me what it was doing when it hit that. |
| 01:41:30 | santana | http://pastie.caboo.se/201282 |
| 01:43:01 | evan | hm |
| 01:43:06 | evan | it's doing DEP that it occures.. |
| 01:43:35 | evan | santana_: do |
| 01:43:37 | evan | rake --trace |
| 01:43:42 | evan | and paste me the whole thing. |
| 01:43:53 | zenspider | slooooowly pushing. |
| 01:43:58 | zenspider | damn cafe |
| 01:44:09 | evan | it seems to be something different with solaris' g++ -MM |
| 01:44:28 | boyscout | 1 commit by Ryan Davis |
| 01:44:29 | boyscout | * Added test/demo/awdwr; 6d6570e |
| 01:47:24 | evan | zenspider: sweet, thanks. |
| 01:50:11 | jtoy enters the room. | |
| 01:50:41 | santana | evan: http://pastie.caboo.se/201290 |
| 01:51:06 | evan | arg |
| 01:51:12 | evan | trace didn't output the lines I wanted. |
| 01:51:21 | evan | thats my screw up. |
| 01:51:32 | evan | santana_: go look in vm/Rakefile |
| 01:51:39 | evan | line 16 |
| 01:51:45 | evan | the g++ -MM line |
| 01:51:59 | santana | ok |
| 01:52:03 | evan | could you print out what that line is before it's run? |
| 01:52:12 | evan | i'm wondering if includes is empty for some reason |
| 01:52:19 | evan | or if G++ is behaving oddly |
| 01:53:32 | santana | Rakefile:16 is a blank line |
| 01:53:35 | rubuildius_amd64 enters the room. | |
| 01:53:42 | santana | line 20 is @linker = "g++" |
| 01:53:50 | lopex leaves the room. | |
| 01:53:52 | santana | which is the body of cpp! method |
| 01:54:16 | evan | oh sorry |
| 01:54:17 | evan | 83 |
| 01:54:18 | santana | ok, I found the g++ #{includes} -MM line |
| 01:54:25 | santana | aha |
| 01:56:48 | santana | it's empty |
| 01:57:35 | moofbong enters the room. | |
| 01:57:42 | evan | thats odd. |
| 01:57:50 | evan | did i screw up the ordering i wonder.. |
| 01:57:52 | santana | I'll print more |
| 01:57:56 | dlee leaves the room. | |
| 01:57:57 | santana | includes and path |
| 01:58:31 | evan | even just p @includes |
| 01:58:32 | evan | in there |
| 01:58:37 | evan | should tell us whats up |
| 01:58:51 | santana | includes is fine |
| 01:58:55 | ezmobius | how much memory does rbx use when you have a rails app loaded? |
| 01:59:05 | rubuildius_ppc leaves the room. | |
| 01:59:11 | santana | -Iexternal_libs/libtommath -Iexternal_libs/onig -Iexternal_libs/libffi/include -Iexternal_libs/libltdl -Iexternal_libs/libev -Itest/cxxtest -I. |
| 01:59:38 | rubuildius_ppc enters the room. | |
| 01:59:47 | santana | path is the cpp file being compiled |
| 02:00:00 | santana | but data, the output of g++, is empty |
| 02:00:06 | evan | odd. |
| 02:00:11 | santana | it's not generating dependencies |
| 02:02:15 | evan | well |
| 02:02:23 | evan | it probably doesn't have anything in it because g++ spits out that error. |
| 02:02:27 | santana | it's probably because it doesn't find ffi.h |
| 02:02:35 | santana | aha |
| 02:02:43 | evan | look in external_libs/libffi/include |
| 02:02:46 | evan | is there an ffi.h? |
| 02:03:00 | santana | ../shotgun/external_libs/libffi/include/ffi.h |
| 02:03:00 | santana | ../shotgun/lib/subtend/ffi.h |
| 02:03:04 | santana | but not under vm |
| 02:03:38 | rubuildius_amd64 | Ryan Davis: 6d6570e4f; 2187 files, 7175 examples, 25803 expectations, 0 failures, 0 errors |
| 02:03:47 | evan | wait wait. |
| 02:03:52 | evan | my commit should have moved it. |
| 02:03:54 | evan | did it not? |
| 02:03:59 | evan | you should have vm/external_libs |
| 02:04:00 | djwhitt | hmm... I don't know why I have problems with runtime sometimes... seems to be ok now |
| 02:04:06 | evan | and no shotgun/external_libs |
| 02:04:28 | santana | I do |
| 02:04:39 | evan | did you get my commit? |
| 02:04:42 | santana | external_libs/libffi |
| 02:04:44 | evan | whats your top commit id? |
| 02:05:06 | santana | yours |
| 02:05:09 | santana | 006344a256c29c5cd350938de96e1954439b213c |
| 02:05:21 | santana | oh |
| 02:05:25 | santana | I have ffi.h.in |
| 02:05:46 | santana | I haven't built any external lib yet |
| 02:05:53 | santana | should I do it manually first? |
| 02:07:14 | evan | oh oh. |
| 02:07:24 | evan | go into external_libs/ffi |
| 02:07:27 | evan | and do ./configure |
| 02:07:30 | evan | did it create ffi.h? |
| 02:07:39 | evan | if so, we need to move configuring up to the beginning. |
| 02:08:09 | santana | it did |
| 02:08:16 | evan | ok, see if things work now. |
| 02:08:37 | lchin enters the room. | |
| 02:08:37 | santana | :), it looks better now |
| 02:08:42 | evan | yay! |
| 02:09:01 | santana | there's an error ...hmmm |
| 02:09:09 | santana | but it's Solaris' math.h |
| 02:09:12 | santana | argh |
| 02:09:30 | santana | builtin_bignum.cpp:694: error: `isinf' undeclared (first use this function) |
| 02:09:30 | santana | builtin_bignum.cpp:694: error: (Each undeclared identifier is reported only once for each function it appears in.) |
| 02:09:30 | santana | rake aborted! |
| 02:10:07 | evan | ack |
| 02:10:09 | evan | thats back. |
| 02:11:24 | santana | I thought libffi was going away |
| 02:11:33 | evan | no |
| 02:11:39 | evan | it's pretty new. |
| 02:11:50 | edwardam_ leaves the room. | |
| 02:12:45 | santana | in that case, I may modify libffi's configure to work around Solaris' math.h problem |
| 02:12:53 | evan | yes. |
| 02:12:59 | evan | go ahead. |
| 02:13:01 | santana | it's easy |
| 02:13:04 | santana | ok |
| 02:13:25 | santana | it may take some time |
| 02:13:32 | santana | I'm supposed to be working :) |
| 02:13:37 | evan | thats fine :) |
| 02:13:40 | evan | did you make the change in shotgun? |
| 02:13:44 | evan | in the other branch |
| 02:13:47 | santana | if not tonight... tomorrow |
| 02:13:56 | santana | I deleted it |
| 02:14:10 | evan | deleted what? |
| 02:14:22 | santana | because the C++ vm was not going not use libffi ... that's what I believed |
| 02:14:35 | santana | deleted my changes |
| 02:14:38 | evan | oh. |
| 02:14:46 | evan | no, we're going to use libffi |
| 02:15:19 | santana | np, I'm making the changes again |
| 02:15:22 | evan | ok. |
| 02:15:26 | santana | I'm going back to work |
| 02:15:32 | evan | sounds good. |
| 02:15:35 | santana | see you |
| 02:15:40 | evan | yes, see you. |
| 02:15:45 | santana_ leaves the room. | |
| 02:19:44 | cezarsa | evan: I want to make FIXNUM_P public avaliable in subtend, should I do like what was done with SYMBOL_P? |
| 02:20:05 | cezarsa | basicaly: |
| 02:20:11 | cezarsa | * #undef FIXNUM_P in ruby.c |
| 02:20:16 | cezarsa | * create a FIXNUM_P() function in ruby.c |
| 02:20:26 | cezarsa | * copy/paste oop.h #define FIXNUM_P to ruby.c renaming to RBX_FIXNUM_P |
| 02:20:31 | cezarsa | * use RBX_FIXNUM_Pin FIXNUM_P() function |
| 02:20:59 | evan | cezarsa: yeah |
| 02:21:05 | evan | follow SYMBOL_P |
| 02:21:30 | cezarsa | that copy/paste from oop.h doesn't seem much DRY |
| 02:21:42 | evan | yeah |
| 02:21:43 | evan | i know. |
| 02:21:47 | evan | thats ok for now. |
| 02:22:01 | cezarsa | ok, I'll follow it |
| 02:22:17 | shame enters the room. | |
| 02:29:37 | _VVSiz_ enters the room. | |
| 02:32:38 | lstoll enters the room. | |
| 02:36:48 | VVSiz_ leaves the room. | |
| 02:44:58 | Yurik-__ leaves the room. | |
| 02:46:55 | AndrewO enters the room. | |
| 02:53:14 | _VVSiz_ leaves the room. | |
| 02:53:33 | therealadam leaves the room. | |
| 02:53:39 | _VVSiz_ enters the room. | |
| 02:59:24 | wycats_ enters the room. | |
| 03:07:03 | twbray enters the room. | |
| 03:07:21 | rubuildius_ppc leaves the room. | |
| 03:07:55 | rubuildius_ppc enters the room. | |
| 03:09:54 | crafterm leaves the room. | |
| 03:10:21 | wycats_ leaves the room. | |
| 03:11:00 | wycats_ enters the room. | |
| 03:11:06 | twbray leaves the room. | |
| 03:12:15 | blakewatters enters the room. | |
| 03:12:21 | wycats_ leaves the room. | |
| 03:12:53 | wycats_ enters the room. | |
| 03:16:40 | blakewatters leaves the room. | |
| 03:17:25 | wycats leaves the room. | |
| 03:18:34 | wycats_ leaves the room. | |
| 03:18:48 | twbray enters the room. | |
| 03:18:51 | wycats enters the room. | |
| 03:19:01 | twbray leaves the room. | |
| 03:21:58 | twbray enters the room. | |
| 03:24:03 | headius enters the room. | |
| 03:24:20 | benburkert leaves the room. | |
| 03:26:35 | seydar enters the room. | |
| 03:26:40 | seydar leaves the room. | |
| 03:27:17 | cksouza enters the room. | |
| 03:27:37 | seydar enters the room. | |
| 03:27:47 | benburkert enters the room. | |
| 03:28:46 | vertiginous enters the room. | |
| 03:30:41 | seydar leaves the room. | |
| 03:34:19 | ezmobius leaves the room. | |
| 03:35:06 | nicksieger leaves the room. | |
| 03:37:09 | wmoxam enters the room. | |
| 03:37:32 | fbuilesv enters the room. | |
| 03:40:41 | RyanTM leaves the room. | |
| 03:42:24 | RyanTM enters the room. | |
| 03:47:48 | gramos leaves the room. | |
| 03:49:20 | twbray leaves the room. | |
| 03:51:42 | benburkert leaves the room. | |
| 03:53:20 | benburkert enters the room. | |
| 03:55:57 | crafterm enters the room. | |
| 04:00:46 | rue | Hm, discarded the half-and-half submodule mesh? |
| 04:03:04 | moofbong leaves the room. | |
| 04:04:40 | vertiginous leaves the room. | |
| 04:04:40 | mass leaves the room. | |
| 04:04:40 | smparkes leaves the room. | |
| 04:04:40 | ko1_away leaves the room. | |
| 04:04:40 | rudebwoy leaves the room. | |
| 04:04:40 | zenspider leaves the room. | |
| 04:04:40 | _VVSiz_ leaves the room. | |
| 04:04:40 | flori leaves the room. | |
| 04:04:40 | nemerle leaves the room. | |
| 04:04:40 | olabini leaves the room. | |
| 04:04:40 | robin_dewd leaves the room. | |
| 04:04:40 | Maledictus leaves the room. | |
| 04:04:40 | scudco leaves the room. | |
| 04:04:40 | Ingmar leaves the room. | |
| 04:05:04 | vertiginous enters the room. | |
| 04:05:04 | flori enters the room. | |
| 04:05:04 | Ingmar enters the room. | |
| 04:05:04 | nemerle enters the room. | |
| 04:05:04 | scudco enters the room. | |
| 04:05:04 | Maledictus enters the room. | |
| 04:05:04 | robin_dewd enters the room. | |
| 04:05:04 | olabini enters the room. | |
| 04:05:04 | rudebwoy enters the room. | |
| 04:05:04 | smparkes enters the room. | |
| 04:05:04 | mass enters the room. | |
| 04:05:04 | ko1_away enters the room. | |
| 04:07:46 | flori leaves the room. | |
| 04:07:47 | nemerle leaves the room. | |
| 04:07:47 | olabini leaves the room. | |
| 04:07:47 | scudco leaves the room. | |
| 04:07:47 | robin_dewd leaves the room. | |
| 04:07:47 | Maledictus leaves the room. | |
| 04:07:47 | Ingmar leaves the room. | |
| 04:07:47 | mass leaves the room. | |
| 04:07:47 | vertiginous leaves the room. | |
| 04:07:47 | smparkes leaves the room. | |
| 04:07:47 | ko1_away leaves the room. | |
| 04:07:47 | rudebwoy leaves the room. | |
| 04:10:31 | jzj enters the room. | |
| 04:11:39 | jeremydurham leaves the room. | |
| 04:19:20 | robin_dewd enters the room. | |
| 04:19:45 | AndrewO leaves the room. | |
| 04:24:25 | charlenopires leaves the room. | |
| 04:25:26 | charlenopires enters the room. | |
| 04:26:18 | wifelette enters the room. | |
| 04:28:05 | trythil enters the room. | |
| 04:29:17 | benburkert_ enters the room. | |
| 04:29:43 | vertiginous enters the room. | |
| 04:29:43 | rudebwoy enters the room. | |
| 04:29:43 | smparkes enters the room. | |
| 04:29:43 | mass enters the room. | |
| 04:29:43 | ko1_away enters the room. | |
| 04:30:04 | AndrewO enters the room. | |
| 04:30:58 | ezmobius enters the room. | |
| 04:33:23 | ezmobius leaves the room. | |
| 04:34:54 | fowlduck enters the room. | |
| 04:38:27 | dysinger enters the room. | |
| 04:43:02 | AndrewO leaves the room. | |
| 04:43:08 | wmoxam leaves the room. | |
| 04:46:34 | RyanTM leaves the room. | |
| 04:46:56 | benburkert leaves the room. | |
| 04:49:05 | AndrewO enters the room. | |
| 04:53:13 | fowlduck leaves the room. | |
| 04:57:49 | edwardam enters the room. | |
| 04:59:43 | AndrewO leaves the room. | |
| 05:04:08 | twbray enters the room. | |
| 05:07:06 | rue | Completely OT but anyone have a recommendation for an alternative to Fetchmail? |
| 05:11:10 | rue | Getmail, I suppose.. not a lot of competition there |
| 05:12:00 | brixen | rue: I use gmail :) |
| 05:12:01 | fbuilesv | rue: Gmail :P |
| 05:12:05 | brixen | hehe |
| 05:12:06 | fbuilesv | heh |
| 05:12:08 | fbuilesv | damn |
| 05:12:08 | brixen | fbuilesv: jinx:) |
| 05:13:09 | rue | I am avoiding Google. It is too big |
| 05:13:25 | brixen | rue: rumors of google stealing your email bits are exaggerated |
| 05:15:01 | rue | My life goal is for Google to not know absolutely everything about me at the time when Larry and Sergey kick the bucket |
| 05:15:14 | fbuilesv | rue: what do you use as a search engine then? |
| 05:16:00 | rue | Proxied |
| 05:16:46 | fbuilesv | ouch |
| 05:17:32 | fbuilesv | brixen: is there any way to modify rake spec:full to make it accept -j? |
| 05:18:13 | twbray leaves the room. | |
| 05:19:42 | rue | It should work fine just copying it out of ci, I imagine |
| 05:19:43 | brixen | fbuilesv: hmm, we could I suppose |
| 05:20:15 | fbuilesv | rephrase that question: Why isn't there a -j in the rakelib task :) |
| 05:20:21 | brixen | fbuilesv: we could just change the spec task command to bin/mspec -j -B full.mspec |
| 05:20:28 | brixen | heh, because it might break |
| 05:20:37 | brixen | it works for me on leopard :) |
| 05:20:38 | fbuilesv | brixen: yes, I'm not sure how safe/unsafe that option is |
| 05:20:41 | fbuilesv | same here |
| 05:21:00 | evan | evening. |
| 05:21:05 | brixen | fbuilesv: I really don't like rake commands for specs |
| 05:21:09 | brixen | evening evan |
| 05:21:19 | fbuilesv | evan: hola |
| 05:21:23 | fbuilesv | brixen: I just find it faster to type |
| 05:21:27 | brixen | fbuilesv: I'm editing -B to default to the extension .mspec |
| 05:21:47 | brixen | fbuilesv: yeah, you could create an alias too though |
| 05:22:11 | brixen | fbuilesv: how about rake spec:multi ? |
| 05:22:40 | fbuilesv | brixen: that sounds fine for me, I just didn't know if -j was non safe or something |
| 05:22:56 | brixen | well, I haven't had any trouble with it |
| 05:23:06 | brixen | I guess if people use it, we'll hear if it breaks |
| 05:23:32 | fbuilesv | yeah I guess, do you want to do it or want me to? |
| 05:24:10 | brixen | fbuilesv: go right ahead if you want. I'll know who to point at :) |
| 05:24:18 | fbuilesv | heh |
| 05:26:15 | evan | oh JRuby people.... |
| 05:26:18 | evan | i have a question.... |
| 05:26:27 | rubuildius_ppc leaves the room. | |
| 05:27:00 | rubuildius_ppc enters the room. | |
| 05:27:57 | headius | odd, I didn't get a beep for that |
| 05:27:59 | headius | maybe my highlight is case sensitive |
| 05:28:06 | evan | hehe |
| 05:28:10 | _VVSiz_ enters the room. | |
| 05:28:10 | olabini enters the room. | |
| 05:28:10 | Maledictus enters the room. | |
| 05:28:10 | scudco enters the room. | |
| 05:28:10 | nemerle enters the room. | |
| 05:28:10 | Ingmar enters the room. | |
| 05:28:10 | flori enters the room. | |
| 05:28:17 | zenspider enters the room. | |
| 05:28:18 | headius | ahh no, it just wasn't there |
| 05:28:20 | headius | what's up |
| 05:28:34 | evan | headius: how did you wire up DATA in jruby in compiled mode? |
| 05:29:15 | boyscout | 1 commit by Federico Builes |
| 05:29:16 | boyscout | * Adds a Rake task for CI on multiple processors; bf5f9e6 |
| 05:29:51 | headius | hmm, let me see |
| 05:30:00 | headius | I don't recall doing anything special for it |
| 05:30:12 | twbray enters the room. | |
| 05:30:49 | headius | show me an example quick, I can never remember the syntax |
| 05:31:01 | evan | put __END__ at the bottom |
| 05:31:06 | evan | and access DATA above it. |
| 05:32:40 | headius | hmmm, it works |
| 05:32:43 | headius | I don't remember doing that |
| 05:32:58 | headius | magic! |
| 05:33:03 | evan | heh |
| 05:33:44 | headius | might just be a parser question...something tom's doing that stuffs the data into a global structure pre-execute |
| 05:33:58 | evan | yeah |
| 05:33:59 | headius | and then I just compile that like anything else |
| 05:34:02 | evan | just curious about compiled mode |
| 05:34:21 | evan | mainly, running the code way after the .rb file is read |
| 05:34:27 | evan | like maybe, across runs |
| 05:34:29 | headius | does DATA parse as anything other than a constant? |
| 05:34:29 | evan | do you guys do that yet? |
| 05:34:33 | headius | I'm checking our special constants |
| 05:34:38 | evan | it's just a constant |
| 05:34:56 | headius | what do you mean, way after the .rb file is read |
| 05:35:02 | headius | like from another file later on? |
| 05:35:44 | evan | i thought you guys were walking about create .class files |
| 05:35:52 | evan | 'precompiled' files |
| 05:35:57 | headius | no, we never dump any files to disk |
| 05:35:58 | evan | not doing that? maybe i made that up |
| 05:36:00 | headius | they compile in memory |
| 05:36:17 | headius | you can forcibly precompile if you want, but it's not the default |
| 05:36:46 | headius | and most files don't compile at all, relying on jit later |
| 05:37:27 | evan | sure |
| 05:37:31 | evan | just curious. |
| 05:38:01 | benburkert_ leaves the room. | |
| 05:38:13 | headius | yeah, I don't know where DATA is wired up..I know enebo's fiddled with it a lot in the past |
| 05:38:20 | rubuildius_amd64 | Federico Builes: bf5f9e6ff; 2187 files, 7175 examples, 25803 expectations, 0 failures, 0 errors |
| 05:38:22 | headius | I'll try precompiling quick |
| 05:39:03 | evan | probably wired up by the parser |
| 05:40:00 | cyndis leaves the room. | |
| 05:40:11 | headius | yeah, looks like it doesn't ever hit the compiler |
| 05:40:13 | headius | pastie |
| 05:40:36 | pastie | http://pastie.org/201364 by headius. |
| 05:40:57 | headius | the contents of DATA appear nowhere in the precompiled output |
| 05:41:27 | headius | perhaps qualifies as a bug, but basically if it's not in the AST, I don't ever see it in the compiler |
| 05:41:50 | evan | yeah |
| 05:42:47 | evan | the constant pool is per class, right? |
| 05:42:54 | headius | yes |
| 05:43:01 | evan | what can it contain? |
| 05:43:21 | headius | literal strings, method signatures/names, type names |
| 05:43:46 | evan | that it? |
| 05:43:59 | headius | the #123 in that output is references to the constant pool |
| 05:44:15 | headius | integers and such are just in the bytecode directly |
| 05:44:34 | headius | I think you can shoehorn other byte data into the constant pool, but it's not typical |
| 05:44:53 | Erlang00t enters the room. | |
| 05:44:54 | evan | ok |
| 05:44:56 | evan | just curious. |
| 05:45:06 | Erlang00t | a bug |
| 05:45:10 | evan | since our CompiledMethods are setup so very similarly |
| 05:45:16 | Erlang00t | def foo(a,b,c=d=1) |
| 05:45:21 | Erlang00t | rubinius can't pass |
| 05:45:22 | evan | ew. |
| 05:45:25 | evan | wtf does that do? |
| 05:45:49 | headius | pastie |
| 05:46:02 | pastie | http://pastie.org/201365 by headius. |
| 05:46:16 | headius | there's the long output with constant pool, stack sizes, internal signatures and stuff |
| 05:46:37 | headius | nothing in this file corresponds to your CompiledMethod though |
| 05:46:49 | Erlang00t | http://pastie.org/201366 |
| 05:46:54 | headius | CompiledMethod would be equivalent to the eventual callable handle we bind to code in this output |
| 05:47:06 | headius | at "def" time, for example |
| 05:47:16 | Erlang00t | this one can't pass, rubinius can not generate bytecode |
| 05:47:39 | kw enters the room. | |
| 05:47:46 | evan | headius: I mean setup |
| 05:47:55 | rubuildius_ppc | Federico Builes: bf5f9e6ff; 2187 files, 7188 examples, 25847 expectations, 0 failures, 0 errors |
| 05:47:59 | evan | a CompiledMethod has a literals tuple (constant pool), etc. |
| 05:48:01 | mediogre enters the room. | |
| 05:48:19 | evan | Erlang00t: file a ticket. |
| 05:48:21 | headius | ahh, sure, I understand |
| 05:48:52 | headius | yeah, basically this uses a single constant pool for an entire .rb file compiled into .class, just the normal Java constant pool |
| 05:48:56 | Erlang00t | how to, where? |
| 05:49:13 | evan | Erlang00t: http://rubinius.lighthouseapp.com/projects/5089-rubinius/overview |
| 05:49:13 | headius | some other literals we cache on first construct and some not |
| 05:49:30 | evan | do you cache them into the constant pool directly? |
| 05:49:37 | evan | or as static class variables |
| 05:49:38 | headius | I think right now we cache symbols, bignum, and regex, but fixnums just go to a global cache of -127..128 |
| 05:49:45 | evan | (i guess those might be the same thing) |
| 05:49:50 | headius | anything outside that we construct new objects for every time |
| 05:50:02 | headius | constant pool is separate from static variables |
| 05:50:11 | evan | yikes, you hope your bignum cache is flushed. |
| 05:50:17 | evan | er. |
| 05:50:18 | evan | I hope. |
| 05:50:33 | rubuildius_ppc leaves the room. | |
| 05:50:34 | benburkert enters the room. | |
| 05:50:38 | headius | we don't cache anything as static variables that holds a reference to the JRuby runtime..so every compiled script is first instantiated with the runtime as a reference |
| 05:50:50 | cremes leaves the room. | |
| 05:50:56 | headius | so all calls from then on are calling instance methods on an AbstractScript subclass which has java fields for various caches |
| 05:51:09 | headius | that allows us to share the same compiled code across runtimes |
| 05:51:33 | headius | the bignum thing is only for literals |
| 05:51:37 | headius | pretty rare |
| 05:51:38 | evan | gotcha |
| 05:52:16 | headius | we also pre-construct the backing store for strings when a script is instantiated, and then only the RubyString objects are new each time |
| 05:52:31 | headius | due to COW, we basically just mark all new literal strings as shared, so they're cheap |
| 05:53:05 | _VVSiz_ leaves the room. | |
| 05:53:05 | zenspider leaves the room. | |
| 05:53:10 | flori leaves the room. | |
| 05:53:10 | nemerle leaves the room. | |
| 05:53:10 | scudco leaves the room. | |
| 05:53:10 | olabini leaves the room. | |
| 05:53:10 | Maledictus leaves the room. | |
| 05:53:10 | Ingmar leaves the room. | |
| 05:53:10 | evan | yep |
| 05:53:11 | evan | we do the same. |
| 05:53:37 | zenspider enters the room. | |
| 05:53:37 | _VVSiz_ enters the room. | |
| 05:53:37 | olabini enters the room. | |
| 05:53:37 | Maledictus enters the room. | |
| 05:53:37 | scudco enters the room. | |
| 05:53:37 | nemerle enters the room. | |
| 05:53:37 | Ingmar enters the room. | |
| 05:53:37 | flori enters the room. | |
| 05:53:52 | headius | okeedoke |
| 05:54:13 | headius | guess I've said all you care to hear :) |
| 05:54:20 | evan | nah! |
| 05:54:24 | evan | i love talking VM design |
| 05:54:30 | evan | I so rarely get to do it |
| 05:54:44 | evan | i look all over the net for descriptions and papers on VM construction |
| 05:55:33 | headius | btw, I didn't get to show you this the other day |
| 05:55:34 | headius | http://pastie.org/pastes/200438 |
| 05:55:55 | headius | tom and I were talking about adding a separate method cache to classes and I was curious about our current sclass cost |
| 05:56:03 | evan | heh |
| 05:56:05 | headius | seems like we're both a helluva lot better than MRI or 1.9 |
| 05:56:06 | evan | objc style. |
| 05:56:08 | headius | no idea what's going on there |
| 05:56:12 | anteaya leaves the room. | |
| 05:56:26 | evan | objc has a method cache per class |
| 05:56:33 | headius | we used to have such a cache, but it got removed in favor of one that was supposed to be better |
| 05:56:37 | headius | turned out not to be, now we have none |
| 05:56:44 | evan | there are some great papers about objc_msgsend |
| 05:56:56 | evan | how to make pulling from the method cache fast |
| 05:57:07 | headius | yeah, the cache isn't as hard as coming up with a safe way to invalidate it |
| 05:57:10 | evan | you still have the global one though, yeah? |
| 05:57:13 | headius | nope |
| 05:57:18 | headius | nothing but call site caches |
| 05:57:21 | evan | wow. |
| 05:57:30 | evan | thats probably good |
| 05:57:32 | headius | which don't do anything for send, respond_to, etc as you know |
| 05:57:37 | evan | gets you pushing on the call sites more. |
| 05:57:39 | evan | yep |
| 05:57:47 | headius | yeah...but we really need to get it back |
| 05:57:53 | headius | respond_to is hit hard, and we have no cache for it |
| 05:58:01 | headius | probably post 1.1.2 though |
| 05:58:05 | evan | gotcha |
| 05:58:24 | evan | i've been pondering more and more about having a shadow object in the VM |
| 05:58:26 | evan | one per class |
| 05:58:33 | evan | that stores and speeds things up |
| 05:58:41 | rubuildius_ppc enters the room. | |
| 05:58:55 | headius | a secondary abstraction of class internals? |
| 05:59:15 | headius | would the version presented to ruby then be more of a mirror? |
| 05:59:19 | cremes enters the room. | |
| 05:59:41 | evan | well, i'm thinking it would have info the class doesn't store |
| 05:59:44 | evan | info thats hidden from the GC |
| 05:59:52 | headius | ahh, like what |
| 05:59:53 | evan | and thus can be moreflexible |
| 06:00:18 | evan | well, i'm thinking thats where type specialized methods would be stored |
| 06:00:56 | headius | how would you handle the dispatching to them? |
| 06:01:30 | evan | well |
| 06:01:39 | evan | the method dispatch logic would look in them |
| 06:01:45 | evan | to find potential matches |
| 06:02:01 | evan | they'd be executed like normal |
| 06:02:04 | evan | that wouldn't change. |
| 06:02:15 | evan | in the new VM, a CompiledMethod object already has a shadow C++ object |
| 06:02:18 | evan | VMMethod |
| 06:02:41 | evan | that contains a runtime dependent version of the CM |
| 06:03:13 | evan | in the same way, I imagine, the JVM stores private, fast presentations of bytecode methods internally |
| 06:03:33 | headius | almost all bytecode is massaged on the way in, so yeah, there's something similar |
| 06:03:45 | headius | but of course, there's also the code cache for the jitted versions hanging around somewhere too |
| 06:03:56 | evan | course |
| 06:04:13 | headius | I don't believe the JVM specializes bytecode though |
| 06:04:15 | headius | the compiler does that |
| 06:04:22 | headius | JIT compiler I mean |
| 06:04:57 | headius | is this to allow you to dispatch more quickly to type-specific paths in core methods? |
| 06:05:30 | headius | or is this for general ruby code? I've been trying to think of a way to use type specialization in regular Ruby code, but it's a lot harder than in Java because there's so many variations |
| 06:06:04 | headius | currently we also don't have separate entry points into core class methods for specific parameter types...only for specific arities |
| 06:06:08 | evan | it would be for all ruby code |
| 06:06:34 | evan | everything is a type specific path |
| 06:06:52 | evan | it's just whether or not there is a type specific version of a method available |
| 06:07:32 | headius | so you would be doing much deeper analysis of the bytecode to determine which types follow which paths? in order to produce specialized partial methods? |
| 06:07:55 | evan | dunno |
| 06:08:08 | evan | right now, i'm thinking specialization of the bytecode based on new information |
| 06:08:11 | evan | for example |
| 06:08:16 | evan | the new ivar_as_index replacement |
| 06:08:51 | evan | the VM, based on a mapping of ivar to slot number, specializes the VMMethod to access the slot rather than using the ivar hashtable |
| 06:09:06 | evan | so while the normal bytecode says |
| 06:09:10 | evan | push_ivar :@blah |
| 06:09:20 | evan | the VM combines that with the information that :@blah => 3 |
| 06:09:24 | evan | to make that |
| 06:09:27 | evan | push_my_field 3 |
| 06:09:37 | headius | right, I see |
| 06:09:57 | evan | phase 1 i'm working on now, has the ivar => slot maps be static |
| 06:10:07 | evan | ie, it doesn't learn anything new |
| 06:10:21 | evan | it just uses maps generate at VM compiled time by looking at annotations of the builtin classes |
| 06:10:29 | headius | ahhh |
| 06:10:36 | michaellatta leaves the room. | |
| 06:10:48 | headius | so the methods themselves are still looking in a map for now |
| 06:11:09 | michaellatta enters the room. | |
| 06:11:09 | evan | sorta |
| 06:11:14 | evan | when the method is added to the class |
| 06:11:23 | evan | the VMMethod behind the CompiledMethod is specialized |
| 06:11:26 | evan | based on the class |
| 06:11:49 | headius | ok, gotcha, that makes sense |
| 06:12:13 | headius | so it inspects the body and only ivars that have been previously annotated thus are transformed into indexes |
| 06:12:17 | evan | yep |
| 06:12:21 | evan | a simple phase 1 |
| 06:12:31 | evan | with enough in place to make phase 2 easier |
| 06:12:57 | headius | that's a good idea...I wonder if that would work for my java layer |
| 06:13:24 | headius | there I've essentially already got the list of fields, right? so at method add time I could rewrite it to just be direct object field accesses when using a Java object |
| 06:13:47 | headius | I suppose that would work for jruby too...specially-named or annotated fields on the core classes that get wired up differently |
| 06:14:11 | evan | yeah |
| 06:14:13 | evan | same thing |
| 06:14:14 | headius | have to keep that in mind later...so far there hasn't been a need |
| 06:14:24 | evan | i've got it wired up through some C++ infrastructure |
| 06:14:34 | evan | so that assignment is type safe too |
| 06:14:38 | evan | so that |
| 06:14:40 | evan | class String |
| 06:14:42 | evan | def the_suck |
| 06:14:45 | evan | @data = 3 |
| 06:14:46 | evan | end |
| 06:14:46 | evan | end |
| 06:14:54 | evan | doesn't cause the STring to self destruct |
| 06:15:19 | evan | it would just raise a TypeError |
| 06:15:27 | evan | in this case, indicating that a Fixnum can't be use as a ByteArray |
| 06:15:39 | evan | thats one place where this arch is better than what we curretly have |
| 06:15:52 | headius | yeah, I want to start adding that in one of these iterations |
| 06:15:55 | evan | it limits duck typing |
| 06:15:57 | headius | we manually check types everywhere right now |
| 06:16:01 | evan | but you can't duck type all the way down |
| 06:16:06 | evan | it has to end somewhere |
| 06:16:13 | headius | ironruby has some extra sauce in their binding layer to do it |
| 06:16:34 | evan | i'm just using a simple script that pulls out data member annocations |
| 06:16:40 | evan | class String : public BuiltinType { |
| 06:16:41 | evan | ... |
| 06:16:46 | evan | ByteArray* data; // slot |
| 06:16:57 | vertiginous leaves the room. | |
| 06:17:01 | evan | it gives it a number, and generates glue to check that the type is ByteArray |
| 06:17:29 | headius | right, it would be something like @JRubyIvar ByteList value; for us |
| 06:17:36 | headius | to go with @JRubyMethod we have now |
| 06:18:10 | headius | given any more thought to stackless versus not? |
| 06:18:18 | evan | i'm back and forth constantly |
| 06:18:19 | evan | mentally. |
| 06:18:46 | fowlduck enters the room. | |
| 06:18:55 | headius | I saw a talk on stackless python at pycon, sounds like it's pretty mature and it's still a couple times slower than cpython |
| 06:19:06 | brixen | evan: how does that type checking work compared to RISA and RTYPE in shotgun? i.e. HASH_P uses RISA |
| 06:19:38 | evan | headius: i dunno if thats a symptom of them being stackless or all the stuff they had to add to make Python stackless |
| 06:19:47 | evan | ie, if it were stackless from the ground up, it would probably work better. |
| 06:19:48 | headius | yeah, me neither |
| 06:20:00 | headius | could be, I dunno |
| 06:20:07 | fowlduck leaves the room. | |
| 06:20:09 | evan | brixen: type checking in C++ |
| 06:20:11 | evan | ? |
| 06:20:20 | evan | i've always wanted to chat with those guys |
| 06:20:25 | evan | i have a front that works for IronPort |
| 06:20:30 | evan | s/front/friend/ |
| 06:20:31 | brixen | evan: so it's just C++ check then? |
| 06:20:50 | evan | all their products are based on an internal version of stackless python |
| 06:21:05 | evan | brixen: there is some special sause |
| 06:21:11 | evan | for example |
| 06:21:18 | evan | ByteArray* ba = as<ByteArray>(obj); |
| 06:21:31 | evan | if obj isn't a ByteArray, it throws a C++ TypeError exception |
| 06:21:35 | evan | which is translated into a ruby one |
| 06:21:50 | evan | as<> is a rubinius function template. |
| 06:21:54 | evan | which is very simple |
| 06:21:58 | evan | it's basically |
| 06:22:00 | headius | dynamic_cast |
| 06:22:15 | evan | if(T::type == obj->obj_type) return (T*)obj; |
| 06:22:19 | evan | throw TypeError(...); |
| 06:22:27 | evan | dynamic cast wont work for us |
| 06:22:29 | headius | seeing this almost makes me miss my C++ days |
| 06:22:30 | headius | almost |
| 06:22:33 | evan | but it works very similarly |
| 06:22:45 | brixen | evan: ok. I was trying to remember an issue I had converting stuff to LookupTable |
| 06:22:47 | evan | dynamic_cast only works for stuff with virtual functions |
| 06:22:51 | headius | yeah |
| 06:23:00 | brixen | evan: because it was expecting a Hash |
| 06:23:01 | headius | it's meant for stuff that fits fully into a C++ virtual class hierarchy |
| 06:23:11 | evan | brixen: ah, well, they're seperate types |
| 06:23:16 | evan | headius: yep |
| 06:23:27 | evan | our builtin class set is small enough |
| 06:23:34 | evan | it's actually not bad using our own versions |
| 06:23:38 | evan | you just have to do |
| 06:23:46 | evan | class Blah : public BuiltinType { |
| 06:23:56 | evan | const static object_type type = BlahType; |
| 06:23:56 | evan | ... |
| 06:23:57 | evan | } |
| 06:24:03 | evan | and it works with as<> automatically |
| 06:24:17 | evan | the type field on the class is what as uses |
| 06:24:42 | evan | brixen: they can't intermix anymore. |
| 06:24:57 | brixen | evan: yeah, I'm getting it |
| 06:25:22 | evan | doing |
| 06:25:27 | headius | is as<> smart about supertypes? or is your core class hierarchy flat? |
| 06:25:33 | evan | ByteArray *ba = (ByteArray*)obj; |
| 06:25:42 | evan | is strictly forbidden in the new VM |
| 06:25:46 | evan | that kind of cast. |
| 06:26:06 | evan | (and by strictly forbidden, i mean ok only in very few contexts) |
| 06:26:17 | evan | headius: thats the magic. |
| 06:26:17 | brixen | hehe |
| 06:26:29 | evan | headius: as<> is specialized per supertype |
| 06:26:33 | evan | to understand all subtypes |
| 06:26:41 | evan | it's a static thing |
| 06:26:41 | brixen | strictly forbidden except where it's not |
| 06:26:53 | evan | but not being totally magic is good |
| 06:26:58 | evan | keeps things slim. |
| 06:27:06 | headius | so then, it expands to a set of ifs or something? |
| 06:28:00 | evan | http://github.com/evanphx/rubinius/tree/006344a256c29c5cd350938de96e1954439b213c/vm/builtin_class. hpp#L87 |
| 06:28:06 | evan | as<> actually uses kind_of<> |
| 06:28:15 | evan | and kind_of<> is specialized |
| 06:28:27 | evan | that link is an example |
| 06:28:36 | headius | ok, got it |
| 06:29:07 | headius | out of curiousity, why didn't you make a real hierarchy and use virtual methods? |
| 06:29:32 | evan | a good question. |
| 06:29:50 | evan | initially, as I was prototyping this |
| 06:30:14 | evan | my aim was to create C++ who's internal structure was fully GC'able |
| 06:30:27 | evan | if you use virtual functions |
| 06:30:40 | evan | then the objects would contain a void* as the first datamember |
| 06:30:45 | evan | which would blow the GC up |
| 06:30:56 | evan | this is actually exactly how StrongTalk did it to |
| 06:31:40 | headius | ahh, I see |
| 06:32:15 | evan | so stuff like single inheritance to make sure the data is layed out sanely, etc. |
| 06:32:43 | headius | yeah, that's a good point...and vtable logic isn't always portable |
| 06:32:47 | evan | ironically, with the annotations, the GC is small enough to know exactly where GCable fields are located in the builtin types |
| 06:32:53 | evan | s/small/smart/ |
| 06:33:34 | evan | so it doesn't have treat them like untype boxs of references |
| 06:33:45 | evan | it can know exactly where to look |
| 06:33:58 | evan | so i could potentially have virtual functions now. |
| 06:34:07 | evan | but i think i'm going to avoid them for now |
| 06:34:13 | headius | so you use the annotations to also advise the GC on which references it should be tracking |
| 06:34:18 | evan | since thats how I've started out |
| 06:34:24 | evan | yep |
| 06:34:37 | evan | the annotations generate a mark glue function |
| 06:34:50 | evan | each BuiltinType has a Info subclass too |
| 06:34:52 | headius | primary reason I asked about virtual methods would be the ease of interfacing with stuff outside rubinius |
| 06:34:54 | evan | which is a TypeInfo subclass |
| 06:35:03 | headius | but since you're still stackless the builtin methods already have a lot of prerequisites |
| 06:35:19 | evan | the mark function is generate for each BuiltinType's Info |
| 06:35:21 | headius | it would be like calling one of our dumb compiled bodies without the appropriate stack fiddling |
| 06:35:44 | evan | yeah |
| 06:35:47 | evan | actually |
| 06:36:20 | evan | the method dispatch logic (post lookup), is one line: |
| 06:36:26 | evan | as<Executable>(msg.method)->execute(state, this, msg); |
| 06:37:09 | evan | Executable::execute dispatches to a virtual function, VMExecutable::execute |
| 06:37:16 | evan | of which, VMMethod overrides |
| 06:37:20 | evan | ditto with VMPrimitiveMethod |
| 06:37:36 | headius | yeah, more and more similar to what we have |
| 06:37:45 | headius | DynamicMethod and its subtypes that override virtual methods |
| 06:37:58 | headius | JavaMethod, DefaultMethod (bad name, should be InterpretedMethod), CompiledMethod |
| 06:38:16 | evan | yep |
| 06:38:18 | headius | we essentially only have the objects equivalent to your VMMethods |
| 06:38:26 | _sk enters the room. | |
| 06:38:28 | evan | VMMethod twiddles the status of the current Task object |
| 06:38:32 | evan | so that when things return |
| 06:38:39 | evan | the Task is now executing the new method |
| 06:38:41 | evan | stackless |
| 06:38:55 | kw leaves the room. | |
| 06:38:55 | mass leaves the room. | |
| 06:38:55 | smparkes leaves the room. | |
| 06:38:55 | ko1_away leaves the room. | |
| 06:38:55 | rudebwoy leaves the room. | |
| 06:39:13 | headius | in our case it just twiddles the thread-specific stacks on the way in and out |
| 06:39:24 | evan | whats in those stacks? |
| 06:39:27 | evan | scope and such? |
| 06:39:43 | headius | my stackless version essentially returned separate callables for those that were executed at the same level |
| 06:39:47 | headius | yeah |
| 06:39:50 | headius | scope, frame, rubyclass, etc |
| 06:41:50 | evan | I think that i've come up with a way to use LLVM stackless, which is something i really want to investigate soon. |
| 06:42:03 | headius | oh yeah? it's capable of that? |
| 06:42:17 | headius | or is it something where you'd have to decorate the llvm IL to trampoline? |
| 06:42:20 | evan | depends on how you use it :) |
| 06:42:44 | headius | I had a trampolining decorator I played with on JVM to make normal Java calls stackless, and it worked reasonably well |
| 06:42:51 | foysavas leaves the room. | |
| 06:43:11 | evan | my thinking is to translate a bytecode method into an LLVM function |
| 06:43:22 | evan | each LLVM function is split into a number of blocks |
| 06:43:26 | headius | there's an actual library out there now though, that you can use to transform any method into a non-stack-deepening version...basically just converts calls into returns of specific markers, then the caller does the call for it and calls back in |
| 06:43:33 | evan | to perform a stack deeping ruby call |
| 06:43:37 | headius | yeah |
| 06:43:49 | evan | the function sets up some state (including the number of the next block) and returns |
| 06:43:56 | headius | that's what I mocked up in jruby too |
| 06:44:01 | evan | the VM goes off and starts executing |
| 06:44:06 | evan | and to return |
| 06:44:15 | evan | the first thing the LLVM function always does is branch to the block number passed in |
| 06:44:39 | evan | it's certainly not as fast as using LLVM's invoke instruction to deepen the C stack |
| 06:44:43 | headius | though my experiment trampolined every time there would be a potential Ruby thread switch, to allow swapping in a new runnable |
| 06:44:51 | headius | yep, I used a switch for mine |
| 06:44:52 | evan | but it eliminates bytecode dispatch entirely |
| 06:44:53 | headius | same thing |
| 06:45:11 | evan | what do you mean trampolined? |
| 06:45:20 | evan | used exceptions to unwind? |
| 06:45:35 | headius | every call into a method is guaranteed to bounce back out, either with a final return or with a new deeper call to execute |
| 06:45:47 | headius | mine didn't use any exceptions |
| 06:45:57 | evan | yep, same thing i'm considering. |
| 06:45:57 | headius | but there are others who have done that on JVM also |
| 06:46:41 | evan | interesting. |
| 06:46:52 | headius | usually to emulate things like continuations or coroutines |
| 06:46:59 | evan | you decided against it because it's just not fast enough? |
| 06:47:07 | evan | as just deepening the java stack |
| 06:47:09 | headius | wasn't really useful enough |
| 06:47:33 | headius | and we can't do it to the rest of the stack we don't control anyway |
| 06:47:45 | evan | yeah |
| 06:47:50 | evan | thats one problem I don't have |
| 06:47:58 | evan | which has it's ups and downs. |
| 06:48:1 |