Da
Show enters and exits. Hide enters and exits.
| 00:36:07 | boyscout | Refactoring BlockEnvironment using the interpreter - ceee888 - Evan Phoenix |
| 00:37:00 | evan | ok, now I have a place to put a JIT'd block. |
| 00:43:45 | boyscout | CI: ceee888 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 00:44:25 | evan | we need to be careful about not getting a commit thats 6666666! |
| 00:44:48 | lopex | why ? |
| 00:44:49 | tarcieri | hahaha |
| 00:44:54 | evan | lopex_: just being silly. |
| 00:45:08 | tarcieri | loves funny git hashes |
| 00:45:22 | evan | ceee888 is pretty eird. |
| 00:45:23 | evan | weird. |
| 00:47:13 | lopex | evan: just being acerbic :D |
| 00:47:28 | ddub | can't wait for cafebad |
| 00:47:44 | lopex | just looked up that word in a dict |
| 00:47:53 | ddub | or maybe dedbeef ? |
| 00:48:27 | lopex | maybe it was meant to be weee ? |
| 00:48:45 | lopex | weee666 |
| 00:49:17 | rue | evan: Do const pointers have significance for LLVM? |
| 00:50:09 | slava | const pointers can potentially improve alias analysis so I'd use them where possible in generated code, in any case |
| 00:51:12 | rue | Half the codebase should essentially be const, sure :) |
| 00:51:41 | slava | are you talking about const in your C++ code? |
| 00:51:53 | slava | I'm pretty sure code generators ignore that, because of const_cast hindering any analysis |
| 00:53:10 | rue | He added a couple * const, I was wondering if there was a particular significance |
| 00:55:24 | rue | evan: And on the style front, might we consider dropping the opening brace to the next line for those long argument lists? The double-indent just looks like the first line of the body got indented wrong to me, but that might just be me. |
| 00:56:16 | evan | which? |
| 00:56:49 | evan | rue: no LLVM doesn't use const |
| 00:57:00 | evan | i added those just to be clear to the user |
| 00:57:25 | rue | E.g. vm/builtin/block_environment.cpp:120 |
| 00:57:45 | evan | you want to put the { on the next line? |
| 00:58:28 | rue | Yeps |
| 01:00:01 | evan | when the definition spans multiple lines, i think thats ok. |
| 01:00:14 | evan | but when it's all on one line, the { should stay on that line |
| 01:00:43 | rue | Okaydoke * 2 |
| 01:08:52 | headius | hey, I haven't looked at your profiling stuff, but is it in ruby or C++? |
| 01:09:39 | evan | the data generator is wired into the VM at the C++ level. |
| 01:10:05 | headius | I see |
| 01:10:17 | headius | I thinking I could add that and have the ruby part just work for jruby as well |
| 01:10:19 | evan | brixen most of the analyzer in ruby though |
| 01:10:29 | evan | briken wrote, rather. |
| 01:10:38 | headius | I get it |
| 01:10:47 | slava | hi headius |
| 01:10:52 | headius | slava: hello there |
| 01:11:00 | slava | headius: IIRC you were looking into adding some dataflow optimizations to JRuby |
| 01:11:05 | headius | yes |
| 01:11:14 | headius | post javaone, but it will be part of new compiler work |
| 01:11:42 | rue | Along with the pool |
| 01:12:51 | headius | evan: got a pointer to where this is in the vm? I don't see an obvious "profiler.cpp" |
| 01:13:34 | headius | maybe instruments |
| 01:14:13 | evan | yep. |
| 01:14:20 | rue | vm/instruments |
| 01:14:23 | headius | lot more cpp than I expected |
| 01:14:32 | rue | And the Ruby side goes lib -> lib -> kernel |
| 01:14:58 | evan | headius: thats because it's not just firing a giant stream of data |
| 01:15:09 | evan | it builds a few trees in C++ |
| 01:15:15 | evan | for the ruby to make sense of |
| 01:16:18 | headius | yeah, I see |
| 01:16:31 | headius | hmm well that's too bad, looks like the bulk of the logic is in cpp |
| 01:18:30 | evan | depends |
| 01:18:36 | evan | on what you see as the bulk of the logic |
| 01:18:47 | evan | there is considerable logic in C++, yes. |
| 01:19:02 | slava | rubinius has too much logic in C++ in general :) |
| 01:19:26 | evan | slava: perhaps. |
| 01:19:39 | headius | well, I was hoping the C++ just did callbacks to ruby when an event boundary was crossed or just gathered raw data and then tossed that over |
| 01:20:00 | evan | it's not just rb_event_hook |
| 01:20:02 | evan | no. |
| 01:20:17 | headius | maybe I'll see if I can get zenprofile to work then |
| 01:20:26 | headius | it has some C in it but it's all event-hook based, which we have |
| 01:20:48 | evan | you guys have no profiler now? |
| 01:21:12 | headius | well, there's a few half-assed options for profiling ruby |
| 01:21:29 | headius | tons for profiling everything, of course, but that's too much noise for rubyists |
| 01:21:42 | headius | twould be like having a profile include all your C++ code as well |
| 01:22:02 | evan | sure |
| 01:22:03 | headius | and the library functions your C++ code calls |
| 01:22:14 | evan | etc, etc, etc. |
| 01:22:14 | headius | we need something that's just ruby |
| 01:22:15 | evan | yep. |
| 01:22:38 | rue | `profile_data.reject {|line| line =~ javaish }` |
| 01:22:48 | rue | Problem solved :) |
| 01:24:09 | boyscout | Added Hash benchmarks. - 60a6e89 - Brian Ford |
| 01:24:09 | boyscout | Rework prototype Cuckoo Hash to pass specs. - b6f3796 - Brian Ford |
| 01:25:32 | ddub | cuckoo hash? |
| 01:26:29 | boyscout | CI: b6f3796 success. 2682 files, 10322 examples, 32867 expectations, 0 failures, 0 errors |
| 01:26:36 | rue | ddub: It is like a hash |
| 01:27:49 | headius | rue: except that profiling every java function tends to skew results just a tad |
| 01:27:57 | headius | instrumenting everything slows execution down 1000% |
| 01:28:05 | headius | or more |
| 01:28:27 | headius | brixen: how's the cuckoo looking now? |
| 01:29:40 | rue | Well, technically, slowing _everything_ down 1000% is not "skewing" |
| 01:29:46 | evan | headius: what Java profiler do you use? |
| 01:30:46 | evan | i might call it deawesoming |
| 01:30:55 | evan | (slowing everyting down 1000%) |
| 01:32:06 | brixen | headius: it's got bad hash functions atm that behave very poorly ~20% of the time, but even with that it is currently benching on par with the chained bucket we have |
| 01:32:57 | brixen | you can see the hash benches I just committed |
| 01:33:34 | brixen | rake -q bench:dir DIR=benchmark/rubinius/hash VM='rbx -r cuckoo' HASH_CLASS=Rubinius::Cuckoo |
| 01:35:04 | brixen | headius: the benches are based on data from http://gist.github.com/113844 |
| 01:35:43 | ddub | oh interesting algorithm |
| 01:36:15 | evan | i wonder if I can just make this a better Fixnum#hash... |
| 01:36:20 | evan | headius: what do you use for Fixnum#hash |
| 01:36:20 | evan | ? |
| 01:37:02 | ddub | wonders what alternatives would exist for Fixnum#hash and why they would be chosen |
| 01:37:37 | evan | bask in the glory of integer hash functions: http://burtleburtle.net/bob/hash/integer.html |
| 01:37:40 | ddub | I'd probably favor an implementation that returns itself. |
| 01:37:54 | ddub | basks in the ugly green glory |
| 01:38:03 | evan | you'd think so |
| 01:38:12 | evan | but thats nearly the worst hash function possible for a Fixnum |
| 01:38:14 | evan | it terms out. |
| 01:38:17 | evan | turns out. |
| 01:38:45 | ddub | what do you use for the second hashing function in a cuckoo hash? |
| 01:38:47 | ddub | hash + 1? |
| 01:39:25 | evan | (key_hash ^ 0xaaebc93) |
| 01:39:29 | evan | I COMPLETELY made that up |
| 01:39:32 | evan | on the spot |
| 01:39:37 | evan | at 4am on an airplane |
| 01:39:59 | evan | after 2 glasses of red wine |
| 01:40:03 | slava | the second hash function should be key_hash >> log2(size of hash) |
| 01:40:16 | evan | slava: so all 0? |
| 01:40:17 | evan | :/ |
| 01:40:28 | ddub | or 1 |
| 01:40:42 | slava | no, you want one set of bits for the first hashcode and another set of bits for the second |
| 01:41:23 | ddub | I guess evan's makes more sense than mine, as rebuilding the hash will change the secondary values more |
| 01:41:24 | evan | actually, thats not a terrible idea. |
| 01:41:45 | evan | but that assumes that the initial hashcode distributes over 32bits |
| 01:41:52 | evan | which is an invalid assumption |
| 01:41:52 | evan | :D |
| 01:41:56 | ddub | if you had a bunch of values that hashed close the first time, they would continue to hash close after the table was rebuilt, while that big xor, once you modded things, would probably prevent that |
| 01:42:22 | ddub | evan: use integer hashing on the returned hashcode! :D |
| 01:42:39 | evan | a good idea |
| 01:42:42 | slava | evan: then you can make your hashcode better first, and take the high and low bits |
| 01:42:48 | evan | need a decent way to get an initial hash then. |
| 01:42:55 | slava | cuckoo hashes are sort of a pain, because they're not general purpose |
| 01:43:06 | slava | what you really want is for the user to be able to provide their own hash functions |
| 01:43:12 | evan | it all comes down to having at least ONE way to get a properly distributed hashcode |
| 01:43:23 | slava | that's the problem, its impossible in the general case |
| 01:43:33 | rue | slava: (And users who can provide their own hash functions:) |
| 01:43:36 | rue | BYOHF |
| 01:44:03 | slava | booyaaa |
| 01:44:09 | slava | users? who needs those |
| 01:44:21 | ddub | I sense Object#hash2 coming |
| 01:45:55 | ddub | I have implemented a hash function before where items are basically put in the first free spot in an array after their index |
| 01:45:57 | slava | ddub: that's not a bad idea |
| 01:46:20 | slava | ddub: that's an open addressing hashtable, and its superior to bucket chaining in almost all respects |
| 01:46:30 | slava | you guys should implement that instad of cuckoo hashing |
| 01:46:53 | evan | irb(main):001:0> 1.hash |
| 01:46:53 | evan | => 881230262 |
| 01:46:53 | evan | irb(main):002:0> 2.hash |
| 01:46:53 | evan | => 577222732 |
| 01:46:54 | ddub | the advantage of cuckoo hashing is a faster lookup on conflict |
| 01:46:56 | evan | booya |
| 01:47:40 | rue | `class Fixnum; def hash(); puts "Use an Array, you lazy bum"; end; end` |
| 01:49:06 | evan | slava: we may |
| 01:49:10 | evan | slava: we're sort of playing |
| 01:49:22 | evan | ie, we might use cuckoo hash for MethodTables |
| 01:49:51 | slava | your general-purpose hash should be open addressing, not chaining |
| 01:50:38 | rue | + 1 % size? |
| 01:50:47 | evan | how open? |
| 01:50:48 | evan | just 1? |
| 01:51:08 | slava | yeah |
| 01:51:27 | evan | we'll give that a shot |
| 01:51:28 | evan | ok, |
| 01:51:30 | evan | cavs game on |
| 01:51:32 | evan | go cavs! |
| 01:51:42 | evan | bbiab |
| 01:51:48 | ddub | I love how mri's fixnum#hash is basically (intptr_t)obj; |
| 01:52:03 | slava | doesn't mri have tagged fixnums? |
| 01:52:07 | slava | or are they heap-allocated? |
| 01:52:17 | brixen | tagged |
| 01:52:17 | ddub | tagged |
| 01:52:35 | ddub | so 1 hashes to 3, 2 to 5, 3 to 7, etc. |
| 01:52:40 | slava | ok |
| 01:53:13 | brixen | good stuff http://www.cs.sunysb.edu/~algorith/implement/LEDA/implement.shtml |
| 01:53:51 | evan | ok |
| 01:53:52 | evan | nm |
| 01:53:53 | evan | BACK |
| 01:53:55 | evan | commercial |
| 01:53:59 | evan | ok |
| 01:54:05 | evan | one spec failure on the new Fixnum#hash |
| 01:54:07 | slava | ddub: 0 is the one true fixnum tag(tm) |
| 01:55:22 | ddub | I think symbols hash the same way, but somehow via their location in the symbol table |
| 01:55:35 | ddub | so :class.hash has a way lower number than :madeupsymbol.hash |
| 01:56:29 | ddub | and they seem to increment by 80 when you make up newer values, at least within irb |
| 01:56:32 | evan | yeah, it does. |
| 01:57:01 | ddub | if only I could look at the MRI source code. but I'm hindered by my lack of interest |
| 01:57:04 | ddub | :) |
| 01:57:37 | evan | i'm happy to be your MRI source proxy :D |
| 01:57:43 | ddub | oh, re: compiler earlier, I was looking at what I could do with c++ generation in bison. |
| 01:58:20 | evan | cool |
| 01:58:25 | ddub | it seems limited though; for example, it looked like it was requiring iostreams, and it looked like you couldn't control the namespace fully |
| 01:58:48 | ddub | also, that they had made improvements in 2.4, while leopard ships with 2.3 |
| 01:59:45 | ddub | but yeah, I was looking at a way to make the parser one class with a public interface and self-contained parser state |
| 01:59:50 | evan | brixen: check out line 48 in core/hash/rehash_spec.rb |
| 01:59:51 | ddub | (2.3 vs. 2.4 of bison) |
| 02:01:48 | brixen | evan: um... |
| 02:02:05 | brixen | why is that a spec? |
| 02:02:08 | evan | that spec is dependent on Fixnum#hash |
| 02:02:18 | evan | it's failing because I changed Fixnum#hash to not just return itself |
| 02:02:25 | brixen | yeah, no idea why that is something to spec |
| 02:02:43 | brixen | there's a Hash spec that #shift return elts in the same order as #to_a |
| 02:02:48 | brixen | which should also go |
| 02:03:51 | evan | yeah, i don't see what it's really spec'ing |
| 02:04:00 | brixen | me neither |
| 02:04:15 | brixen | I'm pulling in rubyspec for Hash and I'll remove those |
| 02:04:20 | evan | 10-4 |
| 02:04:28 | evan | i'll hold on off on this commit until i see your update |
| 02:13:07 | boyscout | Fixed a couple nonsense Hash specs. - 2d762d6 - Brian Ford |
| 02:16:48 | boyscout | CI: 2d762d6 success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 02:19:49 | evan | I wonder if I should modify Symbol#hash to use the mix function too... |
| 02:22:51 | brixen | probably |
| 03:04:08 | yakischloba | evan, rue: i wrote up a #read_array_of_string for ruby-ffi. This makes it much faster. Is such a method viable for other FFI implementations (or even this one?) |
| 03:04:30 | yakischloba | err. *get*_array_of_string |
| 03:25:09 | evan | yakischloba: whats it look like? |
| 03:25:28 | yakischloba | well. it does have to assume that the strings are null terminated. |
| 03:26:05 | yakischloba | pls dont laugh if it sucks :) |
| 03:26:07 | yakischloba | http://pastie.org/private/t02xtphjrxcdcwx7fq |
| 03:28:45 | evan | no, thats fine |
| 03:28:49 | evan | thast a common enough pattern |
| 03:29:13 | yakischloba | do you think it was previously absent just because no one had needed it? |
| 03:29:18 | evan | likely |
| 03:30:40 | yakischloba | for my test with 5000 iterations of the query with a large result, using that method took me from 112 seconds down to 77 (with mysql gem at 59) |
| 03:34:34 | headius | evan: (int)(value ^ value >>> 32) |
| 03:37:15 | slava | that's a bad hash functions |
| 03:41:16 | headius | it's what MRI does |
| 03:41:42 | yakischloba | evan: i am submitting to ruby-ffi. i take it you will include it in rubinius ffi at some point then? |
| 03:42:44 | headius | actually I'm not sure where we got this hash from |
| 03:44:56 | headius | yakischloba: cool |
| 03:45:09 | yakischloba | headius: will you also support this? |
| 03:45:33 | headius | well, since wayne does our ffi, I'm sure it will be in a release real soon after it's in ruby-ffi |
| 03:45:48 | headius | especially if it has a good use case and much better perf |
| 03:45:53 | yakischloba | oh, i did not know that |
| 03:46:18 | yakischloba | well i just sent an email to that ML so we shall see soon. |
| 03:46:18 | headius | yeah, he did ours first and then did ruby-ffi |
| 03:46:35 | yakischloba | i see |
| 03:46:35 | headius | well ours first after rbx came up with the FFI APIs that is |
| 03:48:30 | yakischloba | so rbx and wayne are basically who decide what the APIs are to be? |
| 03:54:51 | headius | I think anyone using ffi helps make that decision |
| 03:55:01 | evan | we're open |
| 03:55:03 | headius | ruby-ffi seems to be the best place to discuss changes though |
| 03:55:07 | evan | wayne has run away with the API |
| 03:55:09 | headius | since it's the most widely-used ffi now |
| 03:55:10 | evan | so they're not in sync |
| 03:55:25 | evan | and we need to get the rubinius API back in sync |
| 03:55:42 | yakischloba | heh |
| 03:55:50 | yakischloba | need to get more people using FFI :p |
| 03:55:55 | headius | truly |
| 03:57:06 | yakischloba | and half of what I should have said is: "need more documentation" |
| 03:58:55 | headius | ahh documentation |
| 03:59:18 | yakischloba | i just said to someone else in another channel after htey said "ffi has enum stuff?" |
| 03:59:36 | yakischloba | yes ffi has all kinds of shit you would never dream of by looking at the doc/example on the website |
| 04:00:48 | yakischloba | i think a lot of people look at it and say "ok great, how do i write something that isnt fibonacci" |
| 04:06:01 | headius | I'd like to see more use of the swig generator |
| 04:06:09 | headius | we could probably get a lot of libraries wired up really quickly |
| 04:06:13 | headius | have you played with it at all? |
| 04:06:20 | headius | I got it to work for something really simple |
| 04:06:20 | evan | no one knows how to use it |
| 04:06:33 | evan | i don't know that there is any info on it |
| 04:06:37 | headius | well, you have to know how to use swig first off, which took some bootstrapping |
| 04:06:42 | yakischloba | no. i barely even know what swig is. i have avoided it since i decided (without knowing anything about it) that it was icky |
| 04:06:43 | headius | there's a readme and some examples in it |
| 04:06:59 | slava | swig is useful for binding to C++ libraries |
| 04:07:33 | headius | the swig generator doesn't even need swig at runtime, it just uses it to generate ffi bindings |
| 04:08:44 | yakischloba | is the result clean? |
| 04:08:57 | yakischloba | can you go in and understand wtf it means and edit it? ;) |
| 04:09:20 | headius | yeah, it's pretty good |
| 04:09:28 | headius | check it out and run some examples, it's not bad |
| 04:09:39 | headius | I was over-ambitious at first, trying to generate bindings for all of libc for example |
| 04:09:46 | yakischloba | :) |
| 04:13:35 | headius | that andrea fellow was able to generate a full set of opengl bindings though, so I presume it works |
| 04:25:46 | slava | I don't think opengl bindings can be generated automatically |
| 04:26:00 | slava | at least not for gl extensions, because you call those through a function pointer |
| 04:26:05 | slava | if you want enough gl to run glxgears, sure you can use swig though :) |
| 04:33:42 | headius | evan: is the jit hooked up by default yet, or still needs to be turned on? |
| 04:33:58 | headius | or rather, does it get compiled |
| 04:34:16 | evan | it's not running based on method usage |
| 04:34:24 | yakischloba | hey what is a good palce to read about VM stuff for noobs? |
| 04:34:32 | evan | only explicitly by calling Rubinius.jit or Rubinius.jit_soon |
| 04:34:48 | headius | jit_soon punts it to the jit thread I presume |
| 04:34:54 | evan | yep |
| 04:35:00 | headius | which is still GILed or not? |
| 04:35:06 | evan | nope |
| 04:35:09 | headius | ok |
| 04:35:16 | evan | runs in parallel |
| 04:35:19 | headius | that's why you made the symbol change I suppose |
| 04:35:23 | evan | yep |
| 04:36:04 | headius | okeedoke |
| 04:36:59 | headius | is that the only thread-related fix you had to make for it? |
| 04:39:45 | yakischloba | anyone? :) |
| 04:41:45 | headius | yakischloba: I just guess at it |
| 04:41:56 | headius | I'm sure these guys have some resources though |
| 04:42:19 | yakischloba | headius: i mean for serious noobs, ie i barely know what a VM does |
| 04:43:30 | headius | well, it really just handles allocating/collecting data structures and executing instructions at a level higher than the native CPU |
| 04:43:47 | headius | there's more to it obviously, but I think you probably already know more than you think |
| 04:44:13 | headius | it's a program that runs programs :) |
| 04:44:16 | yakischloba | so higher level than the CPU but lower level than C for instance ya? |
| 04:44:31 | headius | well, depends if you mean C as a language or C as what it compiles to |
| 04:44:57 | yakischloba | what it compiles to. but that is also something i do not understand |
| 04:45:19 | headius | imagine taking an instruction set like x86 ASM and just writing a program with fake registers and fake memory that walks those instructions |
| 04:45:33 | headius | that's all there is to it really |
| 04:45:58 | headius | rubinius, yarv, jvm all have their own instruction sets and their own sets of "primitives" to allocate objects and interact with the OS |
| 04:46:49 | yakischloba | so the point of the VM is to create an instruction set abstraction that is closely coupled to the CPU no matter what it may be? |
| 04:47:28 | yakischloba | so the rest of everything can use the VM instruction which will use whatever CPU instruction it happens to be running on and not have to think about it? |
| 04:48:07 | evan | no |
| 04:48:17 | evan | the idea is an instruction set thats NOT close to a CPU |
| 04:48:23 | evan | that is ideal for the work you want to do |
| 04:48:53 | headius | right |
| 04:49:13 | yakischloba | yes, i believe i said it wrong |
| 04:49:16 | headius | you certainly can make it be similar to a CPU or even identical to the CPU, but usually they're more coarse-grained and higher-level |
| 04:50:29 | yakischloba | hmm |
| 04:50:57 | yakischloba | so no reading resources? i have made a meager attempt or two at google but 'virtual machine' is polluted with other shit |
| 04:51:27 | headius | the wikipedia article is a nice intro |
| 04:51:30 | yakischloba | i suppose most of it is just understanding how the normal machine works eh |
| 04:51:54 | headius | what we're talking about are process virtual machines, not system virtual machines like vmware or virtualbox |
| 04:52:14 | yakischloba | yes i am aware of this. that is what i was referring to when i said google was polluted. |
| 04:52:25 | headius | hah |
| 04:52:26 | headius | ok :) |
| 04:53:02 | yakischloba | :) |
| 04:59:50 | yakischloba | night |
| 05:00:36 | headius | nite nite |
| 05:00:46 | headius | evan: is there any way to make it jit everything at startup? |
| 05:01:04 | evan | nope |
| 05:01:13 | evan | might be interesting to add such a thing. |
| 05:02:33 | brixen | evan: you going to push the hash change? |
| 05:02:40 | evan | yeah |
| 05:02:46 | evan | i played with moving it up |
| 05:02:56 | evan | so all immediates are mixed as their hash |
| 05:02:58 | evan | ie |
| 05:03:08 | evan | irb(main):003:0> :foo.hash |
| 05:03:08 | evan | => 326135087 |
| 05:03:08 | evan | irb(main):004:0> :Blah.hash |
| 05:03:08 | evan | => 116859376 |
| 05:03:19 | evan | got 2 spec failures |
| 05:03:37 | evan | it looks like they depend on each_pair/each yield order |
| 05:04:01 | brixen | which specs? |
| 05:04:22 | evan | Hash#each_pair processes all pairs, yielding two arguments: key and value |
| 05:04:23 | evan | and |
| 05:04:29 | evan | Hash#each yields one argument |
| 05:06:11 | brixen | #each_pair spec assumes hash ordering |
| 05:06:43 | brixen | both those specs do |
| 05:07:00 | evan | you going to fix them, or should I? |
| 05:07:11 | brixen | either way |
| 05:07:13 | brixen | want me to? |
| 05:07:23 | evan | i can |
| 05:07:27 | brixen | k |
| 05:07:30 | evan | just want to be sure we both don't |
| 05:07:31 | evan | :D |
| 05:07:38 | brixen | ok |
| 05:08:05 | brixen | I'm working on a linear probing hash |
| 05:08:43 | evan | rad. |
| 05:09:18 | brixen | the only reason I think it may perform better than cuckoo is because x + 1 will be faster than and h2() |
| 05:09:30 | brixen | unless h2(x) = x + 1 of course :) |
| 05:09:40 | evan | true true |
| 05:09:57 | brixen | the Pagh did his dissertation on hashing |
| 05:10:13 | brixen | I haven't read it yet, just rereading the cuckoo hashing paper |
| 05:11:00 | evan | well, easy to combine the 2 a little |
| 05:11:16 | evan | check idx and idx + 1 |
| 05:11:21 | evan | then switch to table 2 |
| 05:11:35 | brixen | hm |
| 05:15:03 | boyscout | Minor commenting and style fix - d2b5bcb - Evan Phoenix |
| 05:15:03 | boyscout | Fix specs that were dependent on Hash#each ordering - ebe7665 - Evan Phoenix |
| 05:15:03 | boyscout | Use a proper integer mix to hash immediates - ff47c96 - Evan Phoenix |
| 05:15:03 | boyscout | Use Fixnum#hash on the original hash value for table 2 - 1ef0d03 - Evan Phoenix |
| 05:15:21 | evan | woo |
| 05:15:38 | evan | all immediates have a much better #hash now |
| 05:15:56 | brixen | sweet |
| 05:16:08 | evan | cuckoo uses key_hash.hash for table 2 now. |
| 05:16:13 | evan | oh, you can see the commit message |
| 05:16:14 | evan | :D |
| 05:19:24 | evan | ok, well, off to do a bit of work |
| 05:19:36 | brixen | ok |
| 05:21:30 | boyscout | CI: 1ef0d03 success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 06:23:18 | balint | hey, I'd like to contribute to rubinius and as a first step wanted to run some (ruby)specs |
| 06:24:05 | balint | when I do ./bin/mspec I get this, though: |
| 06:24:28 | balint | ... /lib/mspec/commands/mspec.rb:153:in `exec': No such file or directory - bin/rbx (Errno::ENOENT) |
| 06:27:56 | ddub | are you interested in working on the specs, or work on rubinius proper? |
| 06:37:18 | balint | ddub: rather on rubinius proper |
| 06:37:54 | balint | but I'd like to get acquainted with rubinius first so that I have a wild guess of how it works :) |
| 06:41:22 | brixen | balint: so, you cloned rubinius and typed rake? |
| 06:42:18 | balint | brixen: after cloning, I typed 'rake spec' then it ran the compilation and showed some options to run diff. spec suites |
| 06:42:36 | balint | I chose to run ./bin/mspec :core |
| 06:43:12 | balint | brixen: now running rake ... |
| 06:44:03 | brixen | yeah, you need to build first ;) |
| 06:44:33 | brixen | you should have a read of /doc/getting_started.txt |
| 06:44:55 | brixen | some of the /doc files are dated, but that one should be good |
| 06:47:48 | balint | brixen: thank you. somehow that useful file skipped my attention |
| 06:50:33 | brixen | balint: heh, n/p |
| 06:50:53 | brixen | it's always a challenge to know what to name it |
| 06:51:02 | brixen | there's README too |
| 06:51:19 | brixen | but kidding aside, if we can make it easier to get started, let us know |
| 06:53:51 | balint | brixen: yes, the getting_started.txt file is referenced from the README and that's where I started, I just somehow skipped that paragraph :) |
| 06:54:18 | boyscout | Update compiler location in README. - 11294ce - Brian Ford |
| 06:54:53 | brixen | ah, actually good to hear |
| 06:55:05 | brixen | I never know if folks read the README |
| 06:55:27 | balint | ok, so when I now run ./bin/mspec core, I get "1128 files, 5760 examples, 18986 expectations, 230 failures, 196 errors", I guess this is ok and this is one of the many possibilities one can help with Rubinius, is that right? |
| 06:55:46 | brixen | yeah, that command runs all the specs |
| 06:56:05 | brixen | bin/mspec ci will run only the specs known to pass |
| 06:56:24 | brixen | so, the errors you see are definitely places that need fixing |
| 06:57:30 | brixen | one note about the specs, we're not currently implementing #freeze/#frozen? |
| 06:57:33 | boyscout | CI: 11294ce success. 2682 files, 10321 examples, 32864 expectations, 1 failure, 0 errors |
| 06:57:42 | balint | brixen: ok |
| 06:57:49 | brixen | most of those should be tagged so you could do bin/mspec -G frozen to omit them |
| 06:58:32 | brixen | we really need to get the CI bot to report spec failures as a failure :) |
| 06:58:51 | brixen | but that 1 failure is a random one |
| 06:59:06 | balint | I go this from ./bin/mspec ci : 1502 files, 7375 examples, 23839 expectations, 0 failures, 0 errors |
| 07:01:07 | brixen | yeah, looks right |
| 07:01:30 | brixen | so, bin/mspec ci runs the files in :ci_files in spec/default.mspec |
| 07:01:42 | brixen | rake will run bin/mspec ci -B full |
| 07:01:53 | brixen | which runs all the passing specs in core and standard lib |
| 07:02:12 | brixen | that's the :ci_files in spec/full.mspec |
| 07:02:32 | balint | brixen: ok, so boyscout ran the full ci suite that's why there were more test cases |
| 07:03:25 | brixen | yeah, it just runs the default 'rake' |
| 07:07:17 | brixen | bbiab.. (running benchmarks) |
| 08:40:54 | headius | hmm |
| 08:41:39 | headius | what "Bench" do these hash benchmarks depend upon? |
| 08:45:42 | brixen | headius: benchmark/utils/bench.rb |
| 08:45:53 | headius | yeah I found that now...trying to figure out how to run these though |
| 08:45:55 | brixen | it's the same as what was merged into RBS |
| 08:46:10 | brixen | I'll give you the command, sec.. |
| 08:46:23 | brixen | eg rake -q bench:dir DIR=benchmark/rubinius/hash VM='rbx -r cuckoo' HASH_CLASS=Rubinius::Cuckoo |
| 08:46:33 | headius | wow, long command line |
| 08:46:44 | brixen | the command line is your friend :) |
| 08:46:49 | headius | not that one |
| 08:46:50 | headius | :) |
| 08:47:19 | evan | brixen: you should rerun those stats on cuckoo with the new hash code in |
| 08:47:44 | brixen | jitting just a couple methods, like the key_index, gives a 2-10% improvement |
| 08:47:49 | brixen | evan: already did |
| 08:47:57 | headius | they still don't seem to run |
| 08:47:57 | headius | status: "NoMethodError undefined method `const_lookup' for main:Object" |
| 08:47:59 | brixen | look at sheet3 of that spreadsheet |
| 08:48:05 | evan | mm |
| 08:48:07 | evan | i think i closed it :/ |
| 08:48:22 | evan | one sec |
| 08:48:56 | brixen | evan: so, the hash changes are very good for removing those pathological cases |
| 08:49:11 | brixen | let's see if I can gist this file... |
| 08:49:55 | evan | cool. |
| 08:50:20 | evan | i'm happy that thus far, having a real hash code hasn't broken anything |
| 08:50:46 | brixen | headius: you have to define that method, look in kernel/delta/kernel.rb |
| 08:52:01 | headius | this was with rbx though |
| 08:52:07 | headius | well VM='rbx ....' |
| 08:52:28 | headius | what is this method? |
| 08:52:43 | headius | just breaking up ::? |
| 08:54:03 | headius | hmmm |
| 08:54:12 | headius | it seems to write blank results to the yaml now |
| 08:54:14 | headius | strange |
| 08:57:11 | brixen | headius: ah with rbx? |
| 08:57:14 | brixen | that's odd |
| 08:57:27 | brixen | no issues for me, even ran it with some jitted methods |
| 08:59:32 | headius | hmm |
| 08:59:43 | headius | seems like it may be something odd running rake under jruby for this |
| 09:00:02 | brixen | hm, I can give you a non rake cmd |
| 09:00:08 | brixen | it will be longer :) |
| 09:00:21 | headius | I'm curious why it didn't work with jruby though |
| 09:00:28 | brixen | yeah, that is odd |
| 09:00:34 | headius | grr, ^C not working in rbx? |
| 09:00:39 | brixen | in rake |
| 09:00:59 | brixen | I don't have issues with ^C in rbx by itself |
| 09:03:16 | brixen | headius: actually, that nomethoderror is from mri I believe |
| 09:03:24 | brixen | it wasn't exec'ing rbx |
| 09:03:51 | headius | yeah probably |
| 09:04:15 | headius | perhaps bench.rb should define this method if it doesn't exist, since it's not in any other impl? |
| 09:04:30 | headius | did those rbs guys ever merge your stuff in? I lost track of all that |
| 09:04:38 | brixen | yeah they did |
| 09:05:04 | headius | well, that's positive |
| 09:05:56 | headius | ok, I managed to get results with rbx and jruby |
| 09:06:06 | headius | took some path twiddling, but it worked |
| 09:06:08 | headius | weird |
| 09:06:48 | headius | one more lazy question: is there a way through the rake command to bump up iterations? some of these don't even register |
| 09:06:59 | brixen | yeah |
| 09:07:20 | brixen | use ITERATIONS=n |
| 09:07:22 | headius | ok |
| 09:07:45 | brixen | actually, that's not what you want |
| 09:07:47 | brixen | I think |
| 09:07:52 | headius | didn't sound like it |
| 09:08:00 | headius | like make the benchmarks run longer per iteration |
| 09:08:02 | brixen | that's how many trials are run |
| 09:08:05 | brixen | yeah |
| 09:08:12 | headius | I phrased it wrong |
| 09:08:20 | brixen | you need to modify the iteration counts in setup.rb |
| 09:08:28 | brixen | benchmark/rubinius/hash/setup.rb |
| 09:08:29 | headius | mmm ok |
| 09:09:48 | headius | yeahm bm_create in the hash stuff...for all but the 20k version it's under 0.01, so sensitive to noise |
| 09:10:09 | brixen | yeah |
| 09:10:20 | brixen | I sigstop firefox to run the benchmarks :) |
| 09:11:31 | brixen | but with bm_create, I get consistent numbers in the 0.00003 range |
| 09:12:07 | headius | yeah, not really useful |
| 09:20:23 | headius | bm_proportional_get_set_delete |
| 09:20:28 | headius | should that take a long time? |
| 09:24:45 | headius | brixen: looks like everything ran ok, thank you |
| 09:25:02 | brixen | ahh cool |
| 09:25:09 | brixen | yeah, that bench takes a while |
| 09:28:32 | headius | yeah, definitely does |
| 10:50:12 | rue | Hey, neat, someone on #ruby-lang posted http://github.com/sophsec/udis86-ffi/blob/master/lib/udis86/ud.rb |
| 11:57:52 | daddy | hi |
| 11:59:06 | daddy | I try to compile and install rubinius from git. I've got the following error during the install 'Building extension lib/ext/readline |
| 11:59:06 | daddy | An exception has occurred: |
| 11:59:06 | daddy | Unable to find a script 'compile' to run (LoadError) |
| 11:59:06 | daddy | Backtrace: |
| 11:59:06 | daddy | Object#__script__ at kernel/loader.rb:269 |
| 11:59:07 | daddy | rake aborted! |
| 11:59:11 | daddy | Command failed with status (1): [./bin/rbx compile -p -I/usr/local/src/rub...] |
| 11:59:23 | daddy | how can I resolve this? |
| 12:00:22 | dbussink | what command are you running? |
| 12:00:43 | dbussink | easiest way to get tests running is to git clone and then just run rake with no other arguments |
| 12:00:43 | daddy | dbussink: rake install |
| 12:01:03 | dbussink | ah, advise was to not install atm |
| 12:01:09 | dbussink | just run stuff from the clone |
| 12:01:34 | daddy | dbussink: thank you i'am trying.. |
| 12:02:30 | dbussink | daddy: if you run just rake, it compiles and runs the tests |
| 12:02:37 | daddy | dbussink: I've got: Winettou rubinius # bin/rbx -v |
| 12:02:37 | daddy | Runtime exception: Unable to load /usr/local/lib/rubinius/0.11/runtime/platform.conf, it is missing |
| 12:02:54 | daddy | dbussink: Ok i try recompile the wole |
| 12:02:57 | daddy | whole |
| 12:03:00 | dbussink | daddy: what does just running "rake" give you? |
| 12:03:48 | daddy | dbussink: no, that was with the previous compiled rubinius. it ts compiling now |
| 12:04:42 | daddy | dbussink: Running 726 tests..... Runtime exception: Unable to load /usr/local/lib/rubinius/0.11/runtime/platform.conf, it is missing |
| 12:04:53 | daddy | but test was OK |
| 12:04:55 | dbussink | hmm, weird |
| 12:05:05 | dbussink | if you run rake clean first and then rake? |
| 12:05:25 | dbussink | you should nuke the install in /usr/local too btw |
| 12:05:30 | daddy | dbussink: ok clean and recompile |
| 12:05:49 | daddy | dbussink: how can I do that? |
| 12:06:35 | dbussink | daddy: just remove the rubinius directory in /usr/local/lib and check whether you don't have anything in /usr/local/bin either |
| 12:07:11 | daddy | dbussink: OK I try |
| 12:21:20 | daddy | dbussink: 82 files, 10338 examples, 32880 expectations, 28 failures, 0 errors |
| 12:22:01 | daddy | dbussink: bin/rbx -v |
| 12:22:02 | daddy | rubinius 0.11.0-dev (ruby 1.8.6) (11294cedf 12/31/2009) [i686-pc-linux-gnu] |
| 12:22:52 | dbussink | daddy: hmm, what kind of failures are you getting? |
| 12:23:13 | daddy | dbussink: like this: |
| 12:23:15 | daddy | 27) |
| 12:23:16 | daddy | FileTest.writable? returns true if named file is writable by the effective user id of the process, otherwise false FAILED |
| 12:23:16 | daddy | Expected true |
| 12:23:16 | daddy | to equal false |
| 12:23:16 | daddy | #<Object:0x1f7de>.__script__ {} at spec/frozen/shared/file/writable.rb:11 |
| 12:23:18 | daddy | Kernel(Object)#instance_eval at kernel/common/eval.rb:117 |
| 12:23:24 | dbussink | daddy: could you use something like gist/ |
| 12:23:24 | dbussink | ? |
| 12:23:46 | dbussink | daddy: are you running this as a regular user or as root? |
| 12:23:57 | daddy | dbussink: as root |
| 12:24:11 | dbussink | daddy: ah ok, that explains the failures then |
| 12:24:33 | daddy | dbussink: should I do this as a regular user? |
| 12:24:44 | daddy | I mean recompile |
| 12:24:54 | dbussink | daddy: well, for the specs to pass you should yeah, there's no need to run stuff as root |
| 12:25:59 | daddy | dbussink: Ok I see. There is an other problem with gems. I want to install gems by 'bin/rbx gem install' but I've got error: make: *** No rule to make target `/usr/local/src/rubinius/vm/capi/config.h', needed by `tmailscanner.o'. Stop. |
| 12:26:20 | dbussink | daddy: and if you do ./bin/rbx -S gem install some_gem |
| 12:26:33 | daddy | dbussink: I'am trying.. |
| 12:26:37 | dbussink | what gem is it? |
| 12:26:56 | daddy | it is my own, but it depends on tmail |
| 12:27:09 | dbussink | i'll try installing tmail here |
| 12:27:19 | daddy | dbussink: OK |
| 12:27:29 | daddy | dbussink: same result. |
| 12:27:40 | dbussink | daddy: ah, yeah, i see it too, tmail seems to fail |
| 12:28:36 | daddy | dbussink: can I do anything to solve this? |
| 12:29:45 | dbussink | hmm, looks rubinius doesn't provide a config.h |
| 12:31:17 | dbussink | daddy: tmail doesn't work on 1.9 either |
| 12:31:31 | daddy | dbussink: yeah, I know ... :-( |
| 12:31:41 | daddy | dbussink: tmail is a problematic stuff... |
| 12:34:11 | dbussink | daddy: what depends on it then? |
| 12:34:25 | daddy | dbussink: do you mean on my stuff? |
| 12:34:39 | dbussink | daddy: why you need tmail and can't use something else |
| 12:34:53 | dbussink | although we should get tmail working too |
| 12:35:18 | daddy | dbussink: it is an SMTP proxy program and examine and manipulate rwa SMTP mails (attachments and so on) |
| 12:35:32 | daddy | raw |
| 12:38:13 | daddy | dbussink: can we provide a config.h for tmail ? |
| 12:40:31 | dbussink | daddy: seems like there is more stuff missing |
| 12:40:38 | dbussink | no re.h |
| 12:41:13 | jarib | daddy: tmail works without the c extension though |
| 12:41:30 | daddy | dbussink: there is re.h but at wrong place... |
| 12:41:34 | jarib | try setting NORUBYEXT=true when installing the gem |
| 12:41:39 | daddy | I've made a symlink by hand.. |
| 12:42:28 | dbussink | daddy: to which re.h? |
| 12:42:37 | dbussink | because rubinius doesn't have any |
| 12:43:00 | daddy | dbussink: yes, of course in the ruby's include dir |
| 12:43:17 | daddy | when I've tried it with 'simple' ruby. |
| 12:43:30 | daddy | This is the first time with rubinius for me |
| 12:43:52 | dbussink | daddy: well, combining rubinius and ruby provided headers is very likely not going to work |
| 12:44:20 | dbussink | re.h probably provides methods rubinius doens't even have yet in the c extension api |
| 12:45:38 | daddy | dbussink: how can I install tmail without C ? |
| 12:46:18 | dbussink | daddy: you can try jarib's suggestion |
| 12:46:47 | dbussink | daddy: you can also create an issue on github explaining the stuff that is missing from the c api |
| 12:47:39 | daddy | dbussink: there is no warning when I compile rubinius as a regular user.... till now |
| 12:48:25 | dbussink | daddy: why would there be? compiling stuff doesn't require writing anything into system directories |
| 12:48:51 | daddy | dbussink: I'm registrating myself on github... |
| 12:49:17 | daddy | dbussink: I mean there were lot of warnings when I did it as root |
| 12:50:55 | rue | Extensions should only use ruby.h |
| 12:52:07 | dbussink | rue: yeah, too bad there's a whole bunch out there that don't adhere to that principle |
| 12:52:15 | rue | Screw'm |
| 12:52:45 | dbussink | rue: well, could provide some additional empty headers to prevent errors, but i dunno what people use from those other headers |
| 12:56:36 | daddy | dbussink: tmail installed successfully with 'NORUBYEXT=true' |
| 12:58:52 | daddy | dbussink: but mysql gem failed: http://pastie.org/485230 |
| 13:00:06 | dbussink | daddy: ah, well, i know that rb_exc_raise is still missing and i guess those others too |
| 13:00:20 | dbussink | you can best create a list with all missing stuff so it can be added |
| 13:00:32 | dbussink | the c api is far from being complete and needs a bunch of work |
| 13:01:09 | daddy | dbussink: Oh , it's OK |
| 17:20:08 | brixen | dbussink: I'll get an the capi stuff asapi, promise |
| 17:22:11 | brixen | heh, crucial bit of cuckoo hashing... the maxloop value |
| 17:22:17 | brixen | compare... |
| 17:22:26 | brixen | [8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536] |
| 17:22:33 | brixen | [3, 4, 5, 6, 7, 8, 9, 10, 10, 11, 12, 13, 14, 15] |
| 17:34:02 | evan | morning |
| 17:34:15 | evan | heheh |
| 17:34:15 | evan | yeah |
| 17:34:31 | evan | cuckoo has few moving parts |
| 17:34:34 | evan | but they all matter a lot. |
| 17:36:04 | brixen | yeah, so that is the maxloop calculation when r >= (1+epsilon)*n and maxloop is (3 * log(r) / log(1 + epsilon)).ceil |
| 17:36:33 | brixen | I'm doing a table for capacity <= 2 ** 16 and above that it will calculate it |
| 17:36:53 | brixen | where n above is our capacity |
| 17:39:49 | evan | rad. |
| 17:46:17 | brixen | oops had an error in my formula, but with epsilon = 1 and r as above, these are the values |
| 17:46:20 | brixen | [12, 15, 18, 21, 24, 27, 30, 33, 36, 39, 42, 45, 48, 51] |
| 17:46:38 | brixen | as epsilon -> 0 the max_loop -> infinity |
| 17:46:45 | brixen | I guess we'll play with some values |
| 17:47:58 | evan | coolness. |
| 17:55:25 | brixen | hm, we don't really need a table, this is a regular sequence |
| 17:55:38 | brixen | just a base and increment when we enlarge will do it |
| 17:59:26 | evan | right |
| 18:25:55 | evan | so, interestly |
| 18:25:56 | evan | koichi said 1.9 will never have a JIT |
| 18:26:38 | chad | what does "1.9" mean exactly? |
| 18:26:46 | chad | i know that's a strange question :) |
| 18:26:51 | chad | (and oh hello) |
| 18:26:57 | brixen | chad: not as strange as you think |
| 18:27:04 | brixen | I ask myself that all the time |
| 18:27:25 | brixen | evan: why is that? |
| 18:27:27 | chad | i wonder if 1.9 will remain the stable path as long as 1.8 did |
| 18:27:28 | evan | chad: i take it to mean (oh HI!) all the code in /trunk |
| 18:27:42 | evan | chad: i'm still surprised 1.9 is the "stable" path. |
| 18:27:50 | chad | yea |
| 18:28:10 | chad | i don't have a good feel for what their thinking is on how temporary 1.9 is |
| 18:28:12 | chad | vs. a stepping stone to 2 |
| 18:28:29 | evan | i think they've made a big blunder |
| 18:28:43 | evan | suddenly deciding "oh 1.9.1 means stable" |
| 18:28:50 | evan | ie, the version numbers are more screwed up. |
| 18:29:30 | chad | yea |
| 18:29:37 | chad | i guess they just weren'tyet done with version 2 |
| 18:29:43 | chad | but wanted to release something people could use |
| 18:30:38 | chad | i wonder if koichi's JIT statement applies to 2.0 as well |
| 18:31:13 | evan | i'm trying to find where he said this... |
| 18:32:09 | evan | http://blog.grayproductions.net/articles/the_ruby_vm_episode_v |
| 18:32:31 | evan | very last paragraph |
| 18:33:08 | chad | yea |
| 18:33:18 | chad | that seems to imply it's not just 1.9 |
| 18:33:25 | chad | but something he generally believes to be true about ruby |
| 18:33:33 | evan | yep |
| 18:33:53 | evan | like "we'll never do a JIT" |
| 18:34:02 | evan | i'm not sure his AOT compiler experiment is going to work out |
| 18:34:04 | evan | personally |
| 18:35:42 | evan | his statement about adding pragmas is interesting. |
| 18:36:30 | brixen | I wonder 1. what is his def if JIT and 2. what he bases his opinion on |
| 18:36:49 | evan | me too |
| 18:36:52 | brixen | jitting just a few rather small methods was an easy 10% increase on those hash benches |
| 18:37:00 | brixen | and that was no inlining |
| 18:37:02 | evan | i wish, in general, there was more communication from those guys |
| 18:37:09 | evan | right |
| 18:37:09 | brixen | which should make #insert quite a bit faster |
| 18:37:16 | chad | i guess his idling here doesn't imply that he'll read this :) |
| 18:37:25 | evan | sometimes he does |
| 18:37:33 | chad | are you guys not doing the ruby implementors meetings anymore? |
| 18:37:42 | evan | they fell off, yes. |
| 18:37:49 | evan | we should back into having them. |
| 18:38:23 | evan | a discussion about why ko1 feels that a JIT isn't possible isn't the kind of discussion we'd have in those meetings though |
| 18:38:31 | evan | they were more about edge case discussion |
| 18:38:59 | chad | ah |
| 18:40:29 | evan | chad: so why have you graced us with your presence? |
| 18:40:32 | evan | got some free time? |
| 18:40:40 | chad | kinda |
| 18:40:51 | chad | i've been cutting back on extra work in an effort to kill burnout |
| 18:41:10 | chad | and now that the burnout is dying i'm finding myself interested in playing with technology again :) |
| 18:41:25 | chad | also i just felt like saying hi |
| 18:41:35 | evan | well yay for us! |
| 18:41:39 | chad | heh |
| 18:41:47 | evan | we're still using your Regexp#to_s impl |
| 18:41:52 | chad | yay me! |
| 18:42:03 | chad | i wonder if it ever got fixed in jruby |
| 18:42:11 | chad | headius asked me to do it there and i got swamped |
| 18:42:18 | chad | knowing them im sure it got fixed |
| 18:42:31 | evan | ah |
| 18:42:38 | evan | yeah, lopex probably did it. |
| 18:43:04 | chad | my memory is so bad that i had forgotten i even did that until you mentioned it |
| 18:43:25 | evan | hehe |
| 18:43:36 | evan | well, it was a personal sprint |
| 18:43:41 | evan | you left japan with it done |
| 18:43:47 | evan | that whole trip is a bit of a blur anyway :D |
| 18:43:53 | chad | yea |
| 18:44:03 | chad | and directly after that trip i started making lots of changes in general |
| 18:44:09 | evan | i'm going be in matsue in septemember it looks like |
| 18:44:21 | chad | oh? |
| 18:44:22 | evan | september too |
| 18:44:24 | chad | heh |
| 18:44:36 | evan | yeah, there is a ruby conference they're putting on |
| 18:44:38 | chad | working with matz? |
| 18:44:46 | evan | thats about ruby adoption |
| 18:44:49 | evan | and such. |
| 18:44:50 | chad | interesting |
| 18:44:56 | evan | i'm surprised ruby central isn't involved.... |
| 18:44:58 | evan | :/ |
| 18:45:08 | chad | again, communication between the continents |
| 18:45:14 | evan | yeah |
| 18:45:17 | evan | gotta send a boat over. |
| 18:45:34 | chad | i had intended to go to ruby kaigi this year |
| 18:45:37 | evan | a steamliner at that, just to get the point across </japanese-history> |
| 18:45:51 | chad | but then i instituted the "I don't do anything I dont' have to do" program to avoid burnout |
| 18:45:56 | evan | good plan |
| 18:46:04 | evan | i hear your training for a triathalon |
| 18:46:06 | evan | thats awesome! |
| 18:46:08 | evan | when is it? |
| 18:46:17 | chad | haven't decided which one yet |
| 18:46:30 | chad | but i want to try to do a sprint one toward the end of the summer |
| 18:46:41 | chad | and kelly and i will do one together at the beginning of the season next year |
| 18:46:53 | chad | excited and afraid :) |
| 18:47:02 | evan | i'm sure! |
| 18:47:06 | evan | i'd be the same |
| 18:47:23 | evan | you're starting to get me motivated to start working out |
| 18:47:28 | chad | rock on!! |
| 18:47:29 | chad | ;) |
| 18:48:00 | evan | i'd love to have my endurance up before ski season |
| 18:48:34 | chad | our trainer works with a lot of people who are seeing her for that reason |
| 18:48:35 | evan | dropping a few lbs would be nice too, but, ironically, i'm at my "ideal weight" for my height |
| 18:48:38 | evan | so what do I know. |
| 18:48:55 | chad | i was going to say, i dno't think you have weight to lose |
| 18:49:17 | evan | i'd have to be doing weight transferance |
| 18:49:34 | chad | that's where i'm at |
| 18:49:57 | chad | i'm always disrupting your peaceful channel changing the topic from deep technical stuff to random crap |
| 18:49:58 | chad | :) |
| 18:50:01 | chad | apologies |
| 18:50:01 | evan | i found out there is a golds gym not 2 blocks away |
| 18:50:07 | evan | nah |
| 18:50:08 | headius | chad: fix which thing in jruby? |
| 18:50:09 | evan | it's 10:50 |
| 18:50:13 | evan | this is the mid morning lul anyway. |
| 18:50:16 | chad | Regexp#to_s |
| 18:50:45 | chad | i'm quite sure it's fixed, charlie :) |
| 18:50:58 | headius | heheh, I sure hope so |
| 18:51:05 | headius | only bugs we get these days are painful ones |
| 18:51:45 | evan | chad found ours was broken because of people doing |
| 18:51:52 | evan | /#{another_regex}/ |
| 18:52:56 | chad | i learned a lot about the string representation of regex when I did that. Was fun. |
| 18:53:25 | evan | thaht ya did |
| 18:53:40 | evan | well, i'm sure we can rustle up some more like that for ya |
| 18:53:42 | evan | :D |
| 18:53:45 | headius | ahh I remember now |
| 18:53:50 | chad | sure :) |
| 18:53:53 | chad | i was about to say |
| 18:54:00 | chad | please send me low hanging fruit |
| 18:54:00 | chad | heh |
| 18:54:23 | chad | i think i might play around with the reia implementation a bit. saw tony talk about it last night and it was really interesting. |
| 18:54:23 | evan | chad: go run your favorite library on rubinius |
| 18:54:33 | chad | hey i said "give" |
| 18:54:34 | evan | you'll likely find some fruit |
| 18:55:12 | evan | it's easy! |
| 18:55:14 | evan | just run some tests |
| 18:56:03 | chad | as a matter of curiosity |
| 18:56:06 | chad | while we have headius here |
| 18:56:16 | chad | would you guys be interested in doing an implementors conference? |
| 18:56:25 | chad | something really small and focused |
| 18:57:02 | evan | course! |
| 18:57:04 | chad | we've (ruby central) talked about sponsoring something like that in the past and the discussion about 1.9 rminded me of it |
| 18:57:18 | chad | is hawaii a good place to hold it? :) |
| 18:57:31 | chad | too bad jackson hole is so hard to get to |
| 18:57:31 | evan | hawaii is a good answer to most questions |
| 18:57:36 | evan | well |
| 18:57:39 | headius | sounds good to me...there's enough implementations for a whole conf now |
| 18:57:48 | chad | yea that's what i was thinking |
| 18:57:49 | evan | i'm on the inside in jackson hole |
| 18:58:01 | evan | my parents live there |
| 18:58:07 | chad | not just the main implementors but the communities around those cores |
| 18:58:11 | evan | and my mom has held a writers conference there |
| 18:58:14 | chad | evan, yea, that's why i mentioned it |
| 18:58:19 | chad | and it's awesome |
| 18:58:27 | evan | that it is. |
| 18:58:38 | evan | ironicly, hawaii is probably easier and cheaper to get to! |
| 18:58:43 | chad | yea |
| 18:58:48 | chad | easy for the japanese people too |
| 18:58:49 | evan | silly wyoming. |
| 19:00:11 | chad | you think a couple of days would make a good implementor conference length? |
| 19:00:17 | chad | wow my english is awesome |
| 19:00:37 | evan | i'd say at least 2 full days |
| 19:00:48 | chad | so maybe start on an evening |
| 19:00:50 | chad | then have 2 full days |
| 19:01:00 | evan | sure |
| 19:01:07 | evan | it would be important to have an agenda |
| 19:01:17 | evan | since all the implementers are workaholics |
| 19:01:24 | evan | we'd just go off into our corners and hack |
| 19:01:31 | chad | :) |
| 19:01:49 | chad | i'll bring this up with the other ruby central people |
| 19:01:56 | evan | coolness |
| 19:02:03 | chad | and get back to you guys if it looks like we're interested in starting to plan it |
| 19:02:17 | chad | if so we'd work with you guys on what would make sense in terms of the flow, etc. |
| 19:02:23 | chad | as opposed to just running a normal conference |
| 19:02:23 | evan | sure |
| 19:02:33 | evan | i'd love it. |
| 19:02:51 | chad | i would love to sit and learn during such a conference |
| 19:03:03 | chad | ...quietly |
| 19:03:10 | evan | :D |
| 19:03:18 | evan | call it a summit |
| 19:03:24 | evan | rather than conference |
| 19:03:34 | evan | that conveys the right scope |
| 19:03:35 | evan | i think. |
| 19:03:40 | chad | yea that's what we were calling it when we were talking about it |
| 19:03:51 | chad | though i think extending it slightly beyond the core implementors would be cool |
| 19:04:05 | chad | so rather than, say 10 people there |
| 19:04:11 | chad | more like 40 or 50 |
| 19:04:47 | dbussink | if only it were in europe :P |
| 19:04:50 | evan | gotcha |
| 19:04:50 | evan | ok |
| 19:04:51 | evan | sure |
| 19:05:06 | yakischloba | get more people involved :p |
| 19:06:04 | evan | we're trying! |
| 19:07:20 | dgtized | evan: how come Object#hash does the type dispatching for String/Bignum/Float instead of having a method for each type? |
| 19:07:51 | evan | a WONDERFUL question |
| 19:08:01 | evan | i was pondering that myself last night |
| 19:08:05 | evan | i'm pretty sure we can remove that |
| 19:08:14 | evan | that was when we had Hash internally |
| 19:08:20 | evan | and used it early on in the boot process |
| 19:08:23 | brixen | yakischloba: re your question about virtual machines, this is a good book http://tinyurl.com/virtual-machines |
| 19:08:31 | dgtized | the only thing I could think of, is that technically hash send_sites all point to the same place |
| 19:08:51 | yakischloba | brixen: cool, thank you |
| 19:08:51 | brixen | yakischloba: also, have a look at doc/reading_list.txt |
| 19:08:54 | evan | dgtized: whats "hash send_sites" ? |
| 19:08:57 | yakischloba | brixen: doh ;) |
| 19:08:59 | brixen | yakischloba: it's a small collection |
| 19:09:10 | chad | goes to the gym. later guys. |
| 19:09:17 | brixen | see ya chad |
| 19:09:20 | evan | chad: later! |
| 19:10:26 | dgtized | evan: I guess I just meant that any send_sites for a call to a hash will be the same, I guess that doesn't make a difference though |
| 19:11:33 | evan | .... |
| 19:11:39 | evan | i still don't follow. |
| 19:11:57 | dgtized | never mind, I think I spoke to soon and it didn't make sense, sorry |
| 19:12:03 | evan | no prob. |
| 19:12:43 | dgtized | second question though, is concerning hashing of strings in general |
| 19:12:53 | evan | sure |
| 19:13:49 | dgtized | ["a","b","c"].map {|x| x.hash} => [97, 98, 99] |
| 19:14:03 | dgtized | that's kind of a shitty hash distribution |
| 19:14:04 | evan | in rbx? |
| 19:14:06 | dgtized | yes |
| 19:14:09 | evan | wow |
| 19:14:11 | evan | it's busted |
| 19:14:12 | evan | completely. |
| 19:14:28 | evan | yes |
| 19:14:31 | evan | thats completely wrong. |
| 19:14:32 | evan | one sec. |
| 19:14:52 | dgtized | in mri it's [100,101,102] :) so we aren't that bad |
| 19:15:08 | evan | it should be a fully distributed 32bit hash value though. |
| 19:15:13 | dgtized | yea |
| 19:15:23 | tilman | 28 bit i think :p |
| 19:15:31 | evan | WHAT |
| 19:15:31 | evan | THE |
| 19:15:32 | evan | FUCK |
| 19:15:34 | tilman | to make sure it's a fixnum (on 32 bit arches anyway) |
| 19:15:36 | evan | who the fuck changed our hash algo |
| 19:15:37 | evan | completely |
| 19:15:46 | evan | they removed the really decent hash algo |
| 19:15:50 | evan | and put a crappy one in |
| 19:15:59 | evan | pulls out git blame |
| 19:16:36 | evan | it was you tilman! |
| 19:16:43 | evan | what is with this terrible hash function |
| 19:16:56 | tilman | wtf? |
| 19:17:00 | tilman | evan: bs |
| 19:17:06 | tilman | i just shuffled the code around |
| 19:17:21 | tilman | fwiw, i have a local branch that swaps the retarded fnv for hsieh's hash function |
| 19:17:37 | evan | ok |
| 19:17:38 | evan | well |
| 19:17:40 | evan | fuck me. |
| 19:17:41 | evan | it was I. |
| 19:17:48 | evan | i guess i thought it was a more... robust. |
| 19:18:00 | evan | i don't get why you refactored it. |
| 19:18:05 | evan | but it is the same algo. |
| 19:18:35 | tilman | i forget why i did that. the preceding/following commit probably explains it though |
| 19:18:38 | evan | tilman: whats wrong with fnv? |
| 19:19:00 | evan | your commit says to allow for passing a NULL terminated string |
| 19:19:20 | lypanov | wibbles |
| 19:19:50 | tilman | evan: you just called our hash terrible and now you're asking me what's wrong with it? |
| 19:20:03 | lypanov | tilmaaaaaannnnnnnnnnnn |
| 19:20:09 | evan | sorry! |
| 19:20:11 | tilman | hello lypanov |
| 19:20:12 | evan | i over reacted. |
| 19:20:23 | evan | i thought that FNV had a better distribution for small strings |
| 19:20:24 | tilman | don't shoot innocent bystanders |
| 19:20:25 | evan | i forgot. |
| 19:20:39 | evan | i was just curious why you refactored it. |
| 19:20:45 | evan | but i see why now. |
| 19:20:54 | tilman | i'd have to read the commit log ;> |
| 19:21:06 | evan | i did. |
| 19:21:13 | evan | again, sorry. |
| 19:21:21 | headius | hey, when you have 900 committers, who can fault ya for losing track |
| 19:21:35 | dgtized | ["aa","ab","ac"].map {|x| x.hash} => [16816340, 16816343, 16816342] |
| 19:21:52 | dgtized | that's not very distributed either |
| 19:22:02 | evan | no |
| 19:22:05 | evan | i think somethings wrong... |
| 19:22:51 | headius | jruby's matches ruby, and is also not particularly distributed for that input |
| 19:22:58 | headius | [6562050, 6562051, 6562052] |
| 19:23:04 | evan | ouch. |
| 19:23:11 | evan | thats just summing them |
| 19:23:16 | brixen | doesn't python use fnv? |
| 19:24:01 | evan | i'm going to make a couple of tweaks |
| 19:24:20 | evan | our fnv is a little busted |
| 19:24:24 | tilman | related question: can we drop the 28 bit clamp for hash_str on x86_64, or do we need to generate the same hash values for the same strings on any platform? |
| 19:24:28 | evan | we're using 0 as the offset basis |
| 19:24:38 | evan | tilman: we can |
| 19:24:40 | evan | i'm going to fix that now |
| 19:24:46 | evan | by clamping it to FIXNUM_MAX |
| 19:24:53 | evan | so it will adjust based on pointer size |
| 19:25:08 | headius | it's not just summing them |
| 19:25:15 | headius | it sums, shifts, sums, shifts |
| 19:25:48 | headius | http://gist.github.com/115617 |
| 19:27:37 | headius | but the last characters are only off by bits |
| 19:28:24 | dgtized | >>> [hash(x) for x in "a","b","c","aa","ab","ac"] |
| 19:28:24 | dgtized | [-468864544, -340864157, -212863774, -1549758592, -1549758589, -1549758590] |
| 19:29:27 | dgtized | so whatever python is using is distributed nicely for single chars but isn't so distributed for the two char case |
| 19:30:56 | evan | i dislike negative hash values. |
| 19:31:36 | dgtized | I agree, but I'm just pointing out that there distribution appears to suck for 2 char case as well |
| 19:31:48 | evan | ok, with my change |
| 19:31:49 | evan | irb(main):004:0> ("a".."e").to_a.map { |c| c.hash } |
| 19:31:49 | evan | => [604776751, 655109606, 638331985, 554443888, 537666275] |
| 19:31:52 | headius | what's wrong with negative hash values? |
| 19:32:13 | evan | there is a minor variant of FNV that works better for short sequences |
| 19:32:23 | evan | that just changes the order of operations |
| 19:32:58 | evan | it appears to give us a bit better 32bit distribution |
| 19:33:13 | evan | and still work fine for longer sequences |
| 19:33:18 | evan | headius: they look funny :) |
| 19:33:23 | dgtized | headius: because they make more sense as unsigned values? They are technically array offsets |
| 19:33:44 | dgtized | well ish |
| 19:36:17 | headius | dgtized: bits is bits |
| 19:36:44 | headius | that they're being represented as a signed integer is not the hash value's fault |
| 19:37:22 | evan | true enough. |
| 19:38:52 | evan | it's almost like hash values should be their own knid of object |
| 19:39:01 | evan | and #inspect prints them out in binary. |
| 19:39:13 | brixen | that'd be cool |
| 19:39:22 | brixen | save me a lot of to_s(2) :) |
| 19:39:27 | evan | hehe |
| 19:39:40 | evan | all this changing hash functions is sussing out a lot of specs |
| 19:39:46 | evan | found another thats dependent on hash ordering |
| 19:39:47 | evan | :D |
| 19:39:52 | brixen | cool |
| 19:40:01 | brixen | I'm surprised jruby didn't find them all |
| 19:40:12 | evan | me too |
| 19:40:21 | evan | well headius said they use the same hash algo as MRI for a few things |
| 19:40:29 | brixen | ahh ok |
| 19:40:31 | headius | most things |
| 19:40:36 | evan | this new one is when the Array is full of Strings |
| 19:40:48 | headius | and since most of the specs don't care about insertion order it probably just happened to match |
| 19:40:56 | evan | yep |
| 19:41:11 | headius | I need to pull updated specs now, to make sure we weren't implementing something broken :) |
| 19:41:55 | dgtized | so I have a third hash question concerning the cuckoo hash |
| 19:42:38 | evan | luislavena: hola! |
| 19:42:47 | luislavena | evan: hey! |
| 19:42:49 | evan | dgtized: just pushed the String#hash fix |
| 19:42:53 | evan | not sure why boyscout didn't say so. |
| 19:43:09 | dgtized | my understanding is that part of the performance gain we hope from is that we will increase the cache hits by avoiding the bucket based linked lists |
| 19:43:53 | dgtized | however, if we still store each entry as a seperate object, when we push them all into the tuple, we lose the linear memory ordering property, because they are all indirect objects |
| 19:44:11 | evan | dgtized: thats a property of cuckoo hash, yes, but we need to restructure things a little to really start to see that |
| 19:44:23 | evan | we still have a tuple that contains references to Entry objects |
| 19:44:28 | evan | to get the cache line improvements |
| 19:44:34 | evan | we need to remove the Entry objects |
| 19:44:34 | dgtized | I wonder if we can increase hash performance by storing the data as [key,hash_key,value,key,hash_key,value,key,hash_key,value,key,hash_key,value,key,hash_key,value,key, hash_key,value] |
| 19:44:39 | dgtized | yea |
| 19:44:39 | evan | so all the data is stored directly in the Tuple |
| 19:44:54 | headius | I hope you didn't type all that |
| 19:44:57 | evan | hah |
| 19:45:08 | evan | thats odd. |
| 19:45:14 | evan | my commit didn't show up on github... |
| 19:45:45 | brixen | evan: it's there |
| 19:45:56 | brixen | github is just slow displaying it |
| 19:46:37 | evan | ok |
| 19:46:43 | evan | i think they're having caching issues |
| 19:46:44 | evan | it's http://github.com/evanphx/rubinius/commit/d0aac4e9a665f7a87ad4fe9ca2cc52754fe382a6 |
| 19:46:50 | dgtized | if we store them all flat in the tuple, will setting the hash_key value to nil work as a tombstone for deleted values? |
| 19:46:52 | evan | for those that want to look |
| 19:47:13 | luislavena | evan: how jit-llvm is coming? |
| 19:47:14 | brixen | dgtized: the trade off is a bunch more operations for inserts and moves |
| 19:47:15 | evan | dgtized: yeah, that should work |
| 19:47:18 | evan | luislavena: good! |
| 19:47:22 | evan | about to push some more work on it |
| 19:47:25 | brixen | dgtized: like 3x |
| 19:47:45 | evan | this is where value types would be nice |
| 19:47:52 | brixen | dgtized: you need to show that cache performance is the issue |
| 19:48:03 | brixen | based on what I'm seeing, # of ops is the issue |
| 19:48:03 | luislavena | off-topic question... |
| 19:48:28 | luislavena | is the capi a Rubinius only api or is MRI compatbile one? |
| 19:48:44 | evan | luislavena: it's MRIs API |
| 19:48:45 | dgtized | brixen: ah, that's probably because the interpreter overhead is more then we can stand to gain back by cache hits |
| 19:48:48 | evan | we didn't invent a new one |
| 19:49:00 | brixen | dgtized: it may already be in the cache |
| 19:49:00 | evan | it's glues MRIs C API to rubinius internals |
| 19:49:14 | brixen | just because an object isn't contiguous doesn't mean it's not in the cache |
| 19:49:18 | luislavena | evan: so that replaces subtend, which was C only, and now everything is C++ ? |
| 19:49:26 | evan | correct. |
| 19:50:14 | luislavena | evan: cool. |
| 19:51:00 | dgtized | brixen: if it's being overshadowed by the overhead from the interpreter it doesn't matter if it's in the cache or not |
| 19:51:59 | evan | by having them all in one contigious line of memory |
| 19:52:05 | evan | the idea is your forcing a cache line to be used |
| 19:52:13 | evan | but thats assuming a lot about the MMU |
| 19:52:16 | boyscout | Switch to using FNV-1a for better small string distribution - d0aac4e - Evan Phoenix |
| 19:52:16 | boyscout | Fix spec dependent on Hash ordering - 6ce096c - Evan Phoenix |
| 19:52:38 | dgtized | evan: but if how much do we clobber that every time we go back to the opcode loop? |
| 19:53:09 | evan | we're just as likely to do that to the cache line that contains the whole tuple |
| 19:53:22 | evan | you can't assume much of anything about how your code is going to effect the cache lines |
| 19:53:29 | evan | unless you get out a monitor and check it out |
| 19:54:23 | evan | as for how the interpreter effects i'd |
| 19:54:37 | evan | my super unscientific assumption would be the interpreter blows up cache lines constantly |
| 19:55:10 | dgtized | I can think of one nice effect that we could do if it's stored in triplet in the tuple -- we could try moving the hash back into c++, but still have valid code to read it from interpreted land |
| 19:55:18 | evan | no no. |
| 19:55:21 | evan | we're not doing that. |
| 19:56:24 | dgtized | to ensure deeper turtles, dependency ordering, or some other reasons? |
| 19:56:48 | evan | all of the above |
| 19:57:34 | evan | one being, we should make the system fast enough that moving something like that into C++ gives us no benefit |
| 19:57:40 | evan | we're getting close to that. |
| 19:57:59 | evan | since the Hash table is really bound by the performance of #hash |
| 19:58:38 | dgtized | is it? I thought it was bound up in [] and []= suggesting it was the insert timing, not cost of #hash -- that said maybe I misread brixen's tables |
| 19:58:53 | evan | sure, but moving that into C++ gives us nothing |
| 19:59:12 | evan | because we'd have to have a bunch of primitive boundaries to get to a [] written in C++ |
| 19:59:50 | evan | i'm pretty "meh" about moving large data structures into C++ |
| 19:59:55 | evan | it complicates a lot of things |
| 19:59:59 | evan | and it's a kludge. |
| 20:01:13 | dgtized | I guess I hadn't thought of how many equals and hash calls are made inside the insert function so it would keep jumping back into interpreted code |
| 20:01:24 | evan | yep |
| 20:01:51 | evan | better would be to teach the JIT about this code scenario |
| 20:02:00 | evan | like I did with Array#each |
| 20:02:05 | boyscout | CI: 6ce096c success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 20:02:18 | evan | brixen: I pushed more JIT fixes |
| 20:02:27 | evan | brixen: Iterator#next compiles fine now. |
| 20:03:37 | brixen | evan: saweeeet |
| 20:04:11 | boyscout | Fix how the JIT calculates which BasicBlock to use - 2ca52ab - Evan Phoenix |
| 20:05:29 | dgtized | evan: did you already push the code for dealing with Array#each? |
| 20:05:34 | evan | yep |
| 20:05:43 | evan | try the bm_array_each.rb with --fast |
| 20:05:43 | evan | ie |
| 20:05:53 | evan | bin/rbx --fast benchmark/rubinius/bm_array_each.rb |
| 20:05:58 | dgtized | and what's the recompile to enable --fast first? |
| 20:06:07 | dgtized | or does --fast just work these days? |
| 20:06:19 | evan | you need to have run rake with RBX_LLVM=1 |
| 20:06:24 | evan | to link in LLVM |
| 20:06:26 | dgtized | k |
| 20:08:18 | dgtized | and just check out llvm into vm/external_libs/llvm? |
| 20:09:34 | evan | yes. |
| 20:11:16 | boyscout | CI: 2ca52ab success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 20:31:52 | rue | Hola |
| 20:32:02 | rue | dgtized: Or symlink it |
| 20:32:08 | dgtized | yuck, llvm HEAD fails to compile |
| 20:32:41 | rue | If it is the __STDC, just build again |
| 20:33:40 | dgtized | http://gist.github.com/115673 |
| 20:34:07 | dgtized | I'm trying it again with the default 2.5 release |
| 20:34:15 | evan | no |
| 20:34:19 | evan | you have to use SVN HEAD |
| 20:34:59 | rue | dgtized: r72106 is OK for me, which revision do you have? |
| 20:35:14 | rue | And wtf `svn log --limit 1` takes like 10 seconds |
| 20:35:18 | dgtized | 72220 |
| 20:35:37 | brixen | llvm commit log makes for some amusing reading |
| 20:37:56 | luislavena | wonders why rubinius repo is sooo huge |
| 20:38:15 | brixen | is there a well-maintained public git-svn of llvm? |
| 20:38:27 | brixen | svn just sucks so bad |
| 20:38:27 | evan | not that I know of. |
| 20:38:42 | rue | Could set one up |
| 20:38:54 | rue | Though I shudder to consider the initial import |
| 20:40:30 | evan | yeah |
| 20:40:31 | evan | me too. |
| 20:40:40 | evan | if you do |
| 20:40:44 | evan | don't do full history |
| 20:40:52 | evan | do it relative to the current HEAD |
| 20:40:53 | rue | installs git-svn |
| 20:41:18 | dgtized | couldn't you do it relative to say release 2.4? |
| 20:41:31 | dgtized | allowing for a recent revert or two? |
| 20:41:44 | evan | sure |
| 20:52:02 | tilman | brixen: there's a mirror on repo.cz, but i don't know how up to date it is |
| 20:54:36 | rue | Looks about 24h behind |
| 20:54:43 | rue | http://repo.or.cz/w?p=llvm.git;a=summary |
| 20:55:00 | brixen | tilman: sweet |
| 20:55:56 | brixen | gitweb is so retro |
| 20:55:57 | evan | my patch is in there |
| 20:56:05 | evan | so we're free to use that |
| 20:56:09 | rue | Hah. "Test commit" |
| 20:59:34 | rue | They only have a bit over 100k objects. |
| 21:07:55 | boyscout | Playing with building up another optimization pass set - 7b809fa - Evan Phoenix |
| 21:08:26 | rue | *Jaws music* For compiling from the git repo |
| 21:10:32 | evan | hah |
| 21:10:33 | rue | Hm. The OOo website is good. |
| 21:10:41 | evan | let me know how it goes |
| 21:10:46 | evan | we could maybe use that as a submodule |
| 21:11:03 | evan | since, for once, we'd actually be using a submodule for the purpose they're designed for :D |
| 21:11:13 | rue | Heh |
| 21:13:38 | boyscout | CI: 7b809fa success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 21:14:49 | evan | ah sweet. |
| 21:14:57 | evan | i can have LLVM, when it detects invalid IR |
| 21:15:08 | evan | just print out a message and indicate as such. |
| 21:15:11 | evan | and not abort |
| 21:15:20 | evan | which means I can turn on the hotspot jit |
| 21:15:32 | evan | and not worry about it aborting the problem because it's not yet working perfectly |
| 21:16:28 | lypanov | evan |
| 21:16:36 | evan | lypanov |
| 21:16:53 | lypanov | did you get around to dumping bitcode for the intrinsics? |
| 21:17:02 | lypanov | as in |
| 21:17:28 | lypanov | are the rubinious opcodes now intrinsics |
| 21:17:41 | lypanov | and are you compiling said c into llvm bitcode? |
| 21:18:39 | evan | i did that before |
| 21:18:47 | evan | it was a bit of a pain |
| 21:19:03 | evan | this time, i did it more logically |
| 21:19:18 | evan | ie, i decided which opcodes should be functions and which ones not |
| 21:19:25 | evan | and coded them myself |
| 21:19:30 | evan | the ones that are functions are implemented in C |
| 21:19:35 | evan | and called out to |
| 21:19:39 | evan | but not all of them |
| 21:19:41 | evan | since last time |
| 21:19:52 | evan | the thing that was taking a huge amount of time was the inliner |
| 21:20:09 | evan | now the IR is much cleaner |
| 21:20:20 | evan | but i know which opcodes are common and which are rare |
| 21:20:23 | evan | so i can make the decision once |
| 21:21:49 | dgtized | rue: did you get git llvm to compile, and is so what version of gcc are you using? |
| 21:29:59 | evan | lypanov: make sense? |
| 21:30:16 | dgtized | evan: when was your patch to llvm committed? |
| 21:30:35 | evan | http://repo.or.cz/w/llvm.git?a=commit;h=6841c1aafe655bc77643107716f46d5951df8626 |
| 21:32:00 | dgtized | alright I will try compiling from that |
| 21:33:22 | lypanov | evan: sorry. mega distraction. will read shortly |
| 21:34:23 | evan | no prob |
| 21:36:24 | boyscout | Manually verify each Function and report if it's broken - 0566724 - Evan Phoenix |
| 21:37:21 | dgtized | evan: are you depeneding on rake to compile LLVM or configuring and making it by hand? |
| 21:37:42 | evan | either is fine. |
| 21:37:48 | evan | rake will do it if it must |
| 21:38:10 | dgtized | well it's not compiling for me, including from the revision your patch was accepted for |
| 21:38:26 | dgtized | consistantly get this build error: http://gist.github.com/115673 |
| 21:38:47 | evan | ok, one sec |
| 21:38:49 | evan | what gcc version? |
| 21:38:56 | dgtized | 4.3.3 |
| 21:39:32 | evan | i'm asking the llvm guys |
| 21:40:01 | dgtized | k, thank you -- do they have an irc channel or just a dev email list? |
| 21:41:05 | evan | irc on oftc.net |
| 21:41:54 | boyscout | CI: 0566724 success. 2682 files, 10321 examples, 32866 expectations, 0 failures, 0 errors |
| 21:42:12 | evan | dgtized: they're going to take a look |
| 21:45:08 | dgtized | thanks again |
| 21:48:25 | evan | no prob |
| 22:06:45 | brixen | dgtized: this is a quite good paper http://www.siam.org/meetings/alenex05/papers/13gheileman.pdf |
| 22:06:50 | brixen | see the conclusions |
| 22:09:09 | dgtized | brixen: fair enough |
| 22:11:02 | brixen | dgtized: it really comes down to the key distribution more than anything else |
| 22:11:23 | brixen | if it's the normal distribution, you are golden just throwing darts at a wall |
| 22:11:43 | brixen | if not, your careful algorithm falls down all around itself |
| 22:13:35 | brixen | dgtized: I'm looking at this now http://crpit.com/confpapers/CRPITV91Askitis.pdf |
| 22:15:39 | headius | so perhaps I'll show my ignorance here, but what exactly is wrong with those sequential strings having sequential hashcodes |
| 22:15:50 | headius | they'll end up in different buckets in just about every distribution |
| 22:16:51 | dgtized | can you re-explain how you get 3x operations by flattening the structure into the Tuple, from my mind even though you save multiple accesses into the Tuple, you pay for it by 3 accesses into the Struct + 1 for getting the struct from the Tuple |
| 22:17:30 | headius | dgtized: I think the problem there is not having the buckets reference a separate structure |
| 22:17:49 | headius | so if you have hash collisions or need to grow the hash (which you may have to do more often) you're reallocating and redistributing more stuff |
| 22:17:57 | luislavena | evan: is just me or simple rake -T just fires the entire build process? |
| 22:18:19 | luislavena | thinks a dependency issue smell over there. |
| 22:18:28 | luislavena | evan: talking about rubinius itself. |
| 22:21:01 | brixen | luislavena: what do you mean by entire build process? |
| 22:21:35 | luislavena | brixen: rake -T fires the compilation of the vm, which fires the compilation of the externals... |
| 22:21:47 | luislavena | brixen: while only should list the task I have available. |
| 22:21:49 | brixen | from a fresh clone ? |
| 22:21:57 | brixen | it only lists tasks for me |
| 22:22:50 | luislavena | brixen: yes, fresh clone. |
| 22:23:07 | brixen | yeah, probably some dep messed up |
| 22:23:11 | brixen | build once ;) |
| 22:23:22 | luislavena | brixen: guess have no choice ;-) |
| 22:23:39 | brixen | luislavena: replacing rake is the next task on my list |
| 22:23:51 | luislavena | brixen: with what? |
| 22:23:55 | brixen | Tap |
| 22:23:57 | luislavena | brixen: I think rake is not the problem. |
| 22:24:12 | luislavena | brixen: hmn, I have my doubts.. |
| 22:24:22 | brixen | luislavena: sure, you can always work around rake |
| 22:24:30 | brixen | but I'm tired of working around it |
| 22:24:34 | luislavena | brixen: tap sounds good to pipe "task" but not file based dependency. |
| 22:24:44 | brixen | it's got both |
| 22:25:23 | luislavena | brixen: yes, I know, but in comparison aren't so powerful. |
| 22:25:35 | luislavena | brixen: I guess I'm sooo used to rake and the way it works :D |
| 22:25:38 | evan | the deps are a mess. |
| 22:25:41 | evan | again. |
| 22:25:53 | luislavena | evan: you need a dep cleaner ;-) |
| 22:26:06 | luislavena | evan: there is a tool that graphs the build tree. |
| 22:26:16 | brixen | luislavena: when all you have is rake, everything looks like a dep ;) |
| 22:26:24 | evan | luislavena: yeah, ryan wrote it AND he did most of our deps |
| 22:26:27 | evan | so meh. |
| 22:27:07 | brixen | luislavena: but, your build will be done by the time your done complaining ;) |
| 22:27:11 | luislavena | evan: there is also drake, which is like make -j :D |
| 22:27:15 | brixen | and you only build a fresh clone once |
| 22:27:21 | luislavena | brixen: ;) |
| 22:27:29 | evan | luislavena: yeah, drbrain couldn't get our deps sorted out to use drake reliably |
| 22:27:52 | luislavena | evan: I cannot promise but been peeking some workarounds in a local branch. |
| 22:28:04 | luislavena | evan: peeking/hacking. |
| 22:28:17 | evan | sure |
| 22:28:22 | luislavena | evan: got quite used to rake so do proper chaining feels natural now. |
| 22:28:52 | brixen | luislavena: show me "proper chaining" for rake clean build and I'll change my mind |
| 22:29:10 | brixen | without a bunch of gross Task.invokes |
| 22:29:29 | luislavena | brixen: CLEAN.include ;-) |
| 22:29:42 | luislavena | brixen: you need to know what are your artifacts, of course. |
| 22:30:23 | luislavena | have a quick question, is the libtommath makefile generated by you guys, or is part of the original lib? |
| 22:30:24 | brixen | luislavena: also, could you add decent task docs and command line args |
| 22:30:31 | brixen | ohh, now you have Tap :) |
| 22:30:48 | luislavena | because need to change the "a.out" to just "-o a" so I can run it on windows. |
| 22:30:49 | evan | luislavena: it's part of the original lib. |
| 22:31:00 | evan | go for it |
| 22:32:53 | luislavena | brixen: maybe I need to give another opportunity to Tap. |
| 22:33:15 | luislavena | brixen: wonder why any of you guys went with Thor :P |
| 22:33:58 | brixen | I haven't scientifically evaluated the difference |
| 22:34:12 | evan | Thor isn't really a build tool. |
| 22:34:14 | evan | as I recall. |
| 22:42:48 | luislavena | evan: well, people used it in so many weird ways :P |
| 22:44:22 | lypanov | evan: tonight is just not my night. acceptance blew up also. i'll get back to you another time on the topic |
| 22:44:54 | evan | no problem |
| 22:44:56 | evan | i'll still be here. |
| 22:45:23 | lypanov | :) |
| 22:45:27 | lypanov | speak to you soon |
| 22:45:29 | slava | hi evan |
| 22:45:45 | evan | so, i guess their is an laruby group meeting tonight |
| 22:45:54 | evan | but damned if i can find any details about it |
| 22:46:08 | rue | evan: I can probably get you info, sec |
| 22:46:45 | evan | they don't seem to put the info anywhere |
| 22:53:29 | headius | evan: just ran into an interesting case |
| 22:53:38 | headius | we added super call site caching in 1.3 |
| 22:53:39 | evan | oh? |
| 22:53:51 | headius | but there's one special case that screws it up |
| 22:54:06 | evan | whats that? |
| 22:54:27 | headius | [:name1, :name2].each do |name|; define_method name do; super; end; end |
| 22:54:39 | headius | someone was doing that in a real app |
| 22:54:54 | headius | the problem is that there's only one super call site, right? but it's got multiple names that super through it |
| 22:55:07 | headius | in all other cases it's ok to not have to re-check the previously cached name |
| 22:55:11 | evan | wow. |
| 22:55:14 | headius | this one case has to check the name too |
| 22:55:14 | evan | fire. |
| 22:55:16 | evan | fired. |
| 22:55:23 | headius | yeah, pretty gross |
| 22:55:30 | rue | evan: Looks like the ATTi offices in Glendale, confirming |
| 22:55:38 | headius | I'm pretty sure this is the only way this can happen |
| 22:55:47 | headius | any other block would have a single containing method to super |
| 22:56:33 | evan | headius: what about duping the block body |
| 22:56:35 | evan | for define method |
| 22:56:38 | headius | that was my first thought |
| 22:56:38 | evan | to create 2 sendsites |
| 22:56:52 | headius | the problem is that I may already have compiled it |
| 22:56:57 | slava | I think in the future dynamic language designers will go for a stricter compile time/run time separation to ensure to avoid things like this |
| 22:57:03 | headius | define_method is just stuffing that block into something else |
| 22:57:18 | evan | true |
| 22:57:47 | headius | I'll probably just do a string identity check since we intern all method names |
| 22:58:04 | headius | worst case would be if there's a method name somewhere that didn't get interned (very unlikely) and kept failing identity check |
| 22:58:04 | luislavena | stupid question: llvm download: binaries or svn/tarball and then configure make? |
| 22:58:15 | headius | at which point it would be no slower than before 1.3 |
| 22:58:43 | evan | luislavena: has to be svn |
| 22:58:59 | evan | headius: well |
| 22:59:03 | luislavena | evan: cool, but I need to manually make then, since is looking for Release, right? |
| 22:59:04 | evan | since you're going to be checking |
| 22:59:17 | evan | seems like you could spin that as an inline cache for Object#send too |
| 22:59:39 | evan | Release don't matter |
| 22:59:40 | evan | but yes |
| 22:59:45 | headius | we have a send cache for literals, but I haven't gone the next step |
| 22:59:58 | headius | we also have a respond_to? site that's like a two-level cache with name check |
| 23:00:08 | headius | so this isn't unprecedented |
| 23:00:15 | headius | I just didn't consider the case of a super site handling two names |
| 23:00:30 | evan | yeah |
| 23:00:34 | evan | seriously. |
| 23:00:37 | rue | luislavena: Or git! |
| 23:00:43 | headius | it's definitely weird |
| 23:00:50 | headius | and no existing tests or specs caught it |
| 23:00:52 | headius | sigh |
| 23:01:00 | luislavena | rue: isn't out of sync the git version? |
| 23:01:31 | rue | luislavena: The one from repo.cz is a day behind, so it works too |
| 23:01:37 | rue | Just built actually |
| 23:01:53 | luislavena | rue: yikes, in the middle of the checkout. |
| 23:02:15 | rue | It will take a bit longer for SVN :) |
| 23:10:48 | headius | should just do a GH mirror under evanphx |
| 23:12:01 | evan | i'm not that mean to the GH guys :D |
| 23:12:01 | luislavena | rue: already compiling, so not bad :) |
| 23:12:17 | sandal | anyone got a moment to verify a bug for me? |
| 23:12:27 | evan | sandal: sure |
| 23:12:33 | sandal | http://bit.ly/K9hDL |
| 23:13:00 | sandal | evan: I finally got off my ass and decided to play with rubinius :) |
| 23:13:07 | sandal | thanks to you and others for a very cool project |
| 23:13:17 | evan | :D |
| 23:13:18 | sandal | all Prawn's examples run perfectly! |
| 23:13:38 | evan | um |
| 23:13:47 | evan | i have no clue why your code would run |
| 23:13:50 | evan | oh |
| 23:13:54 | evan | you want to make name writable? |
| 23:14:11 | evan | in rubinius, the name of a class is stored as a @name ivar |
| 23:14:11 | sandal | test/spec depends on this |
| 23:14:16 | evan | that has to be a symbol |
| 23:14:17 | sandal | and it works on Ruby 1.8.6 MRI |
| 23:14:21 | evan | right |
| 23:14:28 | evan | because MRI doesn't store the name of a class in ivars |
| 23:14:32 | evan | we do. |
| 23:14:40 | sandal | so this is just an incompatibility then? |
| 23:14:59 | sandal | I see. |
| 23:15:28 | evan | @name is a slot style ivar |
| 23:15:35 | evan | with a fixed type (Symbol) |
| 23:15:40 | evan | thats why you get this error. |
| 23:15:48 | evan | i guess we could change what the slot is called... |
| 23:15:52 | sandal | I could probably make a patch that works to test/spec that works around this issue for Rubinius |
| 23:15:52 | rue | Could write a conversion wrapper, of course |
| 23:16:48 | sandal | I'm not sure how often people are going to run into this, it seems a little scary to me to change name anyway |
| 23:16:50 | evan | sandal: thats certainly one solution |
| 23:16:54 | evan | yeah |
| 23:16:58 | sandal | But... it does break compatibility with MRI |
| 23:17:00 | evan | what is test/spec expecting to do? |
| 23:17:10 | evan | well, we've got lots more stuff like this |
| 23:17:13 | sandal | my guess is that this is for describe blocks |
| 23:17:18 | evan | so we're going to run into this. |
| 23:17:21 | evan | but why is it on Class? |
| 23:17:25 | evan | thats the problem. |
| 23:17:37 | sandal | actually, check my spec |
| 23:17:41 | sandal | it doesn't need to be on class |
| 23:17:48 | sandal | It just needs to be on 'a class' |
| 23:17:57 | evan | same thing |
| 23:18:00 | sandal | which is what test-spec is actually doing |
| 23:18:05 | sandal | well... anonymous clases |
| 23:18:09 | evan | the receiver is a Class object |
| 23:18:12 | sandal | subclasses of Test::Unit::TestCase |
| 23:18:13 | evan | an instance of Class |
| 23:18:23 | sandal | think of it like this |
| 23:18:35 | sandal | foo = Class.new(Test::Unit::TestCase) |
| 23:18:50 | sandal | foo.name = "My Test Case" |
| 23:19:00 | evan | sure i get it |
| 23:19:09 | evan | so test/spec picked, imho, a bad method name |
| 23:19:16 | evan | and we happen to conflict with it. |
| 23:19:17 | sandal | I think so too. |
| 23:20:17 | sandal | So actually, I think that Rubinius has a better behavior here |
| 23:20:17 | sandal | I just didn't know how religiously you wanted to be compatible with MRI |
| 23:20:17 | sandal | (totally new here :) |
| 23:20:17 | evan | well, there are 2 ways around this |
| 23:20:24 | evan | we do |
| 23:20:33 | evan | but we have to push back in certain places |
| 23:20:37 | evan | otherwise we'll get painted into a corner. |
| 23:21:00 | sandal | true, it's not necessarily best to duplicate design mistakes |
| 23:21:24 | rue | I like you :D |
| 23:21:33 | evan | :D |
| 23:21:44 | evan | sandal: perhaps you should push back on test/spec, have them change it to .description |
| 23:21:48 | evan | or something |
| 23:21:53 | evan | you'd be doing us a favor if you did. |
| 23:21:56 | sandal | yeah, I'll give that a try. |
| 23:22:02 | evan | thanks! |
| 23:22:09 | evan | btw, i totally meant to reply to your email |
| 23:22:13 | evan | but it slipped my mind. |
| 23:22:25 | sandal | It's not too important to me, just that if I can get my tests to pass in Prawn |
| 23:22:35 | sandal | that makes Rubinius the current leader of the GoRuCo Prawntest |
| 23:22:41 | evan | wooo |
| 23:22:50 | sandal | MacRuby also gets 100% examples to run |
| 23:23:12 | headius | Prawntest? |
| 23:23:14 | sandal | but does not seem to like RubyGems much |
| 23:23:14 | sandal | or something |
| 23:23:25 | headius | I think all prawn tests run green in jruby master now |
| 23:23:31 | headius | there was one last bug to fix that I pushed last night |
| 23:23:35 | sandal | hahah headius you're losing the Prawntest, BTW |
| 23:23:35 | sandal | I'll be sending you bug reports too |
| 23:23:41 | rue | sandal: MacRuby development version? |
| 23:23:44 | sandal | Oh, really? |
| 23:23:45 | sandal | Awesome |
| 23:23:46 | headius | yes |
| 23:23:52 | sandal | rue: 0.4 |
| 23:24:08 | sandal | headius: I gotta try that out then |
| 23:24:35 | rue | Ah, OK! I figured the experimental branch is probably not at that stage yet |
| 23:24:36 | sandal | was it the issue with pack/unpack or something like that? |
| 23:24:36 | sandal | Okay, so basically... I'm giving a talk that's about two different things at GoRuCo |
| 23:24:47 | sandal | The different Ruby language versions, and the different implementations |
| 23:25:00 | sandal | I want to leave the science to you guys ( headius, evan , etc) |
| 23:25:06 | sandal | so I just tried to get Prawn working :) |
| 23:25:17 | rue | sandal: You *must* flip a coin on stage in that case :P |
| 23:25:18 | evan | :) |
| 23:25:28 | sandal | It was a way to get familiar with the basics for each project. |
| 23:25:36 | evan | sandal: well, if you need anything from me, let me know. |
| 23:25:46 | headius | that was just based on gem install prawn and then rake test from the gem dir |
| 23:25:51 | headius | what was it failing? |
| 23:25:57 | sandal | evan: would you accept a patch to getting started that just lets people know that running rbx without any args == irb ? |
| 23:25:58 | headius | I think there was one "unexpected nil" failure left or something |
| 23:26:26 | sandal | headius: I didn't try running the tests for JRuby yet. |
| 23:26:35 | sandal | The examples fail because of some array index out of bounds |
| 23:26:37 | evan | sandal: certainly |
| 23:26:41 | headius | oh, how is it that we're "losing" the test then? |
| 23:26:46 | headius | it looks ok to me |
| 23:27:00 | sandal | Because any example involving TTF didn't run :) |
| 23:27:07 | headius | hmm |
| 23:27:15 | sandal | examples != unit test |
| 23:27:16 | headius | is that newer than the current released gem? |
| 23:27:30 | headius | well, if prawn doesn't have tests that actually exercise things that's not my fault ;) |
| 23:27:33 | sandal | no, just run rake examples on 0.4.1 |
| 23:27:37 | sandal | I can pastie you |
| 23:27:44 | headius | sure |
| 23:27:54 | headius | I could have the fixes in 1.3.0RC2 if they're not extensive |
| 23:27:56 | sandal | They do, that's what the nil failure was about |
| 23:28:09 | sandal | but let me pull down JRuby from edge before wasting time |
| 23:28:45 | headius | sure |
| 23:28:56 | sandal | FWIW (and to all the alt. implementer's credit) I have never tried to run Prawn on anything other than MRI and ko1's Ruby 1.9 until yesterday |
| 23:28:59 | headius | there's dist builds here: http://jruby.headius.com:8080/hudson |
| 23:29:10 | sandal | the fact that it all pretty much just 'works' is awesome |
| 23:30:12 | evan | yeah |
| 23:30:24 | evan | i'm super jazzed it's working as well as it has for you |
| 23:30:25 | evan | yay! |
| 23:30:59 | sandal | headius: if I just pull from master on github mirror will I get the changes? |
| 23:31:11 | sandal | Or should I be looking elsewhere? |
| 23:31:44 | headius | the github mirror should be fine |
| 23:31:51 | headius | it's only about 5 minutes behind at any given time |
| 23:32:04 | headius | we're pushing out RC2 monday, so there's a window for fixes |
| 23:32:34 | headius | git://github.com/sandal/prawn.git yes? |
| 23:33:25 | sandal | yep |
| 23:33:48 | sandal | but I've been testing against 0.4.1 to avoid my edge nastiness from skewing results |
| 23:33:59 | sandal | so just unpacking the latest gem would work |
| 23:34:26 | sandal | (Though AFAIK, the latest in master should work, just a pita to get set up) |
| 23:34:38 | headius | ahh ok |
| 23:35:21 | headius | I know test should be fine, trying examples |
| 23:35:37 | headius | Running Examples |
| 23:35:37 | headius | Ran in 21.387 s |
| 23:35:39 | headius | is that right? |
| 23:35:54 | rue | is tempted to push LLVM to github |
| 23:36:07 | sandal | headius: yeah, sounds like you are getting something that works |
| 23:36:16 | headius | rue: do |
| 23:36:17 | sandal | you would have seen a bunch of ArrayIndexOutOfBounds errors |
| 23:36:25 | sandal | check something like output/utf8.pdf |
| 23:36:31 | sandal | if that's there, it worked |
| 23:36:49 | headius | it's there and looks good...bunch of greek characters? |
| 23:37:08 | sandal | yup |
| 23:37:18 | headius | great, no worries then |
| 23:37:21 | sandal | building jruby now to test on my end |
| 23:37:31 | sandal | is that going to create a working bin/jruby for me? |
| 23:37:36 | headius | yep |
| 23:37:49 | headius | that's all there is to it |
| 23:38:07 | headius | the fixes for all this should be in last night's build too, if you have any trouble building |
| 23:38:31 | sandal | man both Rubinius and JRuby have been making my lap warm for the last day. And I don't mean that in a good way. |
| 23:38:44 | sandal | damn MBP gets hot when it compiles |
| 23:38:50 | slava | the new unibody ones aren't so bad |
| 23:38:57 | headius | heheh |
| 23:38:59 | headius | at least you don't have to build the JDK |
| 23:39:07 | sandal | true |
| 23:39:10 | slava | <troll>JDK is bad for the environment!</troll> |
| 23:39:29 | brixen | slava: yeah, the new mbp's are so nice |
| 23:39:55 | sandal | it'd be nice if jruby, kvm, mri, and rubinius all supported a standard command line layout for sub commands. |
| 23:40:03 | sandal | I really like bits and pieces of each of them |
| 23:40:16 | brixen | rbx is the best of course :) |
| 23:40:19 | sandal | I sort of like the idea of moving everything inside one command |
| 23:40:33 | sandal | instead of having 500 executables with different prefixes |
| 23:40:44 | sandal | then it'd also allow something like |
| 23:40:48 | sandal | <my interpreter of choice> gem install ... |
| 23:40:50 | headius | we do things like MRI |
| 23:40:54 | brixen | sandal: the ironruby guys started some command line specs :) |
| 23:41:01 | evan | sandal: both rubinius and jruby support using -S to use "internal" versions |
| 23:41:03 | headius | the -S thing is only to avoid calling MRI's versions |
| 23:41:12 | sandal | oh, neat |
| 23:41:16 | headius | if you put jruby's bin first in path you can just do "rake" or "gem" or whatever |
| 23:41:26 | headius | most people don't want to do that |
| 23:41:40 | sandal | Okay, -S makes sense then |
| 23:41:58 | sandal | It's mainly that right now I like 100 different Rubies installed :) |
| 23:42:06 | headius | we go back and forth on the debate about whether they should all be "jgem" and "jrake" and "jspec" |
| 23:42:18 | headius | gem install --format-executables is your friend |
| 23:42:20 | sandal | When I use MacRuby I keep thinking of McDonalds |
| 23:42:28 | sandal | which isn't a good thing |
| 23:42:30 | headius | haven't quite been willing to pull the trigger on making that default |
| 23:42:35 | sandal | A macrake sounds pretty disgusting |
| 23:42:40 | headius | eww |
| 23:43:10 | headius | macgod |
| 23:46:21 | sandal | headius: how recently was that patch applied? |
| 23:46:33 | headius | days |
| 23:46:35 | sandal | having the same problem here with the new build on master |
| 23:46:40 | headius | really? |
| 23:46:42 | headius | hmm |
| 23:46:45 | sandal | latest commit on jruby master is may 03rd, i think |
| 23:46:55 | headius | oh, you grabbed my jruby I bet |
| 23:46:59 | headius | get jruby/jruby |
| 23:47:17 | sandal | ah, yep, that's the problem |
| 23:47:20 | headius | deleting |
| 23:47:26 | headius | I thought I had nuked that already |
| 23:47:35 | sandal | Github sprawl FTL |
| 23:47:40 | headius | totally |
| 23:48:27 | sandal | this stuff is way too much fun. I'm afraid that I'm going to end up getting sucked into this whole implementing Ruby thing |
| 23:48:40 | sandal | just when I thought I could relax and take a break from open source for a while |
| 23:48:57 | headius | heheh |
| 23:50:10 | luislavena | sandal: you can never escape of open source... |
| 23:50:20 | luislavena | sandal: it suck you in... |
| 23:50:28 | luislavena | sandal: and never let you go. |
| 23:50:34 | sandal | luislavena: hahaha, good point |
| 23:50:45 | sandal | The only way to escape is to unplug completely |
| 23:51:06 | luislavena | sandal: yes, stop coding, stop using software, just start doing pottery... |
| 23:51:20 | luislavena | sandal: been thinking on that for a while... |
| 23:52:41 | headius | heh, 135 commits since may 3 |
| 23:52:48 | headius | no wonder it failed |
| 23:54:07 | sandal | headius: how far along is Ruby 1.9 support for JRuby? |
| 23:54:16 | sandal | evan: Is there plans for 1.9 support in Rubinius? |
| 23:54:18 | headius | kinda stuck around 90%ish |
| 23:54:30 | headius | hopefully to be finished up in 1.4 this summer |
| 23:55:02 | slava | wasn't 1.9 a preview release for 2.0, or something? |
| 23:55:11 | sandal | slava: well... :) |
| 23:55:14 | headius | it's a stable preview! |
| 23:55:18 | luislavena | evan: how do I know if rbx built with LLVM support? rake RBX_LLVM and everything is ok (after a clean) |
| 23:55:19 | sandal | 1.9.0 was originally supposed to be that |
| 23:55:24 | headius | a final beta |
| 23:55:29 | sandal | but 1.9.1 is considered stable |
| 23:55:39 | evan | luislavena: rake RBX_LLVM=1 |
| 23:55:46 | evan | sandal: haha |
| 23:55:48 | evan | :/ |
| 23:55:52 | luislavena | evan: there is no info in the rbx -v ? |
| 23:55:59 | evan | luislavena: about what? |
| 23:56:04 | evan | if it was compiled with LLVM? |
| 23:56:05 | evan | not atm. |
| 23:56:15 | luislavena | evan: about LLVM being linked/included/used. |
| 23:56:27 | luislavena | sandal: 1.9.1 is the stable version of the 2.0 preview :D |
| 23:56:27 | sandal | so is MacRuby the only alternative implementation that's Ruby 1.9 compatible right now? |
| 23:56:29 | evan | not currently, no. |
| 23:56:36 | evan | sandal: thats even debatable |
| 23:56:43 | evan | because they've gutting so much |
| 23:56:43 | sandal | evan: true :) |
| 23:56:49 | headius | macruby isn't 1.9 compatible |
| 23:56:58 | sandal | I was just really happy that they released 1.9.1 before my book prints |
| 23:56:59 | headius | mainly because nobody knows what 1.9 compatible is |
| 23:57:07 | sandal | But it's based on 1.9, right? |
| 23:57:18 | headius | yeah, and then they took out all the 1.9 core classes and replaced them with objc |
| 23:57:28 | evan | it's not based on 1.9 anymore |
| 23:57:30 | headius | so I think largely they had to start over on compat in many cases |
| 23:57:33 | sandal | Yeah, that's simultaniously awesome and scary |
| 23:57:33 | evan | they happen to still use their parser |
| 23:57:38 | evan | but thats about it. |
| 23:57:45 | sandal | they're moving to LLVM, right? |
| 23:57:49 | evan | yep. |
| 23:57:53 | evan | for execution. |
| 23:57:58 | sandal | but MacRuby 0.4 is YARV based? |
| 23:58:05 | evan | execution, yes. |
| 23:58:09 | evan | but even in 0.4 |
| 23:58:23 | evan | they've gutted and rewrite a large portion of the core classes |
| 23:58:42 | sandal | interesting. |
| 23:59:15 | sandal | okay, then, let me back up. A more pessimistic way of putting it is that MacRuby is the only one of the major implementations NOT targeting Ruby 1.8 |
| 23:59:28 | evan | sure |
| 23:59:39 | headius | that is true |
| 23:59:49 | evan | they're also the one thats devating the most |
| 23:59:53 | evan | deviating |