Show enters and exits. Hide enters and exits.
| 00:10:06 | slava | evan: no more LLVMWorkhorse? :( |
| 00:10:16 | evan | hehe |
| 00:10:16 | evan | nope |
| 00:10:33 | evan | refactored it into better pieces |
| 00:50:15 | boyscout | Make sure SHA1 is available. Fixes #92. - e568524 - Evan Phoenix |
| 00:50:15 | boyscout | defined?(super) support, served with a side of crow. Fixes #100. - 90d6311 - Evan Phoenix |
| 00:50:15 | boyscout | Unmask defined?(super) specs for rubinius - 4b8eb15 - Evan Phoenix |
| 00:50:24 | evan | to understand that 2nd commit |
| 00:50:30 | evan | you have to read the diff of the 3rd |
| 00:50:48 | brixen | hmm |
| 00:51:40 | evan | specificly, the comment I deleted |
| 00:51:47 | brixen | pulling... |
| 00:53:03 | brixen | hm ok, I will sync rubyspec probably tomorrow |
| 00:53:04 | boyscout | CI: 4b8eb15 success. 3005 files, 11483 examples, 35626 expectations, 0 failures, 0 errors |
| 00:53:08 | evan | k |
| 00:53:35 | evan | i need to write a spec i'm dreading |
| 00:53:55 | evan | class A < B; define_method(:foo) { defined?(super) }; end |
| 00:54:06 | brixen | ugh |
| 00:58:12 | evan | hey! |
| 00:58:17 | evan | the define_method one works! |
| 00:58:22 | evan | thats.. |
| 00:58:22 | evan | wow. |
| 00:58:26 | evan | a miracle. |
| 00:58:33 | evan | but i did find a breakage |
| 01:02:02 | justin-george | wow, that's a pretty twisted line of code. awesome stuff. |
| 01:03:29 | evan | heh |
| 01:07:22 | brixen | evan: @todo: discuss how to set up an offline CI that does stuff like configure for install, check preinstalled gems, etc |
| 01:07:35 | evan | 10-4 |
| 01:07:44 | brixen | ohh |
| 01:07:54 | brixen | we should have boyscout track @todo's in channel |
| 01:07:59 | brixen | and make us a list! :) |
| 01:08:13 | evan | we could certainly do that |
| 01:08:20 | brixen | hey, what about @issues too |
| 01:08:40 | brixen | like @issue: It doesn't work: http://gist.github.com/xxx |
| 01:08:40 | seydar | boyscouts are supposed to be good at organization |
| 01:08:46 | brixen | seydar!!!! |
| 01:08:49 | seydar | so this could be the equivalent of his eagle project |
| 01:08:49 | brixen | lurker!! |
| 01:08:56 | seydar | brixen!!!!! |
| 01:09:20 | brixen | how's amp going? |
| 01:09:48 | seydar | swimmingly. i'm in a licensing debate with mpm of mercurial, but we're knocking off some good bugs in amp while we're at it |
| 01:09:59 | brixen | nice! |
| 01:10:06 | brixen | did you get it running on rbx? |
| 01:10:32 | seydar | i still can't find the IP of my linux box. like it was sitting right next to me, but i don't know its IP |
| 01:10:49 | seydar | but once i do, i will inform you of its results |
| 01:10:53 | brixen | um, do you have a terminal hooked up? |
| 01:10:54 | justin-george | that's better than being able to ping it, but not knowing where it physically is. |
| 01:11:04 | brixen | justin-george: heh |
| 01:11:21 | justin-george | "I know it's connected to this switch... hmmm" |
| 01:11:47 | brixen | justin-george: isn't that when you just start powercycling and pinging iteratively? :) |
| 01:12:02 | justin-george | yeah I'm sure the customers would be *thrilled*. |
| 01:12:06 | brixen | heh |
| 01:12:12 | brixen | oh customers.. |
| 01:25:05 | boyscout | Fix a few defined?(super) edge cases - 3f371a3 - Evan Phoenix |
| 01:25:05 | boyscout | More defined?(super) specs - e468c99 - Evan Phoenix |
| 01:25:33 | evan | thats pretty thorough |
| 01:25:40 | evan | checks all edge cases I could think of |
| 01:25:48 | seydar | this deserves to be retold. mcilroy just said "ceci n'est pas une |" |
| 01:25:55 | evan | in a block, in a define_method, in a block in a define_method |
| 01:26:06 | evan | hah |
| 01:27:52 | boyscout | CI: e468c99 success. 3005 files, 11489 examples, 35632 expectations, 0 failures, 0 errors |
| 01:29:29 | evan | hello brian. |
| 01:32:58 | brianmario | yo |
| 01:39:39 | brianmario | evan: you ever go to the github meetups? |
| 01:39:48 | evan | when i'm in SF, yes. |
| 01:39:57 | brianmario | oh yeah :P |
| 01:40:01 | brianmario | forgot your in LA, yeah? |
| 01:40:09 | evan | yep |
| 01:47:12 | brixen | heh, I think I made configure --show for myself, I use it all the time |
| 01:47:52 | boyscout | Changed require paths for compiler to avoid RUBYOPT complications. - 771381c - Brian Ford |
| 01:47:52 | boyscout | Ensure kernel is recompiled after compiler changes. - d60fc51 - Brian Ford |
| 01:47:52 | boyscout | Fixed installing pre-installed gems. - ae4b893 - Brian Ford |
| 01:48:14 | brixen | evan: that should fix the recompile kernel if compiler is changed issue, but not recompile .rbc's in general |
| 01:48:23 | brixen | the signature check will fix that |
| 01:48:28 | brixen | coming up... |
| 01:48:39 | evan | 10-4 |
| 01:48:51 | brixen | and install is fixed for pre-installed gems |
| 01:49:02 | brixen | we really need to get something in CI though |
| 01:49:24 | brixen | since I discovered by accident it was broken... |
| 01:50:30 | brixen | snap snap boyscout, geez |
| 01:50:47 | boyscout | CI: ae4b893 success. 3005 files, 11489 examples, 35632 expectations, 0 failures, 0 errors |
| 01:50:53 | brixen | ty |
| 03:53:28 | evan | man the openssl extension has a shitton of compiler warnings. |
| 03:53:37 | evan | ones that I didn't create. |
| 08:13:29 | brixen | pretty funny in this readme where it says you aren't allowed to override a class's .name method http://github.com/superchris/rubyjs |
| 08:13:45 | brixen | "But you wouldn't do that anyways in Ruby, |
| 08:13:53 | brixen | so that's no big restriction!" |
| 08:13:58 | brixen | heh |
| 08:15:33 | brixen | we definitely need a js backend for llvm |
| 08:16:03 | brixen | hmm, ohh someone has worked on that |
| 08:21:46 | evan | hehe |
| 08:24:21 | evan | brixen: if you wanna try your hand at it |
| 08:24:29 | evan | the Marshal code for dealing with Floats needs some math love. |
| 08:24:39 | evan | there is some code to save the mantissa |
| 08:24:43 | evan | thats been ported from MRI |
| 08:24:46 | evan | that doesn't work |
| 08:37:16 | brixen | ok |
| 08:37:50 | evan | i'm poking at OpenSSL |
| 08:38:01 | evan | going to work on that a little more tomorrow |
| 08:38:05 | evan | it's terribly tedious though. |
| 08:38:15 | evan | so on a Friday, I might get distracted :) |
| 08:47:39 | evan | there also needs to be a long term project to reformat and review all of the openssl extension |
| 08:47:51 | evan | it needs to be cleaned up and modernized. |
| 08:47:53 | evan | it's a mess. |
| 08:52:20 | dbussink | brixen: could it be that kernel/bootstrap/rubinius_config.rb and kernel/bootstrap/ruby_config.rb should be added to the gitignore? |
| 08:53:19 | brixen | dbussink: no, they should not |
| 08:53:25 | brixen | they should be deleted |
| 08:53:57 | dbussink | brixen: ah ok |
| 08:54:08 | brixen | git clean or something |
| 08:54:24 | brixen | goes to sleep |
| 08:58:36 | dbussink | evan: nice to see that the ci is a bunch faster now again :) |
| 09:54:24 | rue | dbussink: I noticed those two too, but they do not exist anymore :) |
| 09:57:35 | dbussink | rue: yeah, i removed them and they didn't came back, so that's a good thing then :) |
| 09:57:37 | rue | Hrm. The compiler being in lib/ is kind of awkward but I suppose the workarounds are not too bad |
| 15:15:08 | rue | Applying the patches from the ML if they work out... |
| 15:15:19 | rue | Looks the first could also use changes on the Ruby side |
| 16:02:31 | dwaite | good morning |
| 16:17:21 | rue | You are WAY late |
| 16:22:06 | jammi | good morning, it's 18.22 here and I just woke up :) |
| 16:22:23 | rue | Argh, damn it I hate git-am failure not aborting it :/ |
| 16:39:36 | boyscout | Try handling negative indexes in Array#aset (Michael Neumann.) - f2b9fe5 - Eero Saynatkari |
| 16:39:36 | boyscout | Improve Array resizing with Tuple shifting (Michael Neumann.) - d56b6a1 - Eero Saynatkari |
| 16:39:36 | boyscout | Modify Tuple::lshift_inplace() slightly. - a9ed65b - Eero Saynatkari |
| 16:44:59 | boyscout | CI: a9ed65b success. 3005 files, 11489 examples, 35632 expectations, 0 failures, 0 errors |
| 17:24:08 | evan | hm. |
| 17:24:22 | evan | i'm thinking that capi implemented methods need to show up in the backtrace. |
| 17:24:27 | evan | it's confusing without them there |
| 17:24:33 | evan | since we show everything else |
| 17:32:01 | rue | Yes, they should |
| 17:34:45 | brixen | yes, that would be nice |
| 17:35:25 | brixen | rue: what issues are you having with compiler in lib? |
| 17:36:40 | evan | rad. |
| 17:36:44 | evan | openssl is working. |
| 17:37:00 | evan | just encrypted and decrypted some text |
| 17:38:30 | rue | brixen: It is too tightly required (coupled is not really a good word here) with the kernel to not be in kernel |
| 17:38:44 | rue | Required by... |
| 17:38:49 | brixen | evan: woot! |
| 17:39:10 | brixen | rue: I disagree... |
| 17:39:15 | evan | rue: it's used by MRI just fine |
| 17:39:19 | evan | and MRI doesn't have the kernel. |
| 17:40:37 | brixen | evan: could you elaborate on the Float marshal issue, it was ported from MRI but doesn't work? |
| 17:40:42 | brixen | I don't follow |
| 17:40:47 | brixen | are there failing specs? |
| 17:40:54 | evan | yes |
| 17:40:58 | evan | you'll see if you check them out |
| 17:41:08 | evan | basically, jroach tried to port the mantissa saving code from MRI |
| 17:41:10 | evan | but never got it working. |
| 17:41:21 | evan | if you check out the code in MRI |
| 17:41:25 | evan | you'll notice it's a direct port |
| 17:41:36 | evan | he FFI'd in all the relevent float manip functions to try and make it work |
| 17:41:38 | evan | but it doesn't work. |
| 17:42:16 | brixen | ok |
| 17:42:35 | slava | hi guys |
| 17:44:55 | rue | brixen: Does the kernel work without a compiler? |
| 17:45:38 | brixen | rue: yes |
| 17:45:49 | rue | Then we should not need to rebuild it if the compiler changes |
| 17:45:55 | brixen | or it will soon as I rewrite #require |
| 17:46:04 | brixen | those are 2 totally different things |
| 17:46:12 | brixen | define "work" |
| 17:46:36 | brixen | my definition, kernel runs fine without a compiler with the necessary prereqs |
| 17:46:46 | brixen | I've written a bridge to run hash, array in MRI before |
| 17:47:03 | brixen | in rbx, kernel runs fine from the rbc's without a compiler |
| 17:47:04 | rue | Is there anything else in lib/ that is used by kernel? |
| 17:47:14 | brixen | what does that matter? |
| 17:47:26 | brixen | why is that a relevant criteria for you undefined "work"? |
| 17:48:45 | evan | the rebuild on complier changes has nothing to do with the kernel using the compiler |
| 17:48:48 | evan | thats just a convience |
| 17:48:53 | brixen | oh, and we never compile the kernel inside rbx anyway, as it is running |
| 17:48:56 | evan | because often the compiler changes the bytecode being emitted |
| 17:49:06 | evan | and you want to be sure you get everything using the new bytecode |
| 17:49:24 | rue | What about mixing old and new bytecode? |
| 17:49:33 | evan | there is no such thing. |
| 17:49:44 | evan | I misspoke |
| 17:49:59 | evan | by new bytecode i mean "fixes a bug in the compiler" |
| 17:50:19 | evan | a new pattern |
| 17:50:25 | evan | a fix |
| 17:50:39 | evan | the old pattern runs fine, but in that case, it would probably be buggy |
| 17:50:42 | evan | thus the change. |
| 17:52:19 | rue | By and large, I would formulate the objection such that nothing in lib/ should be required for kernel to run. Perhaps that is fulfilled, it just does not feel quite right. |
| 17:52:41 | evan | and i'd say that is currently true. |
| 17:55:06 | evan | your comments have been taken into account |
| 17:55:15 | evan | brixen and I talked through this earlier this week |
| 17:55:24 | evan | he made a good case for having it in lib |
| 17:55:38 | evan | and it's not that big of a deal |
| 17:55:42 | evan | so we're going to stick with that for now. |
| 18:02:26 | evan | oh openssl. |
| 18:02:30 | evan | you're so crazy. |
| 18:12:34 | dwaite | whats up with openssl evan? |
| 18:12:52 | evan | the code is just crazy. |
| 18:12:58 | evan | and it should be conservative. |
| 18:13:30 | rue | Ah, I was not aware this was already discussed |
| 18:13:31 | dwaite | it was a long road to 1.0.0 |
| 18:13:39 | dwaite | with lots of casualties |
| 18:16:33 | evan | there are tons of warnings and such |
| 18:16:41 | evan | for a library thats focused on security |
| 18:16:44 | evan | it worries me. |
| 18:16:57 | evan | but it's still the most complete impl. |
| 18:17:02 | evan | so we'll do what we do. |
| 18:17:04 | evan | make it better. |
| 18:19:51 | rue | OpenSSL itself, or the rather questionable bindings thereof? |
| 18:20:02 | evan | hehe |
| 18:20:04 | evan | well really both |
| 18:20:08 | evan | but in this case, the bindings. |
| 18:20:35 | rue | I think Jamis was actually on here one day asking about SSL |
| 18:20:40 | evan | he was |
| 18:20:44 | evan | thats why i'm working on it. |
| 18:20:55 | evan | a ticket was entered for it |
| 18:21:29 | rue | Ah |
| 18:21:48 | rue | Thought he might have been feeling up for redoing it himself |
| 18:21:58 | evan | we discussed that at rubyconf |
| 18:22:04 | evan | neither of us have time to reimplement it |
| 18:22:18 | evan | and since capi is getting really complete |
| 18:22:29 | evan | i figured we'd try and see about using the existing one |
| 18:22:32 | evan | it's going well |
| 18:22:42 | evan | fleshing out things we haven't done yet in capi |
| 18:22:46 | evan | like rb_call_super :) |
| 18:30:50 | rue | What is the thought on exposing an rbx extension API? Just enforcing FFI is of course an option for most things |
| 18:33:56 | evan | rue: i've thought about it a few times |
| 18:34:04 | evan | we're actually sort of moving that direction already |
| 18:34:14 | evan | in that capi is a superset of MRI's functionality |
| 18:34:27 | evan | we provide functions for things that people have to dig around for normally |
| 18:41:10 | rue | Yes, but the MRI API is terrible...I would not want to force it on anyone writing a new extension. |
| 18:41:31 | rue | Just exposing one is not terribly tricky, if it seems like a good idea to do so |
| 18:41:47 | evan | it's mainly a question of what it would look like. |
| 20:11:13 | justin-george | a new design pattern: instead of a new object, just use a big case statement. |
| 20:13:07 | rue | Sounds brilliant |
| 20:13:30 | justin-george | one giant method becomes a new object and a 'Object.new.send(key)' |
| 20:14:20 | scoopr | design pattern or anti-pattern? :P |
| 20:14:57 | justin-george | this file had 1800 flog. anti-pattern. |
| 20:15:51 | justin-george | (side note: since rubinius produces low-level compiled instructions, one can estimate the complexity of a file by looking at the .rbc with wc -l) |
| 20:24:46 | evan | justin-george: are you refering to code in rubinius? |
| 20:26:01 | justin-george | no, I am not, but I was using rubinius as a sort of a poor man's flog |
| 20:26:27 | evan | aah |
| 20:26:28 | evan | gotcha. |
| 20:28:11 | scoopr | aah, how about rb/rbc ratio as a 'compression' ratio :P |
| 20:38:53 | agardiner | hmm... is the doc regarding the specs organisation out of date, or am I just missing the spec/ruby directory? |
| 20:50:26 | evan | agardiner: out of date it sounds like. |
| 20:51:23 | agardiner | hey evan! |
| 20:51:41 | evan | hey hey! |
| 20:51:45 | agardiner | so, what's the procedure now for updating a ruby spec? |
| 20:51:56 | evan | brixen was going to sync them today |
| 20:52:04 | evan | so you can either change it in frozen if it's minor |
| 20:52:10 | evan | or you just change it in rubyspec |
| 20:52:15 | evan | and we'll pick it up on the sync |
| 20:52:36 | agardiner | ah, ok - so the sync is two-way, not just rubyspec->frozen. |
| 20:52:43 | evan | yep |
| 20:52:47 | agardiner | coolio |
| 20:52:56 | evan | but be sure to do any commits to frozen in their own commit |
| 20:53:05 | agardiner | yeah, will do |
| 21:34:47 | boyscout | Add examples for String#% with string args - 7f55db4 - Adam Gardiner |
| 21:34:47 | boyscout | Fix String#% with empty string arg - d9ea513 - Adam Gardiner |
| 21:37:39 | boyscout | CI: d9ea513 success. 3005 files, 11489 examples, 35634 expectations, 0 failures, 0 errors |
| 22:00:22 | VVSiz | brixen: ping? |
| 22:04:41 | brixen | VVSiz: sup yo? |
| 22:05:07 | VVSiz | brixen: hi there. I'm a bit confused about these commitss to spec/frozen in rbx repo |
| 22:05:26 | VVSiz | i thought that you use rubyspecs directly without changes |
| 22:05:30 | brixen | we do |
| 22:05:34 | brixen | but ppl are lazy |
| 22:05:39 | brixen | so I try to make it easier |
| 22:05:40 | evan | me specificly |
| 22:05:44 | brixen | I merge back to rubyspec |
| 22:05:45 | evan | is lazy. |
| 22:05:45 | VVSiz | ahhh |
| 22:05:49 | evan | and brixen is awesome. |
| 22:05:49 | brixen | and then sync back here |
| 22:05:52 | evan | so he humors me. |
| 22:05:59 | VVSiz | heheheheh |
| 22:06:00 | brixen | VVSiz: are you having a problem with somethingL |
| 22:06:03 | brixen | ? |
| 22:06:05 | VVSiz | brixen is da man! |
| 22:06:28 | VVSiz | not really, I just noticed plenty of new specs in rbx's spec/frozen and was confused |
| 22:06:49 | brixen | yeah, there are about 20 some commits |
| 22:07:01 | brixen | I have to vett them and merge back |
| 22:08:18 | VVSiz | sweet! if there are periodic sync-ups, then there is no problem at all ;) |
| 22:09:22 | brixen | yep, periodically |
| 22:09:36 | brixen | I didn't want to try to manage that before 1.0rc1 but I'll do it now |
| 22:17:45 | rue | *chomp, chomp* I will have eaten 7200kcal today |
| 22:19:01 | evan | you going for a record? |
| 22:19:17 | evan | or are you trying to match the energy output of a food stove |
| 22:19:28 | evan | wood stove |
| 22:19:29 | evan | rather. |
| 22:19:31 | rue | Trying to avoid a grisly starvation |
| 22:19:59 | evan | i do like in chemistry class when you convert kcal's to joules |
| 22:20:06 | evan | and joules to all kinds of fun things |
| 22:20:44 | rue | Yes, I use J natively...what with this 'science' thing it works out nicely for Watts for example ;) |
| 22:20:44 | brixen | joules sound so much sexier than kcalories |
| 22:21:12 | evan | "my sandwich is worth 10000 turns of a hamster wheel!" |
| 22:21:15 | rue | Really, kJ and kcal |
| 22:21:36 | evan | sbryant``: is that real?! |
| 22:21:41 | rue | Easy rule of thumb, 1kcal = 4kJ and change |
| 22:22:27 | brixen | I've heard of sumo eating > 12-15k calories a day |
| 22:22:55 | evan | phelps was eating like 20k or something |
| 22:22:58 | evan | during the olympics |
| 22:23:14 | evan | but he was burning 18k or 19k per day |
| 22:23:32 | evan | the 400 fly or something is like 3k calories to swim. |
| 22:23:37 | evan | at the pace they do. |
| 22:23:46 | rue | I think Phelps is around 12k |
| 22:24:02 | evan | it was a lot. |
| 22:24:07 | rue | Even the pro cyclists are not much more than 8-9k per race day |
| 22:24:11 | evan | but he had zero delta |
| 22:24:16 | evan | between days |
| 22:24:36 | rue | sbryant``: For vastly shorter periods of time :) |
| 22:25:35 | evan | well |
| 22:25:40 | evan | he was doing like 5 races per day |
| 22:25:51 | rue | Yeah |
| 22:26:01 | evan | and swiming like 3x the distance of the races per day |
| 22:26:06 | evan | to warm up and cool down |
| 22:26:50 | rue | Yeah, I could see 10-13k or so at 0 delta |
| 22:27:04 | evan | yeah |
| 22:27:10 | evan | i don't recall the exact numbers |
| 22:27:22 | rue | Although he could have been overstuffing a little, it does not matter that much for a relatively short period |
| 22:27:35 | evan | yeah |
| 22:28:10 | rue | Still, ways to go :) |
| 22:28:43 | evan | heh |
| 22:30:44 | VVSiz | brixen: am I doing something wrong?: http://pastie.org/728274 has just compiled rbx, and the tests during the build are OK. but standalone rubyspecs can't start |
| 22:31:54 | brixen | VVSiz: looks like stale rbc files |
| 22:32:09 | brixen | make sure you rm all the .rbc files in that dir |
| 22:32:29 | VVSiz | ahhhhh, I *always* forget about those damn stale files |
| 22:32:38 | agardiner | hi brixen! |
| 22:32:39 | brixen | yeah, I'm fixing right now :/ |
| 22:32:43 | brixen | agardiner!!! |
| 22:32:46 | brixen | how goes man? |
| 22:32:53 | agardiner | wassup! |
| 22:32:57 | agardiner | :-) |
| 22:33:05 | brixen | nuttin much :) |
| 22:33:16 | brixen | being harrassed by VVSiz, but what's new :D |
| 22:34:22 | VVSiz | heheheh |
| 22:34:36 | VVSiz | do you guys ever run rubyspecs' optional/ffi? |
| 22:34:58 | VVSiz | so far seems no-go with rbx |
| 22:34:59 | brixen | I haven't yet... |
| 22:35:08 | brixen | rbx ffi isn't quite the same |
| 22:35:09 | agardiner | so i'm trying to dig into the debugger again... |
| 22:35:15 | brixen | agardiner: sweet! |
| 22:35:27 | brixen | agardiner: I was wondering about using irb as the command shell for the debugger |
| 22:35:33 | agardiner | man, its such a long time since i touched it |
| 22:35:38 | brixen | agardiner: wycats was doing a nice refactoring of the irb code... |
| 22:35:44 | evan | VVSiz: ruby-ffi and jruby-ffi have strayed pretty far rom my original API |
| 22:35:45 | agardiner | yeah, that might be cool |
| 22:35:54 | evan | and we haven't yet resolved the differences. |
| 22:35:57 | justin-george | http://pastie.org/728281 any thoughts? |
| 22:36:10 | brixen | agardiner: I figured it'd be a nice way to integrate and save duplication |
| 22:36:15 | VVSiz | evan: got it. but is there a hope? :) it would be pretty *sweet* to have the same FFI for MRI/JRuby/RBX |
| 22:36:15 | evan | justin-george: wierd |
| 22:36:17 | agardiner | where does he find the time!?! |
| 22:36:20 | evan | justin-george: run with --debug |
| 22:36:23 | evan | see if you get a backtrace |
| 22:36:28 | justin-george | can do |
| 22:36:29 | brixen | agardiner: so we could easily drop into the debugger whenever |
| 22:36:29 | evan | VVSiz: well, there was |
| 22:36:38 | VVSiz | oh? |
| 22:36:39 | evan | imho, the rbx FFI API is the base level one |
| 22:36:42 | evan | the original one |
| 22:36:55 | evan | that ruby-ffi diverged is sad |
| 22:37:05 | evan | because it did not need to diverge alone |
| 22:37:38 | justin-george | no love, same message |
| 22:37:43 | evan | um |
| 22:37:48 | evan | how do you get the backtrace from rubygems? |
| 22:37:54 | agardiner | anyway, i'm trying to understand how the instruction.def stuff works now... |
| 22:37:57 | evan | do you have to do that with the .gemrc? |
| 22:38:05 | agardiner | i see that iseq.rb is gone |
| 22:38:58 | brixen | justin-george: you could try bin/rbx --dl -S gem install rails |
| 22:38:59 | justin-george | evan: wait, I'm retarded, I need to update *everything* before I even talk more. |
| 22:39:11 | evan | k |
| 22:39:21 | brixen | agardiner: you should check out instructions.def and the rake tasks in vm.rake |
| 22:39:32 | brixen | agardiner: everything is gen'd from instructions.def now |
| 22:39:50 | brixen | agardiner: rakelib/instruction_parser.rb |
| 22:39:55 | agardiner | is there a ruby class gen'd, or is it all in the VM? |
| 22:40:09 | brixen | I just installed rails 2.3.5 btw |
| 22:40:15 | brixen | it was pretty damn fast... |
| 22:40:36 | brixen | agardiner: there's ruby structures created for the opcodes used by the compiler |
| 22:41:02 | agardiner | yeah, that's what i'm looking for... |
| 22:41:06 | brixen | agardiner: look at instruction_parser.rb, it's really simple... |
| 22:41:09 | agardiner | there used to be a flow attrib on iseq |
| 22:41:32 | evan | agardiner: yeah, we didn't know what it did |
| 22:41:39 | VVSiz | evan: anything that needs to be done to resolve the FFI differences? this mismatch between the APIs is realy an unfortunate one |
| 22:41:40 | agardiner | ah! |
| 22:41:41 | evan | so it got removed |
| 22:41:43 | agardiner | hehe |
| 22:41:54 | agardiner | i used it to determine whether an opcode could branch or not |
| 22:41:58 | evan | VVSiz: ruby-ffi could conform back to the rbx API |
| 22:42:02 | agardiner | i need that to know how to step |
| 22:42:10 | VVSiz | heh |
| 22:42:10 | evan | but that means removing features. |
| 22:42:27 | evan | the long and short of it is that I think there needs to be a full stop on the FFI API |
| 22:42:45 | evan | all impls were really experiments on an idea |
| 22:42:50 | evan | without much direction of what was needed |
| 22:42:55 | evan | we've got a better idea now |
| 22:43:02 | evan | so it might be time to break API compat for all |
| 22:43:07 | evan | and unify them. |
| 22:43:19 | evan | there are a few things I was thinking about last night |
| 22:43:25 | evan | that would cleanup a lot of things. |
| 22:43:25 | brixen | agardiner: so, one idea I had was annotations preceding the instruction def to add flags |
| 22:43:40 | brixen | agardiner: we were able to put everything we needed into the args and stack effect |
| 22:43:49 | brixen | agardiner: but feel free to experiment |
| 22:44:23 | brixen | agardiner: also, I was thinking about trying out Yard doc style for the opcode docs... |
| 22:44:26 | brixen | just a thought |
| 22:44:34 | VVSiz | evan: OK, got it. will keep watching where it goes |
| 22:44:40 | evan | VVSiz: the big thing is that ruby-ffi was making unilateral changes |
| 22:44:53 | agardiner | i'm not familiar with Yard, so i don't have any thoughts on that... :-S |
| 22:44:57 | evan | and not contributing them back |
| 22:45:01 | evan | which caused the current situation. |
| 22:45:41 | VVSiz | so, the "main" or "canonical" repo, where it should be? where to contribute back to? |
| 22:46:02 | evan | thats the thing |
| 22:46:08 | VVSiz | my understanding is that it should be http://wiki.github.com/ffi/ffi , no? |
| 22:46:13 | evan | why? |
| 22:46:24 | evan | again, that was all setup unilaterally |
| 22:46:38 | evan | tries to not show his frusteration with the ruby-ffi situation too much |
| 22:46:51 | justin-george | you should poke them with pointy sticks. |
| 22:46:56 | evan | if anywhere is going to be canonical |
| 22:47:08 | VVSiz | I understand, I just figuring this stuff out |
| 22:47:08 | evan | all implementers need to be explicited invited into it |
| 22:47:13 | evan | and there needs to be coordination. |
| 22:47:23 | evan | thats not what has occured thus far. |
| 22:47:29 | evan | thats no fault of anyone |
| 22:47:37 | evan | i certainly didn't try and take the reigns of it |
| 22:47:42 | evan | I just wanted an FFI to use within rbx |
| 22:48:07 | VVSiz | sometimes it is hard to move forward and at the same time to have everybody onboard and in agreement, yeah. |
| 22:48:45 | evan | now people expect that all the FFI impls have perfect sync |
| 22:48:49 | evan | but that was never a goal |
| 22:48:51 | VVSiz | but it *is* useful for rbx to have unified FFI that can be used without changes in JRuby and MRI, right? Is that still a goal? |
| 22:48:54 | evan | if we want sync |
| 22:48:56 | evan | then we have to work for it |
| 22:48:59 | evan | it doesn't come for free. |
| 22:49:11 | evan | if want it to be a goal |
| 22:49:12 | evan | sure |
| 22:49:22 | evan | but it has be defined as a goal! |
| 22:49:26 | evan | it hasn't been thus far. |
| 22:49:32 | evan | thats why everyone makes incompatible changes |
| 22:50:14 | VVSiz | it is clearer now |
| 22:50:43 | evan | if you wanna help, i'd love that. |
| 22:50:55 | evan | wanna here my current take on the APIs themselves? |
| 22:51:51 | VVSiz | evan: that would be nice, yeah. but maybe it needs to be in some more permanent format? like mail posting or something? |
| 22:52:02 | VVSiz | or blog post |
| 22:52:04 | evan | well, lets discuss |
| 22:52:10 | evan | then we can write it up |
| 22:52:16 | rue | Yespees |
| 22:52:19 | evan | sbryant``: well, what additions |
| 22:52:21 | evan | so |
| 22:52:28 | evan | there are WAY too many Pointer classes. |
| 22:52:31 | evan | ruby-ffi has 4 of them |
| 22:52:36 | evan | and no one knows which to use |
| 22:52:47 | evan | actually, it has 6 |
| 22:53:00 | evan | rbx FFI has one |
| 22:53:00 | evan | yes |
| 22:53:05 | brixen | VVSiz: the specs are at rubyspec/optional/ffi |
| 22:53:13 | evan | sbryant``: go for it |
| 22:53:20 | evan | sbryant``: adding callback support |
| 22:53:25 | evan | we'll need that anyways |
| 22:53:45 | evan | so, I think there needs to be 2 pointer classes |
| 22:53:51 | evan | Pointer and TypedPointer |
| 22:54:02 | evan | TypedPointer is a subclass of Pointer that knows the type of the thing pointed at |
| 22:54:21 | evan | you can create a Pointer from a TypedPointer |
| 22:55:03 | evan | ruby-ffi has an AutoPointer |
| 22:55:08 | evan | which needs to go entirely |
| 22:55:41 | VVSiz | but I don't see 6/4 different pointers in the API |
| 22:55:47 | evan | ruby-ffi's AutoPointer lets you register cleanup |
| 22:55:49 | VVSiz | MemoryPointer/AutoPointer |
| 22:56:05 | evan | VVSiz: Pointer, MemoryPointer, AutoPointer, NullPointer, Buffer, AbstractMemory |
| 22:56:45 | evan | AutoPointer's cleanup uses finalizers. |
| 22:56:56 | evan | it's way too unreliable to be used with C memory management. |
| 22:57:13 | evan | and it luls users into thinking that it is reliable 100% of the time |
| 22:57:47 | evan | eh? |
| 22:58:06 | evan | no |
| 22:58:09 | evan | be more verbose |
| 22:58:12 | evan | i don't know what you're commenting on. |
| 22:58:34 | VVSiz | but that AutoPointer is handy ;) |
| 22:58:43 | evan | but it's wrong. |
| 22:59:00 | evan | no matter how handy it is |
| 22:59:13 | evan | automatic cleanup of external resources can be done |
| 22:59:17 | evan | but using finalizers is not the answer. |
| 22:59:31 | evan | I think the answer has to be managed cleanup pools |
| 22:59:42 | evan | with a simple, clean API for users |
| 23:00:30 | evan | that solves the fast majority of the use cases of AutoPointer |
| 23:00:38 | evan | and still gives you the nicity |
| 23:01:38 | evan | ok, well i guess we'll have to discuss another time |
| 23:01:46 | evan | looks like everyone has wandered off. |
| 23:02:19 | VVSiz | I'm still here. :) Trying to figure out what is NullPointer, never used it, not seeing in the sources. |
| 23:02:33 | evan | wayne created it as a singleton |
| 23:02:39 | evan | to provide Pointer::NULL |
| 23:02:44 | evan | he said he copied the java way of doing it |
| 23:02:48 | evan | but it's needless |
| 23:02:54 | evan | it should be just removed |
| 23:04:38 | VVSiz | OK, what I'm getting is that some sync-up is needed for sure :) |
| 23:04:56 | evan | some sync up, yes |
| 23:05:03 | evan | but i disagree with the some APIs in ruby-ffi |
| 23:05:24 | evan | so thats a sticking point. |
| 23:05:52 | rue | It would probably be better to just define a working API and then proffer that |
| 23:08:00 | justin-george | religious wars! 0_o |
| 23:08:35 | evan | something that I really want to convey is that in my mind, FFI is a quite conservative API |
| 23:08:52 | brixen | and very very thin |
| 23:08:55 | evan | yes |
| 23:08:57 | evan | the thinner the better. |
| 23:09:09 | brixen | maybe we should try the documentation-driven approach to the api |
| 23:09:17 | brixen | just write out the description of each method |
| 23:09:29 | rue | The 'work' for a FFI extension should be done in Ruby, or in the library, not in FFI. |
| 23:09:29 | justin-george | dare I say a ruby-ffi-spec project? |
| 23:09:41 | VVSiz | but there is also a need for user-friendly "thick" API too. so, multi-level APis? |
| 23:09:46 | brixen | justin-george: there's already specs |
| 23:09:52 | evan | VVSiz: I disagree. |
| 23:09:59 | evan | i've yet to see where those are needed |
| 23:10:05 | brixen | justin-george: rubyspec/optional/ffi, but they do not conform to the style guide in many places |
| 23:10:05 | evan | i'm open to examples |
| 23:10:10 | evan | but i've yet to see them. |
| 23:10:15 | evan | rubinius is still the biggest FFI user |
| 23:10:22 | evan | and we haven't needed them. |
| 23:10:23 | rue | But, for the sake of argument, we could stipulate that such an additional API could be a separate library |
| 23:10:29 | evan | sure |
| 23:10:31 | rue | Or would be, rather |
| 23:10:35 | brixen | I'm missing the need for a thick api too |
| 23:10:44 | evan | all impls should share some ruby code |
| 23:10:46 | brixen | that's called an FFI client app in my mind |
| 23:10:48 | evan | that implements parts of the API |
| 23:10:53 | evan | that should be a goal. |
| 23:11:06 | rue | Also, but it is not something that needs to be addressed if it is assumed to be a separate entity, if anything |
| 23:11:15 | evan | i'm cloudy on what a thick API is |
| 23:11:18 | rue | Ideally the "thick" API would be pure-Ruby |
| 23:11:19 | evan | so i'll just ignore the idea |
| 23:11:24 | evan | until someone shows me an example. |
| 23:11:50 | VVSiz | for example, current ffi_lib is very "thin", it just tries to load the lib |
| 23:12:05 | VVSiz | no way to specify extra places where to look for, and things like thaty |
| 23:12:23 | rue | So, basic stuff needed are function calls, callbacks/"function pointers", the limited set of basic types |
| 23:12:45 | evan | VVSiz: got an example? |
| 23:12:47 | VVSiz | also, platform dependent things, different lib names and extensions, this all needs to be done in client code |
| 23:12:47 | evan | of that |
| 23:12:49 | evan | being a problem |
| 23:13:03 | VVSiz | yeah, nokogiri on Windows with JRuby |
| 23:13:05 | evan | ffi_lib delegates to dlopen() |
| 23:13:22 | evan | which searchs in the proper platform dependent way. |
| 23:13:27 | VVSiz | yeah, bare-bones delegate to dlopen |
| 23:13:34 | evan | so |
| 23:13:42 | evan | you've put libxml.dll some random place |
| 23:13:47 | evan | and you want to pick it up? |
| 23:14:04 | evan | seems like a simple ffi_library_path |
| 23:14:06 | evan | would solve this. |
| 23:14:20 | evan | i don't consider that a "thick" API |
| 23:15:12 | brixen | right |
| 23:15:26 | evan | i'm totally open to looking at examples |
| 23:15:38 | evan | and figuring out how we come up with solutions |
| 23:15:43 | brixen | there could be more machinery resolving the path |
| 23:15:50 | evan | but some examples will require solutions i don't think should be in the base FFI |
| 23:15:54 | evan | which is fine |
| 23:15:55 | brixen | but the thin part is that it just uses one syscall to load the library |
| 23:16:02 | evan | those can easily go somewhere else if someone really needs them. |
| 23:17:07 | brixen | could conceivably have #require_ffi with it's own load path data |
| 23:17:18 | evan | sure |
| 23:17:18 | brixen | if we really need a complex path resolver |
| 23:17:35 | evan | ways of loading libraries should probably be in base |
| 23:17:41 | evan | none of that is very complex. |
| 23:17:42 | rue | If you need a really complex path resolver, your LD env is fucked up. |
| 23:17:53 | VVSiz | then again, on Windows, it is not just ffi_lib "libxml2", it must be "libxml2.dll" |
| 23:17:55 | rue | Or you put your library in the wrong place |
| 23:18:17 | VVSiz | rue: nokogiri comes with dll's in gem itself |
| 23:18:55 | justin-george | hmm. Kernel#exec is broken. I make test. |
| 23:18:57 | brixen | VVSiz: why should the .dll be specified? can't the loader API know it's running on windows? |
| 23:19:07 | VVSiz | so this all complicated the user code a bit. |
| 23:19:18 | VVSiz | because it is currently a dump/thin API doing minimal work |
| 23:19:32 | justin-george | what's a cross-platform command to exec? hmmm |
| 23:19:43 | VVSiz | and when it comes to features/functionality everybody has different boundaries what is thin and what is an extended functionality |
| 23:20:24 | brixen | VVSiz: that's true, but then there is an aesthetic to making useful APIs |
| 23:20:35 | rue | VVSiz: Yeah...in that case, I think the Gem should either install the library in the correct place |
| 23:20:37 | brixen | we, of course, have many examples of horrid APIs hehe |
| 23:20:52 | evan | ok |
| 23:20:54 | rue | Erm -either |
| 23:20:59 | evan | the idea of thin vs thick is useless |
| 23:21:02 | evan | no more discussion of it |
| 23:21:16 | evan | examples should be evaluated on their own merit. |
| 23:21:35 | evan | VVSiz: ffi_lib was always supposed to try and load the library in the best possible way fo the platform |
| 23:21:40 | evan | than it requires .dll is a bug |
| 23:22:04 | evan | that you can't specify additional places is a simple enhancement request. |
| 23:22:13 | evan | lets fix those 2 things |
| 23:22:55 | VVSiz | it might not require in simple case, but when you do ffi_lib "full/path/to/lib.dll", on must use proper slashes and extension, etc. because that's how LoadLibrary on windows works |
| 23:23:09 | evan | ok |
| 23:23:09 | evan | hold on. |
| 23:23:15 | evan | lets take a step backward. |
| 23:23:32 | evan | imho, FFI must be platform independent |
| 23:23:50 | evan | so if ffi_lib needs to have a bunch of code do deal with windows, then it should have it |
| 23:24:06 | evan | platform independency is different than very high level APIs |
| 23:24:12 | evan | which was the original discussion point. |
| 23:25:01 | slava | hi evan |
| 23:25:04 | evan | than LoadLibrary has certain rules is fine |
| 23:25:13 | rue | To expand on earlier, there could for example be a conventional location to put libraries "imported" by/for a FFI binding |
| 23:25:20 | evan | ffi_lib should take it's argument and transform it properly do hand to LoadLibrary |
| 23:25:26 | evan | thats basic API requirements. |
| 23:25:39 | evan | slava: hi hi |
| 23:26:21 | VVSiz | OK, I clarified the situation for myself a bit, thanks. |
| 23:29:53 | evan | welcome back. |
| 23:30:38 | evan | yeah |
| 23:30:41 | evan | 2 in my eyes |
| 23:30:54 | evan | the callback work is unrelated |
| 23:30:56 | evan | if you do it now. |
| 23:31:13 | slava | evan: I think its time I stopped using gcc extensions for global register variables |
| 23:31:24 | evan | huzzah |
| 23:31:25 | evan | ! |
| 23:32:56 | justin-george | hey what's the schedule for rc2? |
| 23:33:08 | evan | justin-george: out in 3 weeks. |
| 23:33:12 | evan | right before the holidays. |
| 23:33:25 | justin-george | and that's going to be 2.3.5 compatible? |
| 23:33:30 | evan | yep |
| 23:33:32 | justin-george | I can't even get rails to boot :( |
| 23:33:38 | evan | you should be able to |
| 23:33:41 | evan | i can on master |
| 23:33:57 | evan | you need to open an issue with your details |
| 23:34:01 | evan | so we can figure out why |
| 23:34:14 | justin-george | yeah I'm going through the backtraces |
| 23:34:29 | justin-george | it's failing on 'require "config/boot.rb"' |
| 23:34:36 | justin-george | let me run it and pastie into an issue |
| 23:34:43 | justin-george | probably my error, but still :P |
| 23:35:06 | dbussink | justin-george: running rc1 or master? |
| 23:35:10 | justin-george | master |
| 23:35:34 | dbussink | justin-george: ok, that's good :) |
| 23:35:42 | dbussink | i need to get some sleep though :P |
| 23:35:45 | justin-george | http://pastie.org/728368 |
| 23:36:13 | evan | wtf is with that top line!? |
| 23:36:28 | evan | the main.script one |
| 23:36:32 | justin-george | bin/rbx script/server |
| 23:36:41 | evan | um |
| 23:36:44 | evan | is this a big rails app? |
| 23:36:48 | evan | or a blank one? |
| 23:36:48 | justin-george | your guess is as good as mine? let me try clearing everything |
| 23:36:51 | justin-george | no, it's fairly small |
| 23:36:58 | justin-george | it's our test for New Relic RPM's agent |
| 23:36:59 | evan | please try a blank one |
| 23:37:03 | justin-george | basically a microblog |
| 23:37:03 | evan | see if you can get that up |
| 23:37:08 | justin-george | kk will do |
| 23:37:10 | evan | rails blah |
| 23:37:16 | evan | bin/rbx blah/script/server |
| 23:37:20 | justin-george | sorree :) |
| 23:37:23 | evan | no no |
| 23:37:30 | evan | i just need to know what does and deosn't work for you. |
| 23:37:51 | justin-george | yup, I'm on it |
| 23:40:35 | justin-george | hmm blank app works... I'm wondering if there are some excess .rbc files hanging around. |
| 23:41:40 | justin-george | also, for reference, I hate gems. |
| 23:44:23 | justin-george | ah now here's the meat of the matter: http://pastie.org/728380 |
| 23:44:37 | justin-george | rails boots fine, btw, much better |
| 23:44:47 | justin-george | our plugin is broken but that's to be expected |
| 23:45:15 | evan | hopefully we'll have the bad .rbc problem solved for rc2 |
| 23:45:31 | justin-george | check file modified times? |
| 23:46:12 | evan | we already do that. |
| 23:46:17 | evan | it's because we're fixing compiler bugs. |
| 23:46:40 | justin-george | ah cool beans ;) good reason for breakage |
| 23:50:11 | evan | oh man |
| 23:50:14 | evan | it's so nice having the heat fixed. |
| 23:50:40 | brixen | it's freakin cold here |
| 23:50:48 | justin-george | haha my office was 62 degrees at the beginning of november. Perfect if you like wearing a coat all the time. |
| 23:50:57 | brixen | high is supposed to be 34deg on monday |
| 23:51:00 | justin-george | it's a balmy 67 now. |
| 23:51:03 | evan | it's not that cold here |
| 23:51:15 | evan | it's just that my condo stays about 10 degrees cooler than outside |
| 23:51:28 | evan | so it's been like 64ish in here for the last few weeks |
| 23:51:35 | evan | which is just a little chilly |
| 23:51:50 | evan | heat is fixed, now it's 72 |
| 23:53:07 | brixen | heh |
| 23:55:21 | evan | openssl is sussing out some good capi bugs |
| 23:55:27 | evan | because it pushes it hard. |