Show enters and exits. Hide enters and exits.
| 00:03:07 | rue | 10.5.7 is available |
| 01:01:16 | ddub | 10.5.7 is overrated |
| 01:29:37 | rue | Already? |
| 01:48:29 | boyscout | 1.8.7: StringIO (optional block) - 6c3f46e - Marc-Andre Lafortune |
| 01:48:29 | boyscout | 1.8.7: ARGF (optional block) - 7517225 - Marc-Andre Lafortune |
| 01:48:29 | boyscout | 1.8.7: Method#name, #owner, #receiver (new) - 232c44d - Marc-Andre Lafortune |
| 01:48:29 | boyscout | 1.8.7: UnboundMethod#name, #owner - 3757cfc - Marc-Andre Lafortune |
| 01:55:32 | boyscout | CI: 3757cfc success. 2679 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 03:29:57 | tarcieri | yo |
| 03:30:12 | tarcieri | did you guys see the CUDA thread on ruby-talk? |
| 03:34:32 | slava | hi tarcieri |
| 03:34:39 | tarcieri | sup slava |
| 04:13:29 | wycats | how do I run the specs? |
| 04:13:57 | tarcieri | rake ci? |
| 04:16:12 | wycats | :) |
| 04:16:23 | wycats | checks out rubyspecs :) |
| 04:18:14 | wycats | Don't know how to build task 'ci' |
| 04:21:49 | tarcieri | :/ |
| 04:24:20 | wycats | tarcieri: thoughts? |
| 04:25:32 | tarcieri | i am not sure? |
| 04:25:36 | tarcieri | from the rbx repo? |
| 04:25:43 | wycats | ahhh bin/mspec ci |
| 04:25:49 | tarcieri | aah |
| 04:26:08 | tarcieri | hasn't pulled rbx in awhile |
| 04:30:25 | wycats | hehe |
| 04:49:43 | wycats | tarcieri: where's the right place to submit patches? |
| 04:52:33 | tarcieri | submitted his here... then got commit access :/ |
| 04:52:49 | tarcieri | you could post on the google group maybe? |
| 04:55:24 | tonyla | http://github.com/evanphx/rubinius/blob/e6240bbbeaf52905bee9f767be842282efab5b22/doc/howto/fix_a_f ailing_spec.txt |
| 04:55:38 | tonyla | i'm new but that says to upload it to a lighthouse ticket |
| 04:56:10 | wycats | tarcieri: once upon a time I had commit |
| 04:56:11 | wycats | ;) |
| 04:56:21 | wycats | I think I lost it with the switch to github |
| 04:56:35 | tarcieri | o |
| 04:56:38 | tarcieri | just ask then |
| 04:57:02 | wycats | yo evan: can I have commit? |
| 04:57:15 | wycats | just fixed a Kernel#extend bug |
| 04:57:19 | wycats | there are only 4 specs =-o |
| 04:57:27 | wycats | and one of them failed =-o |
| 04:58:19 | tarcieri | heh |
| 05:17:28 | wycats | tarcieri: how am I supposed to recompile changes so they get included in a spec run? |
| 05:17:40 | wycats | the rbc's that is |
| 05:50:54 | crafterm | gday all! |
| 06:09:18 | tarcieri | wycats: I don't know :/ |
| 06:09:26 | tarcieri | like |
| 06:09:29 | tarcieri | they should check mtime |
| 06:09:37 | tarcieri | and automatically recompile when loaded |
| 06:09:38 | tarcieri | I believe |
| 06:10:41 | slava | factor caches compiled code in an image and there's a word which reloads any source files which have changed on disk. its really handy |
| 07:07:27 | ddub | checks git to see if the robots and unicorns branch has been made yet |
| 07:07:43 | ddub | does a git checkout rainbow-laserbeams |
| 07:32:48 | tarcieri | heh |
| 07:36:55 | tarcieri | robots don't necessarily have laser beams... that's a misconception |
| 07:37:04 | tarcieri | but robots are able to tap into UNICORN POWER |
| 07:48:00 | ffwonko | true story |
| 07:48:27 | tarcieri | quite |
| 09:47:57 | rue | wycats: `rake build` (clean firsnt in some cases) |
| 09:48:11 | rue | First* |
| 13:14:15 | scoopr | ooh yeah http://www.e-booksdirectory.com/programming.php |
| 18:24:52 | rue | Hm, weird |
| 18:42:53 | luislavena | hey guys, quick question. |
| 18:43:29 | evan | luislavena: hey! |
| 18:43:32 | evan | wassup? |
| 18:43:58 | luislavena | evan: hey man, is there are reason why libev is 3.48 ? |
| 18:44:38 | luislavena | evan: win32 support of if is not good compared to 3.6 |
| 18:44:53 | luislavena | cannot comment further what he has been doing. |
| 18:46:53 | evan | in rubinius? |
| 18:46:54 | evan | no reason |
| 18:46:59 | evan | we're not actually using libev much anymore |
| 18:47:04 | evan | since the switch to stackful |
| 18:47:24 | evan | but I intend to allow for it's usage again eventually |
| 18:51:29 | luislavena | evan: oh, but when executed rake -T the depedency is being checked to be built. |
| 18:51:38 | luislavena | evan: that was my noob question. |
| 18:52:12 | luislavena | evan: other noob question. |
| 18:54:02 | evan | sure |
| 18:54:05 | evan | it's being built |
| 18:54:07 | evan | and linked |
| 18:54:09 | evan | but not used |
| 18:54:47 | luislavena | evan: ah, cool then. |
| 18:55:04 | evan | luislavena: hows things? |
| 18:55:12 | luislavena | evan: overwhelmed by work :) |
| 18:55:42 | luislavena | besides that, everything is good. |
| 18:55:47 | evan | good! |
| 18:58:50 | luislavena | evan: what about you? |
| 18:59:20 | luislavena | evan: how rubinius is coming? when a 1.0 release? (or at least nightly builds) :D |
| 19:03:24 | rue | luislavena: I have not updated the included libev since 3.48 :P |
| 19:03:57 | luislavena | rue: |
| 19:04:06 | luislavena | rue: I see, but no problem ;-) |
| 19:27:35 | slava | luislavena: does libev use windows io completion ports yet, or is it still calling lame-ass winsock select()? |
| 19:28:01 | evan | slava: probably using select() |
| 19:28:13 | luislavena | slava: I can bet that still calls lame-ass winsock2 select() :( |
| 19:28:21 | rue | Yes |
| 19:28:50 | luislavena | slava: haven't this kind of things solved in libraries like boost ? |
| 19:29:13 | luislavena | slava: I mean, instead of using plain posix or NT API, rely on those IO libraries? |
| 19:30:25 | slava | I don't think there's a good abstraction layer for all that yet |
| 19:30:35 | slava | last I looked at libev and libevent neither one was satisfactory |
| 19:30:58 | rue | libev is good, except for the IOCP support |
| 19:33:05 | slava | rue: its also missing OS X CFRunLoop support |
| 19:37:08 | rue | Mm, yep |
| 19:38:34 | slava | took me way too long to implement all this crap for every platform |
| 19:38:45 | slava | and i still don't have non-blocking SSL sockets on windows |
| 19:39:00 | slava | it should be easier |
| 19:39:24 | slava | linux's insistence on using epoll instead of kqueue is kind of moronic too, its just NIH since epoll is almost the same |
| 19:40:02 | scoopr | uh, so in total, how many different ways there are to do the same thing currently? |
| 19:40:17 | slava | you mean non-blocking i/o in general, or in rubinius? |
| 19:40:23 | scoopr | in general |
| 19:40:30 | slava | every OS has several overlapping APIs |
| 19:40:40 | scoopr | nice =) |
| 19:41:00 | slava | everybody has select() in some form, but it sucks, linux has epoll, bsd has kqueue, os x also has the core foundation run loop stuff, windows has two more APIs and one of them is shit |
| 19:41:24 | slava | there's also async i/o apis of various sorts |
| 19:41:52 | scoopr | if you have mostly done the work on all of those, could you separate that part in to a separate lib, or is it factor-dependant code? |
| 19:42:14 | slava | the code is pluggable and modular and all but its written in factor |
| 19:42:25 | scoopr | ah right |
| 19:42:53 | slava | it was one of the first things I did with ffi |
| 19:43:54 | slava | to avoid infinite regress in bootstrap, I have the VM export some simple wrappers around fopen()/fread()/fwrite() that are only used to load the source for the 'real' I/O implementation |
| 19:44:07 | slava | rubinius could take a similar approach eventually, instead of baking I/O into the VM |
| 19:45:35 | boyscout | Updated CI frozen specs to RubySpec 897ddcd3. - e9f6598 - Yehuda Katz |
| 19:45:36 | boyscout | Make Dir.glob much faster - 2e898ea - Yehuda Katz |
| 19:45:56 | luislavena | slava: interesting approach, do you have something online that I can peek? |
| 19:46:35 | slava | luislavena: all the code is in http://gitweb.factorcode.org/gitweb.cgi?p=factor/.git;a=tree;f=basis/io/backend;hb=HEAD |
| 19:47:27 | luislavena | slava: awesome, thank you. |
| 19:47:57 | boyscout | CI: 2e898ea success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 19:55:03 | tarcieri | wants a self-hosted compiler :( |
| 19:55:30 | brixen | tarcieri: for a small fee.. |
| 19:56:18 | slava | tarcieri: I'm not sure self-hosting is a worthy goal in itself |
| 19:56:28 | slava | if it makes things simple, sure, but as a matter of principle its probably not a good idea |
| 19:56:35 | tarcieri | slava: but if I don't, I have to write the compiler in Erlang :( |
| 19:56:59 | slava | other than the factor parser being written factor, its not really self-hosting |
| 19:57:24 | tarcieri | slava: I'm really sick of the Erlang-based compiler :/ |
| 19:57:36 | slava | is Erlang painful for this task or something? |
| 19:57:53 | slava | when you say compiler you really mean parser, right, since you're not really doing any optimization or code transformations? |
| 19:57:59 | tarcieri | single assignment sux |
| 19:58:01 | slava | you're just parsing reia and dumping beam bytecode? |
| 19:58:05 | tarcieri | no, I mean compiler |
| 19:58:12 | tarcieri | the thing that translates the parse tree into Erlang code |
| 19:58:17 | slava | oh ok |
| 19:58:36 | tarcieri | anyway, loonch! |
| 19:58:47 | slava | tarcieri: if you want to see pain, go look at javascript compilers implemented in C++ |
| 20:05:15 | luislavena | is funny, but FreeBASIC (yeah, basic) is self hosted parser and compiler. |
| 20:05:29 | luislavena | and it's BASIC! if basic could do it ... :P |
| 20:05:33 | luislavena | (you get the idea) |
| 20:24:33 | rue | evan: What was the plan with the LLVM distro? Does not look like llvm-jit includes it |
| 20:27:50 | evan | rue: yes, it's been removed |
| 20:27:52 | evan | not sure yet |
| 20:28:20 | rue | So just uses the system version if it exists? |
| 20:28:28 | evan | well |
| 20:28:32 | evan | you need to use the svn version |
| 20:28:55 | rue | Hm |
| 20:28:59 | rue | installs SVN |
| 20:29:08 | evan | with http://github.com/evanphx/llvm-patches/blob/master/jit-info.diff applied |
| 20:29:29 | evan | i'm working to get that patch committed |
| 20:29:40 | evan | i was hoping to get it committed today |
| 20:29:42 | evan | but not yet. |
| 20:30:26 | rue | ...On the eight link to the SVN version now.. :P |
| 20:31:35 | boyscout | A mild refactoring - 7af8b85 - Evan Phoenix (llvm-jit) |
| 20:31:35 | boyscout | Sync with latest jit-info patch - 9df5c8c - Evan Phoenix (llvm-jit) |
| 20:31:49 | rue | Did you find out who has github.com/rubinius? I thought we set it up at some point |
| 20:32:36 | evan | no |
| 20:32:37 | evan | i need to |
| 20:33:31 | rue | Hu, weird, apparently a semi-active user |
| 20:33:36 | brixen | I messaged the account, got a response |
| 20:33:57 | brixen | Sorry I had this nick already before ruby and rubinius was so popular |
| 20:33:57 | brixen | But as a fan of rubinius as a vm for ruby i would love to donate my account to the project |
| 20:34:00 | brixen | so let me know, it even does not fit to the projects that i have in mind to put on github.... |
| 20:34:03 | evan | what was the response? |
| 20:34:04 | brixen | erg |
| 20:34:07 | evan | no wa |
| 20:34:10 | brixen | http://gist.github.com/111234 |
| 20:34:12 | rue | Haha |
| 20:34:13 | evan | no fucking way did have that nick |
| 20:34:17 | brixen | yeah |
| 20:34:19 | brixen | exactly |
| 20:34:31 | evan | before rubinius existed |
| 20:34:34 | evan | it's a fucking made up word. |
| 20:34:40 | brixen | heh |
| 20:34:42 | headius | so is headius |
| 20:34:50 | rue | Well, theoretically someone could have made it up too |
| 20:35:04 | rue | But there is a slim chance they never noticed it in the last, what, 3 years :P |
| 20:35:17 | evan | i suppose that i could be killed by a quark storm right now too |
| 20:35:22 | evan | but it's pretty fucking unlikely. |
| 20:35:31 | rue | Well, 50/50 chance |
| 20:35:40 | rue | Either you are or not ;) |
| 20:36:28 | rue | Agh. It takes forever or so to even checkout LLVM |
| 20:36:37 | brixen | I should ask if he's got anything with a date on it before oh nov 2006 |
| 20:36:56 | rue | Nah, should leave the poor guy/gal alone :P |
| 20:37:21 | headius | evan: you mentioned the other day that there are still things busted in 1.8.7...what are they? |
| 20:37:33 | headius | I think in JRuby 1.4 we're just going to flip the bits and make 1.8 mode 1.8.7 |
| 20:37:55 | evan | headius: i dunno what they are |
| 20:37:57 | evan | thats the problem |
| 20:38:00 | evan | brb |
| 20:38:08 | headius | nobody's been able to say, even though ruby-core asked |
| 20:39:36 | rue | headius: Do you have any plans for 1.8.8? |
| 20:40:19 | headius | not right now |
| 20:40:28 | headius | I guess they merged some of the parser changes |
| 20:40:36 | headius | other than that I haven't been tracking it |
| 20:56:49 | PierreY | hi guys ! |
| 20:57:07 | PierreY | Finished in 324.439925 seconds |
| 20:57:08 | PierreY | 2684 files, 10328 examples, 32859 expectations, 0 failures, 0 errors !!!!!!! yeah ! |
| 20:57:56 | brixen | PierreY: cool! what platform? |
| 20:58:13 | PierreY | rubinius 0.11.0-dev (ruby 1.8.6) (9df5c8cb9 12/31/2009) [x86_64-unknown-linux-gnu] |
| 20:58:36 | brixen | what distro? |
| 20:59:07 | PierreY | ubuntu x64 |
| 20:59:08 | rue | Emm.. what is the svn command to apply the diff? :P |
| 21:00:51 | brixen | I just use patch for diffs |
| 21:36:31 | dgtized | where do we get our definition of RBASIC? |
| 21:37:14 | dgtized | in capi I mean? |
| 21:38:28 | rue | I do not think we do :) |
| 21:39:12 | dgtized | the compiler is not reporting that the definition of RBASIC is missing, it just doesn't seem to know how to dereference from it correctly |
| 21:40:19 | dgtized | I was trying to test the algorithms gem |
| 21:40:23 | dgtized | and got this: |
| 21:40:25 | dgtized | rbtree.c: In function ‘rbtree_compare_function’: |
| 21:40:25 | dgtized | rbtree.c:295: error: invalid type argument of ‘->’ (have ‘int’) |
| 21:40:43 | rue | Might it be possible that it is including the *actual* ruby.h somewhere? |
| 21:41:10 | rue | Looks like zlib uses it too |
| 21:41:40 | dgtized | yea I was confused on that too, I did a git grep, and only found it there |
| 21:43:28 | rue | Make sure all the #includes are capi/ruby.h, not just ruby.h |
| 21:44:03 | dgtized | in the gem? |
| 21:44:18 | rue | Well, ideally you should just be able to double-check the -I |
| 21:44:45 | dgtized | the -I is for . and for the capi directory |
| 21:44:57 | dgtized | and there is no ruby.h in . |
| 21:45:02 | rue | Hrm...it uses <ruby.h>, right? |
| 21:45:22 | rue | By and large, the angle brackets mean a system include dir lookup |
| 21:45:24 | dgtized | nope "ruby.h" |
| 21:45:26 | dgtized | yea I know |
| 21:45:58 | rue | There are a bunch of <ruby.h> in the sources. Humm. |
| 21:46:37 | dgtized | yea so it's pulling in our ruby.h, and then maybe getting an mri ruby.h from there somewhere? |
| 21:46:41 | dgtized | do we want that? |
| 21:47:30 | rue | Probably not, no.. |
| 21:47:34 | dgtized | bet you if we change zlib include <ruby.h> to "ruby.h" it breaks |
| 21:47:43 | dgtized | well depending on load order anyway |
| 21:48:14 | dgtized | I also note that every one of the capi test includes uses <ruby.h> instead of "ruby.h" |
| 21:50:04 | rue | See what happens if you change all those. |
| 21:50:32 | headius | I like QBASIC better |
| 21:50:54 | rue | Blitz Basic |
| 21:50:58 | dgtized | headius: personally I liked Commodore Basic 7.0 |
| 21:51:24 | dgtized | headius: as you didn't have to mess with all the poke codes like you did in 2.0 |
| 21:52:00 | headius | I only used basic when I was about 8, so I never really did much peeking and poking |
| 21:52:59 | dgtized | I used basic from 8 - 12 or so, in commmodore basic 2, if you wanted to change the output colors you had to poke a foreground / background / border color in order to change it |
| 21:53:44 | dgtized | same for initializing the SID chip to put out audio |
| 21:54:51 | dgtized | heh, I bet you we couldn't even fit the rubinius runtime into 64k |
| 21:55:19 | headius | not counting the kernel, maybe |
| 21:56:52 | dgtized | rue: do you know if the the spec/capi/ext specs were written to link against both capi AND mri ruby.h? |
| 21:57:08 | dgtized | rue: because i bet you that's why they use <ruby.h> and not "ruby.h" |
| 21:58:49 | dgtized | come to think of it, I'm not sure if capi specs are included during the vm specs pass |
| 21:59:03 | rue | I suppose it could be possible, but "" is the correct way |
| 21:59:07 | brixen | dgtized: of course they're written to run against both |
| 21:59:19 | brixen | but you should not need the <ruby.h> form |
| 21:59:25 | brixen | I'm not sure why that was used |
| 22:00:19 | brixen | they don't all use it, so you should try changing the <ruby.h> ones |
| 22:00:41 | brixen | I know I specifically used "ruby.h" in language_spec.c |
| 22:01:22 | brixen | however, since this normally is working, I think this is a red herring... |
| 22:02:08 | rue | Possibly working |
| 22:02:16 | brixen | you probably are not using the right include path when building your ext |
| 22:02:32 | brixen | rue: how possibly? |
| 22:02:38 | brixen | the ci specs run every commit |
| 22:02:48 | brixen | the exts build too |
| 22:03:05 | dgtized | rbx gem install algorithms is what I am testing and what is failing |
| 22:03:14 | dgtized | it correctly uses "ruby.h" |
| 22:03:31 | dgtized | but it's getting a definition of RBASIC from somewhere in our sources |
| 22:03:32 | brixen | so, check the include path in the makefile |
| 22:03:50 | dgtized | the include path reported by the compile line before that is for capi and . |
| 22:04:50 | dgtized | how do I force the capi specs to recompile / run? |
| 22:05:24 | brixen | you can rm all the .bundle/.so files |
| 22:05:48 | brixen | we have no def of RBASIC in our sources http://gist.github.com/111295 |
| 22:06:17 | brixen | so, it's picking up your system dir for ruby.h |
| 22:07:07 | rue | I am not sure if angle brackets _ever_ look at anything but system include dirs |
| 22:07:10 | brixen | which is most likely an rbconfig or mkmf problem |
| 22:07:20 | slava | rue: angle brackets look in the paths that you pass to gcc with the -I flag as well |
| 22:07:36 | slava | so if you do -I. then you can #include <foo.h> from the current dir |
| 22:07:54 | dgtized | I can't remember is GCC aware of CPPFLAGS or is that merely the common way to suggest to a configure script? |
| 22:08:10 | rue | slava: Assuming that there is no foo.h system header, in that case |
| 22:08:45 | rue | "" will look in system headers, I was not aware that <> would also look elsewhere, but I assume you are correct about that part |
| 22:09:16 | slava | dgtized: that's usually done in the makefile |
| 22:09:19 | slava | configure scripts? gah |
| 22:09:42 | rue | But "" is the correct option |
| 22:09:44 | dgtized | slava: ok that's what I thought, it doesn't have a configure script it just has an mkmf |
| 22:10:04 | brixen | dgtized: I don't see why you think it's picking up the mri ruby.h |
| 22:10:28 | dgtized | brixen: because it is not complaining that it doesn't know what RBASIC is |
| 22:10:36 | dgtized | it's complaining that it doesn't know what to do with the result |
| 22:11:07 | brixen | the error I get compiling is because RBASIC isn't defined |
| 22:11:50 | brixen | if I put #ifdef RBASIC around 295 to 299 ir rbtree.c, poof, no error |
| 22:12:44 | dgtized | http://gist.github.com/111302 |
| 22:13:10 | brixen | and, like I said... |
| 22:13:16 | dgtized | if the "invalid type argument '->' is a reference that RBASIC doesn't exist |
| 22:14:12 | dgtized | I presumed it would actually report that name was not something it would know about |
| 22:14:48 | dgtized | alright so the answer then is that we need an implementation of RBASIC in capi? |
| 22:16:07 | dgtized | and my second question is that we shouldn't have references to <ruby.h> in our extensions either should we? I'm pretty sure that the only reason zlib compiles is because it's using a combination of mri ruby.h and our ruby.h |
| 22:18:28 | rue | No, that is not a missing definition error |
| 22:20:38 | rue | And yes, all should be "" |
| 22:21:13 | dgtized | also, I tried switching the spec/capi/ext specs to "", and I don't know how to get them to recompile, they are not tested if you run rake |
| 22:21:39 | dgtized | wait, actually just a sec let me check one more thing on that |
| 22:22:58 | dgtized | ok, I see they get compiled during the bin/mspec run |
| 22:24:46 | rue | There is an extensions:clean or something |
| 22:24:49 | rue | Or just delete the .so |
| 22:25:24 | dgtized | yea I figured that out, I just deleted the .so, it's just I expected it to report it was recompiling those extensions for the tests, but it happens silently somewhere in the mspec run |
| 22:27:20 | dgtized | ah -- I see, zlib uses RBASIC, but we stopped using zlib |
| 22:27:46 | dgtized | so it's not getting any copy of mri ruby.h in, we are simply missing RBASIC |
| 22:28:33 | rue | Try it |
| 22:29:48 | dgtized | try what, compiling zlib? |
| 22:32:00 | dgtized | oh, we are using the ffi form of zlib, but we still have stdlib/ext/zlib |
| 22:41:41 | rue | dgtized: Where is your MRI ruby.h located? |
| 22:42:18 | rue | Hell, even INCLUDES sets /usr/local/include to be looked in *before* . and vm :/ |
| 22:46:08 | dgtized | rue: a couple of places, but none of them are in /usr/include, /usr/local/include or the like |
| 22:46:57 | dgtized | rue: /usr/lib/ruby/1.8/i486-linux/ruby.h, /home/clgc/usr/lib/ruby/1.8/i686-linux/ruby.h, /home/clgc/usr/include/ruby-1.9/ruby.h |
| 22:48:28 | dgtized | if I make a file that just does a #include <ruby.h> and try to compile it gcc reports it can't find ruby.h |
| 22:49:23 | rue | And your error for RBASIC says nothing about an implicit declaration, right? |
| 22:49:57 | dgtized | http://gist.github.com/111302 -- thats the error I get |
| 22:50:45 | brixen | haha, I had time to make and eat a sandwich and you guys still think it's including mri's ruby.h |
| 22:51:06 | brixen | goes back to his codez |
| 22:53:24 | dgtized | rue: do you get the same error from rbx gem install algorithms, or the same? |
| 22:55:08 | dgtized | rue: ah alright, gcc is reporting a pointless error if it can't find RBASIC |
| 22:55:55 | dgtized | brixen: besides making fun of us for trying to search down the problem, do you have any pointers for how to implement RBASIC in capi? |
| 22:57:04 | rue | RBasic is the "header" in MRI |
| 22:57:14 | dgtized | for each object? |
| 22:57:26 | brixen | dgtized: I gave you the problem, RBASIC is not defined |
| 22:57:38 | brixen | if you want to define it, read the MRI source |
| 22:58:22 | rue | Oh, fuck off |
| 22:58:25 | brixen | there's examples in capi you can follow, eg RCLASS |
| 22:58:31 | dgtized | brixen: I did, and it doesn't look like it's directly analogous to how we store our objects |
| 22:58:38 | brixen | it's not |
| 22:59:07 | brixen | rue: that's funny |
| 22:59:37 | brixen | dgtized: if we support it, we have to fake it |
| 22:59:38 | evan | geez guys |
| 22:59:38 | evan | chill. |
| 22:59:47 | headius | you guys have a weird way of cooperating |
| 23:01:11 | rue | The struct only has the two fields, so it is reasonably easy to fake out...and I am not sure there are any extensions that access the flags field, for that matter |
| 23:01:32 | evan | we've got our own zlib extension |
| 23:01:39 | evan | so we don't need to run the MRI one |
| 23:01:46 | evan | unless we're trying to get rid of our own and use the MRI one |
| 23:02:05 | brixen | nah |
| 23:02:05 | seydar | greets |
| 23:02:13 | brixen | this is about the algorithms gem |
| 23:02:16 | dgtized | evan: I'm trying to compile the algorithms gem which requires RBASIC |
| 23:02:18 | brixen | which is using RBASIC |
| 23:02:27 | brixen | seydar: sup yo |
| 23:02:39 | evan | dgtized: ah |
| 23:02:44 | evan | dgtized: why does it need RBASIC |
| 23:02:54 | rue | (And, regardless, they should all use "", not <>) |
| 23:02:55 | dgtized | evan: http://gist.github.com/111302 |
| 23:02:56 | evan | i've never seen anyone using RBASIC in an extension |
| 23:03:21 | evan | dgtized: that guys is just being a douche |
| 23:03:31 | evan | that code is busted |
| 23:03:56 | evan | we can work support for RBASIC in |
| 23:04:02 | rue | Or did not realise there are better ways of getting the class object |
| 23:04:03 | evan | but whoever wrote this needs to fix their code |
| 23:04:11 | evan | comparing directly against class does NOT do what you think it does |
| 23:04:32 | evan | directly against class == RBASIC()->klass |
| 23:05:05 | rue | dgtized: Yes, I have the same error |
| 23:05:18 | evan | case in point: s = ""; def s.fun; end; code_that_calls_this_rbtree_compare(s) |
| 23:05:27 | evan | that code will fail incorrectly |
| 23:05:32 | rue | Checking with "" substituted |
| 23:06:03 | dgtized | I think it's intended as a performance opt in the extension for comparing two red black tree nodes |
| 23:06:06 | dgtized | but anyway regardless |
| 23:06:29 | dgtized | it would seem like if we don't implement RBASIC, we should at least spit out deprecated |
| 23:06:38 | dgtized | or implement it in some fashion |
| 23:06:46 | dgtized | instead of just letting the compiler spit out a nonsense error |
| 23:07:02 | brixen | dgtized: we just haven't encountered it yet |
| 23:07:15 | evan | yeah |
| 23:07:17 | brixen | there's not stubs for all MRI macros and functions |
| 23:07:20 | evan | almost no one uses RBASIC in extensions |
| 23:07:39 | evan | and i'd say that everyone that does use it probably has bugs |
| 23:08:48 | brixen | dgtized: btw, my making fun of you is because almost an hour ago I told you it wasn't defined and you didn't listen |
| 23:08:57 | brixen | and that wastes my time looking at your issue |
| 23:09:03 | brixen | and that is super annoying |
| 23:09:07 | brixen | just so you know |
| 23:09:27 | rue | The error message says zippo about it not being defined. |
| 23:09:44 | evan | true |
| 23:09:45 | evan | hm |
| 23:09:45 | brixen | doesn't matter, I checked and told you so |
| 23:09:50 | evan | i wonder how we could do that |
| 23:10:20 | evan | perhaps |
| 23:10:39 | rue | And, once again, using <> is wrong either way |
| 23:10:43 | evan | #define RBASIC assert(!!! && "NOT DEFINED") |
| 23:11:05 | evan | sounds like the problem is 2 fold |
| 23:11:10 | evan | rubinius has no RBASIC |
| 23:11:19 | evan | and ruby.h is being used from MRI inside a rubinius extension |
| 23:11:23 | evan | the later is much worse that the former atm |
| 23:11:37 | dgtized | brixen: well when you dismiss issues without explaining then it's harder to accept the dismissal -- I wasn't sure you had the exact same error and it's not like it's an intuitive error message |
| 23:12:37 | brixen | there is no evidence it is including mri's ruby.h |
| 23:12:40 | dgtized | no ruby.h is not being used in any rubinius extension other then zlib, but we implement that using FFI now, so it's not using the source that uses <ruby.h> |
| 23:13:12 | dgtized | brixen is correct that we aren't using mri's ruby.h as far as I can tell |
| 23:13:17 | evan | dgtized: FFI has no relation to any ruby.h |
| 23:13:22 | brixen | stdlib/zlib is not being used |
| 23:13:24 | brixen | remove it |
| 23:13:31 | evan | ok |
| 23:13:36 | evan | why are we talkinga bout zlib? |
| 23:13:38 | dgtized | and the other stdlib extensions that reference <ruby.h> there as well? |
| 23:13:45 | dgtized | because that was the red herring |
| 23:13:51 | dgtized | that rue and I chased |
| 23:14:19 | dgtized | anyway, it doesn't matter, the point is RBASIC doesn't exist, and so the question is how it should be handled if encountered in an extension |
| 23:14:54 | evan | this is one really shitty thing about gcc/C |
| 23:15:04 | evan | the error is because, since there is no RBASIC defined |
| 23:15:10 | evan | it figured it's declared to return an int |
| 23:15:17 | evan | since thats the default |
| 23:15:30 | dgtized | wow that's user friendly |
| 23:15:36 | evan | exactly. |
| 23:15:48 | evan | i wonder why it didn't report that there is no RBASIC defined |
| 23:15:51 | slava | if you compile with -Wall -Werror it actually complains about the missing identifier |
| 23:15:51 | evan | it usually does that as well |
| 23:15:57 | slava | instead of assuming it returns an int |
| 23:16:02 | evan | so just -Wall |
| 23:16:08 | evan | -Werror is something else. |
| 23:16:10 | slava | I highly recommend -Werror too |
| 23:16:13 | slava | it makes all warnings into errors |
| 23:16:25 | evan | i know what -Werror does |
| 23:16:26 | evan | :/ |
| 23:16:29 | dgtized | should we add that to our default flags for mkmf? |
| 23:16:35 | evan | yes |
| 23:16:38 | brixen | slava: that means most code associated with MRI would not compile |
| 23:16:39 | evan | i'm surprised we don't have it now. |
| 23:16:57 | brixen | we do not, because exts are not generally warning free |
| 23:17:04 | evan | i'd rather spit warnings |
| 23:17:06 | evan | and not error out |
| 23:18:17 | evan | dgtized: your time would be best served contacting the algorithms gem guy |
| 23:18:21 | slava | brixen: that's a shame |
| 23:18:23 | evan | and tell him to use rb_knid_of |
| 23:19:00 | dgtized | evan: ok, and then we just throw in some kind of build warning for RBASIC usage? |
| 23:19:17 | slava | if you adopt the right coding style, warnings will indicate actual problems with the code |
| 23:19:51 | evan | dgtized: -Wall will provide the proper warning |
| 23:20:05 | brixen | I've added it to rbconfig |
| 23:20:14 | brixen | it gives the implicit def warning |
| 23:20:44 | evan | ok |
| 23:20:46 | evan | i think thats fine |
| 23:21:01 | brixen | http://pastie.org/477422 |
| 23:22:16 | evan | bingo |
| 23:22:40 | dgtized | so we don't have rb_eval_string or rb_ary_new3 yet as well I guess? |
| 23:22:48 | evan | just haven't done them yet |
| 23:23:03 | evan | but yes |
| 23:24:38 | dgtized | k, well I'll try to work up a rb_kind_of patch for the algorithms guy, and then just wait on rb_eval_string or rb_ary_new3 to test |
| 23:25:12 | evan | k |
| 23:25:45 | dgtized | I just picked this gem as I thought it was neat to have some basic datastructures available by extension and that might be a good angle for some of our more specialized structures -- I didn't expect it to unearth a list of not yet implemented capi functions |
| 23:26:46 | evan | when you drink from the firehouse, it can knock you on your ass. |
| 23:28:26 | boyscout | Added -Wall to rbconfig CFLAGS. - 075a90d - Brian Ford |
| 23:28:49 | dgtized | he also implemented some c extension versions of sort, I don't know how much overhead we get using c extensions, but I wonder if we could move a few things out of core into a library like this |
| 23:29:20 | evan | having the kernel depend on someone's extension gem makes my stomach turn |
| 23:29:21 | dgtized | http://github.com/kanwei/algorithms/tree/master |
| 23:29:54 | brixen | having evidence from real apps that we need to implement something differently is the first step |
| 23:30:05 | brixen | after that, it would be fixed in core |
| 23:30:18 | brixen | or kernel rather |
| 23:31:04 | dgtized | wait, before everyone thinks I'm criticizing, it just seemed like this guys project has some overlap, we are discussing using vlists and alternate hash implementations and the like |
| 23:31:10 | boyscout | CI: 075a90d success. 2684 files, 10335 examples, 32880 expectations, 0 failures, 0 errors |
| 23:31:52 | evan | dgtized: PDI |
| 23:31:54 | dgtized | and this guy has pure ruby implementations of red black trees and suffix arrays and what not, that also have capi backings for performance if necessary |
| 23:32:28 | evan | dgtized: give it a look |
| 23:32:32 | evan | let us know what you fin.d |
| 23:32:45 | evan | i know nothing about it |
| 23:32:49 | dgtized | I wasn't actually suggesting we load up a rubygem just after a loading kernel with a bunch of sorting methods and the like |
| 23:32:52 | evan | the alorgithms gem that is. |
| 23:33:28 | dgtized | it was more just that if he is doing performance testing on datastructures in pure ruby that have c api backends for performance, it just seems like there is some overlap |
| 23:33:41 | evan | have a look |
| 23:33:43 | evan | let us know |
| 23:33:45 | evan | i'll leave it at that. |
| 23:35:16 | dgtized | k |
| 23:58:57 | rue | evan: Might want to do the patch against a more recent checkout...looks like it is about 1500 revisions behind |
| 23:59:38 | evan | oh. hrm. |