Show enters and exits. Hide enters and exits.
| 00:05:20 | tmm1 | http://pastie.org/1009411 |
| 00:05:27 | tmm1 | missing assert.h? |
| 00:11:05 | brixen | tmm1: something you are building is defining NDEBUG |
| 00:19:29 | tmm1 | ooh this is a tricky one |
| 00:19:35 | tmm1 | st_foreach(RHASH_TBL(nslist), iterate_ns_hash, self); |
| 00:19:38 | tmm1 | that's the offending line |
| 00:19:47 | brixen | oh yeah, that's right |
| 00:19:49 | brixen | argh |
| 00:19:54 | tmm1 | without assert.h, it compiles fine |
| 00:20:10 | tmm1 | with it, i get |
| 00:20:13 | tmm1 | ruby_xml_xpath_context.c:224: error: invalid use of void expression |
| 00:20:26 | brixen | yeah |
| 00:20:28 | brixen | let's see |
| 00:21:03 | brixen | hm, perhaps a function here then |
| 00:21:19 | brixen | that prints that to stderr rather than using assert |
| 00:21:21 | brixen | and returns obj |
| 00:21:49 | brixen | that == "RHASH_TBL/RHASH is not supported" |
| 00:23:09 | tmm1 | hmm yea, ideally it'd be compile time i think |
| 00:23:18 | brixen | :) |
| 00:23:27 | brixen | well, yes, how would you define those macros then? |
| 00:23:44 | tmm1 | i'm thinking. i tried #error but that didn't work =P |
| 00:24:06 | brixen | heh, yes I tried that too |
| 00:24:22 | brixen | the runtime warning sucks |
| 00:24:28 | brixen | we could just leave them undefined |
| 00:24:39 | tmm1 | #define ASSERT_ON_COMPILE(pred) switch(0){case 0:case pred:;} |
| 00:24:43 | brixen | but most users of C ext won't know why the build fails |
| 00:24:43 | tmm1 | heh |
| 00:25:17 | tmm1 | yea printing something out at runtime is probably easiest |
| 00:25:26 | brixen | hmm interesting |
| 00:25:32 | tmm1 | in this case it would have crashed right after but atleast you'd know what happened |
| 00:26:25 | tmm1 | brixen: that's something joe is using in memprof, but the compiler error is not very useful |
| 00:27:35 | brixen | tmm1: well, can't we make the compiler error output better? |
| 00:28:12 | evan | tmm1: i think i had it be |
| 00:28:36 | evan | #define RHASH_TBL ("sorry charlie, this won't fly" && won't compile) |
| 00:29:14 | brixen | heh |
| 00:29:33 | brixen | where "sorry charlie.." is "RHASH_TBL is not supported on Rubinius" |
| 00:29:36 | brixen | :) |
| 00:30:45 | evan | yeah yeah. |
| 00:30:46 | evan | :D |
| 00:31:33 | tmm1 | well, you could just add an include <assert.h> to ruby.h |
| 00:31:41 | evan | yeah |
| 00:31:44 | evan | thats a bug |
| 00:31:45 | evan | it should be. |
| 00:32:02 | evan | the real issue is using RHASH_TBL |
| 00:32:06 | evan | you know how to change that? |
| 00:32:32 | evan | use rb_hash_foreach instead |
| 00:32:39 | tmm1 | - st_foreach(RHASH_TBL(nslist), iterate_ns_hash, self); |
| 00:32:42 | tmm1 | + rb_hash_foreach(nslist, iterate_ns_hash, self); |
| 00:33:02 | evan | yep. |
| 00:55:29 | tmm1 | wow |
| 00:55:33 | tmm1 | it works |
| 00:56:10 | evan | hot damn! |
| 01:01:11 | tmm1 | Assertion failed: (current_->exception_handler()), function build, file vm/llvm/cfg.hpp, line 216. |
| 01:01:15 | tmm1 | on the spec suite |
| 01:02:22 | evan | thats.. weird. |
| 01:02:22 | tmm1 | on my spec suite that is |
| 01:02:35 | evan | wait |
| 01:02:37 | evan | i'm confused. |
| 01:02:43 | evan | how did you get that |
| 01:04:36 | tmm1 | i'm trying to narrow it down |
| 01:04:42 | evan | k |
| 02:09:25 | fowlduck | alright, now, lets see about that .rbc stuff |
| 02:13:25 | brixen | fowlduck: Compiler.compiled_name can be overridden at runtime |
| 02:13:50 | brixen | you could define that in your own rc file |
| 02:14:01 | brixen | and use whatever scheme you want |
| 02:14:05 | fowlduck | you know...if the files just started with . that would solve the only remaining issue |
| 02:14:13 | brixen | no, it really wouldn't |
| 02:14:17 | fowlduck | really? |
| 02:14:20 | brixen | it might for you ;) |
| 02:14:21 | fowlduck | has no idea |
| 02:15:25 | brixen | you have to take apart every filename to insert the . |
| 02:15:43 | brixen | why pay the penalty for that when you can just ignore the files in your editor or in git? |
| 02:16:16 | brixen | but anyway, this is very easy for you to customize without rbx having to support it |
| 02:17:11 | fowlduck | how again? |
| 02:17:59 | brixen | see kernel/loader.rb:91 |
| 02:18:06 | brixen | rbx will load a .rbxrc |
| 02:18:21 | brixen | Rubinius::Compiler.compiled_name is just a plain old ruby method |
| 02:18:27 | brixen | make it do whatever you want :) |
| 02:18:34 | fowlduck | ah, i see |
| 02:19:42 | brixen | see lib/compiler/compiler.rb for the default def of Compiler.compiled_name |
| 02:20:22 | brixen | postmodern: looks like I've almost got rbx building with 1.9.1+ |
| 02:20:29 | brixen | postmodern: doing a few more checks |
| 02:20:37 | brixen | I should say, it is building |
| 02:20:42 | postmodern | brixen, badass! |
| 02:20:47 | brixen | but I'm cleaning up some warnings and stuff |
| 02:29:06 | fowlduck | changing that method results in exceptions. boo |
| 02:29:34 | brixen | what exceptions? |
| 02:30:56 | brixen | dinner, bbl... |
| 02:31:06 | fowlduck | http://pastie.org/1009527 |
| 02:31:09 | fowlduck | k, later |
| 02:31:44 | brixen | haha |
| 02:31:56 | brixen | well, you can't just put a . on the front of the path :) |
| 02:32:17 | brixen | try pulling the path apart and inserting a . on the filename, then putting it back together |
| 02:32:48 | fowlduck | ah, that's the issue *facepalm* |
| 02:32:57 | fowlduck | i figured it was just the filename |
| 02:33:04 | brixen | File.dirname, File.basename |
| 02:33:10 | brixen | heh |
| 02:33:13 | brixen | ok, have fun! |
| 02:33:16 | brixen | bbiab... |
| 02:35:12 | fowlduck | got it |
| 02:35:40 | fowlduck | http://pastie.org/private/infoiyd3y8j5yapcmbnb2w |
| 02:37:10 | fowlduck | i wonder if that's reliable |
| 02:42:27 | fowlduck | you know, looking at that backtrace i didn't notice this line: Caused by: No such file or directory - ./Users/nate/.rvm/rubies/rbx-1.0.1-20100603/lib/bin/irb.rbc (Errno::ENOENT) |
| 02:42:36 | fowlduck | *facepalms again* |
| 02:46:07 | postmodern | fowlduck, that would be some bad code trying to load files using * |
| 02:46:14 | postmodern | fowlduck, and not *.rb |
| 02:46:59 | fowlduck | what? |
| 02:47:20 | fowlduck | updated a wee bit |
| 02:47:55 | fowlduck | postmodern: i don't follow |
| 02:52:54 | tarcieri | hrmm, how hard would it be to embed rbx into a C-only environment :) |
| 02:53:51 | tarcieri | I've been meaning to play around with llvm-g++ and the "C" machine architecture |
| 02:53:54 | tarcieri | is that insane? |
| 02:53:56 | tarcieri | heh |
| 02:58:25 | fowlduck | hrm, segfaulting rubinius |
| 02:59:20 | fowlduck | bah |
| 04:40:31 | tarcieri | maybe a better approach would be to write an LLVM backend for this crazy intermediate language |
| 04:43:11 | evan | tarcieri: that sounds cool. |
| 04:45:43 | tarcieri | I'd really like to experiment with getting some kind of scripting language interpreter onto this platform |
| 04:46:11 | tarcieri | they pretty much wrote their own IL for C ala TenDRA, then patched early versions of GCC to output it (note: not g++) |
| 04:46:29 | tarcieri | and got sued by the free software foundation for violating the GPL, heh |
| 05:11:03 | evan | tarcieri: oops. |
| 05:11:19 | tarcieri | heh, yeah |
| 05:11:33 | evan | what is the thing you're looking at? |
| 05:11:40 | tarcieri | OpenTV O-Code |
| 05:12:10 | evan | and what does it do? |
| 05:12:23 | tarcieri | digital TV set top box middleware |
| 05:12:42 | tarcieri | I mean, it sounds fairly cool... |
| 05:12:46 | tarcieri | "The OpenTV programming model is an asynchronous message-based environment. OpenTV applications make o-code function calls to the OpenTV library. The library routines initiate operations or requests. They do not block until the operation has completed; they return immediately. When an operation or request completes, a message is sent to the application indicating completion. Applications consist primarily of a message loop, which retrieves messages f |
| 05:12:54 | tarcieri | fully async! |
| 05:12:55 | tarcieri | w00t! |
| 05:20:21 | BrianRice | huh |
| 05:21:32 | BrianRice | that's pretty cool, from an erlang perspective, and also from a tv media analytics perspective |
| 05:22:28 | brixen | heh, which BrianRice would know nothing about whatsoever :) |
| 05:22:50 | evan | because BrianRice works in radio? |
| 05:22:59 | brixen | um, yeah :) |
| 05:23:01 | tarcieri | lol |
| 05:23:10 | brixen | tarcieri: that daily show is hilarious! thanks for the link |
| 05:23:20 | tarcieri | BrianRice: dude my first thought when people started describing these STBs was "USE ERLANG!#$!#$!#" |
| 05:23:21 | brixen | of course, the daily show always nails it |
| 05:23:23 | tarcieri | that would so fail |
| 05:23:25 | tarcieri | brixen: indeed! |
| 05:23:57 | BrianRice | tarcieri: yeah some people just emulate it in c++. I've been paid to do that for restricted embedded environments |
| 05:24:06 | tarcieri | these boxes don't do C++ |
| 05:24:07 | tarcieri | lol |
| 05:24:23 | tarcieri | that's why I'm... looking at LLVM to cross-compile C++ to C, then to O-Code |
| 05:24:23 | tarcieri | lol |
| 05:24:36 | BrianRice | interesting. well, whatever works. |
| 05:24:45 | tarcieri | although if they have technical people who are good C(++) programmers with an intimate knowledge of their bytecode format |
| 05:24:49 | tarcieri | they should just bust an LLVM backend |
| 05:28:02 | BrianRice | the c++ environment was 4mb ram + 6mb flash storage, on hm I forget which ARM chipset |
| 05:28:15 | BrianRice | anyway, usually this is not a problem. |
| 05:28:49 | BrianRice | oh well. time to read. gnite |
| 05:30:50 | tarcieri | heh |
| 05:31:00 | tarcieri | yeah our hardware is, uhh, slightly more powerful |
| 05:38:43 | evan | brixen: i'm fine tuning the perf for ivar access of packed objects |
| 05:38:49 | evan | getting closer to even with normal ivar. |
| 05:42:52 | evan | tomorrow... heap dump! |
| 05:46:38 | brixen | sweet1 |
| 05:46:42 | brixen | ! |
| 05:47:10 | brixen | just got a random sigbus :/ |
| 05:47:17 | evan | :( |
| 05:47:25 | brixen | Executable::Info::mark_inliners |
| 05:47:46 | brixen | about to push the rbx/1.9 build stuff |
| 05:47:55 | brixen | fixing a couple 1.9 warnings |
| 05:48:07 | evan | damnit! that again. |
| 05:48:10 | evan | POOP |
| 05:48:14 | evan | i can't figure that one out. |
| 05:48:18 | brixen | :( |
| 05:52:50 | brixen | man I dislike 1.9's warning about shadowing an outer local |
| 05:52:59 | evan | ditto. |
| 05:53:04 | brixen | it's named node because it's a node! |
| 05:53:13 | brixen | and yes, my function got passed a node too! |
| 05:58:35 | brixen | evan: should we clear all the openssl ext warnings someday? |
| 05:58:44 | evan | yes. |
| 05:58:56 | evan | I thought I had them cleared actually |
| 05:59:42 | brixen | really? |
| 05:59:46 | brixen | I get a ton building |
| 05:59:48 | brixen | always have |
| 05:59:50 | evan | ok |
| 05:59:52 | evan | maybe not then! |
| 05:59:55 | brixen | heh |
| 06:00:11 | brixen | it was probably the other openssl ext :) |
| 06:05:17 | brixen | jc00ke: hey man |
| 06:08:40 | jc00ke | brixen: sup dude, how was RailsConf? Bang up job on Evan's game! ;-) |
| 06:08:48 | evan | ha! thanks! |
| 06:08:54 | evan | glad everyone seemed to enjoy it |
| 06:09:03 | jc00ke | Conan ain't got shit on you |
| 06:09:08 | evan | you're too kind. |
| 06:09:23 | brixen | jc00ke: hah, that was funny |
| 06:09:27 | brixen | and fun :) |
| 06:09:27 | jc00ke | I was rooting for Brian, but he looked nervous |
| 06:09:35 | brixen | nah, it was all an act |
| 06:09:37 | brixen | :) |
| 06:09:59 | jc00ke | so remember how I was having problems getting rbx installed w/rvm? |
| 06:10:08 | brixen | yeah, vaguely |
| 06:10:23 | jc00ke | tried getting help from Wayne but that shit don't work, so I'm just installing it directly |
| 06:10:30 | brixen | do you have an error I can look at? |
| 06:10:40 | jc00ke | yeah, lemme find the gist |
| 06:10:47 | brixen | also, about to push support for building with 1.8 or 1.9 |
| 06:11:15 | jc00ke | nice! |
| 06:11:16 | jc00ke | http://gist.github.com/402495 |
| 06:11:29 | brixen | C++ template warnings/errors are so crazy |
| 06:11:32 | brixen | evan: halp http://gist.github.com/443313 |
| 06:11:40 | jc00ke | so, I have 187 p249 as my default rvm ruby |
| 06:12:15 | jc00ke | rvm tries configuring but then balks (last line of http://gist.github.com/402495#file_rvm_install_rbx.log.sh) |
| 06:12:37 | brixen | hm that is so weird |
| 06:12:58 | brixen | did you try cloning rbx and running configure/rake directly? |
| 06:13:13 | evan | brixen: yes, wonderful, wonderful g++ error output |
| 06:13:31 | evan | like ramming a fork with 25 fingers through your eye |
| 06:13:57 | jc00ke | yeah, it's running now, working through the specs I believe |
| 06:13:57 | brixen | evan: that and I have no clue what it's trying to say |
| 06:14:12 | brixen | jc00ke: ok, did you update rvm to latest before trying btw? |
| 06:14:55 | jc00ke | brixen: yes, I even removed the rvm src dir under .rvm & ran his update script, still didn't work |
| 06:15:29 | jc00ke | BUT, I did create a new user on my system, installed rvm and then installed rbx in rvm just fine |
| 06:15:34 | brixen | evan: I changed int to size_t in the typedef of quark_map, but that did not fix the warning |
| 06:15:46 | brixen | I have no idea what freakin value it is referring to |
| 06:15:48 | jc00ke | so there's gotta be something hanging around |
| 06:16:05 | brixen | jc00ke: hm, that is really odd |
| 06:16:25 | brixen | jc00ke: did you try rvm reset to get back to your system ruby? |
| 06:16:31 | evan | brixen: why are you getting this suddenly? |
| 06:16:33 | brixen | also, what is your system? |
| 06:16:42 | brixen | evan: compiling against 1.9, no clue |
| 06:16:42 | jc00ke | brixen: let me try that. Ubuntu 10.04 |
| 06:16:58 | brixen | jc00ke: ah, I have an ubuntu 10.04 vbox, I'll try it |
| 06:18:25 | jc00ke | brixen: I ran rvm reset; rvm use 187-p249; rvm install rbx and it still failed |
| 06:18:33 | evan | brixen: ug. |
| 06:19:01 | evan | jc00ke: you should ask wayneeseguin |
| 06:19:04 | evan | i'm sure he'll know |
| 06:19:23 | evan | he is expert. |
| 06:19:37 | jc00ke | evan: yeah, I've asked him a few times but he hasn't been able to help |
| 06:19:57 | jc00ke | I guess I could just blow away all my rvm shit & install fresh |
| 06:20:12 | brixen | jc00ke: well, rvm is great but rbx is so easy to build + install |
| 06:20:24 | brixen | 1. clone, 2. configure, 3. rake |
| 06:20:29 | jc00ke | brixen: true, so I'm just going to do that |
| 06:20:39 | jc00ke | you symlink rbx as ruby in your path? |
| 06:20:44 | jc00ke | or just use rbx? |
| 06:20:49 | brixen | I just use rbx |
| 06:21:09 | brixen | but you can just symlink from your build dir too |
| 06:21:27 | brixen | be aware, you should use rbx/ruby -S rake etc |
| 06:21:39 | jc00ke | werd, I have ~/bin set up so I'll just symlink through that |
| 06:21:47 | brixen | where MRI installs gems and litters gem exe's in your path, rbx puts them in one dir |
| 06:21:50 | evan | jc00ke: I leave ruby as MRI |
| 06:21:55 | evan | and rubinius as rbx. |
| 06:22:18 | evan | they can happily cohabitate |
| 06:22:21 | jc00ke | evan: so you have MRI installed as system? |
| 06:22:24 | brixen | yeah, I prefer to know which I'm running |
| 06:22:30 | evan | i have about 18 versions of MRI installed |
| 06:22:32 | evan | yeah. |
| 06:22:39 | jc00ke | all as system or with rvm? |
| 06:22:44 | evan | system |
| 06:22:54 | jc00ke | fuck dude, you're hardcore ;-) |
| 06:22:55 | evan | 18, 19, macruby, jruby, rbx |
| 06:23:23 | scoopr | does ironruby work with mono? ;) |
| 06:23:30 | postmodern | why does 1.9.2-preview3 put everything in ruby/1.9.1 |
| 06:23:33 | evan | scoopr: so i've heard. |
| 06:23:51 | evan | hah |
| 06:23:55 | postmodern | i think someone pointed it out immediately on the mailing list when they announced it |
| 06:24:02 | jc00ke | brixen: so you're suggesting to always use ruby -S ... as well as rbx -S ...? |
| 06:24:10 | evan | brixen: so, I added ">> 2" to key_hash() in lookuptable.cpp |
| 06:24:34 | evan | shaved autopack below non-autopack |
| 06:24:43 | evan | because the @ivar => index are stored in a lookup table |
| 06:24:57 | brixen | evan: sweet! |
| 06:25:03 | evan | and the straight object isn't as good of a hash |
| 06:25:12 | evan | because of the shared bottom 2 bits |
| 06:25:15 | brixen | jc00ke: I mean with rbx, but if you symlink rbx to ruby, then yes, with ruby :) |
| 06:25:30 | evan | hah |
| 06:25:36 | evan | of course, now I run without autopack |
| 06:25:41 | jc00ke | brixen: k, that's what I thought you meant |
| 06:25:43 | evan | and it's also better. |
| 06:25:43 | evan | :D |
| 06:25:58 | evan | but both are faster than the old non-autopack |
| 06:25:59 | brixen | heh |
| 06:26:04 | brixen | nice |
| 06:26:09 | evan | a bit more tuning tomorrow. |
| 06:26:25 | evan | i really think I want a better datastructure for the @name => offset map/hash |
| 06:26:32 | evan | need to think about it |
| 06:26:45 | evan | or figure out a way to not do the lookup at all. |
| 06:27:36 | brixen | hm |
| 06:27:50 | jc00ke | brixen: you get any spec errors on 10.04 with latest master? |
| 06:28:01 | jc00ke | I got 2 failures, 3 errors :-( |
| 06:28:20 | jc00ke | all have to do with TCP |
| 06:28:29 | evan | i've seen that |
| 06:28:30 | evan | gist? |
| 06:29:21 | jc00ke | evan, http://gist.github.com/443331 |
| 06:29:43 | evan | weird. |
| 06:29:55 | evan | you can safely ignore them |
| 06:30:05 | brixen | jc00ke: hm, haven't see those |
| 06:30:26 | jc00ke | That's twice tonight I got "weird" from you guys... that's always fun ;-) |
| 06:30:33 | brixen | networking shit is so wonky |
| 06:30:49 | brixen | jc00ke: yes, for certain values of fun :) |
| 06:30:55 | evan | jc00ke: we're weird guys |
| 06:30:59 | evan | ok, i'm going to get to bed. |
| 06:31:01 | evan | nite! |
| 06:31:03 | jc00ke | evan: ok, so just to double check, I do not need to create tickets |
| 06:31:04 | brixen | nite! |
| 06:31:18 | evan | jc00ke: go ahead. |
| 06:31:21 | evan | create them |
| 06:31:26 | evan | so we remember to check it out further. |
| 06:31:42 | jc00ke | will do. g'night! |
| 06:31:58 | brixen | jc00ke: put in there if you have any custom networking settings |
| 06:32:06 | brixen | other than vanilla install |
| 06:32:25 | jc00ke | like? |
| 06:32:46 | jc00ke | All I've done is edit my hosts file but that should have no effect |
| 06:32:52 | brixen | :) |
| 06:32:58 | brixen | well, put that in there |
| 06:33:03 | jc00ke | okey dokey |
| 06:33:04 | brixen | like, what you added |
| 06:33:28 | brixen | editing hosts often has more effects than one expects |
| 06:35:20 | jcooke | I'll revert the changes to my hosts file and re-run the specs |
| 06:45:56 | jc00ke | ok |
| 06:47:12 | jc00ke | brixen: it takes upwards of 10 minutes to run ./bin/mspec spec/ruby/library/socket/tcpsocket/new_spec.rb |
| 06:47:37 | jc00ke | I'll start fresh tomorrow & get this stuff into GitHub |
| 06:47:53 | jc00ke | g'night |
| 06:47:57 | brixen | jc00ke: ok thanks! |
| 06:48:00 | brixen | night! |
| 10:40:15 | lypanov | aw crap, you guys talked too much and i missed most of the log |
| 11:07:30 | dbussink | lypanov: there's a site with the logs |
| 11:09:20 | dbussink | lypanov: http://donttreadonme.co.uk/rubinius-irc/index.html |
| 11:32:03 | parndt | secret logs :/ |
| 11:48:22 | lypanov | cool. thx dbussink ! |
| 12:02:57 | dbussink | parndt: they aren't secret |
| 12:03:29 | parndt | not advertised in the topic |
| 12:03:55 | dbussink | true, probably disappeared when that was changed at some point |
| 12:04:03 | dbussink | it has been in there as far as i can recall |
| 12:04:08 | dbussink | and has been on the website too |
| 12:04:54 | dbussink | ah, it's still on the website at http://rubini.us/about/community |
| 12:05:10 | parndt | alright then.. |
| 12:06:04 | dbussink | it has never been intended to be secret in any way :) |
| 12:06:30 | parndt | Just making sure it was said somewhere.. :p |
| 12:17:07 | dbussink | parndt: one of those things that's easily forgotten :P |
| 12:17:18 | dbussink | i always assume every channel to be publicly logged somewhere |
| 12:19:11 | scoopr | I bet nsa has logs of every channel! |
| 12:27:04 | dbussink | they have everything! |
| 12:27:25 | dbussink | i've been in the pentagon once, so the us has everything on me :p |
| 12:27:41 | dbussink | never had any problems entering the us though, i still suspect a connection there :p |
| 12:28:52 | scoopr | when I form a superpowernation, I will call the military hq 'hexagon'.. perhaps even 'octagon' |
| 12:29:01 | scoopr | just to show my superiority |
| 12:29:11 | parndt | I'll use dodecahedron |
| 12:29:46 | prophile | I'll build mine out of a 6-dimensional hypertorus |
| 12:29:55 | prophile | take that, physics as we know it |
| 12:30:19 | dbussink | only 6 |
| 12:30:21 | dbussink | ? |
| 12:30:29 | parndt | I'll construct my base out of Higgs Boson |
| 12:30:39 | dbussink | i'm going for the 11 dimensional googlegon build out of strings |
| 12:31:42 | scoopr | I now see why they settled on pentagon |
| 12:31:43 | dbussink | but i'll bow for someone who builds their base from tachyons :P |
| 12:33:11 | parndt | Mine will be powered by dilthium crystals |
| 12:33:19 | parndt | and it'll run on rubinius, green. |
| 12:34:25 | parndt | awkward and nerdy enough yet? |
| 12:51:18 | dbussink | parndt: well, tachyons are actually a hypothetical particle, dilithium crystals are just nonsense :P |
| 12:51:28 | parndt | bazinga |
| 14:29:12 | goyox86 | Hi people, i've switched my rails development stack to rbx, and i've a question |
| 14:30:09 | goyox86 | When i tell rubinius don't generate rbc files, the performance gets affected, i mean the execution time? |
| 14:30:28 | goyox86 | Im using of course the --no-rbc flag |
| 15:50:53 | brixen | goyox86_: --no-rbc does nothing, I'll commit a fix to remove that |
| 15:51:11 | brixen | goyox86_: you can use -Xcompiler.no_rbc to tell rbx to not create .rbc files |
| 15:51:29 | brixen | goyox86_: that means that rbx will have to recompile the rb source file every time |
| 15:51:53 | brixen | our bytecode compiler is quite fast, but there's really not a good reason to use this option |
| 15:52:07 | brixen | finally, the runtime performance is not affected |
| 15:52:37 | brixen | but depending on when you load a file, it may take longer to run some things (because rbx is having to recompile it instead of just loading the .rbc) |
| 15:58:19 | goyox86 | mmm, thx @brixen |
| 15:58:47 | brixen | goyox86_: the best approach is just to ignore .rbc in your .gitignore and your editor |
| 15:59:02 | brixen | nothing else cares about them but rbx :) |
| 15:59:23 | goyox86 | yep , i've done this, yesterday i've ignored that in textmate too |
| 16:00:11 | goyox86 | i've tried it coz i'm experimenting some hangs, in development mode using webrick |
| 16:01:15 | brixen | hmm |
| 16:01:58 | brixen | if you get a hang, get the pid from ps and do gdb -p to attach |
| 16:02:07 | brixen | then do a bt and show us |
| 16:02:20 | brixen | gdb -p <pid> rather |
| 16:06:27 | goyox86 | i will, some times webrick becomes unresponsible, even while i try to send a Ctrl+C keystroke (sometimes) |
| 16:07:00 | goyox86 | it takes a long time to exit te process, I'm running Leopard by the way |
| 16:08:02 | goyox86 | I will attach gdb to see what's happening, se yaa in a (i hope ) few moments :-) |
| 16:15:17 | evan | hi hi |
| 16:16:48 | brixen | morning |
| 16:17:13 | brixen | evan: I experimented with various ways to get compile errors out of RHASH |
| 16:17:26 | brixen | I'm making them functions that error and abort |
| 16:17:34 | evan | coolness. |
| 16:18:49 | brixen | evan: so, 1.9.2 defines -Wshorten-64-to-32 in CFLAGS |
| 16:18:57 | brixen | which of course we pick up for building exts |
| 16:19:04 | brixen | and a bunch of other warnings btw |
| 16:19:06 | evan | ah, so we've had it the whole time. |
| 16:19:09 | brixen | yes |
| 16:19:18 | brixen | but I still have no fucking clue |
| 16:19:28 | brixen | I asked dwaite to look at it and he couldn't figure it out either |
| 16:19:33 | evan | can you strip out that flag for now? |
| 16:19:43 | brixen | hmm, I could I suppos |
| 16:19:48 | daschl | hey guys, i try to build rubinius from source.. why do i need the "llvm" stuff and what happens if i install it without?! |
| 16:19:50 | brixen | it's the only warning from it though |
| 16:19:50 | evan | lets do that |
| 16:20:01 | brixen | daschl: what platform? |
| 16:20:02 | evan | daschl: you need it because thats what the JIT uses |
| 16:20:16 | brixen | daschl: we have a bunch of prebuilts and it will build from source if it needs to |
| 16:20:24 | brixen | daschl: just run ./configure and let it do its thing |
| 16:20:53 | daschl | ah i see.. maybe (on my ubuntu) box a aptitude install llvm will have done the trick too? |
| 16:21:02 | evan | daschl: it might |
| 16:21:13 | brixen | daschl: you probably cannot use what it installs |
| 16:21:26 | brixen | daschl: what ubuntu? |
| 16:21:30 | evan | daschl: but if you want, give it a shot. |
| 16:21:35 | daschl | 10.4 |
| 16:21:35 | evan | it might not work |
| 16:21:53 | daschl | its ok for me if configure does the trick :> |
| 16:22:04 | daschl | just want to explore rubinius |
| 16:22:07 | evan | daschl: could you run "apt-cache show <llvm>" |
| 16:22:11 | evan | and gist that output? |
| 16:22:19 | daschl | sure! |
| 16:22:19 | evan | if some linux distros have LLVM |
| 16:22:29 | evan | we should do some testing to see which distros can use their LLVM packages |
| 16:22:34 | brixen | daschl: we have a prebuilt that works fine for 10.04 |
| 16:22:49 | daschl | i want to build it from source to learn it :> |
| 16:22:50 | brixen | daschl: it takes just a minute to download and unpack it |
| 16:23:02 | daschl | learned linux through gentoo too ;) |
| 16:23:05 | evan | daschl: using the prebuilt is best. |
| 16:23:06 | brixen | daschl: the prebuilt is for llvm, you're still building from the source |
| 16:23:18 | brixen | daschl: read doc/getting_started.txt |
| 16:23:42 | daschl | evan, here you are http://gist.github.com/443852 |
| 16:23:51 | brixen | daschl: if you want to compile llvm from source, ./configure --skip-prebuilt |
| 16:24:10 | evan | daschl: we can't use that anyway |
| 16:24:12 | evan | thats 2.7 |
| 16:24:13 | daschl | brixen, jeah i've tried that but got an error so i ran ./configure |
| 16:24:17 | evan | i'm working on the upgrade to 2.7 |
| 16:25:38 | daschl | ok it seems with ./configure && rake it works "out of the box" :) |
| 16:25:41 | brixen | daschl: tried what exactly nd got what error? |
| 16:26:34 | daschl | brixen, tried again, now there is no error (maybe because ./configure installed the llvm stuff for me?) |
| 16:26:46 | brixen | man, I have no idea |
| 16:26:49 | brixen | what did you try |
| 16:26:52 | brixen | exactly? |
| 16:27:37 | daschl | git clone, cd rubinius, ./configure --skip-prebuilt |
| 16:27:42 | daschl | but im sure i have it in my logs sec. |
| 16:27:54 | daschl | oh not anymore |
| 16:35:15 | daschl | hey tests passing *hooray* thanks guys for helping out |
| 16:35:22 | brixen | yay! |
| 16:43:35 | daschl | brixen, when i change a line of code in an .rb file of rubinius, do i have to recompile it? |
| 16:45:58 | brixen | if you change a .rb in kernel, you need to run rake build |
| 16:46:12 | brixen | if it's in lib or one of your own files, rbx recompiles automatically |
| 16:47:41 | brixen | arg, why am I getting a symbol not found now when I built this thing 50 times yesterday |
| 16:48:14 | daschl | is there some documentation online about the architecture of the code? where is a good "starting point"? :) i tried to find rbx.rb ;) |
| 16:48:41 | brixen | did you read the stuff in doc/*.txt ? |
| 16:49:09 | daschl | maybe i should read all that first before asking again :D thanks |
| 16:49:09 | brixen | tell me more about yourself and I'll tell you a good starting point |
| 16:49:38 | brixen | yeah, you might start with doc/table_of_contents.txt :) |
| 16:50:00 | daschl | ok thanks for now ill dig into that and come back then :> |
| 16:50:05 | brixen | ok |
| 17:03:04 | brixen | 2 successful builds down, 3 to go |
| 17:03:20 | brixen | my poor computer |
| 17:11:10 | evan | hehe |
| 17:13:04 | toulmean | hey guys, I'm trying to play with usb, and ruby-usb is a pain to install. I finally got it to compile and behave, but it fails loading at runtime. |
| 17:13:16 | toulmean | did someone try to do anything with ruby-usb with rubinius ? |
| 17:14:12 | evan | not that i'm aware of |
| 17:14:14 | evan | whats ruby-usb? |
| 17:14:57 | daschl | may i run rake without the testing after compiling? |
| 17:15:20 | evan | rake build |
| 17:15:23 | evan | will just build and not test. |
| 17:15:36 | daschl | thanks :) |
| 17:17:57 | evan | brixen: thoughts on LookupTable not converting a String to a Symbol? |
| 17:18:01 | evan | we've never really used that |
| 17:18:53 | brixen | hmm |
| 17:19:20 | evan | I want to really treat LookupTable as an IdentityHash |
| 17:19:49 | brixen | don't we use strings in the platform conf |
| 17:20:00 | brixen | what do you mean by not converting a String to a Symbol? |
| 17:20:08 | evan | look in lookuptable.cpp |
| 17:20:12 | evan | the key_to_sym macro |
| 17:20:13 | brixen | redefine key_to_sym() ? |
| 17:20:15 | brixen | yeah |
| 17:20:18 | evan | just don't call it. |
| 17:20:22 | evan | remove that macro entirely |
| 17:20:38 | brixen | so strings are raw references in a LT? |
| 17:20:48 | toulmean | evan: ruby-usb is just a binding to discuss with the ruby interface of your machine |
| 17:20:59 | toulmean | sorry with the usb interface |
| 17:21:17 | toulmean | so you can send low level signals to your usb ports. |
| 17:21:20 | evan | brixen: yeah |
| 17:21:27 | evan | we never put Strings in a LookupTable anyways |
| 17:21:29 | evan | that I can tell. |
| 17:21:34 | brixen | toulmean: what do you mean by "fails loading at runtime" ? |
| 17:21:47 | toulmean | brixen: it uses dylib |
| 17:21:59 | toulmean | dyld |
| 17:22:01 | toulmean | dyld: Symbol not found: _usb_init |
| 17:22:01 | toulmean | Referenced from: /Library/Ruby/Site/1.8/universal-darwin10.0/usb.bundle |
| 17:22:01 | toulmean | Expected in: flat namespace |
| 17:22:18 | toulmean | you know. Some kind of after the fact error. |
| 17:22:36 | brixen | toulmean: where's the source, I'll look at it |
| 17:23:01 | toulmean | brixen: I forked it yesterday: http://github.com/atoulme/ruby-usb |
| 17:23:10 | toulmean | let me commit a few changes I found in a blog post. |
| 17:24:22 | toulmean | brixen: ok committed. |
| 17:24:47 | toulmean | brixen: I took the original source code and modified it as pointed at here: http://www.jedi.be/blog/2009/11/11/ruby-usb-libusb/ |
| 17:25:18 | toulmean | so the current source code assumes libusb-compat is installed with macports. The current source code only works with mac. |
| 17:25:25 | brixen | evan: well, if we don't use it, I can't see it mattering if we change it |
| 17:25:32 | evan | ok |
| 17:25:34 | evan | i might leave it |
| 17:25:39 | evan | just musing and tuning. |
| 17:25:42 | brixen | I'm sure we did put strings in LT's at one point |
| 17:25:49 | brixen | since I wrote that on purpose |
| 17:26:05 | evan | i figured there was a reason at some point |
| 17:27:01 | brixen | it seems like we could just use a Hash if we needed |
| 17:27:42 | brixen | although Hash isn't functional by the time eg kernel/platform is loading |
| 17:31:20 | toulmean | brixen: to give you some context, I got this for my bday: http://www.pixmania.ie/ie/uk/4654883/art/no-name/i-buddy-devil-usb-desktop.html |
| 17:31:40 | toulmean | brixen: it can be controlled via usb with python or ruby, some people hacked into it. |
| 17:32:00 | brixen | ah cool |
| 17:32:20 | evan | heheh |
| 17:32:22 | brixen | well, it would seem that it's not linking correctly |
| 17:32:23 | toulmean | brixen: if you want one, I can get one for you when I'm back in Europe this summer. |
| 17:32:38 | toulmean | as a reward for all the help you guys pulled. |
| 17:32:47 | brixen | toulmean: aww that's so sweet of you and all... but I'll pass :D |
| 17:33:01 | toulmean | now I need to be sure it was a nice gift. |
| 17:33:03 | toulmean | yeah :) |
| 17:33:04 | toulmean | ok |
| 17:33:36 | brixen | toulmean: you said you installed libusb from macports? |
| 17:33:43 | toulmean | yes. |
| 17:33:47 | toulmean | and libusb-compat |
| 17:33:47 | brixen | k |
| 17:34:57 | toulmean | brixen: of course libusb-compat real interest is usb.h, installed under /opt/local/include/usb.h |
| 17:35:03 | toulmean | I guess that file changed. |
| 17:35:04 | toulmean | maybe. |
| 17:35:24 | brixen | I don't get a libusb-compat in macports |
| 17:35:30 | brixen | libusb installed though |
| 17:35:53 | toulmean | you don't ? can you see usb.h in the contents of libusb ? |
| 17:36:02 | toulmean | port contents libusb |
| 17:37:30 | brixen | I just did sudo port install libusb |
| 17:37:47 | brixen | then cloned, cd'd, rbx extconf.rb; make; make install |
| 17:38:11 | brixen | I get a different error though on require 'usb': Symbol not found: _st_add_direct |
| 17:38:21 | toulmean | sweet... |
| 17:38:28 | toulmean | oh well. |
| 17:39:00 | toulmean | I have seen a reference to a st.h |
| 17:39:04 | brixen | hm, why doesn't install install usb.rb ? |
| 17:39:14 | brixen | yeah, it's doing some st maddness |
| 17:39:17 | brixen | but I could patch that |
| 17:39:30 | toulmean | have_header("ruby/st.h") |
| 17:39:33 | toulmean | ok. |
| 17:39:47 | brixen | and usb.rb requires 'usb.so' <rolleyes> |
| 17:40:28 | brixen | toulmean: I'll play with this a bit after I push the build stuff I'm doing |
| 17:42:26 | brixen | 3 builds down, 2 to go |
| 17:48:35 | evan | woop! |
| 17:48:42 | boyscout | Improve LookupTable, PackedObject, and Object.get_ivar perf - 0f068f5 - Evan Phoenix |
| 17:48:43 | boyscout | Enable gc.autopack by default - e92fc82 - Evan Phoenix |
| 17:48:58 | evan | on spec/ruby/core, it's the same speed. |
| 17:49:10 | evan | seems to be a little slower on the library specs, but they have a lot of wobble in them |
| 17:49:12 | evan | so it's hard to tell |
| 17:49:17 | brixen | yeah |
| 17:49:19 | evan | thusly, i'm turning autopack on by default. |
| 17:49:24 | brixen | ok |
| 17:49:57 | brixen | you should compare compiling lib or something |
| 17:50:14 | brixen | since the compiler uses a lot of ivars and is pure ruby |
| 17:53:04 | evan | ok |
| 17:54:39 | evan | brixen: on a trivial eval benchmark |
| 17:54:46 | evan | eval("a = 1") |
| 17:54:57 | evan | autopacked is 1.9s, nonpacking is 2.3s |
| 17:55:07 | evan | the saved time is purely in allocation/gc |
| 17:55:33 | brixen | cool |
| 17:57:34 | toulmean | brixen: don't break your back over it. It's really just twiddling. |
| 17:57:57 | bcg | evan: looks like in bignum.cpp I could expose big->mp_val()->sign to help MsgPack build but Im wondering if this should be handled another way? Here's what MsgPack wants to do: http://pastie.org/1010228 |
| 17:58:27 | evan | bcg: oh weird. |
| 17:58:28 | brixen | ack! I thought rvm fixed the gem env stuff |
| 17:58:37 | evan | bcg: sure, you can expose the sign |
| 17:58:42 | evan | bcg: put it behind a function |
| 17:58:48 | evan | and call the function from the macro |
| 17:58:57 | brixen | evan: http://gist.github.com/443976 |
| 17:59:10 | evan | UG |
| 17:59:11 | evan | wtf. |
| 17:59:14 | evan | ask wayneeseguin |
| 17:59:19 | brixen | k |
| 17:59:49 | evan | oh |
| 17:59:56 | evan | no, rvm didn't change this |
| 18:00:02 | evan | it's still exporting GEM_HOME |
| 18:00:05 | bcg | evan: k, thanks ... |
| 18:00:13 | evan | you have to run some rvm command to have it unset those env vars. |
| 18:00:37 | brixen | well, were do we fix it |
| 18:00:41 | brixen | it should not be this way |
| 18:00:57 | evan | thats the thing |
| 18:00:59 | evan | there is no fix. |
| 18:01:04 | evan | rvm sets GEM_HOME |
| 18:01:09 | evan | and we respect that |
| 18:01:21 | evan | I guess we could detect the GEM_HOME for another interpreter |
| 18:01:23 | evan | and blow up |
| 18:01:27 | brixen | that's going to be a huge problem |
| 18:01:35 | brixen | there has to be a sensible fix |
| 18:01:37 | evan | it's been this way for a long time. |
| 18:01:48 | evan | so it's been a problem. |
| 18:04:11 | wayneeseguin | evan: issue? |
| 18:04:55 | brixen | wayneeseguin: same one we're discussing |
| 18:04:55 | evan | wayneeseguin: the whole GEM_HOME issue. |
| 18:05:04 | evan | if you use rbx with rvm still active |
| 18:05:07 | evan | it fucks things up |
| 18:05:15 | evan | where rbx was not built inside rvm |
| 18:05:39 | evan | because GEM_HOME points to whatever the current rvm interp is |
| 18:05:54 | evan | is there a way to not use GEM_HOME? |
| 18:06:19 | wayneeseguin | evan: During the install or .. ? |
| 18:06:25 | evan | at runtime. |
| 18:06:28 | wayneeseguin | Normal usage requires GEM_HOME to be set |
| 18:06:30 | brixen | wayneeseguin: this is not during any install |
| 18:06:38 | evan | brixen: run 'env | grep GEM_HOME' and show the output |
| 18:06:47 | evan | wayneeseguin: why? |
| 18:07:05 | evan | it causes such havoc if you try and use an ruby runtime outside rvm then |
| 18:07:10 | wayneeseguin | For gems & bundler to be respecting the correct gem homes |
| 18:07:25 | wayneeseguin | evan: ok I'm quite confused at what your saying currently. |
| 18:07:36 | wayneeseguin | evan: if you want something outside rvm, you do 'rvm use system ; rbx gem env ' |
| 18:07:42 | brixen | wayneeseguin: so, here's the steps |
| 18:07:46 | wayneeseguin | eg 'rvm use system' => deactivate rvm |
| 18:07:50 | evan | right |
| 18:07:56 | evan | people forget the rvm use system |
| 18:07:57 | evan | a lot. |
| 18:07:59 | evan | it seems. |
| 18:08:03 | brixen | rvm use x; cd rubinius; rake; bin/rbx gem install foo |
| 18:08:06 | brixen | => BOOM |
| 18:08:10 | evan | brixen: right |
| 18:08:13 | evan | you have to deactivate rvm |
| 18:08:20 | evan | is what wayneeseguin is saying |
| 18:08:30 | brixen | wayneeseguin: it's fairly hidden that you have to rvm use system |
| 18:08:35 | wayneeseguin | basically when it comes to system rubies RVM is 'hands off' so it unsets all of its stuff |
| 18:09:05 | wayneeseguin | brixen: I'm open to suggestions... that's not exactly a trivial issue since it's kind of 'user training' |
| 18:09:14 | brixen | wayneeseguin: yep, I'm seeing that |
| 18:09:16 | wayneeseguin | I can hijack the rbx command :) |
| 18:09:20 | brixen | I just wish there was a way it was not hidden |
| 18:10:20 | evan | brixen: well |
| 18:10:24 | evan | we could add the detection |
| 18:10:37 | evan | to try and see that rbx is pointed to a bad GEM_HOME |
| 18:10:46 | brixen | yeah |
| 18:11:04 | evan | wayneeseguin: you do that because you use a different gem dir that rubygems would normally use, yes? |
| 18:11:08 | wayneeseguin | interesting... how would you 'detect' that ? |
| 18:11:11 | evan | s/that/than/ |
| 18:11:28 | wayneeseguin | evan: correct, RVM sets a gem dir per interpreter AND gem dir's per project |
| 18:11:29 | evan | why is that? what dir does rubygems want to use? |
| 18:11:34 | wayneeseguin | depending on what the user wants to do |
| 18:11:49 | wayneeseguin | usually ~/.gem/ and/or some F'd up thing in / |
| 18:12:01 | evan | er |
| 18:12:04 | evan | you don't know? |
| 18:12:16 | evan | it should be using data from rbconfig to figure it out |
| 18:12:20 | evan | if you're installing under .rvm |
| 18:12:20 | wayneeseguin | OSX: - /Library/Ruby/Gems/1.8 |
| 18:12:31 | wayneeseguin | And there is another one in OSX |
| 18:12:38 | wayneeseguin | on Linux it's usually something in /usr/local/... |
| 18:12:41 | evan | then rbconfig should list a dir under .rvm |
| 18:12:44 | brixen | wayneeseguin: we compile in various paths, we could compile in our gem path and warn the user if we are respecting a different GEM_PATH |
| 18:12:51 | evan | thats only if you install it into /usr/local |
| 18:12:57 | evan | you're installing them into ~/.rvm/ |
| 18:12:57 | wayneeseguin | .rvm for user install and rvm for root install |
| 18:13:03 | wayneeseguin | ~/.rvm/ or /usr/local/rvm/ |
| 18:13:13 | evan | right, so it should be using paths under there. |
| 18:13:25 | wayneeseguin | correct |
| 18:13:25 | wayneeseguin | yes |
| 18:13:36 | evan | so why not let it use what it wants and not set GEM_HOME |
| 18:13:39 | wayneeseguin | (unless the user configures it differently but that's a whole otheer level of... fun) |
| 18:13:55 | wayneeseguin | You've lost me again. |
| 18:14:06 | evan | ok |
| 18:14:11 | wayneeseguin | One of the biggest use cases for RVM is 'gemsets': http://rvm.beginrescueend.com/gemsets/ |
| 18:14:23 | wayneeseguin | If I leave it up to the 'system' or 'ruby' then that is lost |
| 18:14:50 | evan | ok |
| 18:14:54 | evan | i'll trust ou. |
| 18:14:55 | evan | you. |
| 18:14:58 | wayneeseguin | People usually use gemsets + project rvmrc files to bootstrap their envs ( http://rvm.beginrescueend.com/workflow/rvmrc/#project ) |
| 18:15:14 | wayneeseguin | eg. 'cd $project_root' => oh look, my environment is all setup for me! |
| 18:15:28 | evan | here is an option. |
| 18:15:37 | evan | export GEM_HOME as RVM_GEM_HOME |
| 18:15:45 | evan | and then, at some phase, mutate it back to GEM_HOME |
| 18:15:51 | evan | that phase could be a couple of places |
| 18:16:12 | evan | 1) compile a tiny C program that changes the env var and executes the real interpreter |
| 18:16:27 | evan | 2) have rvm add a few lines to the top of rubygems.rb |
| 18:17:29 | wayneeseguin | We are actually effectively doing both 1 & 2 already for other interpreters |
| 18:17:39 | brixen | wayneeseguin: do you know about this one: rvm reset; irb has the old prompt still |
| 18:17:44 | wayneeseguin | 1) is more a bash that does 'exec' |
| 18:17:57 | wayneeseguin | brixen: no didn't likely missed the IRBRC |
| 18:18:22 | evan | wayneeseguin: well, no |
| 18:18:33 | wayneeseguin | brixen: I've added a story for that thanks |
| 18:18:37 | evan | 1) doesn't work because you can't have a shebang point to a shell script in some cases. |
| 18:18:39 | brixen | wayneeseguin: ok, thanks |
| 18:18:40 | evan | as I recall. |
| 18:18:58 | wayneeseguin | that's correct |
| 18:19:07 | wayneeseguin | so it usually looks like this: |
| 18:19:09 | wayneeseguin | #!/usr/bin/env bash |
| 18:19:11 | wayneeseguin | <<setup env>> |
| 18:19:17 | evan | ah |
| 18:19:19 | evan | so in that thing |
| 18:19:20 | wayneeseguin | exec rbx "@args" |
| 18:19:20 | evan | do |
| 18:19:29 | evan | export GEM_HOME = RVM_GEM_HOME |
| 18:19:33 | evan | then we'll all be very happy |
| 18:19:41 | evan | because unless you run via that trampoline script |
| 18:19:49 | evan | another interp won't see that setting |
| 18:20:31 | wayneeseguin | Something is nagging in my thoughts about this however... I need to give it some more thought |
| 18:20:43 | wayneeseguin | There are several reasons that GEM_HOME is being exported |
| 18:21:14 | evan | sure |
| 18:21:45 | evan | the issue is clearly that rvm sets GEM_HOME expecting no one outside of rvm's control will read it |
| 18:21:51 | wayneeseguin | Other programs and scripts rely on it for integration for one that I can think. |
| 18:21:55 | evan | rather than just hope thats the case |
| 18:21:57 | wayneeseguin | correct |
| 18:22:06 | evan | lets figure out how to make it the case. |
| 18:22:19 | evan | which other scripts? |
| 18:22:38 | evan | only stuff that runs via a ruby, and thusly would be launched via your trampoline script, can care. |
| 18:22:39 | wayneeseguin | JetBrains |
| 18:22:47 | wayneeseguin | Some TextMate Plugins |
| 18:22:53 | wayneeseguin | Some Emacs Plugins |
| 18:23:07 | wayneeseguin | there are several 3rd party integration things built up around it |
| 18:23:14 | evan | well fuck. |
| 18:23:25 | wayneeseguin | My thoughts exactly :-p |
| 18:23:45 | wayneeseguin | Some of the recent refactorings make altering it for RVM side very easy |
| 18:26:20 | brixen | man I hate RHASH :( |
| 18:26:42 | brixen | evan: to do the function that warns approach, we'd need a fake struct for RHASH |
| 18:26:50 | brixen | since usage is RHASH(o)->tbl |
| 18:26:54 | evan | yeah |
| 18:26:57 | evan | thats why i never bothered |
| 18:27:06 | brixen | well, I can bother if you don't mind |
| 18:27:11 | evan | i just put some junk shot in the header file |
| 18:27:12 | evan | and let it blow up |
| 18:27:26 | brixen | except the blow up is inscrutable |
| 18:27:36 | brixen | thanks of course to gcc's brilliant error messages |
| 18:28:00 | evan | right |
| 18:28:01 | brixen | well, effin eff |
| 18:28:06 | evan | if you want |
| 18:28:08 | brixen | I'll just redefine them back to 1 |
| 18:28:15 | evan | the simplest way is to make a static struct |
| 18:28:18 | evan | with those fields |
| 18:28:25 | evan | and have RHASH() return that static struct |
| 18:28:29 | evan | that will make it pass. |
| 18:28:29 | brixen | right |
| 18:28:44 | brixen | yeah, was just checking if you're ok with that |
| 18:29:18 | evan | it's all just trying to tell the user "hey dude, we don't do this" |
| 18:29:24 | evan | so whatever you wanna do. |
| 18:29:27 | brixen | ok |
| 18:39:56 | brixen | evan: where's boyscout CI ? |
| 18:55:26 | bcg | evan: is there a preferred method for defining rubinius in an extension? Is there some sort of -DRBX set I should check for in my ifdef's? |
| 19:02:05 | brixen | bcg: ifdef RUBINIUS |
| 19:04:51 | bcg | brixen: thanks! |
| 19:05:07 | bcg | Ok I got msgpack building now ... thanks guys! |
| 19:07:10 | brixen | sweet! |
| 19:10:38 | aniero | SIGSEGV in an extension! |
| 19:12:13 | brixen | ZOMG ticket! |
| 19:23:28 | evan | brixen: CI looks hung. |
| 19:23:29 | evan | :( |
| 19:23:31 | evan | i'll kick it. |
| 19:39:28 | boyscout | CI: Commit 6f97da0 failed. http://github.com/evanphx/rubinius/commit/6f97da0d24e2a3304534e6ea7c3f538522f04d5b |
| 19:52:39 | boyscout | CI: rubinius: e92fc82 successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 19:58:13 | boyscout | Generalize building with MRI 1.8/1.9 or rbx. - 9465976 - Brian Ford |
| 19:58:13 | boyscout | Silence warnings under 1.9. - d22e12d - Brian Ford |
| 19:58:13 | boyscout | Fix warnings compiling Melbourne ext in 1.9. - 820a881 - Brian Ford |
| 19:58:13 | boyscout | There is no --no-rbc option. Use -Xcompiler.no_rbc. - 3f7e481 - Brian Ford |
| 19:58:13 | boyscout | Force usage of RHASH and RHASH_TBL to cause compile-time syntax errors. - a9d6440 - Brian Ford |
| 20:07:22 | aniero | brixen: i have a stack trace, not sure what else to include |
| 20:08:22 | brixen | aniero: stack trace is great |
| 20:08:27 | brixen | all the steps to get to that too |
| 20:08:45 | aniero | i don't know much about this extension, though :P just that someone i work with wrote it... |
| 20:09:06 | aniero | i'll dig a little bit |
| 20:09:12 | brixen | ok, well I'll need the source probably |
| 20:10:06 | boyscout | CI: rubinius: 051e742 successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 20:10:20 | brixen | yay! |
| 20:10:55 | brixen | so, I've built with 1.8.6, 1.8.7, 1.9.1p378 and 1.9.2preview3 |
| 20:10:59 | brixen | as well as rbx 1.0.1 |
| 20:11:33 | brixen | and boyscout passed |
| 20:11:39 | brixen | so now I'm going to eat lunch |
| 20:12:01 | brixen | wayneeseguin: ^^^ |
| 20:12:36 | brixen | wayneeseguin: rbx master should build with any stable MRI 1.8.6+ and rbx 1.0.1+ |
| 20:13:55 | wayneeseguin | brixen: Very good news. |
| 20:14:09 | wayneeseguin | brixen: I'll file a story so it doesn't get forgotten |
| 20:14:53 | brixen | wayneeseguin: awesome, thanks man! |
| 20:14:59 | wayneeseguin | Absolutely. |
| 20:33:35 | aniero | brixen: aha! bundles were built against MRI, after recompiling them i'm getting a pretty rubinius stack trace |
| 20:33:48 | aniero | brixen: Symbol not found: _rb_require_safe |
| 20:34:33 | evan | aniero: le sigh. |
| 20:34:36 | evan | why use require_safe? |
| 20:34:42 | evan | we just need to alias it to rb_require |
| 20:34:42 | aniero | no idea! |
| 20:36:36 | aniero | i don't know what rb_require_safe is... hmm. |
| 20:36:41 | aniero | not in the pickaxe |
| 20:36:45 | evan | it's just rb_require |
| 20:36:52 | brixen | it probably checks $SAFE |
| 20:36:52 | evan | whatever extension is using it shouldn't |
| 20:37:01 | brixen | oh yeah |
| 20:37:06 | evan | but MRI's ruby.h mixes external API with internal API. |
| 20:37:07 | brixen | it's actually internal |
| 20:37:10 | brixen | yep |
| 20:37:21 | evan | just stub it out. |
| 20:37:24 | evan | to call rb_require |
| 20:37:24 | brixen | aniero: if that's your co-workers ext, tell 'em to fix it! |
| 20:37:32 | aniero | brixen: i have commit privs, i can do it :P |
| 20:37:38 | brixen | do it! :D |
| 20:37:43 | aniero | 1m! |
| 20:37:45 | brixen | heh |
| 20:38:40 | brixen | evan: I gave up on RHASH at runtime |
| 20:38:47 | evan | :D |
| 20:38:51 | evan | thats fine. |
| 20:38:52 | brixen | I made sure it cannot compile without a syntax error |
| 20:38:58 | evan | exactly |
| 20:39:05 | evan | and there is almost now pay off for getting it to work |
| 20:39:28 | brixen | C is just a terrible language, frankly |
| 20:39:47 | aniero | hmm, is _rb_set_kcode internal too? |
| 20:39:49 | brixen | if only someone would work on an alternative... :P |
| 20:40:09 | brixen | aniero: we should add that |
| 20:40:28 | aniero | in the meantime, know how to set it? :) |
| 20:40:29 | evan | aniero: thats 1.9 only. |
| 20:40:37 | aniero | evan: is not! works on 1.8.7! |
| 20:40:43 | evan | ha |
| 20:40:44 | evan | ok |
| 20:40:52 | evan | perhaps it crept in |
| 20:40:53 | aniero | (i'm arguing as if i know what i'm talking about... but it compiles and runs!) |
| 20:40:54 | evan | how are you using it? |
| 20:40:57 | brixen | yeah |
| 20:41:04 | aniero | rb_set_kcode("U"); |
| 20:41:20 | fowlduck | evan: http://gist.github.com/443158 btw |
| 20:41:23 | brixen | it's prototyped in internal.h in 1.8.7 |
| 20:41:30 | fowlduck | pretty sure brixen thinks i'm mad |
| 20:41:37 | aniero | these gems build against 1.8.6 too though... hmm |
| 20:41:39 | brixen | but don't let that internal.h dissuade anyone :) |
| 20:41:57 | aniero | this ext does, i mean |
| 20:41:57 | brixen | fowlduck: is it working well for you? |
| 20:42:15 | fowlduck | brixen: seemed to be last night. i don't have rbx on my work box |
| 20:42:24 | brixen | fowlduck: excellent |
| 20:42:39 | brixen | my favorite way to fix stuff like this, let the user do it :) |
| 20:42:47 | brixen | in their own little world |
| 20:43:29 | evan | fowlduck: that .sub makes my stomach turn. |
| 20:43:32 | brixen | haha |
| 20:43:41 | brixen | I was debating whether to say anything |
| 20:44:04 | evan | dirname was too much trouble? |
| 20:44:05 | brixen | fowlduck: File.dirname(x) + "/." + File.basename(x) |
| 20:44:41 | brixen | anyway, let me reassert loud and clear, I don't want this in rbx :) |
| 20:44:55 | fowlduck | uh, yeah |
| 20:45:12 | evan | yeah dirname was too easy? |
| 20:45:21 | brixen | aniero: is this code public? I can get it running |
| 20:46:56 | aniero | brixen: no, alas |
| 20:47:14 | aniero | brixen: i'm going to try this though, which is what rb_set_kcode (with "U" as a parameter) does, internallY: reg_kcode = KCODE_UTF8 |
| 20:47:26 | brixen | aniero: well, send me an nda and give me access :) |
| 20:47:50 | brixen | aniero: when you build, do you get any warnings about undefined functions? |
| 20:48:00 | fowlduck | yeah, dirname was too easy ;) |
| 20:48:05 | fowlduck | not sure what i was thinking, really |
| 20:49:26 | brixen | aniero: if you edit lib/rbconfig.rb to add -Wall and build the ext, you can give me a list of the C-API functions we haven't impl yet |
| 20:49:42 | brixen | aniero: er add -Wall to CFLAGS |
| 20:53:01 | aniero | brixen: setting reg_kcode doesn't work, btw. lemme do -Wall |
| 20:53:13 | aniero | er, where do i add that to CFLAGS? |
| 20:53:26 | brixen | rbx lib/rbconfig.rb line 112 |
| 20:53:38 | brixen | then rebuild your ext |
| 20:53:41 | aniero | ok, 1sec |
| 20:53:48 | brixen | but do a make clean in your ext first |
| 20:55:08 | aniero | brixen: cleaner.rl:185: warning: implicit declaration of function ‘rb_set_kcode’ |
| 20:55:22 | brixen | aniero: ok, so that's the only one? |
| 20:55:25 | aniero | brixen: that's all i see as far as errors/warnings go |
| 20:55:30 | aniero | and that's with -Wall |
| 20:55:30 | brixen | sweet |
| 20:55:33 | brixen | ok |
| 20:57:08 | aniero | oh, of course i can't set reg_kcode, it's static int |
| 20:57:37 | brixen | yeah |
| 21:05:13 | tarcieri | aniero: ohai! |
| 21:06:12 | tarcieri | heh, wtf... |
| 21:06:13 | tarcieri | this is so weird |
| 21:06:42 | tarcieri | (in /Users/tony/src/gems/models) |
| 21:06:42 | tarcieri | rake aborted! |
| 21:06:42 | tarcieri | no such file to load -- /Users/tony/src/gems/models/lib/medioh/models.rbc |
| 21:06:50 | tarcieri | ^^^ that's MRI... getting confused about a .rbc file |
| 21:07:15 | aniero | tarcieri: haha sup |
| 21:07:19 | brixen | tarcieri: you are likely requiring something like * |
| 21:07:21 | aniero | brixen: trying something else as a workaround |
| 21:07:34 | brixen | aniero: I'm working on implementing it |
| 21:07:52 | brixen | aniero: why isn't it set in the .rb file that loads the ext? |
| 21:08:02 | brixen | aniero: IOW, is there a reason it needs to be set from C? |
| 21:08:06 | aniero | probably not! |
| 21:08:11 | aniero | this is the first i've looked at this code |
| 21:08:15 | brixen | ok |
| 21:08:35 | brixen | well, generally things defined in MRI internal.h should probably be considered internal |
| 21:08:37 | aniero | erk! more errors with another extension |
| 21:08:40 | aniero | np |
| 21:08:45 | brixen | if only that were ever respected, ever :) |
| 21:08:48 | aniero | even rb_str_new2? |
| 21:09:02 | brixen | that's the thing |
| 21:09:03 | evan | eh? |
| 21:09:18 | brixen | MRI has done a terrible job of segregating its API |
| 21:09:22 | tarcieri | heh |
| 21:09:25 | evan | tarcieri: something is glob requiring everything in a directory |
| 21:09:27 | brixen | so we implement whatever we can and need to |
| 21:09:28 | evan | rather than just *.rb in a directory |
| 21:09:32 | tarcieri | evan: yeah found it, heh... wtf |
| 21:09:46 | tarcieri | looks like a stupid glob |
| 21:09:48 | tarcieri | at fault, too! |
| 21:09:51 | brixen | hah |
| 21:10:57 | tarcieri | needs to rewrite require_all completely differently |
| 21:11:31 | brixen | evan: ok to define rb_set_kcode like this or do you want to rb_funcall to the Rubinius method? http://gist.github.com/444237 |
| 21:11:33 | tarcieri | calculate the dependency order ahead of time, dump that out to a file which does the requires in the proper order |
| 21:13:03 | evan | brixen: thats fine. |
| 21:13:08 | brixen | k |
| 21:13:15 | aniero | brixen: ok, i fixed that one |
| 21:13:21 | aniero | rb_gv_set("KCODE", rb_str_new2("U")); |
| 21:13:28 | brixen | aniero: that works too |
| 21:13:31 | aniero | brixen: but i'm getting other errors now too. looking into those now... |
| 21:13:40 | aniero | there's three extensions in this gem, i'm doing one at a time :) |
| 21:13:50 | tarcieri | :( @ native extensions |
| 21:13:51 | brixen | evan: want to leave rb_set_kcode out or add it? |
| 21:14:06 | evan | add it. |
| 21:14:09 | evan | it's fine. |
| 21:14:09 | brixen | aniero: just use the -Wall trick and let me know what rb_x are missing |
| 21:14:13 | brixen | evan: ok |
| 21:15:12 | aniero | brixen: will do! |
| 21:17:11 | aniero | brixen: ok, couple more functions to look into: ismbchar and mbclen |
| 21:17:25 | aniero | brixen: i'm not sure if those are ruby or ours |
| 21:18:36 | aniero | brixen: ok, ismbchar comes from regex.h, as does mbclen |
| 21:18:43 | brixen | ugh man |
| 21:18:50 | brixen | what does this ext do? |
| 21:18:52 | aniero | 1.8.7p174 lines 103 and 104, they're macros |
| 21:19:10 | aniero | cleans bad unicode text, far as i can tell from the specs. ragel stuff. |
| 21:19:27 | brixen | and it can't do that in ruby? |
| 21:20:11 | tarcieri | did that in Ruby... |
| 21:20:18 | aniero | ah, cleans html tags too |
| 21:20:19 | brixen | our regexp looks nothing like MRI's in 1.8.x |
| 21:20:21 | tarcieri | with iconv |
| 21:20:48 | aniero | and does utf8-aware string truncation |
| 21:20:54 | aniero | that bit's done in ruby i think |
| 21:22:04 | brixen | aniero: well, to support that, it's going to need to use a function API |
| 21:22:09 | aniero | brixen: i'm sure some of this can be redone in ruby, it's just One Of Those Things that exists at the base level of our gem infrastructure and gets used all over the place... :) |
| 21:22:13 | aniero | brixen: what do you mean? |
| 21:22:14 | brixen | our data in general looks nothing like MRI's |
| 21:22:35 | brixen | you can't just go twiddling the inside of some C array in an ext |
| 21:22:47 | aniero | mm. |
| 21:22:59 | brixen | rbx regexp engine is oniguruma |
| 21:23:38 | brixen | sorry, we support as much craziness as we can in C ext, but there are some limits :) |
| 21:24:04 | brixen | whoever authored that software hates america and kitties |
| 21:24:06 | brixen | basically |
| 21:24:09 | brixen | is the take away :) |
| 21:24:17 | aniero | or didn't know better at the time? it's tim pease who wrote it :P |
| 21:24:25 | aniero | and, once he's back online, i'm going to give him hell for it |
| 21:25:07 | aniero | but anyway, i can extract these bits into another gem (and it installs anyway) so i can test the rest of the libraries against rbx |
| 21:25:08 | brixen | well, anyone who opens a .c file in their editor and thinks mucking with the internal of another system is sane is a little like the guy who gets behind a wheel drunk |
| 21:25:16 | brixen | not knowing is not an excuse |
| 21:25:36 | brixen | but, we can help you sanitize it! :) |
| 21:26:18 | brixen | too bad there's not a general lib for sanitizing text and html tags |
| 21:26:24 | brixen | everyone seems to roll their own |
| 21:26:28 | aniero | sounds like it time to write one |
| 21:26:34 | brixen | haha |
| 21:26:38 | aniero | or extract this one, fix it up nice, and release it |
| 21:26:44 | brixen | good idea! |
| 21:26:59 | brixen | can you see if the source can be OSS'd? |
| 21:27:13 | evan | mbclen and ismbchar we have |
| 21:27:18 | evan | we can make those available |
| 21:27:29 | evan | because I duplicated the kcode setup from 1.8 |
| 21:27:43 | brixen | yeah |
| 21:27:43 | aniero | there's no official policy, i can extract it and release it as long as there's no secret sauce |
| 21:27:50 | brixen | but do we want to make them available? |
| 21:27:59 | brixen | aniero: ok, that's cool |
| 21:28:51 | aniero | thanks for the help! first real foray into anything ruby+c |
| 21:28:52 | brixen | we have kcode::mbchar_p and kcode::mbclen that we could wrap up |
| 21:29:41 | brixen | aniero: n/p thanks for taking a go at it |
| 21:30:00 | evan | brixen: since we've got them |
| 21:30:11 | evan | and it's not too hard to make them available |
| 21:30:16 | evan | might as well. |
| 21:30:18 | brixen | ok |
| 21:31:21 | aniero | how does 1.9's C api compare to 1.8? |
| 21:31:39 | evan | about the same |
| 21:31:42 | evan | a few new things |
| 21:31:44 | evan | thats it. |
| 21:31:50 | aniero | ah cool, ok |
| 21:31:59 | aniero | so if i get this building against rbx, then i oughta be (mostly) alright for 1.9 |
| 21:34:05 | aniero | whoa, just got another SEGV. possibly caused by the bunk extensions i just installed, but should i see those .dylibs in the stack trace? |
| 21:34:20 | evan | aniero: maybe, maybe not |
| 21:34:26 | evan | lets see the stack trace |
| 21:34:50 | aniero | https://gist.github.com/63269737e7ce4444f224 |
| 21:35:18 | evan | you crashed the VM |
| 21:35:20 | evan | not the extension |
| 21:35:27 | evan | thats why it's not listed. |
| 21:35:30 | aniero | neat! |
| 21:41:28 | aniero | oh cool, i put a puts in the code to see if i could find out what was breaking, and i got an entirely different and spectacular explosion |
| 21:41:37 | brixen | haha |
| 21:41:41 | brixen | spectacular |
| 21:42:17 | jarib | brixen: ./configure assumes lsb_release exists (on linux) |
| 21:42:30 | brixen | jarib: ahh indeed it does |
| 21:42:37 | brixen | jarib: I can protect that |
| 21:42:50 | jarib | cool |
| 21:42:56 | brixen | jarib: what linux are you using that's not lsb compliant? |
| 21:42:59 | jarib | arch |
| 21:43:01 | evan | where is lsb_release? |
| 21:43:06 | brixen | jarib: ahhh |
| 21:43:06 | evan | oh arch. |
| 21:43:17 | brixen | has no nice feelings for archlinux |
| 21:43:20 | evan | i still get get why it's popular. |
| 21:43:24 | brixen | none whatsoever |
| 21:43:24 | evan | don't get, rather. |
| 21:43:31 | jarib | i heard 1.9 building support was in |
| 21:43:39 | brixen | jarib: yes, should be |
| 21:44:07 | brixen | jarib: curious, why do you use archlinux? |
| 21:44:29 | aniero | brixen: https://gist.github.com/f2868f6be117b4aa00ad nokogiri's involved somehow, i presume, due to libxml involvement |
| 21:44:58 | jarib | brixen: basically just wanted to try something new and lightweight on my netbook |
| 21:45:13 | brixen | jarib: ok |
| 21:45:15 | evan | aniero: perhaps... |
| 21:45:20 | evan | i've not seen that before. |
| 21:45:55 | jarib | so far i quite enjoy the rolling release / bleeding edge thing as well |
| 21:45:57 | boyscout | C-API specs for rb_set_kcode. - c301c97 - Brian Ford |
| 21:45:57 | boyscout | Added rb_set_kcode. - 1501b63 - Brian Ford |
| 21:47:42 | jarib | i don't seem to have lsb_release on my ubuntu server machine either though |
| 21:48:03 | evan | nor do I |
| 21:48:07 | evan | where is lsb_release? |
| 21:49:28 | tarcieri | /etc |
| 21:49:34 | evan | i thought so |
| 21:49:44 | evan | it's not there on elle, which is an debian unstable machine |
| 21:49:45 | tarcieri | well, there's /etc/lsb-release |
| 21:50:01 | tarcieri | and the "lsb_release" command |
| 21:50:18 | evan | yeah, nope, not there. |
| 21:50:22 | tarcieri | which should be in /usr/bin |
| 21:50:42 | tarcieri | lsb_release is in the "lsb-release" package |
| 21:50:55 | tarcieri | how confusing |
| 21:51:01 | tarcieri | underscores or dashes, pick one motherfucker! |
| 21:51:16 | evan | hah |
| 21:52:02 | evan | elle :: ~> lsb_release |
| 21:52:02 | evan | No LSB modules are available. |
| 21:52:03 | evan | :/ |
| 21:52:09 | tarcieri | heh |
| 21:52:10 | jarib | tarcieri: at least that's better than rubygems-update and update_rubygems |
| 21:52:11 | evan | not sure thats what i expected to see. |
| 21:52:21 | tarcieri | just cat /etc/lsb-release |
| 21:52:22 | tarcieri | *shrug* |
| 21:52:26 | evan | not there. |
| 21:52:30 | tarcieri | unf |
| 21:53:16 | evan | wtf. |
| 21:53:25 | evan | lsb depends on a whole bunch of desktops tuff |
| 21:53:33 | evan | Depends: lsb-core, lsb-graphics, lsb-cxx, lsb-desktop |
| 21:53:34 | brixen | ugh |
| 21:53:43 | brixen | that's ridiculous |
| 21:53:45 | evan | so it's probably not on most server machines. |
| 21:54:11 | tarcieri | heh |
| 21:54:22 | brixen | well, I can check various things then |
| 21:54:25 | brixen | /etc/issue |
| 21:54:32 | brixen | what else |
| 21:54:37 | brixen | linux is such a cluster fuck |
| 21:54:48 | tarcieri | yep |
| 21:55:14 | boyscout | CI: rubinius: 1501b63 successful: 3456 files, 13603 examples, 41167 expectations, 0 failures, 0 errors |
| 21:55:23 | evan | elle :: ~> cat /etc/debian_version |
| 21:55:23 | evan | lenny/sid |
| 21:55:47 | brixen | oh nice, debian_version |
| 21:55:52 | brixen | *roll eyes* |
| 21:56:25 | brixen | it's got /etc/issue though |
| 21:59:58 | brixen | actually, just looking at /etc/issue might be reasonable |
| 22:00:02 | brixen | even fedora 8 has that |
| 22:00:35 | brixen | every ridiculous one has some funky format though |
| 22:00:40 | evan | /etc/issue is old old |
| 22:00:42 | evan | so yeah |
| 22:00:43 | evan | but yeah |
| 22:00:45 | evan | it's unformatted |
| 22:00:50 | brixen | which is why lsb_release -irs was so nice |
| 22:00:54 | brixen | weeps |
| 22:01:01 | brixen | this is why we can't have nice things |
| 22:01:02 | evan | so do this |
| 22:01:14 | evan | use lsb_release, otherwise use the first word of /etc/issue |
| 22:01:20 | evan | and be done with it. |
| 22:01:31 | brixen | first word of that on f8 is Fedora |
| 22:01:37 | brixen | so, yeah, that won't work well |
| 22:01:57 | evan | redhat has /etc/redhat-version |
| 22:01:58 | evan | as I recall. |
| 22:02:02 | brixen | I can envision a really fancy regex though |
| 22:02:07 | evan | no no |
| 22:02:09 | evan | don't parse issue. |
| 22:02:15 | evan | because the user can replace it with anything |
| 22:02:16 | evan | and they do. |
| 22:02:26 | brixen | indeed it does |
| 22:02:44 | brixen | the contents of /etc/redhat-release is the first line of /etc/issue :) |
| 22:02:55 | evan | coincidence |
| 22:03:00 | brixen | sure |
| 22:03:14 | brixen | I'm just saying, redhat-release is the same shit formatted string |
| 22:03:23 | evan | ah. |
| 22:03:26 | brixen | which varies ridiculously on every distro and version |
| 22:03:49 | scoopr | my debian_version has "4.0" as it's contents |
| 22:03:58 | brixen | scoopr: woot :) |
| 22:04:07 | jarib | /etc/<distro>-release seems fairly common |
| 22:04:31 | brixen | jarib: right and the <distro> part of that makes sniffing a bitch |
| 22:04:38 | brixen | fuck, linux |
| 22:05:09 | tarcieri | tweets " |
| 22:05:11 | tarcieri | It's pretty pathetic LSB couldn't decide between underscores and dashes when naming lsb-release, err... lsb_release" |
| 22:05:14 | tarcieri | heh |
| 22:05:20 | tarcieri | way to go, STANDARDS BASE |
| 22:06:06 | jarib | you'd have to maintain a list of distros or look for /etc/(.*)[-_]release |
| 22:06:12 | tarcieri | heh |
| 22:06:29 | jarib | distro = $1 :) |
| 22:07:29 | evan | brixen: search and see if there is a config.guess for linux |
| 22:07:36 | evan | someone must have done this already |
| 22:23:08 | aniero | well, for what it's worth, these extensions don't build on 1.9 either |
| 22:23:24 | evan | oh? what doesn't work? |
| 22:25:08 | brixen | evan: well, the lsb_release is only used for a specific prebuilt |
| 22:25:24 | brixen | the generic prebuilt will just be used if lsb_release isn't available |
| 22:25:31 | brixen | I'm not inclined to fix it now |
| 22:25:39 | brixen | I'll address it with the new build system |
| 22:25:41 | evan | thats fine |
| 22:25:44 | evan | no no |
| 22:25:45 | evan | leave it. |
| 22:25:48 | evan | we've got bigger fish. |
| 22:25:53 | bcg | what do you guys generally do when you run into rb_gc_enable hacks in extensions ... just ifdef them out? |
| 22:26:11 | brixen | bcg: we no-op them |
| 22:26:52 | aniero | evan: error: re.h: No such file or directory |
| 22:27:01 | evan | aniero: yep. |
| 22:28:24 | brixen | interesting, the watches on the rbx repo went from ~580 last week to ~690 now |
| 22:28:51 | evan | nice. |
| 22:28:55 | evan | we're hot! |
| 22:29:11 | brixen | hot tamale |
| 22:29:31 | brixen | must be all the rumors about the -Xzibit flag |
| 22:29:36 | evan | hah |
| 22:29:40 | evan | i'm working on heap dump |
| 22:29:43 | brixen | nice |
| 22:29:48 | brixen | I'm woring on rake doc |
| 22:29:52 | brixen | whoring |
| 22:29:53 | brixen | working |
| 22:29:54 | brixen | something |
| 22:30:00 | evan | why not pack? |
| 22:30:03 | evan | thats more important |
| 22:30:22 | brixen | hmm |
| 22:30:45 | evan | thats basically a blocker atm. |
| 22:30:51 | brixen | blocking what? |
| 22:31:09 | evan | a bunch of performance related thing.s |
| 22:31:11 | brixen | wasting my time answering questions that are in doc/* files is also a blocker |
| 22:31:30 | brixen | what is actually blocked? |
| 22:31:43 | evan | well, we're hitting some bad rails perf because of it |
| 22:31:47 | brixen | there shouldn't be anything that is blocked by pack |
| 22:31:53 | evan | blocker isn't the right thing, it's going past it |
| 22:31:55 | brixen | ok I'll work in it |
| 22:31:57 | evan | but it's of high importance. |
| 22:32:02 | brixen | I know |
| 22:32:08 | brixen | so are the 50 other things |
| 22:44:59 | jarib | brixen: do you want an issue for lsb_release? |
| 23:12:07 | tarcieri | yay awesome backtraces :) |
| 23:12:37 | wayneeseguin | Defiler: around? |
| 23:13:18 | wayneeseguin | Anyone have an idea what this specification error might mean? |
| 23:13:20 | wayneeseguin | http://gist.github.com/444342 |
| 23:13:27 | brixen | jarib: it still configures, right? |
| 23:14:47 | brixen | jarib: lsb is used to see if there's a specific prebuilt for your OS+platform |
| 23:15:07 | brixen | jarib: the generic prebuilt will install if not, or llvm will build from source |
| 23:16:38 | slava | hi brixen |
| 23:18:24 | brixen | hi slava |
| 23:18:48 | wayneeseguin | *nm got it |