Show enters and exits. Hide enters and exits.
| 00:00:56 | evan | brixen: |
| 00:01:06 | evan | class A; define_method :foo, lambda { super }; end |
| 00:01:11 | evan | I get a compiler error |
| 00:05:37 | brixen | um.. |
| 00:06:52 | evan | also get a VM error |
| 00:07:01 | evan | if i move things around a little |
| 00:07:11 | evan | because I think the super send site is created with nil as the name |
| 00:07:15 | evan | which makes sense |
| 00:07:17 | brixen | yes |
| 00:07:32 | brixen | it does have nil name |
| 00:07:37 | jvoorhis | so if i wanted my llvm bindings to run on rbx, i should avoid implicit use of to_ptr, implement dispose instead of AutoPointer, and avoid dynamically linking LLVM if it's already statically linked |
| 00:07:45 | evan | ok, i'll adjust code to allow for that |
| 00:07:53 | evan | i think we should probably always use nil there. |
| 00:08:13 | evan | i'll have to check, but we need to work out the "which super method is invoked" issue |
| 00:08:24 | evan | ie, does aliasing influence super |
| 00:08:28 | brixen | evan: if you look at rubyspec/language/super_spec.rb there are specs at the bottom we've never passed |
| 00:08:38 | evan | jvoorhis: those would help! |
| 00:08:49 | brixen | they are deleted in frozen because they caused compiler errors under the old compiler |
| 00:08:50 | evan | jvoorhis: if you wanna polish up the FFI api a little |
| 00:08:54 | evan | i'd be happy to give you a commit bit |
| 00:09:09 | evan | 10-4 |
| 00:11:00 | jvoorhis | evan: i should ask for it a little bit later :) i'd love to help out, but the LLVM wrapper is just a small piece of a bigger project i want to pull off soon |
| 00:11:12 | evan | ok cool |
| 00:11:18 | evan | i'd love to get your LLVM API running on rbx |
| 00:11:33 | evan | eventually, i could see us writing optimization passes in ruby |
| 00:11:35 | evan | that the JIT would use |
| 00:11:43 | jvoorhis | that would be awesome |
| 00:11:55 | jarib | jvoorhis: what's the bigger project? |
| 00:11:59 | jvoorhis | i'm only going through the C wrappers |
| 00:12:13 | jvoorhis | jarib: i'm prototyping something not entirely unlike Csound |
| 00:12:25 | jarib | oh, nice |
| 00:12:37 | jarib | looked at supercollider? |
| 00:12:45 | brixen | evan: that form above (with super) is a compile error under the old compiler too |
| 00:12:46 | jvoorhis | yeah, supercollider is cool |
| 00:12:57 | brixen | evan: I didn't know how to fix it with the scheme we use |
| 00:13:01 | jvoorhis | i have a pretty different design though |
| 00:13:40 | evan | brixen: ok. |
| 00:13:44 | evan | yeah |
| 00:13:45 | evan | hm. |
| 00:13:45 | evan | ok |
| 00:14:27 | evan | i'm going to focus on "lambda { super() }" |
| 00:14:31 | evan | for right now |
| 00:14:47 | jarib | jvoorhis: i don't really know the internals of either csound/supercollider, just know what they are |
| 00:15:06 | jarib | sounds like a cool project though |
| 00:15:46 | jvoorhis | they're both based around components called "unit generators" that get connected in a graph and pass discrete audio signals around |
| 00:16:37 | jvoorhis | the components are written in C or C++, and get connected by a higher-level language |
| 00:17:33 | jvoorhis | instead of using a traditional digital audio representation, i'm representing audio signals as functions from continuous time to samples |
| 00:18:19 | jvoorhis | and instead of connecting prebuilt components, i'm generating code with llvm |
| 00:20:08 | jarib | sounds interesting |
| 00:20:32 | jvoorhis | design is mostly based on http://conal.net/papers/jfp-saig/compile-dsel.pdf |
| 00:20:43 | jarib | i'm a ruby programmer with a degree in music, so will definitely keep an eye on your work :) |
| 00:21:03 | jvoorhis | but substitute audio for animation, and ruby for haskell |
| 00:21:12 | jvoorhis | and LLVM for C in the codegen :) |
| 00:21:15 | evan | i'm a ruby programmer with a degree in lazy, so i want you to work on the FFI API! |
| 00:21:16 | evan | :D |
| 00:21:51 | jarib | ok, i'll stop distracting him :) |
| 00:21:53 | jvoorhis | i'll get to it :) this is something i've wanted to make for a long time and i keep getting stalled |
| 00:22:21 | evan | :) |
| 00:22:38 | evan | jvoorhis: i'm curious |
| 00:22:45 | evan | what aspects of LLVM are you looking to use? |
| 00:23:10 | evan | i ask because i've been interested in extending rubinius to add some hooks for people to generate rbx bytecode directly |
| 00:23:28 | evan | i could easily add a few things that would make stuff able to be compiled via the JIT very well |
| 00:24:19 | jvoorhis | evan: primarily, i'm interested in generating *fast* callback functions for audio IO |
| 00:24:44 | evan | who calls them? |
| 00:24:52 | jvoorhis | CoreAudio or PortAudio |
| 00:25:03 | evan | i know squat about how audio APIs work |
| 00:25:10 | slava | evan: how do you debug your remembered set? |
| 00:25:18 | jvoorhis | both PA and CA have similar apis |
| 00:25:24 | evan | slava: whats there to debug? |
| 00:26:11 | jvoorhis | you give them a callback, they call it repeatedly with some user data and optionally a buffer of input samples; callback fills a buffer of output samples |
| 00:26:29 | evan | ah ok |
| 00:26:52 | evan | yeah, sounds like something you need a unique language to do |
| 00:27:08 | jvoorhis | so i'm interested in using LLVM as an optimizing JIT |
| 00:27:19 | evan | yep. |
| 00:27:34 | jvoorhis | and i might explore using LLVM's vector types to generate SIMD instructions |
| 00:27:38 | jvoorhis | but i don't know if i'll get to that |
| 00:27:40 | slava | evan: well, what if you forget a write barrier |
| 00:27:43 | slava | and you get a random crash because of it |
| 00:28:01 | slava | jvoorhis: this sort of thing is what llvm is good for |
| 00:28:19 | evan | slava: we've got extensive apis that internally use the write barrier |
| 00:28:24 | jvoorhis | slava: are you the factor guy? |
| 00:28:27 | evan | we almost never poke one pointer into another |
| 00:28:39 | evan | so we rarely have troubles |
| 00:29:08 | slava | evan: so you just encapsulate it all like crazy. hmm |
| 00:29:44 | evan | the attr_accessor() macros we use in a class body setup methods that set data members and then call the write barirer |
| 00:29:51 | evan | and we go through those generated methods always |
| 00:30:11 | evan | the few other cases, such as tuple, are explicitely coded to call the write barrier |
| 00:31:46 | slava | ok |
| 00:32:19 | evan | so the answer try very hard to not have to debug it. |
| 00:32:26 | evan | with disipline |
| 00:32:39 | slava | heh |
| 00:32:50 | evan | because debugging it SUCKS SO HARD |
| 00:33:01 | slava | I was just wondering if you've ever coded up a tool that walks the heap and checks if all young pointers are recorded or something |
| 00:33:03 | evan | i've certainly done my share |
| 00:33:11 | slava | and if you have any thoughts on such an idea |
| 00:33:21 | evan | i wrote a heap debug early on that has done random things |
| 00:33:33 | evan | it's pretty useless now, because i rewrite it to help me debug everytime |
| 00:33:45 | evan | but certainly something that would validate the contents of the remember_set would do the trick |
| 00:33:54 | evan | run the validation before you do a collection |
| 00:34:05 | evan | so you know the mature object and the young objcet that were missed |
| 00:34:32 | evan | that gives you the relative time of the missed write barrier (after the last collection) and the parties involved |
| 00:34:44 | evan | thats typically enough forensics to start the hunt |
| 00:35:10 | slava | yeah |
| 00:35:17 | evan | i'd probably then isolate the time even more |
| 00:35:31 | evan | by numbering each collection |
| 00:35:37 | evan | and on the one right before it goes wrong |
| 00:35:50 | evan | set it up so that every allocation does the validation |
| 00:35:58 | evan | or something thats run frequently |
| 00:36:17 | evan | that should get you pretty darn close to the code that is bad. |
| 00:36:39 | evan | (btw, numbering each collection == |
| 00:36:56 | evan | static int collection = 0; collection++; |
| 00:37:08 | evan | at the top of your garbage_collection function |
| 00:46:09 | evan | erg. |
| 00:46:14 | evan | this super thing sucks. |
| 00:46:30 | evan | because super calls the super class version of whatever the current method calls itself |
| 00:46:36 | evan | a lambda doesn't call itself anything. |
| 00:47:57 | brixen | :( |
| 00:50:25 | jvoorhis | but you're calling some superclass method corresponding to the method enclosing the lambda – calling super within a lambda shouldn't change anything |
| 00:50:36 | evan | ah |
| 00:50:37 | evan | but it does. |
| 00:50:42 | evan | if the lambda was passed to define_method |
| 00:50:56 | evan | and you're invoking the lambda like it were a method. |
| 00:51:17 | evan | in that case, super in the lambda goes towards the superclass version of the method named what was passed to define_method |
| 00:51:39 | jvoorhis | hm |
| 00:52:32 | slava | what if the same lambda is used for two define_methods? |
| 00:52:59 | evan | ah ha! |
| 00:53:05 | evan | 2 different superclass are invoked. |
| 00:53:30 | jvoorhis | yeah, it seems totally late binding in MRI |
| 00:53:49 | evan | i've got an idea |
| 00:53:51 | evan | i'm testing now |
| 00:54:18 | evan | i'm doing to dup the internal data |
| 00:54:34 | evan | and change the name of the CompiledMethod within a lambda to have the name passed to define_method |
| 00:54:41 | slava | why not clone the lambda? |
| 00:54:50 | evan | same thing really |
| 00:54:58 | slava | I don't really know anything but it seems strange that define_method would mutate its argument |
| 00:55:13 | evan | when you pass a lambda to define_method |
| 00:55:27 | evan | i actually use the internal data of the lambda anyway |
| 00:55:36 | evan | a lambda is an instance of Proc |
| 00:55:43 | evan | which is just a wrapper around BlockEnvironment |
| 00:55:54 | evan | so I dup the BlockEnvironment |
| 00:55:58 | slava | ah |
| 00:56:16 | evan | heh |
| 00:56:24 | evan | An exception occurred running scratch/defmeth.rb |
| 00:56:25 | evan | StackError (StackError) |
| 00:56:25 | evan | Backtrace: |
| 00:56:27 | evan | #<D:0x94>.foo at scratch/defmeth.rb:20 (2289 times) |
| 00:56:30 | evan | main.__script__ at scratch/defmeth.rb:25 |
| 00:56:31 | evan | i'm getting closer |
| 00:56:37 | evan | i love my recursion flattening in backtraces |
| 00:56:42 | jvoorhis | ooh |
| 00:57:34 | evan | I should flatten mutual recursion too |
| 00:58:20 | jvoorhis | does rbx support tail calls (mutual or not)? |
| 00:58:31 | slava | it supports them, just doesn't run them in O(1) space :) |
| 00:58:39 | evan | jvoorhis: not atm, no. |
| 00:58:50 | jvoorhis | slava: you knew what i meant :) |
| 00:58:52 | slava | tail calls are kinda shitty as far as stack traces go |
| 00:58:52 | evan | hehe |
| 00:58:57 | evan | yeah |
| 00:59:03 | evan | tail calls are really hard on the programmer |
| 00:59:23 | jvoorhis | yeah, they are |
| 00:59:31 | evan | tail call to myself could be done and not confuse the programmer |
| 00:59:35 | evan | i'd do that before anything else |
| 01:02:16 | jvoorhis | not an important point for me – so far, nobody writes Ruby code that way |
| 01:02:28 | boyscout | Fixed unnamed splat arg to a method calling super. - 630184d - Brian Ford |
| 01:02:28 | boyscout | Fixed clamping mode_t in File. - 8e5aa8a - Brian Ford |
| 01:05:51 | boyscout | CI: 8e5aa8a success. 3002 files, 11417 examples, 35483 expectations, 0 failures, 0 errors |
| 01:37:22 | ddub | I'm fine with tail calls as an optimization, I just don't like it being advertised as a feature |
| 01:38:21 | slava | I'm fine with it being advertised as a feature, but as an optimization that the compiler may or may not do, its problematic :) |
| 01:38:42 | slava | seriously, something that changes space complexity is not "just" an optimization; its either something you can rely on always being there, or you ignore it completely |
| 01:40:11 | evan | yes |
| 01:40:15 | evan | thats why scheme is scheme. |
| 01:40:20 | evan | because it depends on it existing. |
| 01:40:44 | ddub | I don't get this bigdecimal thing |
| 01:40:57 | ddub | building a 32 bit ver of 1.9.1 now to see what happens |
| 01:41:50 | ddub | huh. |
| 01:41:53 | slava | evan: turns out I had a fencepost bug in my write barrier and it wasn't always marking the last card of an array when resizing an array that was so large that the resized array was ending up in tenured space :) |
| 01:42:17 | evan | oops. |
| 01:42:35 | slava | its been there for two weeks but CI only started seeing crashes from it yesterday |
| 01:43:48 | ddub | evan, brixen: http://gist.github.com/232514 |
| 01:44:15 | evan | yes? |
| 01:44:18 | evan | what of it? |
| 01:44:40 | brixen | the value of pi is 3.14159... |
| 01:44:48 | ddub | even on 386 I get the value that you are supposed to get for 64 bit in that failing test |
| 01:44:49 | brixen | ddub: I don't have the problem in my head |
| 01:45:11 | evan | it's fucking stupid |
| 01:45:13 | evan | is the answer. |
| 01:45:19 | evan | when the question involves bigdecimal. |
| 01:46:48 | brixen | ddub: bigdecimal is an ext |
| 01:47:03 | brixen | it may get compiled with different flags than the ones you used to compile mri |
| 01:47:12 | brixen | it's possible, dunno if it's happening |
| 01:47:33 | ddub | I think the test itself is broke, doesn't help that it crashes under the system mri in SL :P |
| 01:48:30 | brixen | well, before you blame the test, make absolutely sure how bigdecimal is being compiled |
| 01:48:48 | brixen | it's got an extconf.rb, it's getting its own Makefile during build on MRI |
| 01:49:49 | ddub | yeah, the test itself seems unpossible |
| 01:49:59 | evan | it's very possible. |
| 01:50:03 | evan | i've seen both values |
| 01:50:12 | evan | perhaps they changed it in the bigdecimal that 1.9 uses |
| 01:50:17 | ddub | bigdecimal internally uses long types, which means on 64 bit OS X (which is LP64) it should have double the precision and accuracy |
| 01:50:18 | evan | like i said, it's fucking stupid. |
| 01:50:29 | ddub | yet the 64 bit test checks it against a less precise answer |
| 01:50:36 | evan | can and should do not apply when the question involves bigdecimal. |
| 01:50:41 | brixen | fires up 64bit ubuntu |
| 01:50:53 | evan | ddub: thats entirely because thats what value it produces |
| 01:51:06 | evan | on the version we use. |
| 01:51:08 | ddub | evan: you sound like a big fan :) |
| 01:51:52 | ddub | tries to get an 'I <3 BigDecimal' bumper sticker made up for evan in time for rc |
| 01:51:57 | evan | sweet! |
| 01:52:36 | brixen | imagined a large set of fins attached to a motor and pushing air |
| 01:53:45 | ddub | the 1.9 bigdecimal (that I looked at earlier) seems to mostly have maintainability changes |
| 01:55:31 | ddub | hmph yeah that time I got the 32 bit value |
| 01:55:37 | ddub | gives up |
| 01:55:46 | evan | see. |
| 01:55:50 | evan | fucking stupid. |
| 01:56:54 | ddub | I'd say the test is broken |
| 01:57:14 | ddub | it is written as "check to see if the ruby impl segfaults" |
| 01:57:23 | ddub | well, obviously most of the tries I had didn't |
| 01:57:27 | ddub | so it should be fine |
| 01:57:37 | ddub | at this point, not segfaulting seems like a good stretch goal for bigdecimal |
| 01:59:11 | brixen | ddub: saying the test is broken is meaningless |
| 01:59:26 | brixen | tell me why the expected value is not correct |
| 01:59:58 | brixen | if the test is "broken" then there is a bug in MRI |
| 02:00:57 | ddub | brixen: the check of the value is not relevant for what the test actually says it is testing |
| 02:01:13 | brixen | sure it is |
| 02:01:18 | brixen | why isn't it? |
| 02:01:38 | brixen | we don't have a lambda { }.should_not segfault() matcher |
| 02:07:48 | evan | sweet. |
| 02:07:51 | evan | super super'd! |
| 02:11:02 | brixen | sweet! |
| 02:14:39 | ddub | hmm |
| 02:14:57 | ddub | brixen: I'm thinking about whether I could write a should_not segfault matcher now |
| 02:15:23 | brixen | ddub: probably shouldn't bother, I won't accept it :) |
| 02:20:07 | ddub | brixen: anyway, to be more clear, I think checking for segfaults and checking for some (standard defined) accuracy of bigdecimal are both valid tests |
| 02:21:05 | ddub | but I'm trying to investigate some arbitrary and undocumented expectation of bigdecimal accuracy in a test which really is "handles creation from really long strings" |
| 02:22:40 | brixen | ddub: why do you say arbitrary and undocumented? |
| 02:22:51 | brixen | it's a value that was shown to cause a segfault |
| 02:22:56 | brixen | the output is the dump format |
| 02:23:03 | brixen | what are you bitchin' about? :P |
| 02:23:37 | brixen | and all bigdecimals are created from strings |
| 02:24:11 | ddub | seems like you don't need to dump the value or look at it to know if creation caused a segfault |
| 02:24:28 | brixen | the dump is to show the string value |
| 02:24:35 | ddub | if there is another spec to say, enforce the format of the dump value, that makes sense |
| 02:24:43 | brixen | how would you confirm it? |
| 02:24:53 | ddub | should_not segfault ;-) |
| 02:24:57 | brixen | no |
| 02:24:58 | brixen | sorry |
| 02:25:02 | brixen | next issue? |
| 02:25:08 | ddub | (actually looked and no, I can't define a sigsegv handler in ruby) |
| 02:26:02 | ddub | *shrug* ok, I'll stop pushing |
| 02:27:45 | ddub | i don't know whether you understand what I am saying or not, but at this point I'm willing to let someone else deal with adding a new platform or exclusion or whatever for bigdecimal on rbx |
| 02:28:14 | brixen | that's fine |
| 02:28:22 | brixen | there's a ticket for it on os x sl |
| 02:28:34 | brixen | I'll investigate in on x86_64 ubunutu |
| 02:32:26 | ddub | (but I would suggest that the test should be at least calling to_s rather than dump) |
| 02:32:46 | brixen | no, we don't need to create a string that big |
| 02:32:53 | brixen | that's why _dump is used |
| 02:33:02 | brixen | besides, *why* should it call to_s? |
| 02:33:12 | brixen | why is that value preferable over _dump? |
| 02:34:29 | ddub | because dump gives an internal representation, while to_s gives the scientific notation |
| 02:34:50 | ddub | well, quasi. => "0.1E10000001" |
| 02:36:15 | brixen | so what? |
| 02:36:29 | brixen | if bd could not reproduce the real value from the dump |
| 02:36:34 | brixen | there would be no point |
| 02:36:52 | brixen | the set of dump values is isomorphic under load to the set of string values |
| 02:37:02 | brixen | is getting very annoyed |
| 02:37:09 | brixen | I'm going to eat some dinner |
| 02:40:48 | evan | :( |
| 04:40:48 | brixen | I've got a repro of the bigdecimal issue on ubuntu 64bit |
| 04:40:53 | brixen | so I can poke at it |
| 04:46:17 | boyscout | Some fixes to build on ubuntu 9.10 64bit. - 31b9126 - Brian Ford |
| 04:48:08 | boyscout | CI: 31b9126 success. 3002 files, 11417 examples, 35483 expectations, 0 failures, 0 errors |
| 05:16:31 | brixen | can someone on SL run this cmd in irb and gist me the output |
| 05:16:32 | brixen | Config::CONFIG.each { |k,v| puts "#{k.to_s.ljust(20)} -> #{v.inspect}" }; nil |
| 05:33:27 | ddub | brixen: http://gist.github.com/232628 |
| 05:41:48 | brixen | ddub: thanks |
| 05:42:01 | brixen | I've got the issue, but the solution sucks :/ |
| 05:42:14 | brixen | the defines are wrong on 64bit for bigdecimal |
| 05:42:34 | brixen | the extconf.rb runs a program to figure out what to define |
| 05:43:41 | brixen | hm, I wonder what is the best way to detect 64bit from rbconfig values |
| 05:43:51 | brixen | I could look for x86_64 |
| 05:44:02 | brixen | or target_cup i686 ? |
| 05:44:31 | brixen | cpu rather |
| 05:44:48 | brixen | ddub: what do you think? |
| 05:46:16 | rue | Hi |
| 05:47:26 | brixen | hi rue |
| 05:50:07 | brixen | mri has a paucity of information about the platform in rbconfig |
| 05:52:51 | rue | x86_64 |
| 05:53:37 | rue | i686 can appear for 32-bits too |
| 05:53:54 | brixen | rue: k |
| 05:55:54 | brixen | effen beautiful |
| 05:56:20 | brixen | target_cpu is i686 on SL, x86_64 on ubuntu 64bit |
| 05:58:17 | brixen | I don't see a standard config value to use :/ |
| 05:58:27 | rue | Hum, is it possible it was built for 32-bit or universal? |
| 05:58:54 | brixen | ddub: that config gist was from default SL ruby, yes? |
| 06:00:58 | brixen | so much for the easy solution... |
| 06:03:22 | rue | Tehee...watching M.A.S.K. |
| 06:03:31 | rue | Wonder if they will resurrect it next |
| 06:05:28 | rue | o/~ Masked heroes / working overtime / fighting crime o/~ |
| 06:05:40 | brixen | bigdecimal you SUCK |
| 06:16:31 | brixen | I suppose I will just use 1.size |
| 06:17:09 | brixen | ddub: giving bigdecimal the right defines makes all the difference :) |
| 06:33:28 | ddub | brixen: what was the missing define? |
| 07:52:29 | dbussink | brixen: hmm, my simple test case for the super(*) was indeed fixed, but rspec seems to still fail, have to look further apparently :) |
| 07:56:59 | dbussink | brixen: ah, stale rbc files |
| 08:04:59 | brixen | dbussink: working on fixing the stale files right now |
| 08:05:33 | dbussink | brixen: w00t, got data_objects passing now completely |
| 08:05:43 | dbussink | uses rspec, with shared specs etc. |
| 08:06:05 | rue | Nice |
| 08:06:15 | dbussink | we're actually looking at moving to bacon |
| 08:06:26 | dbussink | because that would allow us to run specs on new implementations way earlier |
| 08:06:35 | dbussink | like macruby and ironruby these days |
| 08:09:43 | brixen | there's rspec clones that are simpler and wouldn't require changing all the syntax |
| 08:10:13 | brixen | and rumor has in rspec 2.0 will be much simpler |
| 08:10:58 | boyscout | Fixed building bigdecimal ext on 64bit. - 677cf53 - Brian Ford |
| 08:11:29 | dbussink | brixen: yeah, bacon is one of them |
| 08:11:38 | dbussink | that's why we are looking at that |
| 08:12:45 | boyscout | CI: 677cf53 success. 3002 files, 11417 examples, 35483 expectations, 0 failures, 0 errors |
| 08:12:57 | brixen | dbussink: understood |
| 08:13:11 | brixen | point is still that it's possible without changing syntax |
| 08:19:36 | brixen | dbussink: btw, I'd think it'd be a toss-up between LazyArray and rspec for most difficult for a nascent impl to run ;) |
| 08:19:45 | slava | hi brixen |
| 08:19:50 | brixen | hi slava |
| 08:45:24 | boyscout | Fix super in a block passed to define_method - 0adcec2 - Evan Phoenix |
| 08:45:24 | boyscout | Fix a few Module#define_method corners - cc6f8bc - Evan Phoenix |
| 08:45:24 | boyscout | Update Module#define_method tags - 30c120b - Evan Phoenix |
| 08:47:18 | evan | hehe, abby found a WTFWJD xmas card |
| 08:51:38 | evan | if a block doesn't access any outer data |
| 08:51:43 | evan | you could call it... |
| 08:51:44 | evan | pure? |
| 08:52:14 | evan | virtuous? |
| 08:52:24 | evan | closed? |
| 08:53:39 | boyscout | CI: 30c120b success. 3002 files, 11419 examples, 35487 expectations, 0 failures, 0 errors |
| 08:53:47 | scoopr | standalone? |
| 08:53:59 | evan | standalone |
| 08:54:01 | evan | there ya go. |
| 08:57:17 | brixen | evan: I can repro the segfault installing a gem with --ri --rdoc |
| 08:57:23 | brixen | I update #69 with a gist |
| 08:57:32 | evan | k |
| 08:57:33 | brixen | past tense, updated |
| 08:57:52 | evan | so |
| 08:57:55 | evan | you installed rdoc |
| 08:58:02 | evan | so you could build with --rdoc |
| 08:58:05 | evan | then you installed rdoc again |
| 08:58:08 | evan | to generate the rdoc for rdoc |
| 08:58:24 | brixen | gdb --args vm/vm -S gem install rdoc --ri --rdoc |
| 08:58:28 | brixen | it installs the gem |
| 08:58:38 | brixen | segfaults installing the rdoc for it |
| 08:59:05 | brixen | http://gist.github.com/232746 |
| 08:59:11 | brixen | want me to try a different way? |
| 09:00:15 | dbussink | brixen: i've already simplified lazy array :) |
| 09:00:24 | dbussink | brixen: although that makes it a less useful test case ;) |
| 09:00:26 | brixen | dbussink: grand :) |
| 09:00:39 | brixen | indeed, it does a bit |
| 09:00:56 | dbussink | brixen: http://github.com/datamapper/extlib/blob/master/lib/extlib/lazy_array.rb |
| 09:01:20 | dbussink | brixen: no method undeffing and define_method proxying anymoore |
| 09:02:59 | brixen | nice |
| 09:04:22 | evan | dude |
| 09:04:26 | evan | wtf is include? |
| 09:04:38 | evan | you're oring into a begin? |
| 09:05:00 | rue | Eek |
| 09:05:24 | dbussink | evan: not what i wrote, but i've seen it more often, it's not a very uncommon thing actually |
| 09:05:27 | evan | great, i seem to have broken gem. |
| 09:05:37 | evan | dbussink: i've never seen that. |
| 09:05:52 | brixen | I've seen wycats do that I think |
| 09:05:56 | brixen | surprised me too |
| 09:06:05 | dbussink | evan: i've seen code like @object ||= begin; long; bunch; of; statements; end pretty often |
| 09:06:28 | brixen | anyveys, beddie bye für mich |
| 09:06:52 | evan | nite |
| 09:06:54 | evan | yeah, me too. |
| 09:06:57 | brixen | nite! |
| 09:07:18 | evan | people are wierd. |
| 09:11:57 | slava | evan: no u |
| 09:11:59 | rue | Actually, I would not be surprised wycats did that |
| 09:42:07 | boyscout | Trap returns through a define_method {} - 5fa4878 - Evan Phoenix |
| 09:44:47 | boyscout | CI: 5fa4878 success. 3002 files, 11419 examples, 35487 expectations, 0 failures, 0 errors |
| 16:50:37 | evan | AWESOME |
| 16:50:37 | evan | http://github.com/shugo/rubinius |
| 16:50:42 | evan | shugo is working on rubinius |
| 16:52:59 | Defiler | Sweet |
| 16:55:15 | boyscout | Avoid the rounding error of 0.49999999999999994 + 0.5 in Float#round - 4110770 - Shugo Maeda |
| 16:55:15 | boyscout | Fix whitespace - 4040161 - Evan Phoenix |
| 16:58:00 | boyscout | CI: 4040161 success. 3002 files, 11419 examples, 35487 expectations, 0 failures, 0 errors |
| 17:12:12 | brixen | rad |
| 17:12:44 | brixen | evan: could you help me with a git command? |
| 17:12:52 | brixen | git log spec/frozen |
| 17:12:57 | evan | sure |
| 17:13:10 | evan | you want me to run it? |
| 17:13:12 | brixen | I'd like to convert commits from top to some hash to format-patch-es |
| 17:13:23 | brixen | as easily as possible |
| 17:13:29 | evan | from top being what? |
| 17:13:33 | brixen | head |
| 17:13:43 | brixen | most recent commit in spec/frozen |
| 17:13:50 | evan | just the most recent one? |
| 17:14:12 | brixen | all of them from most recent to a particular commit |
| 17:14:28 | brixen | a signpost, like the last time I sync'd with rubyspec |
| 17:15:30 | evan | ok |
| 17:15:32 | evan | one sec |
| 17:15:49 | evan | you want format-patch's right? |
| 17:15:59 | brixen | yeah |
| 17:18:24 | evan | git log -p is SOO close. |
| 17:18:34 | evan | they should have just made it the same format as format-patch |
| 17:18:59 | brixen | hmm |
| 17:20:56 | evan | well |
| 17:21:05 | evan | git-format patch -<num> spec/frozen |
| 17:21:06 | evan | works |
| 17:21:07 | evan | so |
| 17:21:11 | evan | git-format patch -1 spec/frozen |
| 17:21:15 | evan | to get the top one |
| 17:21:18 | brixen | wow, git log man page is awesomer than I remember |
| 17:21:31 | evan | i didn't recall format-patch taking a path |
| 17:21:32 | evan | but it does now |
| 17:21:41 | brixen | ok |
| 17:22:02 | evan | looks like you can do |
| 17:22:11 | evan | git format-patch spec/frozen <since> |
| 17:22:18 | evan | so since just needs to be a spinpost commit |
| 17:22:25 | brixen | k |
| 17:22:42 | evan | i can show you how to detect a spinpost |
| 17:22:45 | evan | if you need |
| 17:23:26 | brixen | yes, please |
| 17:24:31 | evan | you basicly want a merge-base that works across 2 repos |
| 17:27:39 | brixen | well, I would expect git fp spec/frozen R1..R2 to work, but when I specify hashes for R1..R2 I get an error about ambigument, path not in working tree |
| 17:28:09 | evan | hm |
| 17:28:10 | evan | weird. |
| 17:28:11 | evan | oh |
| 17:28:13 | evan | n |
| 17:28:15 | evan | no |
| 17:28:24 | evan | well, i guess you can do that |
| 17:28:29 | evan | but the sha to fp is a since one |
| 17:28:41 | evan | but you don't want all since |
| 17:28:45 | evan | you want just a certain range? |
| 17:29:10 | brixen | well, the man page says since or rev range |
| 17:29:23 | brixen | trying to grok git-rev-parse atm |
| 17:33:05 | brixen | hah, above, ambigument is supposed to be ambiguous argument |
| 17:33:13 | brixen | a little pokemon contraction there |
| 17:34:23 | brixen | adds a new word to the lexicon: ambigument n. an ambiguous argument. usage: that sounds like an ambigument to me |
| 17:34:28 | evan | brixen: ah crap. |
| 17:34:43 | evan | i can't do an automated search using SHA1s |
| 17:34:58 | evan | because when you port them over, the SHA1 changes |
| 17:35:06 | brixen | ah yeah |
| 17:35:15 | brixen | that's ok, I can get the commit hashes manually |
| 17:35:34 | brixen | just thought you may have some magic :) |
| 17:35:51 | evan | i was writing you a little script |
| 17:41:29 | evan | brixen: git rev-list skips from Oct 20 to May 28th on rubyspec |
| 17:41:30 | evan | for some reason. |
| 17:41:42 | brixen | hrm |
| 17:42:51 | evan | oh, then it jumps back |
| 17:43:03 | evan | i guess marc-andre must have had a whole bunch of commits he never pushed |
| 17:43:06 | evan | and then did |
| 17:43:09 | evan | so the dates are funny |
| 17:43:24 | evan | git log can be confusing because it's linearizing a tree |
| 17:45:10 | brixen | ahh |
| 17:45:19 | brixen | well, don't waste time on it |
| 17:46:32 | evan | k |
| 17:46:35 | evan | i shant! |
| 17:46:41 | brixen | heh |
| 17:47:50 | brixen | the git fp -N spec/frozen is sweet and simple enough |
| 17:50:15 | evan | k |
| 18:11:43 | dbussink | evan: you should mail him so he can work directly on the repo then :) |
| 18:11:51 | evan | I did. |
| 18:12:00 | evan | he'll need to fix is formatting though |
| 18:12:11 | evan | he's using the MRI format |
| 18:12:13 | evan | bad news. |
| 18:12:22 | evan | mixed tabs and spaces |
| 18:12:40 | boyscout | Ensure that only internally used method is private - b19d213 - Dirkjan Bussink |
| 18:12:40 | boyscout | Added rb_const_set to CAPI, but forgot to add it to the header - b5cc489 - Dirkjan Bussink |
| 18:13:44 | dbussink | evan: the diff on github also shows it yeah |
| 18:15:13 | brixen | peaches and cream |
| 18:15:32 | brixen | that's oatmeal, people |
| 18:15:40 | brixen | man, kids these days |
| 18:15:51 | boyscout | CI: b5cc489 success. 3002 files, 11419 examples, 35487 expectations, 0 failures, 0 errors |
| 18:16:18 | evan | cinnamon and spice ftw! |
| 18:16:23 | brixen | heh |
| 18:18:25 | brixen | evan: so for installing, are bin, include, lib the 3 main divisions? |
| 18:18:43 | evan | yeah |
| 18:18:46 | brixen | k |
| 18:19:11 | brixen | and for single dir prefix, prefs on the substructure |
| 18:19:21 | brixen | root/bin, root/include, root/lib ? |
| 18:20:05 | brixen | root/runtime? |
| 18:20:16 | brixen | where should the runtime dir go in the 3-part instal? |
| 18:23:18 | evan | no |
| 18:23:21 | evan | not root/runtime |
| 18:23:25 | evan | that would be /usr/local/runtime then |
| 18:23:41 | evan | or are you thinking of root as /usr/local/rubinius |
| 18:23:48 | evan | there are 2 schools of thought |
| 18:23:58 | brixen | yeah, root is prefix/rubinius |
| 18:24:02 | evan | 1) a root dir for the project, with everything in it |
| 18:24:09 | brixen | in the single dir intall |
| 18:24:12 | evan | 2) many project dirs in the respective system dirs |
| 18:24:17 | brixen | right |
| 18:24:19 | evan | /usr/local/lib/rubinius |
| 18:24:21 | evan | etc. |
| 18:25:26 | brixen | oh, we need a man page! |
| 18:25:29 | evan | yeah! |
| 18:25:33 | brixen | how can we be legit with no man page |
| 18:25:34 | evan | if you're going for prefix/rubinius |
| 18:25:38 | evan | then /runtime is fine |
| 18:25:43 | brixen | k |
| 18:26:28 | brixen | but in the case of /usr[/local]/lib/rubinius, it would be .../rubinius/runtime, .../rubinius/lib (stdlib) |
| 18:26:32 | brixen | like that? |
| 18:26:47 | evan | heh? |
| 18:26:51 | evan | i don't see what ya mean |
| 18:27:20 | brixen | well, sec.. |
| 18:27:26 | brixen | I'm making a gist |
| 18:27:34 | brixen | just want to be clear |
| 18:31:45 | brixen | http://gist.github.com/233144 |
| 18:32:42 | brixen | updated |
| 18:38:56 | evan | can we support both? |
| 18:39:13 | evan | if we can only do one |
| 18:39:20 | evan | 3-part install is better |
| 18:39:24 | evan | because thats the typical way |
| 18:39:44 | brixen | oh, we will definitely support both |
| 18:39:52 | brixen | via configure switches |
| 18:39:59 | brixen | --prefix= is a one-dir install |
| 18:40:09 | brixen | --prefix-bin=, etc for 3-part |
| 18:40:15 | evan | k |
| 18:40:30 | brixen | I just need to get everything in the right places |
| 18:40:43 | brixen | like, just realized, where do gems go? |
| 18:41:15 | evan | lib/rubinius/gems |
| 18:41:29 | brixen | k, updated gist |
| 18:41:53 | brixen | and gem bins in /lib/rubinius/bin yes? |
| 18:42:07 | brixen | not with bin/rbx in the 3-part install? |
| 18:43:18 | evan | looks good. |
| 18:43:40 | evan | no, not with bin/rbx in the 3part |
| 18:43:46 | evan | because we'll clutter up a system directory that way |
| 18:45:35 | brixen | k |
| 19:06:43 | boyscout | Fix how and where a return-in-lambda is caught - f319184 - Evan Phoenix |
| 19:06:43 | boyscout | Add specs for behavior of return in lambda - e614007 - Evan Phoenix |
| 19:06:49 | evan | yay! return is fixed! |
| 19:07:16 | imajes | :D |
| 19:07:20 | brixen | sweet! |
| 19:09:57 | evan | lambda was broken |
| 19:10:02 | evan | if you were supposed to return through it |
| 19:10:03 | evan | it wouldn't |
| 19:10:40 | evan | b = block { return }; l = lambda { |x| x.call }; l.call(b); puts "FAIL" |
| 19:10:44 | evan | FAIL would print |
| 19:10:46 | evan | it shouldn't |
| 19:10:47 | evan | fixed now. |
| 19:11:02 | brixen | cool |
| 19:12:55 | evan | woop. |
| 19:13:01 | boyscout | CI: e614007 success. 3002 files, 11423 examples, 35491 expectations, 0 failures, 0 errors |
| 19:13:03 | evan | lambda { |a| a + 1}.standalone? # => true |
| 19:13:17 | evan | b = 1; lambda { |a| a + b }.standalone? # => false |
| 19:13:36 | evan | still not sure if standalone is the word I want |
| 19:16:39 | Defiler | $LOAD_PATHS are searched first-to-last, right? As in, by default '.' is the last directory checked? |
| 19:17:16 | brixen | evan: that's a pretty good adj, signifies it can run "independently" in a sense |
| 19:17:31 | evan | brixen: right |
| 19:18:55 | brixen | Defiler: should |
| 19:19:24 | brixen | unless you $:.unshift "." |
| 19:19:56 | Defiler | I would have sworn I knew how to do this.. but I'm trying to figure out the real path to something shown in $LOADED_FEATURES |
| 19:20:17 | Defiler | got multiple openssl.so files, making sure the correct one is loading |
| 19:20:22 | brixen | hmm |
| 19:20:54 | brixen | problem is, $: could have changed after requiring something |
| 19:21:13 | evan | brixen: what should I used instead of describe now? |
| 19:21:17 | evan | i wanna fix describe to work again. |
| 19:21:17 | Defiler | I'm saving a copy of $LOAD_PATH and $LOADED_FEATURES before the require |
| 19:21:25 | Defiler | and load_path is unchanged, just the new stuff in loaded_features |
| 19:21:26 | brixen | in 1.9, $L_F has absolute paths |
| 19:21:41 | brixen | evan: oh yeah |
| 19:21:46 | Defiler | It seems like 1.8 just discards this info |
| 19:21:51 | brixen | you can do bin/rbx compile -B file |
| 19:22:03 | brixen | evan: but I think an irb plugin would be rad |
| 19:22:11 | evan | ok |
| 19:22:12 | evan | i'll do that |
| 19:22:13 | brixen | that would just cm.decode the expr you typed in |
| 19:22:22 | brixen | for interactive mode |
| 19:22:37 | brixen | I was going to just make describe.rb exec to compile -B |
| 19:23:29 | brixen | I think using irb as the shell for the debugger would be rad too |
| 19:41:35 | evan | woop |
| 19:42:03 | evan | used Proc#standalone? to make it so that Module#define_method can extract and twiddle the enclosed CompliedMethod |
| 19:42:11 | evan | and then insert it directly into the method table of the module |
| 19:42:27 | evan | thusly |
| 19:42:37 | evan | module A; def foo(a) a + 1; end; end |
| 19:42:46 | evan | is the same speed as |
| 19:42:54 | evan | A.define_method(:foo2) { |a| a + 1 } |
| 19:43:46 | brixen | that's awesome |
| 19:46:10 | evan | it's a minor improvement, performance wise, now that i've fixed define_method itself |
| 19:46:15 | evan | but nice none the less. |
| 19:51:36 | Defiler | I saw that Rubinius::DelegatedMethod is relegated to just handling Method objects now |
| 19:51:42 | Defiler | The new setup looks sweet |
| 19:52:47 | evan | yeah, i'm not yet sure if thats right either |
| 19:56:36 | dbussink | evan: were you able to repro the segfault already? i saw brixen commented he saw it too |
| 19:57:12 | evan | oh darn |
| 19:57:13 | evan | i forgot |
| 19:57:16 | evan | i'll try after lunch. |
| 19:57:29 | brixen | I saw it up close and personal, like booyah, right in my terminal |
| 19:58:07 | dbussink | brixen: was it scary? |
| 19:58:12 | brixen | yes! |
| 19:58:15 | brixen | had nightmares |
| 19:58:49 | brixen | that may be because I was looking at bigdecimal.c before bed too |
| 20:11:31 | ddub | brixen: would you like that bigdecimal test to just be inlined into bigdecimal.c? (so that it does the right thing without having to determine and set defs) |
| 20:13:19 | brixen | ddub: you could do that in _init I suppose |
| 20:13:48 | brixen | seems more robust, but it's a tiny bit more cost on load |
| 20:14:01 | brixen | I'm cool with doing that |
| 20:14:26 | ddub | brixen, I was thinking of just doing it at compilation time, in the file |
| 20:14:48 | brixen | with macros? |
| 20:14:53 | ddub | probably enums |
| 20:15:14 | brixen | ok, well show me what you mean |
| 20:16:06 | brixen | I thought you mean compute it the way extconf.rb does |
| 20:16:18 | brixen | if you just mean, move the size check into compile time |
| 20:16:28 | brixen | that's fine, but not really different |
| 20:17:02 | brixen | I guess moody people don't stay long |
| 20:17:34 | brixen | hunts for lunch |
| 20:18:22 | evan | heh |
| 20:19:17 | ddub | brixen: I'm trying to compute it, but at compile time. I'm not sure if it will work, however :) |
| 20:42:01 | ddub | brixen: yeah, I can do it with compile time with templates, know people don't want me to go there :) |
| 20:42:23 | slava | hi |
| 22:15:08 | rue | evan: #selfcontained? |
| 22:27:23 | tarcieri | /join #activemerchant |
| 22:27:26 | tarcieri | durr |
| 22:27:36 | tarcieri | hi |
| 22:27:51 | tarcieri | that channel doesn't exist anyway :( |
| 22:33:07 | ddub | is watching/listening to the go programming language tech talk |
| 22:39:34 | rue | With the little black and white pebbles? |
| 23:27:34 | Defiler | Robert Griesemer, Rob Pike and Ken Thompson started sketching the goals for a new language on the white board on September 21, 2007. Within a few days the goals had settled into a plan to do something and a fair idea of what it would be. |
| 23:27:39 | Defiler | That is an extreme way to begin a FAQ |
| 23:34:16 | rue | They are just machoing it up |