Show enters and exits. Hide enters and exits.
| 01:27:17 | toulmean | brixen, evan, I'm trying to install rubinius 1.0.1 on apache infra |
| 01:27:28 | toulmean | unfortunately it fails at that step: |
| 01:27:29 | toulmean | gcc -c -o readline.o -I. -fPIC -I/home/toulmean/rubinius-1.0.1/vm/capi/include -I/usr/include readline.c > /dev/null |
| 01:27:55 | toulmean | because of those errors: readline.c:12:31: error: readline/readline.h: No such file or directory |
| 01:27:56 | toulmean | readline.c:13:30: error: readline/history.h: No such file or directory |
| 01:28:04 | toulmean | I'll attach a full gist |
| 01:30:03 | toulmean | http://gist.github.com/437162 |
| 01:36:25 | toulmean | trying to work around with using jruby -S rake, it sounds like it fails over melbourne as an optional component (mri_bridge something ?) |
| 01:36:37 | toulmean | anyway. Might just be for nothing. |
| 01:37:57 | toulmean | hmf |
| 01:38:03 | toulmean | different errors |
| 01:38:05 | toulmean | http://gist.github.com/437170 |
| 01:40:49 | toulmean | I think I'm stuck for now. If you have insights, feel free to ping me! |
| 01:49:43 | toulmean | it looks like when installing with mri you need this debian package: libreadline5-dev |
| 01:49:46 | toulmean | correct ? |
| 01:54:04 | toulmean | ok looks like I'll need to get those installed from what I read. |
| 02:29:00 | brixen | toulmean: doc/getting_started.txt has all the stuff you need to install on debian/ubuntu |
| 03:57:49 | dkubb | is there a way to transform a Proc into a sexp? |
| 03:58:51 | dkubb | either directly or through a series of steps. the ideal being something like Proc#to_sexp, but I'll take anything at this point :) |
| 04:02:33 | brixen | dkubb: no, there's not |
| 04:02:52 | brixen | there are no sexp in rbx anymore |
| 04:03:24 | dkubb | brixen: ahh ok, is there a way to access the AST at runtime? |
| 04:03:38 | brixen | yes, parse some source code :) |
| 04:03:52 | brixen | Proc#to_sexp is ridiculous imo |
| 04:04:10 | brixen | a consequence of not having the parser be a useful utility |
| 04:04:32 | brixen | look in lib/compiler/compiler.rb for how to do it |
| 04:04:38 | dkubb | brixen: I was thinking of porting an Ambition-like API to rbx and I was looking at how to approach it |
| 04:05:05 | brixen | you can parse some code and get an AST |
| 04:05:44 | dkubb | cool. I just wanted to make sure it was possible before diving in :) |
| 04:08:14 | brixen | dkubb: http://gist.github.com/437262 |
| 04:10:35 | brixen | dkubb: if you are just parsing, look at lib/melbourne.rb actually |
| 04:14:20 | dkubb | brixen: thank you. I'll check this out and see how far I can push it |
| 04:14:27 | brixen | cool |
| 04:14:40 | brixen | you might already know, but melbourne wraps MRI parser |
| 04:15:03 | brixen | but you get a Ruby AST back that the compiler can process, if you need that |
| 04:15:32 | dkubb | my intention was to try to parse stuff like User.all.select { |user| user.id == 1 } into a DM::Query object, which would be transformed into "SELECT * FROM users WHERE id = 1" if executed with a database adapter |
| 04:15:42 | brixen | also, you should check out lib/compiler/ast/transforms.rb |
| 04:15:47 | dkubb | I've done it before with MRI + ParseTree, just wanted to see if I could do it in rbx |
| 04:16:18 | brixen | yeah, that shouldn't be too hard |
| 04:16:43 | dkubb | it's mostly just for fun. no one uses it in production since it's a bit brittle. I still think it's beautiful when I look at it tho :) |
| 04:17:11 | brixen | yeah, AST can be brittle, mostly because MRI never made the AST part of Ruby |
| 04:17:38 | brixen | I'm not a big fan of stuff based on AST transforms b/c it doesn't fit well with the rest of Ruby |
| 04:17:45 | brixen | but if it floats your boat... :) |
| 05:29:31 | kstephens | dkubb: might wanna look at the ambition gem. |
| 05:30:45 | dkubb | kstephens: yeah I have. I ported it to DataMapper a year ago |
| 05:31:19 | dkubb | kstephens: my approach uses the same as Ambition. I use ParseTree and get the sexp for the proc, and then build up a query as I process it |
| 05:32:17 | dkubb | kstephens: although I don't generate SQL directly like Ambition does. I build a DataMapper::Query object that can be used with any DM adapter |
| 05:43:11 | dkubb | kstephens: the challenge will be to figure out an approach that works without access to the Proc at runtime |
| 06:10:55 | kstephens | I was toying around with ParseTree Friday trying to make a generic Ruby macro processor: http://github.com/kstephens/ruby_unify |
| 16:31:59 | evan | morning! |
| 16:32:06 | brixen | morning! |
| 16:32:22 | brixen | how was chi-ca-go? |
| 16:32:29 | evan | fun! |
| 16:32:35 | brixen | nice! |
| 16:33:07 | LeNsTR | ^__^ |
| 16:33:35 | evan | happy to be home though. |
| 16:34:58 | brixen | going to try to get rbx to build on fedora 8 |
| 16:35:00 | brixen | for dblack |
| 16:35:09 | evan | ok |
| 16:35:18 | brixen | because he's one of the few people I'll support on an os released in 2007! |
| 16:35:38 | evan | hehehe |
| 16:57:46 | evan | welp, still working on the signal delivery issue |
| 16:57:53 | evan | hopefully have it fixed today. |
| 17:04:47 | toulmean | evan, brixen: I now have rubinius installed on apache infra! |
| 17:04:55 | evan | woo! |
| 17:05:03 | brixen | toulmean: yay |
| 17:05:03 | evan | toulmean: I saw your ticket about $LOADED_FEATURES |
| 17:05:06 | evan | we'll have to look into that. |
| 17:05:07 | toulmean | yes |
| 17:05:17 | toulmean | there is more after that, I'm a bit puzzled. |
| 17:05:26 | toulmean | anyways. |
| 17:05:31 | toulmean | first things first. |
| 17:05:59 | toulmean | evan: think $LOADED_FEATURES is a bad hack from buildr ? I could do it in a different way |
| 17:06:11 | evan | a very bad hack |
| 17:06:20 | evan | any direct manipulation of $LOADED_FEATURES is a bad hack. |
| 17:06:27 | toulmean | I can probably use eval with a regexp to catch what I want from the file |
| 17:06:35 | evan | toulmean: so, i'm looking at the ticket |
| 17:06:37 | evan | and confused |
| 17:06:47 | evan | it puts "java" in loaded features, then requires jruby |
| 17:06:56 | evan | does jruby require java? is that why you do that? |
| 17:07:00 | evan | also, what exception does it raise? |
| 17:07:21 | evan | a LoadError for java, i expect |
| 17:07:22 | toulmean | evan: it adds jruby to the LOADED_FEATURES, not java |
| 17:07:23 | evan | but you don't say |
| 17:07:27 | evan | oh |
| 17:07:29 | evan | your ticket is wrong. |
| 17:07:33 | evan | oh oh |
| 17:07:34 | evan | no |
| 17:07:37 | evan | it's me thats wrong. |
| 17:07:40 | evan | NEVERMIND |
| 17:07:47 | evan | we should fix this though |
| 17:07:47 | toulmean | evan: oh wait let me add formatting. |
| 17:07:48 | evan | but it's a hack. |
| 17:09:27 | toulmean | evan: the thing is it works with MRI |
| 17:09:32 | toulmean | rubySpec for it ? |
| 17:09:44 | evan | yes, please. |
| 17:09:48 | brixen | there should be a rubyspec for it |
| 17:10:01 | toulmean | evan: I can file it. Helps ? |
| 17:10:02 | brixen | please check the existing ones to see where the hole is |
| 17:10:10 | toulmean | sure |
| 17:10:37 | brixen | basically, require 'jruby' should be a no-op because you put 'jruby' in $L_F, right? |
| 17:11:12 | toulmean | brixen: yes |
| 17:11:17 | toulmean | funny hack hey ? |
| 17:12:10 | toulmean | this is buildr requiring a file that would heavily depend on jruby, but making sure to not load it using LOADED_FEATURES, so it can grab a constant in the file and use it to compile java |
| 17:12:13 | brixen | well, it's a lame hack inspired and supported by MRI's totally brain-dead code loading |
| 17:12:27 | toulmean | :) |
| 17:12:36 | toulmean | it's ok if you don't want to do it |
| 17:12:50 | brixen | oh, we try to support the rest of it, this is just a bug |
| 17:13:04 | toulmean | a bug in MRI ? |
| 17:13:05 | brixen | but I'm sure there is a better way for you to do it :) |
| 17:13:16 | brixen | yes, #require is a bug in MRI IMO |
| 17:13:26 | brixen | but no, this is a failure of rbx to implement said bug |
| 17:13:35 | toulmean | ah ok |
| 17:13:44 | toulmean | your codebase is just too clean |
| 17:13:47 | toulmean | that's the problem |
| 17:13:48 | toulmean | :) |
| 17:14:03 | brixen | we try to use OO abstractions, that's the problem |
| 17:14:58 | kronos_vano | I'm trying to fix the ticket today, but: $LF << 'jruby'; require 'jruby' #=> false. $LF << 'pp', require 'pp' # => true. WTF? :( |
| 17:15:44 | brixen | kronos_vano: if you are working on a ticket, please indicate that |
| 17:15:47 | toulmean | that's nice |
| 17:15:59 | toulmean | guys I'm looking up rubyspec |
| 17:16:05 | brixen | saves wasting time on something someone else is doing |
| 17:16:11 | toulmean | look at line 43 of load.rb |
| 17:16:33 | brixen | load.rb where? |
| 17:16:42 | toulmean | err |
| 17:16:48 | toulmean | core/kernel/shared/load.rb |
| 17:16:58 | toulmean | sorry wrong file actually. |
| 17:17:02 | toulmean | load != require |
| 17:18:26 | toulmean | the interesting stuff is more in require.rb, same folder line 330 |
| 17:18:35 | kronos_vano | brixen, I always indicate. here is my tag: "kronos". But i dunno how to fix it for now, so i didn't indicate |
| 17:19:08 | brixen | kronos_vano: well, if you are working on it, let us know |
| 17:19:17 | kronos_vano | sure |
| 17:19:30 | brixen | toulmean: yes, there are specs for not requiring the file if it's in $L_F |
| 17:19:31 | toulmean | thanks all for working on it |
| 17:19:42 | brixen | toulmean: that's why I'm wondering why your case is different |
| 17:19:52 | toulmean | brixen: yes, none of them indicate a path without .rb |
| 17:20:03 | brixen | ah, well there it is then :) |
| 17:20:09 | brixen | should be an easy spec/fix |
| 17:20:09 | toulmean | also it's possible you try to bind to an actual file |
| 17:20:32 | toulmean | my case was a bit more complex, but I wanted to reproduce a minima: |
| 17:20:48 | toulmean | first you had the $L_F << 'jruby' |
| 17:21:00 | toulmean | then require 'buildr/nailgun' |
| 17:21:09 | toulmean | then nailgun.rb does require 'jruby' |
| 17:21:18 | toulmean | see, the path changed. |
| 17:22:05 | brixen | toulmean: show me how what you are doing is different than this http://gist.github.com/437974 |
| 17:22:21 | brixen | basically, write me a repro I can run, please :) |
| 17:23:03 | evan | shouldn't $L_F have jruby.rb? |
| 17:23:07 | evan | not just "jruby" ? |
| 17:23:23 | brixen | dunno, i'm trying to follow toulmean's steps |
| 17:23:33 | evan | yeah, I think toulmean's steps are wrong. |
| 17:23:38 | brixen | me too :) |
| 17:37:59 | toulmean | ok will do |
| 17:38:06 | toulmean | will use mature language as well |
| 17:40:11 | toulmean | brixen: hmmm. |
| 17:40:29 | kronos_vano | http://gist.github.com/437991 This fix case when $L_F contain name with rb extension |
| 17:41:54 | toulmean | brixen: ok, I can't repro small scale, I'll give the full steps from my use case |
| 17:42:08 | kronos_vano | feature_provided? method doesn't check name without '.rb' :/ |
| 17:48:07 | toulmean | kronos_vano: updated the issue. |
| 17:48:58 | kronos_vano | toulmean, can you test with http://gist.github.com/437991 ? |
| 17:49:33 | toulmean | err ? |
| 17:49:43 | toulmean | ok one sec. |
| 17:52:12 | toulmean | kronos_vano: still not. |
| 17:52:20 | toulmean | but then. |
| 17:52:26 | toulmean | do I need to run rake again ? |
| 17:52:31 | toulmean | after applying the patch ? |
| 17:52:37 | brixen | yes |
| 17:52:45 | toulmean | rak'ing then |
| 17:52:48 | toulmean | : |
| 17:55:09 | kronos_vano | toulmean, rake build |
| 17:55:14 | toulmean | kronos_vano: yes! |
| 17:55:18 | toulmean | it works. kthx. |
| 17:55:38 | brixen | toulmean: so were you adding jruby.rb or jruby to the $L_F? |
| 17:55:45 | toulmean | jruby |
| 17:56:06 | toulmean | brixen: can I ask roadmap questions ? |
| 17:56:12 | brixen | sure |
| 17:56:27 | toulmean | is there a 1.0.2 coming up ? |
| 17:56:34 | evan | toulmean: not atm, no. |
| 17:56:42 | evan | we can do one if there is the need. |
| 17:57:49 | toulmean | ok no worries. |
| 17:57:54 | evan | why? |
| 17:58:35 | toulmean | evan: I have more issues, and I needed to see if there was a timeline |
| 17:58:41 | toulmean | to rush fixes in or not. |
| 17:58:56 | evan | stuff going into master right now is for 1.1 |
| 17:59:06 | evan | which will come out in august. |
| 18:01:32 | toulmean | ok good deal. |
| 18:02:35 | toulmean | just wondering - you guys will never support rcov right ? |
| 18:02:47 | toulmean | or the other way around - rcov will never support rubinius right ? |
| 18:02:53 | evan | we could probably support the front end |
| 18:02:57 | evan | but likely not the backend |
| 18:03:18 | evan | we've got a better profiler than rcov anyway |
| 18:03:19 | evan | :) |
| 18:03:45 | toulmean | yes. I commented it out using a check on RUBY_ENGINE |
| 18:04:17 | brixen | toulmean: I'll look at rcov |
| 18:04:22 | toulmean | no need |
| 18:04:48 | brixen | toulmean: I have some profiler work to do for wycats to support ruby-prof style collapsable graphs |
| 18:05:04 | toulmean | on Buildr, I can install all dependencies now (rbx -S rake setup) |
| 18:05:12 | toulmean | I removed the need to sudo |
| 18:05:35 | toulmean | then rbx -S spec fails when it uses sh to call rbx to compile java files |
| 18:05:44 | toulmean | it gives a status 1 without more explanations |
| 18:06:14 | evan | toulmean: sounds like the call to javac isn't working |
| 18:06:29 | toulmean | yes but it works if I run the command directly |
| 18:06:30 | evan | maybe some directories were created when you were using sudo |
| 18:06:37 | evan | and they're not root owned. |
| 18:06:41 | evan | s/not/now/ |
| 18:06:44 | kronos_vano | brixen, Why Go? (i'm about gor) |
| 18:06:54 | toulmean | evan: well same gems work well with mri |
| 18:06:56 | toulmean | hmm |
| 18:07:00 | toulmean | let me check. |
| 18:07:25 | brixen | kronos_vano: why not? ;) |
| 18:08:38 | toulmean | evan: no, it doesn't change much. |
| 18:08:51 | evan | toulmean: i'm not sure what you mean. |
| 18:08:57 | toulmean | ok. |
| 18:09:11 | kronos_vano | brixen, :D. I prefer javascript |
| 18:09:13 | brixen | well, blast, doesn't seem like I can get a fedora 8 system running |
| 18:09:50 | brixen | kronos_vano: heh, well get busy running javascript on rbx then :) |
| 18:10:20 | toulmean | evan: http://gist.github.com/438044 |
| 18:10:53 | evan | toulmean: no clue |
| 18:11:29 | evan | toulmean: you'll have to dig in to see whats different |
| 18:11:36 | evan | javac should really be outputing something |
| 19:09:04 | kronos_vano | Patch for #365 http://gist.github.com/438128 |
| 19:10:28 | brixen | kronos_vano: that spec should not use 'should_non raise_error' |
| 19:10:36 | brixen | er should_not |
| 19:11:05 | kronos_vano | What they should use then? |
| 19:11:14 | kronos_vano | .should be_false ? |
| 19:11:22 | brixen | it "returns false when requiring a file that already exists in $LOADED_FEATURES" |
| 19:11:25 | brixen | yes |
| 19:11:44 | brixen | it "returns false when requiring a file with no extension that already exists in $LOADED_FEATURES" |
| 19:12:22 | brixen | kronos_vano: is this true for a path or only a filename? |
| 19:13:12 | kronos_vano | I don't test with path. I'll try |
| 19:13:22 | brixen | also, is this behavior changed if the file actually exists? |
| 19:14:13 | kronos_vano | brixen, yes |
| 19:14:26 | kronos_vano | $LOADED_FEATURES << 'pp'; require 'pp' => true |
| 19:14:38 | kronos_vano | but |
| 19:14:46 | kronos_vano | $LOADED_FEATURES << 'pp.rb'; require 'pp' => false |
| 19:15:21 | brixen | sounds like me need more than one more spec then ;) |
| 19:15:29 | brixen | er me == we :) |
| 19:15:58 | kronos_vano | brixen, I really try to write another, but all of them passed before patch :( |
| 19:17:11 | brixen | they all passed because we implement all that behavior |
| 19:17:25 | brixen | all passing =\=> all behavior is spec'd |
| 19:18:36 | kronos_vano | right. |
| 19:19:05 | kronos_vano | about paths, did you mean that: http://gist.github.com/438144 ? |
| 19:20:50 | brixen | kronos_vano: no, I mean similar to existing specs at core/kerner/shared/require.rb:311-332 |
| 19:21:04 | brixen | and those specs give you an example for how to write these btw |
| 20:37:15 | evan | man signals are a pain. |
| 20:37:19 | evan | i should see how python handles them. |
| 20:39:18 | slava | what problem are you having? |
| 20:39:37 | evan | well, how/where I should dispatch them mainly. |
| 20:39:51 | slava | ideally you'd be able to run ruby code from the signal handler itself |
| 20:39:58 | evan | fuck |
| 20:39:59 | evan | no. |
| 20:40:09 | evan | thats never happening. |
| 20:40:10 | slava | clozure common lisp can do it |
| 20:40:15 | evan | good for them. |
| 20:40:19 | slava | native threads without a GIL + lisp signal handlers |
| 20:40:21 | evan | it's so problematic. |
| 20:40:31 | slava | it means every instruction has to be a safepoint |
| 20:40:34 | evan | the system is in ANY state. |
| 20:40:37 | slava | right |
| 20:43:32 | slava | evan: so the basic approach you use is to queue up signals and then run them in the main thread? |
| 20:43:43 | evan | yeah |
| 20:43:50 | evan | should be easy. |
| 20:44:01 | evan | i'm fighting with some aspects of it though. |
| 20:44:11 | slava | can you interrupt infinite loops with ^C? |
| 20:44:38 | evan | yes. |
| 20:45:54 | evan | i'm now getting this weird behavior where even though i've registered a handler |
| 20:46:05 | evan | the process exits as though the default handler were hit. |
| 20:46:22 | slava | sounds like you forgot to reset the signal mas |
| 20:46:24 | slava | mask |
| 20:46:32 | slava | does this occur when you get the same signal twice in a row? |
| 20:46:47 | evan | perhaps yes. |
| 20:46:56 | evan | reset the mask to what? |
| 20:47:18 | slava | how are you exiting from the handler? longjmp? |
| 20:47:24 | evan | return. |
| 20:47:36 | slava | so you change the instruction pointer in the ucontext to point to some code, and then return? |
| 20:47:41 | slava | that should work fine |
| 20:47:41 | evan | no no |
| 20:47:53 | evan | the handler just records that a signal occured |
| 20:47:55 | evan | nothing more. |
| 20:48:14 | slava | ok |
| 21:05:51 | evan | slava: the complicated part is that if the main thread is in a blocking operation |
| 21:06:00 | slava | oh |
| 21:06:02 | evan | it needs to be woken up to handle the signals |
| 21:06:07 | slava | can't you spin up a new thread to run handlers in? |
| 21:06:21 | evan | i've considered it |
| 21:06:27 | evan | but ^C still needs to be handled on the main thread. |
| 21:07:14 | evan | for IO operations, I think i'm going to introduce a way to advertise a pipe fd that can be used to wake up select |
| 21:07:32 | evan | atm, a signal is sent with pthread_kill to get the syscall to return EINTR |
| 21:14:55 | bakkdoor | hi |
| 21:15:04 | evan | python, it appears, doesn't wake up the main thread at all. |
| 21:15:10 | evan | it just waits until the main thread checks. |
| 21:15:12 | evan | bakkdoor: hi. |
| 21:15:26 | ekidd | Hello! Rubinus is looking really great! |
| 21:15:32 | evan | thanks! |
| 21:15:35 | rue | Perhaps the channel concept could be worked in again |
| 21:15:44 | ekidd | Is there any documentation on setting up rubygems with Rubinius? |
| 21:15:53 | evan | ekidd: it's builtin |
| 21:15:55 | evan | there is nothing to do |
| 21:16:05 | evan | bin/rbx gem <commands> |
| 21:16:10 | ekidd | Ah, nice! |
| 21:17:49 | evan | rue: there still has to be a mechanism to trigger a channel |
| 21:17:52 | evan | which is the level i'm at. |
| 21:18:03 | slava | evan: you should make all io nonblocking :) |
| 21:18:25 | evan | thats an option, it just has it's own set of headaches. |
| 21:18:36 | evan | thats a bit of "now you have 2 problems" solution. |
| 21:19:08 | slava | heh |
| 21:19:18 | slava | signals just suck in general though |
| 21:19:36 | evan | that they do. |
| 21:23:28 | evan | man, IO in a signal handler is such bad news. |
| 21:33:55 | ekidd | Sweet! I'm running MongoDB's GridFS in Rubinius. It's definitely on the slow side, since the bson_ext gem doesn't play nicely with Rubinius and I had to drop back to the native Ruby gem. |
| 21:34:04 | ekidd | But it's working. |
| 21:34:27 | brixen | ekidd: the bson_ext gem probably uses #pack #unpack a lot, right? |
| 21:35:01 | ekidd | brixen: The C version seems to also poke around inside objects. But yeah, I think the native version uses pack and unpack. |
| 21:35:08 | ekidd | I'm just amazed that everything runs. :-) |
| 21:35:15 | brixen | heh, cool |
| 21:35:36 | ekidd | I've worked on compiler projects before, and this is definitely the part of the development process where things get easier... |
| 21:35:57 | brixen | ekidd: if you want me to look at some perf issues, give me a gist with all the steps I need to install and run |
| 21:35:59 | ekidd | ...Oh, if I wasn't devoting every waking hour to a startup, I'd have such fun with this! |
| 21:36:05 | brixen | heh |
| 21:36:33 | brixen | ekidd: you'd be very successful if your startup's product were an hour multiplier |
| 21:36:40 | ekidd | You people just completely rock. |
| 21:36:45 | brixen | just enter the day and how many hours you want to multiply |
| 21:37:07 | brixen | for example, I'd like 6 hrs extra on 6/15/2010 :) |
| 21:37:32 | ekidd | Yeah, I think there's a market for that. :-) |
| 21:37:33 | parndt | I'd like to go back to 2010-02-11 |
| 21:37:42 | slava | I'd like to go back to 1997 |
| 21:38:17 | brixen | evan: so, I have built rbx on fedora 8 |
| 21:38:21 | evan | ok |
| 21:38:38 | brixen | evan: but to do so, I had to build llvm from source |
| 21:38:49 | ekidd | brixen: Here's the code I'm running: https://gist.github.com/a240685f8f650615cbd1 |
| 21:38:51 | brixen | trying to use the prebuilt, I got this while linking http://gist.github.com/438188 |
| 21:39:27 | ekidd | You need mongodb installed, but that's pretty easy--it's pretty straightforward to set up. |
| 21:39:34 | brixen | evan: I'm testing the llvm pkg on ubuntu 10.04 |
| 21:39:43 | brixen | ekidd: sweet, I'll take a look |
| 21:39:44 | evan | bakkdoor: yeah, we'll need to build a prebuilt specificly for it probably |
| 21:39:52 | evan | since it's a pretty old version of libc |
| 21:40:14 | brixen | evan: the problem is, how do we distinguish it? |
| 21:40:27 | brixen | it gets the same host string as a much more recent linux |
| 21:40:34 | bakkdoor | evan: hm? |
| 21:40:44 | brixen | bakkdoor: he meant me :) |
| 21:40:45 | evan | bakkdoor: eh? |
| 21:40:46 | ekidd | brixen: Note that MongoDB GridFS is still a bit piggish in MRI, too--it doesn't run nearly as fast as the pure C GridFS client. Call it 5 files/second. |
| 21:40:51 | evan | oh |
| 21:40:52 | evan | sorry. |
| 21:40:53 | bakkdoor | brixen: ah ok :) |
| 21:40:54 | evan | yes, brixen. |
| 21:40:56 | bakkdoor | no problem ;) |
| 21:40:57 | brixen | heh |
| 21:41:00 | ekidd | Rubinius is rather, um, _slower_. :-) |
| 21:41:04 | evan | brixen: we don't. |
| 21:41:18 | evan | brixen: prebuilt just isn't support on older linux for now. |
| 21:41:30 | ekidd | OTOH, unlike MRI 1.8.7, it doesn't actually _fail_ when trying to run this code, AFAICT. |
| 21:41:35 | evan | we can add a --build option to configure to take a triple |
| 21:41:38 | evan | so they can use |
| 21:41:42 | ekidd | More compatible than the real thing! |
| 21:41:50 | evan | ./configure --build x86_64-linux-fedora8 |
| 21:41:52 | evan | or something |
| 21:41:56 | evan | and we can a prebuilt for that. |
| 21:41:57 | brixen | evan: well, if the prebuilt I built on f8 works with newer ubuntu, could we just use that one? |
| 21:42:04 | bakkdoor | brixen: btw, how is poison coming along? I'm anxiously waiting to see some examples on additional languages running on rubinius :) |
| 21:42:05 | evan | it won't. |
| 21:42:06 | brixen | for the i686-linux |
| 21:42:12 | evan | it will not work. |
| 21:42:18 | brixen | evan: ok |
| 21:42:40 | evan | ekidd: hah |
| 21:42:40 | evan | :) |
| 21:42:50 | brixen | bakkdoor: I pushed what I have up to now, I need to restart with a better parser |
| 21:43:12 | bakkdoor | brixen: alright. i can wait ;) |
| 21:43:20 | brixen | bakkdoor: I'll make "'hello' print" execute |
| 21:43:42 | bakkdoor | brixen: ok |
| 21:43:55 | brixen | bakkdoor: evan added custom callsite logic, so rbx is basically rockin' :) |
| 21:44:40 | brixen | evan: so, f8, how do we want to instruct ppl to build? |
| 21:45:08 | brixen | should we re-enable telling configure to use source directly? add a --no-prebuilt switch? |
| 21:46:39 | evan | no |
| 21:46:44 | bakkdoor | brixen: yeah i'm pretty sure I'll port fancy to rubinius some time soon. lots of things in common and I think supporting the platform is generally a good idea ;) |
| 21:46:49 | evan | we've got that already anyway |
| 21:47:05 | evan | they'll just have to build LLVM themselves |
| 21:47:21 | evan | and use --llvm-path |
| 21:47:23 | evan | to point to it |
| 21:49:48 | brixen | hmm, just linked ok on ubuntu with f8 prebuilt |
| 21:49:54 | brixen | and the specs are running |
| 21:50:28 | evan | you mean for 10.1? |
| 21:50:41 | evan | i'm just uncomfortable building LLVM with a much older version of libc |
| 21:50:47 | evan | and using it in ubuntu 10 |
| 21:52:03 | brixen | yeah, me too |
| 21:52:14 | brixen | I just don't want to force ppl to build llvm :/ |
| 21:52:16 | brixen | it sucks |
| 21:52:45 | evan | best way then is to upload that prebuilt as a special name |
| 21:52:50 | evan | and add --prebuilt-name |
| 21:52:53 | brixen | why not --prebuilt fedora8 => llvm-1686-linux-fedora8.tar.bz2 |
| 21:52:56 | brixen | yeah |
| 21:53:00 | brixen | something like that |
| 21:53:03 | evan | sure |
| 21:53:06 | brixen | k |
| 22:00:29 | cremes | ekidd: i saw that you said bson_ext has problems with rubinius so you fell back to the native bson driver |
| 22:00:57 | cremes | i did the early work to get mongo_ext working with rubinius; is the C extension compiling or failing? |
| 22:01:06 | ekidd | cremes: Yes, it claims that it can't serialize Rubinius' time object. |
| 22:01:16 | cremes | can you gist me the error? |
| 22:04:06 | ekidd | cremes: http://gist.github.com/438390 |
| 22:04:23 | evan | alias_method :write_nonblock, :write |
| 22:04:24 | evan | :/ |
| 22:04:25 | evan | FAIL., |
| 22:04:54 | cremes | ekidd: thanks; i'll look at it this weekend |
| 22:05:21 | ekidd | cremes: I just installed the gems a few minutes ago, so they're all the latest versions as of now. |
| 22:05:22 | evan | it probably uses RTIME or something |
| 22:06:01 | cremes | perhaps... it didn't use to so this would be an incompatibility that was recently introduced |
| 22:14:30 | evan | cremes: http://github.com/mongodb/mongo-ruby-driver/blob/master/ext/cbson/cbson.c#L426-429 |
| 22:14:32 | evan | thats the problem. |
| 22:14:40 | evan | it's detecting Time by digging into the object raw |
| 22:57:00 | brixen | evan: could you move the f8 prebuilts in my home dir to assets so I can test pls |
| 22:57:06 | evan | sure |
| 22:57:10 | brixen | thanks |
| 22:57:40 | evan | done |
| 22:57:46 | brixen | excellente |
| 23:38:39 | cremes | evan: that code is new; i'll try to figure out an alternative this weekend when i can focus on it |
| 23:38:48 | cremes | thanks for doing the legwork to pinpoint it |
| 23:40:26 | evan | cremes: no prob. |
| 23:40:36 | evan | cremes: using rb_kind_of() would be better. |
| 23:41:34 | cremes | yeah |
| 23:42:01 | cremes | it doesn't look like it is accessing anything private; it's calling to_f on it... |
| 23:42:50 | evan | yep |
| 23:43:01 | evan | just a bad shape test |
| 23:43:26 | cremes | "bad shape"? |
| 23:43:42 | evan | "This thing looks like a Time object" |
| 23:43:46 | cremes | ah |
| 23:44:04 | evan | i used "shape" as a generic term for indicating the type a thing is |
| 23:44:14 | cremes | got ya |
| 23:44:28 | cremes | i'll add this to my weekend queue |
| 23:45:05 | evan | awesome |
| 23:45:06 | evan | thanks! |
| 23:45:37 | cremes | np; hopefully brixen will get to his pack/unpack optimization soon so that mongo is usable under rbx... (hint, hint) |
| 23:49:15 | evan | we're going to have to rewrite them entirely likely |
| 23:51:19 | brixen | cremes: I can take a hint! :) |
| 23:52:33 | brixen | cremes: if you could just convince everyone to use the latest mac os x release, we'd spend far less time on these build issues |
| 23:52:44 | brixen | and more time doing "real work" (tm) :) |
| 23:53:01 | evan | brixen: which are you working on? fedora? |
| 23:53:08 | brixen | yeah |
| 23:53:11 | evan | ok |
| 23:53:18 | evan | next time, push back. |
| 23:53:23 | brixen | adding --prebuilt-name |
| 23:53:31 | brixen | well, we need a tad more flexibility here |
| 23:53:34 | evan | we're not going to spend out time building vms for all linux distros |
| 23:53:41 | brixen | yeah |
| 23:53:45 | evan | i'd rather have the user of that distro be helping out |
| 23:53:52 | brixen | this way, they can build and we can use it |
| 23:53:53 | brixen | sure |
| 23:53:56 | evan | not us sinking our own time. |
| 23:54:06 | brixen | yep |
| 23:54:44 | brixen | lsb_release on linux is a sweet thing, btw |
| 23:54:55 | evan | ah cool. |
| 23:54:56 | brixen | I didn't know about it till dwaite told me about it |
| 23:55:23 | brixen | lsb_release -irs appended to the config.guess output is what I'm shootingfor |
| 23:55:52 | brixen | ie llvm-i686-linux-gnu-fedora-8 or ubuntu-10.04 etc |
| 23:56:04 | evan | ok |
| 23:56:18 | cremes | brixen: i will give a sermon to my mac faithful about the wonders of snow leopard so as to save the project some time :) |
| 23:56:21 | evan | are you going to be trying both? |
| 23:56:28 | brixen | cremes: sweet |
| 23:56:39 | brixen | evan: I want to do specific with a fall-back to generic |
| 23:56:51 | evan | k |
| 23:56:58 | brixen | so it will check #{config.guess}-#{lsb_release} then config.guess |
| 23:57:56 | brixen | crazy http://dailydeadbirds.com/ |