Show enters and exits. Hide enters and exits.
| 00:34:45 | wayneeseguin | evan: it copies one set of gems to another ... http://rvm.beginrescueend.com/gemsets/copying/ |
| 00:34:55 | wayneeseguin | evan: It quite literally does a cp -Rf ... IIRC |
| 00:35:02 | evan | does it rebuild all extensions? |
| 00:35:03 | evan | UG |
| 00:35:09 | evan | thats why people keep having issues with rbx on rvm probably then |
| 00:35:10 | wayneeseguin | I didn't think of this use case ;) |
| 00:35:20 | wayneeseguin | SO I think I'm going to have to make it do a 'gem pristine --all' |
| 00:35:22 | evan | they're copying their MRI build extensions directly to run under MRI |
| 00:35:26 | wayneeseguin | Would that fix it ? |
| 00:35:33 | evan | whats that do again? |
| 00:35:52 | wayneeseguin | It essentially re-installs every gem in the GEM_HOME very fast, re-compiling any extensions |
| 00:36:07 | evan | if that forces the extensions to be rebuilt unconditionally |
| 00:36:08 | evan | sure. |
| 00:36:24 | wayneeseguin | yes IIRC it's an unconditional rebuild, perhaps Defiler would know more? |
| 00:36:27 | wayneeseguin | I'll add it in |
| 00:37:01 | evan | please try it. |
| 00:40:21 | wayneeseguin | BBHoss: When you're back around I have something for you to test :) |
| 02:49:21 | toulmean | evan: you there ? |
| 02:54:12 | toulmean | I would like to contribute a spec on method overriding. |
| 04:33:16 | matthewd | toulmean: Should probably go in spec/ruby/language/, if it's something that's not covered |
| 04:48:26 | toulmean | matthewd: thx! |
| 04:49:05 | toulmean | Now I can't write the correct spec for it it seems |
| 05:03:45 | brixen | toulmean: back, what's the issue? |
| 05:04:06 | toulmean | hey brixen, let me open an issue for it |
| 05:05:57 | boyscout | Imported DL extension from 1.8.7. - b1aca38 - Brian Ford |
| 05:05:57 | boyscout | More C-API specs getting DL running. - 547e2ce - Brian Ford |
| 05:05:57 | boyscout | More C-API functions for DL. - d08d084 - Brian Ford |
| 05:05:57 | boyscout | Specs for rb_set_errinfo. - 01c1e42 - Brian Ford |
| 05:05:57 | boyscout | Changed rb_set_errinfo to accept Qnil like 1.9. - f52585b - Brian Ford |
| 05:05:57 | boyscout | More C-API spec fixes to run with MRI. - 5377580 - Brian Ford |
| 05:05:58 | boyscout | Moved C-API .h files to include directory. - 07e6ac4 - Brian Ford |
| 05:07:00 | brixen | toulmean: the next issue with rjb is some frozen weirdness in Hash |
| 05:07:12 | toulmean | ok |
| 05:09:55 | toulmean | brixen: http://github.com/evanphx/rubinius/issues/issue/327 |
| 05:10:03 | toulmean | I tried to make a spec to repro |
| 05:10:26 | toulmean | but it sounds like it's not a generic problem |
| 05:10:52 | brixen | toulmean: could you pls put bt's in <pre> tags |
| 05:11:06 | toulmean | oh ok sure |
| 05:11:21 | brixen | thanks, makes it much easier to parse |
| 05:11:43 | toulmean | brixen: I can edit this after submitting it ? |
| 05:11:49 | toulmean | oh yes |
| 05:11:53 | brixen | hm, do you have an edit link? |
| 05:11:55 | brixen | ah ok |
| 05:11:58 | brixen | otherwise I can |
| 05:12:20 | toulmean | it's all set. |
| 05:12:31 | toulmean | Frankly it's a hard one I'm afraid. |
| 05:12:38 | toulmean | maybe not worth tackling yet |
| 05:14:17 | toulmean | brixen: ^^ |
| 05:14:24 | brixen | toulmean: check out what I did to your repo link in you ticket :) |
| 05:14:35 | brixen | that makes it much easier than manually searching for a line |
| 05:14:35 | toulmean | I feel like I borrowed your brains for too long you know :) |
| 05:14:46 | brixen | er your ticket |
| 05:14:51 | toulmean | I didn't know github had that |
| 05:14:57 | brixen | yeah, pretty cool |
| 05:15:00 | toulmean | thx, good to know |
| 05:15:57 | brixen | ok, so another thing... :) |
| 05:16:24 | brixen | instead of just the bt, pls put the whole thing, ie, the commond you ran and any deps needed to exec that cmd |
| 05:16:44 | brixen | I have no idea how to repro this otherwise |
| 05:16:52 | toulmean | oh crap |
| 05:16:54 | toulmean | sorrt |
| 05:16:55 | toulmean | sorry |
| 05:17:40 | toulmean | brixen: ok done. |
| 05:17:47 | toulmean | you need to run rake spec |
| 05:17:53 | toulmean | on buildr's trunk |
| 05:18:12 | toulmean | you need all the dependencies of buildr, as rake spec checks for them before running. |
| 05:18:30 | brixen | ok, let's see if I can get to this point |
| 05:18:31 | toulmean | you did all the hard setup work already |
| 05:18:36 | toulmean | ok |
| 05:19:26 | brixen | oh, can I run this from the rjb clone? |
| 05:19:37 | brixen | you mentioned something about building the rjb gem |
| 05:20:09 | boyscout | CI: Commit 07e6ac4 failed. http://github.com/evanphx/rubinius/commit/07e6ac4589eacbf5766ae45eda399261c05830e3 |
| 05:20:16 | brixen | ack |
| 05:20:19 | brixen | :( |
| 05:20:59 | brixen | we need to fix CI to point to the ci output instead of the commit link |
| 05:21:54 | brixen | man, these extensions are such a mess... |
| 05:22:11 | brixen | I need to get started on the build system |
| 05:23:01 | toulmean | brixen: oh yeah |
| 05:23:14 | toulmean | I can send you the gem you know. |
| 05:23:20 | toulmean | or you can create it |
| 05:25:22 | brixen | how do I create it again? |
| 05:25:32 | toulmean | you like pain man |
| 05:25:33 | toulmean | ok |
| 05:25:50 | toulmean | you run rake --rakefile rjb.rake at the bottom of the project |
| 05:26:04 | toulmean | sorry at the root of the rake checkout |
| 05:26:19 | toulmean | is watching the Lost finale |
| 05:26:29 | toulmean | which makes him unable to think straight |
| 05:26:48 | toulmean | that should create the gem in the pkg folder |
| 05:27:46 | brixen | k, got it |
| 05:28:27 | toulmean | you will need to modify buildr.gemspec to change the rjb version |
| 05:28:36 | toulmean | or just comment out the dependency rjb line there |
| 05:29:00 | brixen | change it to what? |
| 05:29:05 | toulmean | 1.2.1 |
| 05:29:13 | toulmean | and then to make it simple: |
| 05:29:21 | brixen | it built rjb-1.2.1.gem |
| 05:29:25 | toulmean | yes |
| 05:29:33 | toulmean | so you need to install that gem |
| 05:29:37 | brixen | ok |
| 05:29:41 | toulmean | 1.2.1 is the current rjb trunk |
| 05:30:01 | toulmean | then on Buildr to make it simple, run spec spec/core/application_spec.rb |
| 05:30:09 | brixen | but, if I installed rjb with extconf.rb, why do I need to install the gem? |
| 05:30:26 | toulmean | brixen: because .... buildr checks for the gem |
| 05:30:29 | toulmean | not the lib |
| 05:30:33 | toulmean | ok nvm |
| 05:30:33 | brixen | erg :/ |
| 05:30:41 | toulmean | just run spec spec/core/application_spec.rb |
| 05:30:54 | toulmean | well you know, checking for gems makes kinda sense |
| 05:31:03 | brixen | yeah, that's fine |
| 05:31:09 | brixen | what version of rspec should I use? |
| 05:31:25 | toulmean | latest fine |
| 05:31:28 | brixen | k |
| 05:31:46 | brixen | I need to fix this CI build first |
| 05:32:12 | toulmean | take time, please. I can try to isolate meanwhile. |
| 05:46:35 | boyscout | Force reconfigure for C exts when cleaning. - e484ef7 - Brian Ford |
| 05:54:19 | toulmean | brixen: I'd like to help some more. |
| 05:54:37 | toulmean | I run spec on another file and get an interesting bt: |
| 05:54:41 | toulmean | brixen: http://gist.github.com/411570 |
| 05:55:16 | toulmean | I think it's interesting for you. I am not sure how to help isolate it |
| 05:56:14 | badboy | moin |
| 05:56:25 | toulmean | moin |
| 05:57:46 | boyscout | CI: Commit e484ef7 failed. http://github.com/evanphx/rubinius/commit/e484ef7997a9a0a9bdb3432a785f1048a2ef70b7 |
| 06:02:34 | brixen | damn DL |
| 06:03:00 | toulmean | brixen: for the broken CI or my gist ? |
| 06:07:59 | brixen | toulmean: I'm working on CI |
| 06:08:07 | toulmean | k |
| 06:08:20 | brixen | I should say damn gcc |
| 06:08:41 | brixen | it's always a fucking crap shoot when something will work a particular way |
| 06:08:48 | brixen | </3 gcc |
| 06:08:54 | scoopr | clang ftw ;) |
| 06:08:59 | brixen | no kidding |
| 06:10:27 | toulmean | brixen: well you can forget my gist, it was me being a clown again |
| 06:10:49 | toulmean | rbx -S rbx -S spec something :) |
| 06:11:01 | brixen | hah |
| 06:11:09 | brixen | well, I didn't even look :) |
| 06:11:14 | toulmean | good |
| 06:18:44 | brixen | well, what the hell |
| 07:03:51 | boyscout | Disable DL for now. - 208d81a - Brian Ford |
| 07:04:13 | brixen | rbx is segfaulting when make execs it but not when I do it directly |
| 07:05:40 | brixen | erm, not segfault, StackError |
| 07:12:49 | boyscout | CI: rubinius: 208d81a successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 16:06:16 | evan | morning. |
| 16:12:19 | matthewd | evan: I haven't really investigated, but came across this a little while ago: Module.new.method_defined?(:dup) |
| 16:12:57 | evan | # => true |
| 16:12:58 | brixen | morning |
| 16:12:59 | evan | so? |
| 16:13:11 | matthewd | Not in MRI :) |
| 16:13:16 | evan | screw MRI. |
| 16:13:24 | evan | thats ridiculous. |
| 16:13:31 | matthewd | Kernel.method_defined?(:dup) # => true |
| 16:13:33 | evan | why would that be false? |
| 16:13:40 | matthewd | But not for other modules |
| 16:14:14 | evan | fucking A MRI |
| 16:14:16 | evan | and yet |
| 16:14:23 | evan | >> Module.new.method(:dup) |
| 16:14:24 | evan | => #<Method: Module(Kernel)#dup> |
| 16:14:28 | evan | O_o |
| 16:14:40 | matthewd | M.methods.select {|m| M.method_defined?(m) } # => [] |
| 16:15:24 | evan | well, wait. |
| 16:15:36 | evan | method_defined? says an instance_method of the Module |
| 16:15:41 | evan | not if it responds to it |
| 16:15:49 | evan | so your code is of course false. |
| 16:16:19 | matthewd | But so's M.methods, no? |
| 16:16:26 | evan | ha |
| 16:16:26 | evan | no. |
| 16:16:34 | evan | thats the methods that M, the object, has. |
| 16:16:35 | evan | like |
| 16:16:37 | evan | Object.new.methods |
| 16:16:41 | matthewd | Oh, right |
| 16:17:06 | evan | well |
| 16:17:26 | evan | this bug you've found is because we use find_method_in_hierarchy in Module#method_defined? |
| 16:17:32 | evan | which, because of other method lookup semantics |
| 16:17:35 | evan | also searches Object |
| 16:17:48 | evan | which, in this case, is wrong. |
| 16:19:34 | evan | thats the only reason this that's true. |
| 16:19:51 | evan | i'm not exactly sure why we're checking Object as well |
| 16:19:54 | evan | to tell you the truth. |
| 16:20:18 | evan | but you can try removing the code on line 138 of module.rb |
| 16:20:20 | evan | and rerun the specs |
| 16:20:22 | evan | and see what happens. |
| 16:26:09 | evan | anyone quite famaliar with eventmachine? |
| 16:26:34 | Defiler | I wish I were; trying to get there |
| 16:27:31 | evan | i'm trying to figure out how the depths of it are supposed to work when Ctrl-C is hit |
| 16:27:39 | evan | ie, how it's main run loop is interrupted. |
| 16:28:08 | matthewd | evan: Not that easy :) spec/ruby/core/module/module_function_spec.rb:105 |
| 16:28:48 | evan | i don't see how that matters at all. |
| 16:28:53 | evan | did the call to module_function fail? |
| 16:29:00 | matthewd | Yeah |
| 16:29:01 | evan | i need you to tell me why |
| 16:29:04 | evan | not just what. |
| 16:29:10 | evan | or, where in this case. |
| 16:29:24 | evan | i can't read minds. |
| 16:29:40 | evan | ok, well, i guess some code needs to check Object and some code not. |
| 16:30:11 | evan | add a spec, then add a flag to that method |
| 16:31:11 | matthewd | Fair enough... I really just figured it was more of a binary "does everything pass" question. |
| 16:31:53 | evan | it was, but you should fix it too! |
| 16:31:56 | matthewd | But yeah, for now, I need to get some sleep... but I'll come up with a spec and attempt to fix it tomorrow. |
| 16:33:00 | Defiler | I've assumed it has some trap for SIGINT in there and then propagates a 'cancel' event |
| 16:33:08 | Defiler | but I haven't actually seen that piece of code |
| 16:33:40 | evan | matthewd: ok, well put in an issue |
| 16:33:47 | evan | and maybe someone else will get to it. |
| 16:34:10 | brixen | matthewd: yes, pls open issues, don't sit on bugs you know about |
| 16:34:25 | brixen | matthewd: if you want to say "I'll fix" you can, too |
| 16:40:19 | cyndis | any comments about this? https://gist.github.com/df807c5ccf63243976e2 |
| 16:40:53 | evan | cyndis: why do it? |
| 16:41:09 | evan | oh, for end_proc |
| 16:41:12 | cyndis | yes |
| 16:41:15 | evan | i had to scroll all the way down |
| 16:41:23 | evan | well, get rid the curry method on Proc |
| 16:41:56 | cyndis | how should i pass the parameter then? |
| 16:42:38 | evan | some other way. |
| 16:42:49 | cyndis | ok. |
| 16:42:51 | evan | and writing directly to AtExit is very bad form. |
| 16:43:05 | cyndis | ok |
| 16:43:21 | cyndis | i'll think of something. |
| 16:44:09 | evan | i'd be fine with adding an alternate at_exit API that allows you to pass arguments |
| 16:44:32 | evan | thats a better solution. |
| 16:44:41 | cyndis | hmm, ok |
| 16:44:58 | toulmean | brixen: think I could try to code the JVM loading code using FFI and live with it. For now I'll make sure my buildr specs pass on Windows 7. |
| 16:45:04 | toulmean | with jruby |
| 16:45:20 | toulmean | thanks for all the help |
| 16:45:46 | cyndis | should i just make at_exit take parameters of have a different method? |
| 16:46:12 | evan | no. |
| 16:46:20 | cyndis | *or |
| 16:46:37 | cyndis | which? |
| 16:47:00 | evan | you should add a method under Rubinius that is your enhanced at_exit |
| 16:47:07 | cyndis | ok |
| 16:47:13 | evan | that allows you to pass an object that responds to #call, and any number of arguments for it |
| 16:47:38 | evan | it can put those things in an array and add the array to Rubinius::AtExit |
| 16:47:43 | cyndis | yes, i'll do that |
| 16:47:52 | evan | you then need to change loader.rb to understand what to do if the element in AtExit is an array |
| 16:54:08 | brixen | evan: halp http://gist.github.com/412119 |
| 16:54:25 | brixen | evan: if I invoke rbx directly with the string the make --debug shows, it works fine |
| 16:54:39 | brixen | if make invokes it, that runtime str is wacked |
| 16:54:43 | evan | make? |
| 16:54:52 | brixen | yes, in the DL ext |
| 16:55:06 | brixen | it subprocesses rbx to run a ruby script to gen the call back functions |
| 16:55:22 | brixen | see the gist |
| 16:55:24 | evan | no clue |
| 16:55:26 | evan | honestly. |
| 16:55:28 | evan | i'd have to debug it. |
| 16:55:34 | evan | i'm frusterated with EM right now. |
| 16:58:20 | cremes | is the behavior for Array undefined when you delete elements from it during an &each block? |
| 16:58:30 | evan | yes |
| 16:58:34 | evan | use delete_if |
| 16:58:36 | cremes | shoot |
| 16:58:51 | cremes | gotchya |
| 16:59:23 | brixen | cremes: thanks for reminding me, I'll add that to my post |
| 16:59:40 | cremes | brixen: any time... |
| 17:35:57 | Defiler | evan: OK, so.. eventmachine scenario.. |
| 17:36:12 | Defiler | it is in the middle of a section it has protected by 'rb_disable_interrupts' |
| 17:36:17 | Defiler | meanwhile, you mash ctrl-c |
| 17:36:27 | Defiler | it finishes that section, and re-enables interrupts |
| 17:36:40 | Defiler | does MRI at that point start unwinding the loop to handle the SIGINT? |
| 17:38:47 | kronos_vano | evan, http://mitkokostov.info/resources/results.pdf Rubinius so fast on recursion tests because of method inlining/inline cache? |
| 17:42:07 | evan | which tests? |
| 17:42:35 | evan | be specific. |
| 17:42:39 | evan | i don't know which ones you mean. |
| 17:44:50 | kronos_vano | evan, factorial fib tak tarai |
| 17:45:12 | evan | ah, yes, method inlining and method caches are the reason |
| 17:45:22 | evan | because the inlining inlines fib into itself |
| 17:45:33 | evan | which decreases the number of iterations by 2x |
| 17:45:52 | evan | the inlined fib can actually inline fib again. |
| 17:46:04 | evan | which reduces the loop iteration a lot more. |
| 17:47:33 | scoopr | so_sieve seams to stand out nicely too |
| 17:49:45 | evan | yeah, thats an interesting one |
| 17:49:47 | evan | i should check out the code. |
| 18:01:32 | brixen | evan: I have questions when you have a minute |
| 18:01:44 | evan | go for it. |
| 18:02:46 | brixen | I'm trying to understand vm/vm.hpp:180 in the context of this gist http://gist.github.com/412203 |
| 18:03:11 | brixen | check_stack is called from vm/instructions.cpp:116 |
| 18:03:25 | kronos_vano | rrr. still can not build rubinius :( |
| 18:03:59 | evan | gist the output of 'rake' |
| 18:04:01 | kronos_vano | http://gist.github.com/412209 |
| 18:04:30 | brixen | kronos_vano: gist git status |
| 18:04:32 | evan | kronos_vano: do you have changes? |
| 18:05:07 | brixen | kronos_vano: also gist ./configure --show |
| 18:07:04 | kronos_vano | rrrr |
| 18:07:08 | kronos_vano | git stash |
| 18:07:13 | kronos_vano | and everething works |
| 18:07:18 | kronos_vano | *everything |
| 18:07:21 | evan | thats why I asked if you had changes |
| 18:07:24 | evan | what were they |
| 18:07:27 | evan | are they, rather. |
| 18:09:49 | brixen | evan: so, the first arg to VMMethod::interpreter is state, and you pass &state to check_stack, which reinterprets as an intptr_t and cmps with stack_limit_ |
| 18:09:55 | brixen | I don't understand how that works |
| 18:10:17 | brixen | nor why the eff this would fail under make, but not when I exec rbx from rbx |
| 18:10:44 | evan | you sure thats what is breaking? |
| 18:10:52 | evan | i'll walk you through it anyway |
| 18:11:00 | brixen | yes |
| 18:11:04 | brixen | I'll update the gist |
| 18:11:37 | evan | ok, the stack_limit_ is set to an address that is the start of a 'red zone' on the stack |
| 18:11:48 | evan | if we pass it, we should assume we're close to the end and raise a StackError |
| 18:11:48 | brixen | http://gist.github.com/412203 |
| 18:12:05 | evan | &state is passed only because it's a variable on the stack |
| 18:12:15 | brixen | but in this case, the VMMethod::interpreter is only called once |
| 18:12:22 | brixen | ok, so that makes sense if we were recursing |
| 18:12:23 | evan | and thus it's address on the stack is what we'll use to test how deep the stack is |
| 18:12:28 | brixen | got it |
| 18:13:03 | brixen | I suppose I could read the make source |
| 18:13:19 | evan | wait, how is rbx being called that causes this problem? |
| 18:13:37 | brixen | from make |
| 18:13:44 | evan | the gist is confusing |
| 18:13:51 | evan | it appears you're calling mkcallback.rb directly |
| 18:14:02 | evan | or is that being called from inside make? |
| 18:14:07 | brixen | yes |
| 18:14:15 | evan | not a yes or no question |
| 18:14:16 | evan | :) |
| 18:15:10 | brixen | make execs @$(RUBY) $(srcdir)/mkcallback.rb > $@ |
| 18:15:21 | brixen | $(RUBY) is /home/brixen/devel/rubinius/bin/rbx |
| 18:15:21 | evan | and you added gdb --args in there |
| 18:15:22 | evan | ? |
| 18:15:25 | brixen | yes |
| 18:15:36 | evan | what is breakpoint 2 |
| 18:15:47 | evan | a break on VMMethod::interpreter? |
| 18:16:09 | brixen | yes |
| 18:16:17 | brixen | br 1 is Environment::run_file |
| 18:17:12 | brixen | if I were in some other invocation of VMMethod::interpreter, I could understand this failing |
| 18:17:57 | evan | is, perhaps, make setting some weird ulimit? |
| 18:18:03 | brixen | can make change the way the stack grows? |
| 18:18:26 | evan | maybe there is a bug here. |
| 18:18:40 | evan | maybe for some reasoning running it under make caused to manifest |
| 18:18:49 | evan | i did just fix a bug with stack_limit_ |
| 18:19:02 | evan | double check that stack_limit_and stack_size_ are set properly. |
| 18:19:25 | brixen | so 0xbfd13bb0 => 3218160560, but stack_limit_ in that gist p's as -1075752383 |
| 18:19:52 | brixen | I don't trust gdb for shit though, since the std::string printing was a total red herring |
| 18:20:59 | evan | brixen: add a print in check_stack |
| 18:21:05 | evan | and run it. |
| 18:21:11 | evan | so you don't have to depend on gdb |
| 18:21:17 | brixen | k |
| 18:24:52 | Defiler | evan: This looks right, right? http://github.com/evanphx/rubinius/commit/3ec71eb2f9fbd7b994eff09558c859cefafb8d01#L20R2526 |
| 18:25:09 | evan | yep. |
| 18:25:30 | Defiler | It felt a little lame to make visit_push_rubinius be so similar to the other one that calls push_system_object |
| 18:25:43 | evan | nah, thats fine. |
| 18:25:49 | Defiler | but I didn't want to mess with the existing one by refactoring it |
| 18:25:51 | evan | you could refactor it out if you'd like. |
| 18:25:51 | Defiler | yeah |
| 18:26:00 | Defiler | is it cool if I do that? |
| 18:26:09 | evan | sure. |
| 18:26:18 | evan | ok, yay, fixed EM |
| 18:26:25 | evan | ^C now exits it's run loop now. |
| 18:27:29 | evan | I just had to understand that EM actually does nothing with it. |
| 18:27:33 | evan | *eyeroll* |
| 18:29:51 | scoopr | could you rephrase that as a paraphrased matrix quote? |
| 18:30:39 | evan | "What was said was for you alone." |
| 18:33:41 | evan | brixen: ok, i'm about done with this EM bug, then I can help ya. |
| 18:34:12 | brixen | n/p |
| 18:34:28 | brixen | http://gist.github.com/412241 |
| 18:34:37 | brixen | I'm trying to figure out setting stack_limit_ now |
| 18:37:13 | evan | it's crappy atm. |
| 18:37:22 | evan | it's set a few places. |
| 18:37:27 | brixen | this is happening on ubuntu 9.10 as well, but that uses gmake 3.81 also |
| 18:37:39 | brixen | 9.10 32bit |
| 18:37:42 | evan | brixen: |
| 18:37:46 | evan | (in /Users/evan/git/rbx/lib/ext/nkf) |
| 18:37:46 | evan | make: *** No rule to make target `ruby.h', needed by `openssl_missing.o'. Stop. |
| 18:37:47 | evan | :/ |
| 18:37:53 | evan | i just updated |
| 18:38:00 | brixen | you need a rake clean |
| 18:38:41 | brixen | someday soon our build will not suck |
| 18:38:43 | brixen | promise |
| 18:38:53 | evan | i just removed the openssl Makefile |
| 18:38:54 | evan | and it's going now. |
| 18:39:03 | brixen | yeah, that's what rake clean does |
| 18:39:18 | evan | the biggest thing about some future build system is how to handle interact with stuff like the openssl extension that uses Make. |
| 18:39:26 | brixen | indeed |
| 18:39:51 | brixen | and a way to force a clean build directly |
| 18:40:01 | brixen | somewhat like configure forces a reconfig |
| 18:40:10 | brixen | but without user intervention |
| 18:40:34 | evan | right. |
| 18:41:13 | Defiler | evan: I'm not really going to leave all these comments in, because they are kinda dumb.. but are they correct? |
| 18:41:16 | Defiler | https://gist.github.com/05745e55c47cbbadaaa6 |
| 18:41:58 | evan | s/examples/values/ |
| 18:42:02 | evan | otherwise fine. |
| 18:42:31 | boyscout | Check async events and raise an exception via rb_thread_select. - ff84fbf - Evan Phoenix |
| 18:43:05 | evan | toulmean: you around? |
| 18:43:12 | evan | brixen: ok, any luck? |
| 18:43:15 | toulmean | evan: yep |
| 18:43:20 | evan | anyway I can repro it |
| 18:43:25 | evan | toulmean: ok, one sec, i need to help brixen |
| 18:43:39 | toulmean | no pb |
| 18:47:32 | evan | brixen: i ran the dl makefile and it seemed to go without issue |
| 18:47:43 | brixen | evan: no, other than when running rbx directly, the value for stack_limit_ is different |
| 18:47:46 | brixen | what platform? |
| 18:47:51 | brixen | it works fine on os x |
| 18:47:51 | evan | OS X |
| 18:47:55 | brixen | of course :) |
| 18:47:58 | evan | ok, what platform is in broken on |
| 18:48:01 | evan | i think i missed that. |
| 18:48:03 | brixen | try on somethisg deb or ubuntu |
| 18:48:10 | brixen | it fails on elle |
| 18:48:17 | brixen | or ubuntu 9.10 |
| 18:48:17 | evan | ok |
| 18:48:21 | brixen | the 2 I've tried it on |
| 18:48:27 | brixen | both use gmake 3.81 |
| 18:48:40 | evan | hm. ok. |
| 18:48:47 | evan | i'm builing on elle now. |
| 18:49:11 | evan | OS XS uses gmake 3.81 too. |
| 18:50:00 | brixen | ah, indeed |
| 18:50:18 | boyscout | CI: rubinius: ff84fbf successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 18:50:18 | evan | so we need a different differential |
| 18:51:03 | evan | ok know, it's probably wrong that stack_limit_ is a intptr_t |
| 18:51:07 | evan | it should probably be a uintptr_t |
| 18:53:40 | Defiler | I'm packaging an llvm for 10.3.1 now |
| 18:53:54 | Defiler | are those checked in somewhere, or are they just on the webserver? |
| 18:54:20 | evan | webserver |
| 18:54:36 | evan | what is your host triple on that machine? |
| 18:54:49 | evan | Defiler: you might want to hold off as well |
| 18:55:05 | evan | i'm about to merge a branch that puts us on LLVM 2.7 |
| 18:55:18 | Defiler | x86_64-apple-darwin10.3.1 |
| 18:55:48 | Defiler | gcc 4.2.1 |
| 18:55:50 | evan | there is a 10.3.1? |
| 18:55:51 | evan | :/ |
| 18:55:53 | Defiler | yeah |
| 18:56:01 | Defiler | right now only the i5 and i7 stuff |
| 18:56:18 | evan | ok, well, put the tar.gz on drop.io or something |
| 18:56:23 | evan | and i'll put it in the right place on elle. |
| 18:56:26 | Defiler | but will be in 10.6.4 everywhere, I believe |
| 18:56:28 | Defiler | k |
| 18:59:33 | evan | brixen: how did you start gdb in the makefile? |
| 19:00:01 | evan | it won't give me the gdb output |
| 19:00:13 | brixen | @gdb --args /home/brixen/devel/rubinius/vm/vm $(srcdir)/mkcallback.rb |
| 19:00:14 | toulmean | evan: about to go for lunch in 10 |
| 19:00:22 | evan | that doesn't seem to work for me. |
| 19:00:23 | toulmean | I will be back in an hour after that |
| 19:00:28 | brixen | under callback.func rule |
| 19:00:29 | toulmean | ping me whenever |
| 19:00:32 | evan | brixen: yeah |
| 19:00:40 | evan | toulmean: ok, got time for a quick question? |
| 19:01:11 | brixen | evan: so, in vm.hpp:170 s == 0x0 when I invoke rbx directly, and under gdb... |
| 19:01:11 | toulmean | ok sure |
| 19:01:12 | brixen | Breakpoint 2, rubinius::VM::set_stack_size (this=0x9ac1ce0, s=-1048577) at vm/vm.hpp:170 |
| 19:01:15 | toulmean | evan: ^^ |
| 19:01:24 | evan | toulmean: for issue 327 |
| 19:01:30 | evan | i don't really follow whats wrong. |
| 19:01:37 | evan | you've defined a trace method that takes an argument |
| 19:01:38 | toulmean | yep ok. |
| 19:01:43 | toulmean | yes |
| 19:01:47 | evan | but then you call it with no arguments |
| 19:01:51 | evan | so whats the issue? |
| 19:01:51 | toulmean | and then I try to access a OpenStruct |
| 19:02:03 | toulmean | with the trace method that is interpreted without arguments |
| 19:02:15 | evan | um |
| 19:02:18 | evan | opensturct? |
| 19:02:23 | evan | i see nothing about OpenStruct anywhere |
| 19:02:24 | toulmean | err, yes |
| 19:02:34 | evan | the issue doesn't mention OpenStruct |
| 19:02:39 | toulmean | Buildr::Application extends Rake::Application |
| 19:02:41 | evan | so i've got no clue what you mean |
| 19:02:53 | toulmean | which has an option method, which returns an OpenStruct |
| 19:03:02 | evan | is application.options an OpenStruct? |
| 19:03:04 | toulmean | evan: my sincere apologies if I'm not making sense. |
| 19:03:07 | toulmean | yes. |
| 19:03:12 | evan | ok, thats the missing info |
| 19:03:12 | evan | :) |
| 19:03:27 | evan | also, what do you mean "bent"? |
| 19:03:27 | toulmean | the thing is, I could not reproduce it with a smaller spec. |
| 19:03:39 | toulmean | let me see my description |
| 19:04:41 | toulmean | oh. We are in a bent situation because we are using that accessor, with an overridden class, in a yield, with a method with the same name defined in the default nm |
| 19:04:48 | evan | no bent |
| 19:04:54 | evan | i don't know what you mean by "bent" |
| 19:04:55 | evan | ? |
| 19:05:01 | evan | your vocab is puzzlingi |
| 19:05:05 | evan | do you mean bad? |
| 19:05:12 | evan | weird? strange? |
| 19:05:15 | brixen | bent == not straight |
| 19:06:04 | brixen | deviate from a straight course or path |
| 19:06:08 | brixen | anyway, that's how I read it |
| 19:06:21 | toulmean | not a straightforward situation |
| 19:06:29 | toulmean | sorry again... that's my French |
| 19:06:37 | brixen | toulmean: haha |
| 19:06:43 | toulmean | ok let me try to repro again with a smaller spec where I use a OpenStruct |
| 19:06:47 | brixen | toulmean: are you saying, "pardon my French" ? |
| 19:06:55 | toulmean | and yes I can certainly do better with bug reports |
| 19:06:55 | evan | toulmean: ok, you mention an accessor, etc. |
| 19:07:03 | evan | could you please write out the scenario verbosely |
| 19:07:04 | toulmean | no I'm actually French. |
| 19:07:08 | brixen | heh |
| 19:07:10 | toulmean | yes |
| 19:07:16 | evan | don't assume i know which accessor you mean, which class you mean, etc. |
| 19:07:27 | toulmean | evan: ok put me that one on hold, and I'll work on making it reproducible |
| 19:07:35 | toulmean | or will close as too difficult to repro |
| 19:07:35 | evan | ok |
| 19:07:50 | brixen | evan: re gdb output, make sure you don't redirect that |
| 19:07:55 | brixen | ie no > blag |
| 19:07:58 | brixen | er blah |
| 19:08:11 | evan | brixen: DOH. |
| 19:08:14 | evan | toulmean: ok, thank you. |
| 19:08:21 | brixen | evan: that's ok, got me too |
| 19:13:35 | evan | brixen: well, zoinks. |
| 19:13:41 | evan | stack_limit_ is pretty much wrong. |
| 19:14:11 | brixen | seems so :) |
| 19:14:45 | brixen | how would you know the stack grows the other way on a platform? |
| 19:14:47 | evan | well, thats bizarre. |
| 19:14:51 | brixen | just out of curiosity |
| 19:15:01 | evan | getrlimit(RLIMIT_STACK, &rlim) |
| 19:15:04 | evan | is say that |
| 19:15:18 | Defiler | http://supremetyrant.com/ruby/llvm-x86_64-apple-darwin10.3.1.tar.bz2 |
| 19:15:18 | evan | (gdb) p rlim.rlim_cur |
| 19:15:19 | evan | $1 = 4294967295 |
| 19:15:22 | Defiler | and http://supremetyrant.com/ruby/llvm-x86_64-apple-darwin10.3.1.tar.bz2.md5 |
| 19:15:45 | evan | I think clamp it |
| 19:15:47 | evan | stupidly. |
| 19:15:52 | evan | and then do a subtraction |
| 19:15:56 | evan | which gives us a negative value. |
| 19:16:26 | evan | make must be resetting the ulimit on the stack |
| 19:16:29 | evan | to max. |
| 19:16:31 | evan | ie, 4G |
| 19:16:36 | brixen | hmm |
| 19:16:37 | brixen | ok |
| 19:16:44 | evan | my init_stack_size is wrong. |
| 19:16:51 | evan | let me see about fixing it... |
| 19:17:49 | evan | hrm |
| 19:19:52 | evan | ah ok |
| 19:19:53 | evan | i see |
| 19:19:59 | evan | rlim_cur is 4G |
| 19:20:08 | evan | i clamp the redzone to 1M |
| 19:20:18 | evan | but 4G - 1M is outside of the range of a signed int |
| 19:20:24 | evan | and cStackDepthMax is a signed int. |
| 19:20:35 | brixen | ahh |
| 19:22:38 | evan | i'm testing the change now. |
| 19:22:55 | evan | i find it strange that make sets ulimit.stack to unlimited. |
| 19:22:56 | evan | but whatever. |
| 19:24:32 | brixen | it is weird |
| 19:32:37 | evan | heh |
| 19:32:43 | evan | this is pretty funny actually |
| 19:32:47 | evan | i'm glad I tested it |
| 19:32:53 | evan | because with a limit of 4G (basically) |
| 19:32:57 | evan | i can't add it to anything |
| 19:33:03 | evan | because it wraps around back to the original value every time |
| 19:33:04 | evan | :D |
| 19:34:10 | brixen | heh |
| 19:34:43 | evan | hm, how should I handle this... |
| 19:35:02 | evan | perhaps always clamp it to 1G of stack |
| 19:35:03 | brixen | maybe we need -Xstack_size |
| 19:35:05 | brixen | yeah |
| 19:35:10 | brixen | something smaller |
| 19:35:10 | evan | 1G is A LOT of stack |
| 19:35:14 | evan | A LOOOOOT |
| 19:35:15 | brixen | no kidding |
| 19:36:49 | Defiler | hrm, suddenly getting this after pulling: make: *** No rule to make target `ruby.h', needed by `openssl_missing.o'. Stop. |
| 19:36:50 | evan | maybe 128M? |
| 19:37:03 | evan | Defiler: rake clean or rm lib/ext/openssl/Makefile |
| 19:37:04 | Defiler | lib/ext/nkf |
| 19:37:14 | evan | it's really in openssl |
| 19:37:15 | Defiler | yeah this is after a nuke of all build products |
| 19:37:26 | Defiler | let me try again I guess |
| 19:40:01 | brixen | Defiler: openssl uses extconf.rb and a Makefile |
| 19:40:06 | brixen | it doesn't play well |
| 19:40:11 | brixen | but this situation is rare |
| 19:40:17 | brixen | I changed where ruby.h lives |
| 19:40:38 | Defiler | aah |
| 19:41:09 | Defiler | oh, I see what I did.. I nuked, packaged llvm, pulled, reconfigured, built |
| 19:41:20 | Defiler | it's probably going to work fine when it is done rebuilding this time |
| 19:41:32 | brixen | we have no way to force a clean build |
| 19:41:41 | brixen | which we need to do from time to time |
| 19:41:46 | Defiler | I should name my shell history file .legacy_of_madness |
| 19:43:26 | evan | brixen: ok, got it fixed by clamping the stack size to 128M |
| 19:43:47 | evan | no one should need more that 128M of stack </famous_last_words> |
| 19:43:52 | brixen | heh |
| 19:43:59 | brixen | we'll add -Xstack_size in that case |
| 19:45:01 | Defiler | -Xenterprisemode |
| 19:45:05 | brixen | haha |
| 19:45:16 | evan | Defiler: YES. |
| 19:45:18 | Defiler | -Xseriousserverwepaidalotfor |
| 19:45:30 | evan | we should probably go for |
| 19:45:42 | evan | -X-mode=enterpriselevel:11 |
| 19:45:48 | brixen | -Xrubinius_maximus |
| 19:46:07 | brixen | unfortunately, that cannot all go in one switch |
| 19:46:11 | brixen | it must be 40 |
| 19:47:24 | brixen | evan: grabbing some food... |
| 19:47:29 | evan | me too |
| 19:47:34 | evan | i'm about to commit the fix for you. |
| 19:48:40 | brixen | evan: are you going to re-enable building DL? |
| 19:49:03 | Defiler | --nextoption="enterprise.mode" --@ultra-11 |
| 19:49:13 | Defiler | got to have position sensitive arguments |
| 19:49:24 | brixen | fo sho |
| 19:49:34 | boyscout | factor out some jit code from push_cpath_top and push_rubinius - 254ec08 - Wilson Bilkovich |
| 19:49:44 | brixen | that is, if you want to be taken seriously |
| 19:50:31 | Defiler | -1 --lastoptionwasabout="something" |
| 19:52:32 | evan | brixen: i'll let you do that. |
| 19:56:47 | kronos_vano | http://gist.github.com/412344 1.75x String#[] speed up |
| 19:57:34 | boyscout | CI: rubinius: 254ec08 successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 19:57:53 | Defiler | oh yeah, definitely |
| 19:58:05 | Defiler | some of those lines in red are really not smart :) |
| 19:58:24 | evan | kronos_vano: nice! if it passes all the specs, commit it! |
| 19:58:40 | kronos_vano | evan, of course it passed :) |
| 19:58:45 | evan | kronos_vano: :D |
| 19:59:01 | Defiler | does that need to be self.size there? |
| 19:59:17 | evan | could have @total |
| 19:59:39 | kronos_vano | hm. |
| 19:59:50 | kronos_vano | I should try |
| 19:59:58 | Defiler | yeah I think use @total where you are calling 'size' now |
| 20:00:23 | kronos_vano | mm may be @num_bytes ? |
| 20:00:39 | evan | yes |
| 20:00:42 | evan | @num_bytes |
| 20:05:25 | boyscout | Handle very large values from getrlimit properly - 149a517 - Evan Phoenix |
| 20:16:38 | maharg | 128M of stack could be low with certain kinds of large-object-on-the-stack C++ code |
| 20:17:18 | boyscout | CI: rubinius: 149a517 successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 20:23:14 | dwaite | ouch, 128M on a stack? |
| 20:23:33 | slava | that's a pretty big stack |
| 20:24:02 | dwaite | I think 8M is a pretty big stack :) |
| 20:28:58 | boyscout | Speed up String#[] and String#=~ - 6559f4d - Ivan Samsonov |
| 20:36:52 | boyscout | CI: rubinius: 6559f4d successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 20:38:26 | evan | maharg: if you have such an example, please show me :) |
| 20:52:07 | brixen | well, that was bizarre, just got 500 errors running on ubuntu 9.10 that weakref_alive? is a private method |
| 20:52:10 | brixen | which it is not |
| 20:52:26 | evan | weird... |
| 20:52:28 | brixen | ran again, changing nothing, and they all pass |
| 20:54:13 | evan | :/ |
| 21:06:54 | brixen | evan: so, I've been pondering how to gen stuff for c-api specs |
| 21:07:01 | evan | k |
| 21:07:02 | brixen | my conclusion is, I'm not going to |
| 21:07:06 | brixen | too complex for no real gain |
| 21:07:08 | evan | hah |
| 21:07:12 | evan | i agree |
| 21:07:14 | brixen | instead, I'm going to define some C macros |
| 21:07:20 | evan | since almost every one is different |
| 21:07:22 | evan | k |
| 21:07:31 | brixen | mri defines RUBY, we define RUBINIUS, so jruby can define JRUBY |
| 21:07:41 | brixen | then, they need to give some thought to what they will support |
| 21:07:49 | brixen | and annotate the C files accordingly |
| 21:08:06 | brixen | also, I need to make configure.rb output capi/include/version.h like MRI does |
| 21:08:23 | brixen | which has C macros for RUBY_VERSION_MAJOR, MINOR, etc |
| 21:08:41 | brixen | because we've started adding c-api that mri does not have |
| 21:08:55 | brixen | and if jruby wants to collab on a better c-api, we need to be able to handle that |
| 21:09:01 | evan | ok, back u |
| 21:09:02 | evan | up |
| 21:09:04 | evan | thats all fine |
| 21:09:09 | evan | what is our goal? |
| 21:09:22 | brixen | running the C-API specs on multiple impl |
| 21:09:32 | evan | why do we need to change them from their form to run them on, say, jruby? |
| 21:09:33 | brixen | without adding a bunch of complexity |
| 21:09:43 | evan | from their current form, that is. |
| 21:09:46 | brixen | because jruby will not support all the functions |
| 21:09:59 | brixen | just like MRI does not support rb_thread_blocking_region |
| 21:10:16 | brixen | you can't load that lib on MRI unless that spec is #ifdef'd in the C file |
| 21:10:24 | evan | sure |
| 21:10:31 | evan | so why not put #ifdef guards around those specific things |
| 21:10:33 | brixen | git show 5377580cc |
| 21:10:36 | brixen | we will |
| 21:10:40 | brixen | that's my whole point |
| 21:10:42 | evan | and have a way to configure a header file that will define them |
| 21:10:50 | brixen | but it needs to be easier |
| 21:11:12 | brixen | eg #ifdef IMPL(RUBINIUS, 1, 8, 7) |
| 21:11:13 | evan | ah, ok, i see. |
| 21:11:18 | evan | ew. |
| 21:11:22 | brixen | that's what I mean by adding some C macros |
| 21:11:23 | brixen | eww |
| 21:11:24 | evan | why force it to be on the impl and version? |
| 21:11:29 | evan | why not per feature? |
| 21:11:35 | brixen | huh? |
| 21:11:47 | brixen | mri adds rb_hash_lookup in 1.8.7 |
| 21:11:56 | brixen | it does not exist in 1.8.6 |
| 21:11:59 | evan | ok, here's my thought |
| 21:12:03 | brixen | rb_set_errinfo is adden in 1.9 |
| 21:12:06 | evan | you want to add platfrom version guards |
| 21:12:20 | evan | which implies a relationship between a version and functionality in that version |
| 21:12:23 | evan | correct? |
| 21:12:28 | brixen | yep |
| 21:12:48 | evan | why not instead require that the guard be for the functionality directly |
| 21:12:50 | brixen | we can have a bunch of #ifdef HAVE_BLAH |
| 21:13:31 | brixen | how would you express "for the functionality directly" |
| 21:13:32 | brixen | in C |
| 21:13:52 | evan | and then each impl provides a header file that defines the proper things for the functionality they support |
| 21:14:01 | evan | well, in that commit you have |
| 21:14:06 | brixen | so a bunch of #ifdef HAVE_BLAH ? |
| 21:14:08 | evan | #ifdef HAVE_RB_HASH_LOOKUP |
| 21:14:12 | evan | is a simple way. |
| 21:14:12 | brixen | sure |
| 21:14:24 | evan | then jruby just needs to #define HAVE_RB_HASH_LOOKUP |
| 21:14:26 | evan | to run it. |
| 21:14:32 | evan | that lets us cut it up nicely |
| 21:14:42 | evan | and not hardcode version requirements in the specs |
| 21:14:45 | brixen | it's more semantic, yes |
| 21:15:12 | brixen | it means we (me) have to maintain that file for MRI too |
| 21:15:18 | evan | a halfway measure is to provide a meta-syntax |
| 21:15:24 | evan | that the specs are generated from |
| 21:15:24 | brixen | which I guess is no more than I would anyway |
| 21:15:25 | evan | ie, |
| 21:15:32 | evan | @feature rb_hash_lookup |
| 21:15:35 | evan | .... |
| 21:15:36 | evan | @end |
| 21:15:49 | evan | we'd run that through a script |
| 21:15:51 | brixen | I do not want to generate it from the specs |
| 21:15:55 | evan | the output would have an #ifdef guard |
| 21:16:04 | evan | and a call to rb_define_method at the bottom |
| 21:16:23 | evan | sure, i'm just thinking of a way to simplify the guards |
| 21:16:31 | brixen | that means mucking with all the existing guard stuff |
| 21:16:38 | brixen | I want this to work with existing mspec guards |
| 21:16:53 | brixen | tagging, platform guards, etc |
| 21:17:26 | evan | sure sure |
| 21:17:28 | evan | just a thought. |
| 21:19:18 | evan | you can't do |
| 21:19:19 | evan | #ifdef IMPL(RUBINIUS, 1, 8, 7) |
| 21:19:20 | evan | btw |
| 21:19:37 | brixen | why not? |
| 21:19:38 | brixen | ## |
| 21:19:50 | brixen | will that not expand? |
| 21:20:03 | brixen | I mean #if IMPL |
| 21:20:49 | evan | how do you define IMPL? |
| 21:21:04 | evan | http://www.cims.nyu.edu/cgi-comment/info2html?(cpp)If |
| 21:21:05 | evan | btw. |
| 21:22:29 | toulmean | ok I tried again to reproduce using a simpler structure issue 327 - in vain |
| 21:22:48 | toulmean | I will document how I get there instead. I'll try to make it obvious. |
| 21:23:45 | evan | k |
| 21:23:49 | evan | i can try to run the specs also. |
| 21:23:55 | evan | thats probably my best bet. |
| 21:24:11 | toulmean | evan: the spec of Buildr ? Yes. That's what I'll try to doc |
| 21:24:20 | evan | yes |
| 21:24:23 | evan | specs of Buildr. |
| 21:24:35 | toulmean | you will reproduce for sure if you bin/rbx -S spec path/to/buildr/spec/java/java_spec.rb |
| 21:24:48 | toulmean | but... you might need to install dependencies first. |
| 21:25:18 | evan | can you document how to run the specs? |
| 21:25:21 | evan | that would help |
| 21:25:29 | toulmean | yes. |
| 21:25:35 | evan | thanks! |
| 21:26:15 | brixen | evan: yeah, I was just trying to make the #ifdef guards easier, HAVE_FEATURE works fine |
| 21:26:56 | evan | HAVE_FEATURE is more straightforward |
| 21:27:01 | evan | it's just a little tedious |
| 21:27:01 | brixen | indeed |
| 21:27:03 | evan | but thats C for ya. |
| 21:27:07 | brixen | right |
| 21:27:13 | brixen | but explicit is better |
| 21:27:15 | evan | woo! |
| 21:27:20 | brixen | and less headaches |
| 21:27:26 | evan | nari's book with the rubinius chapter just arrived! |
| 21:27:32 | brixen | hah, nice! |
| 21:27:37 | brixen | it's in japanese, no? |
| 21:27:47 | evan | oh man, i so want to read it! |
| 21:27:51 | evan | yeah, it's in japanese |
| 21:27:52 | brixen | heh |
| 21:27:52 | evan | thats ok! |
| 21:28:00 | brixen | get to studying |
| 21:28:02 | evan | i'm proud to have a copy even if i can't read it (yet) |
| 21:29:33 | evan | hehhe |
| 21:29:49 | evan | it's really incredibly fun to see our ObjectHeader class in a book. |
| 21:30:02 | brixen | take a picture! |
| 21:30:10 | brixen | I suppose I should order the book... |
| 21:30:19 | brixen | I'm trying to not order any more paper books |
| 21:30:29 | brixen | I have 1000lbs of paper books :/ |
| 21:30:30 | evan | well, maybe hold out of this then |
| 21:30:46 | evan | since it's a pure art thnig for me |
| 21:30:49 | evan | since I can't read it. |
| 21:30:59 | Defiler | we should hire norio wakamoto to read it aloud http://www.youtube.com/watch?v=9V1AEvN8VZs |
| 21:31:25 | brixen | Defiler: haha |
| 21:31:33 | evan | http://skitch.com/evanphx/dfyty/cam |
| 21:31:45 | brixen | woot! |
| 21:31:54 | brixen | that is awesome |
| 21:32:20 | Defiler | it should have a bmx bike on the cover |
| 21:32:32 | Defiler | crashing through a dinosaur |
| 21:32:44 | Defiler | ridden by a liquid terminator |
| 21:32:49 | evan | haha |
| 21:34:34 | evan | oh! he goes over c-api! |
| 21:34:41 | evan | (i think) |
| 21:34:53 | evan | i'm infering things from diagrams mostly |
| 21:36:00 | toulmean | evan: ok I updated the bug with a path for reproduction at the bottom. |
| 21:36:04 | toulmean | You can hate me now... |
| 21:36:28 | toulmean | I might need to send frosty beverages your way (both of you guys) once this stuff runs. |
| 21:37:44 | evan | i wonder how much it would be to get the Rubinius chapter translated. |
| 21:37:49 | evan | toulmean: :D |
| 21:38:38 | evan | toulmean: ok, i'm about to fix another bug |
| 21:38:42 | evan | then i'll switch to yours |
| 21:43:12 | brixen | hm, rjb uses OBJ_FREEZE in one spot, but of course that exposes some sort of bug with freeze |
| 21:43:35 | brixen | and I'm segfaulting in LookupTable::store |
| 21:43:41 | evan | :/ |
| 21:43:43 | brixen | so, maybe coffee first |
| 21:43:50 | evan | good plan. |
| 21:43:53 | brixen | :) |
| 21:47:32 | boyscout | Re-enable building DL extension. - e99f097 - Brian Ford |
| 21:47:47 | brixen | crosses fingers |
| 21:48:40 | toulmean | back in da game! |
| 21:48:48 | evan | nari: i got the book! |
| 21:48:50 | evan | thank you so much! |
| 21:48:56 | evan | it's so much fun to see Rubinius details in a book |
| 21:49:20 | nari | evan: You're welcome! |
| 21:51:52 | evan | nari: now I must start learning japanese! |
| 21:52:13 | nari | evan: wow!! |
| 21:52:45 | somebody | ๆฅๆฌ่ช :) |
| 21:52:53 | brixen | nihon go! |
| 21:53:27 | brixen | nihon go wa tottemo omoshiroi desu nee |
| 21:53:33 | kronos_vano | oO |
| 21:53:41 | brixen | sorry, I cant write that in kanji |
| 21:53:47 | brixen | but I know how to say it :) |
| 21:53:53 | kronos_vano | haha) |
| 21:54:40 | nari | Good nihon-go :) |
| 21:55:08 | brixen | juu-go nen mai, nihon go o benkyoo shite imashita |
| 21:55:19 | brixen | unfortunately, I stopped |
| 21:55:24 | brixen | *sob* |
| 21:55:44 | evan | brixen: holiday bonus if you can translate the Rubinius chapter by the winter holidays! |
| 21:55:48 | brixen | nari: can I order a book? :) |
| 21:55:48 | evan | :D |
| 21:55:58 | brixen | evan: haha, don't tempt me :) |
| 21:56:00 | evan | brixen: it's on amazon.jp |
| 21:56:16 | brixen | evan: but do I need to read Japanese to order from amazon.jp?? |
| 21:56:19 | brixen | :) |
| 21:56:49 | evan | i think you can do it without |
| 21:56:55 | evan | i'd tell you what to search for |
| 21:56:58 | evan | but i don't know how to type it! |
| 21:57:31 | evan | found it |
| 21:57:32 | evan | http://www.amazon.co.jp/%E3%82%AC%E3%83%99%E3%83%BC%E3%82%B8%E3%82%B3%E3%83%AC%E3%82%AF%E3%82%B7%E 3%83%A7%E3%83%B3%E3%81%AE%E3%82%A2%E3%83%AB%E3%82%B4%E3%83%AA%E3%82%BA%E3%83%A0%E3%81%A8%E5%AE%9F%E8 %A3%85-%E4%B8%AD%E6%9D%91-%E6%88%90%E6%B4%8B/dp/4798025623/ref=sr_1_12?ie=UTF8&s=books&qid=1 274738237&sr=8-12 |
| 21:57:36 | evan | ZINGO |
| 21:57:39 | brixen | I of course searched for 'Rubinius garbage collectors' |
| 21:57:40 | evan | damn dawg. |
| 21:57:50 | evan | I put some escape codes in your url so you could escape your url. |
| 21:58:17 | brixen | heh |
| 21:58:25 | brixen | evan: my search got me the book! |
| 21:58:35 | brixen | it's the guy with a kid on his shoulders, yeah? |
| 21:58:56 | nari | brixen: yeah! |
| 21:59:00 | brixen | (that's what your link brings up) |
| 21:59:04 | brixen | heh, how did I know |
| 21:59:25 | brixen | 3,360?? that's going to have to wait a bit |
| 21:59:30 | brixen | oh, yen, nvm |
| 21:59:34 | boyscout | Spec showing Object's includes are search as a last resort - 3d5896b - Evan Phoenix |
| 21:59:34 | boyscout | Search Object's includes also. Fixes #328 - 836d4b5 - Evan Phoenix |
| 21:59:34 | evan | hahahah |
| 21:59:39 | evan | brixen: hahah |
| 21:59:43 | brixen | heh |
| 21:59:46 | brixen | just keeeeding |
| 21:59:52 | evan | it's $35 |
| 22:00:05 | evan | actually, what is rate... |
| 22:00:21 | evan | oh, 90 |
| 22:00:37 | evan | so $37 |
| 22:00:50 | evan | a lot cheaper than a lot of books here |
| 22:01:13 | brixen | I added it to my wish list |
| 22:01:19 | kronos_vano | As I remember someone want to release 1.0.1 today :) |
| 22:01:21 | brixen | evan: you should send me yours and I'll translate it for you :) |
| 22:01:32 | evan | brixen: i'll bringing it to railsconf. |
| 22:01:36 | brixen | heh |
| 22:01:36 | brixen | ok |
| 22:03:05 | brixen | I had an awesome kanji dictionary/learing tutor on my zaurus |
| 22:03:16 | brixen | I wonder what there is for the iPad these days |
| 22:03:26 | toulmean | evan: brixen: think the code I have for rjb is good enough I can do a pull request on it ? |
| 22:03:31 | brixen | er learning, not learing |
| 22:03:40 | evan | toulmean: which? |
| 22:03:42 | brixen | toulmean: what code? |
| 22:03:56 | toulmean | err, my fork you guys helped me with the instructions |
| 22:04:05 | toulmean | remember ? RBASIC ? RHASH_TBL ? |
| 22:04:26 | evan | oh oh |
| 22:04:33 | toulmean | url: http://github.com/atoulme/rjb/ |
| 22:04:34 | evan | i thought you had the main rjb repo! |
| 22:04:35 | evan | soryr |
| 22:04:38 | evan | i forgot |
| 22:04:41 | evan | let me look over it |
| 22:04:44 | evan | i'm starting in your bug |
| 22:04:50 | evan | i'll check out the code after that. |
| 22:04:56 | toulmean | my bug doesn't load rjb .... |
| 22:05:04 | evan | um |
| 22:05:06 | toulmean | I can tell rjb now compiles with rubinius. |
| 22:05:08 | evan | why does your bug say to istall it? |
| 22:05:24 | evan | what should I set JAVA_HOME to? |
| 22:05:38 | boyscout | CI: rubinius: e99f097 successful: 3463 files, 13859 examples, 41513 expectations, 0 failures, 0 errors |
| 22:05:42 | brixen | prabably JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/ |
| 22:05:47 | brixen | that's where it is for me |
| 22:05:58 | evan | k |
| 22:06:35 | brixen | toulmean: we should probably add a HAVE_RB_HASH_FOREACH and use that in code |
| 22:06:43 | brixen | rather than RHASH_TBL == 1 |
| 22:06:53 | toulmean | brixen: yes :) but it's up to you |
| 22:07:11 | brixen | toulmean: well, we'd likely accept a patch for that :) |
| 22:07:12 | evan | never do RHASH_TBL == 1 |
| 22:07:14 | evan | always do |
| 22:07:17 | evan | #ifdef RHASH_TBL |
| 22:07:29 | evan | 0 is a fine value for it to be defined to |
| 22:07:35 | toulmean | evan: aha, but see the code fragment here: |
| 22:07:47 | brixen | toulmean: vm/capi/include/defines.h if you want to add that |
| 22:07:57 | toulmean | brixen: will do |
| 22:08:28 | toulmean | evan: http://github.com/atoulme/rjb/blob/master/ext/rjb.c#L1783 |
| 22:08:36 | brixen | ok, never got that coffee, bbiab... |
| 22:08:49 | evan | toulmean: yes, if i'ts defined |
| 22:08:54 | evan | don't test that it's 1 |
| 22:09:05 | toulmean | evan: well it's defined in other cases |
| 22:09:10 | toulmean | that's my point. |
| 22:09:11 | evan | show me |
| 22:09:14 | evan | i don't get what you mean. |
| 22:09:15 | brixen | we define it as 1 |
| 22:09:20 | toulmean | evan: http://github.com/atoulme/rjb/blob/master/ext/rjb.c#L1783 ? |
| 22:09:23 | brixen | so you can't just go on it being defined |
| 22:09:34 | brixen | that's why HAVE_RB_HASH_FOREACH would be better |
| 22:09:34 | evan | i define it as 1 just to have it be defined |
| 22:09:37 | evan | this is the wrong way to do it |
| 22:09:38 | evan | yes |
| 22:09:46 | evan | we need to use HAVE_RB_HASH_FORACH |
| 22:09:51 | evan | wtf |
| 22:09:53 | brixen | heh |
| 22:09:55 | evan | why is rake setup asking for my password? |
| 22:10:05 | brixen | it sudo installs |
| 22:10:07 | evan | ok ^C that. |
| 22:10:15 | evan | .... |
| 22:10:18 | brixen | yes, I've advised toulmean on that :) |
| 22:10:21 | evan | not for long. |
| 22:11:13 | evan | this is prety weird |
| 22:11:37 | toulmean | evan: file a bug... |
| 22:11:49 | evan | ok |
| 22:12:02 | evan | a rake task that install gems seems pretty weird. |
| 22:12:07 | evan | personally. |
| 22:12:43 | evan | although it's clever |
| 22:12:51 | toulmean | evan: how do you install gems from a gemspec file ? |
| 22:12:57 | evan | since it uses rubygems and it's own gemspec to figure out whats missing. |
| 22:12:59 | toulmean | I looked for that recently |
| 22:13:02 | toulmean | yep |
| 22:13:09 | evan | toulmean: you don't normally |
| 22:13:13 | evan | you make it a gem |
| 22:13:15 | evan | and install it |
| 22:13:18 | evan | and let rubygems handle it |
| 22:13:23 | evan | i guess since most people use it via a gem |
| 22:13:25 | toulmean | well it's stupid too - as brixen remarked, you need to install rjb as a gem, not extconf.rb, otherwise it complains. |
| 22:13:27 | evan | they don't do this weird rake setup |
| 22:13:37 | toulmean | yeah it's for devs |
| 22:13:41 | toulmean | aka you ppl |
| 22:13:45 | evan | :) |
| 22:14:07 | evan | well, I removed ' << "sudo " ' and it's a bit saner |
| 22:14:11 | slava | yo evan |
| 22:14:43 | toulmean | evan: patches on issues.apache.org/jira/browse/BUILDR |
| 22:14:48 | evan | toulmean: ok. |
| 22:14:52 | evan | slava: hello sir. |
| 22:19:22 | evan | toulmean: ok, i've got the failure |
| 22:19:29 | toulmean | cool |
| 22:20:57 | slava | evan: you wrote a gtk binding for ruby at some point right? |
| 22:21:46 | evan | i worked on some a very long time ago. |
| 22:21:54 | evan | i didn't write them from scratch |
| 22:22:12 | slava | did you manage to integrate the gtk event loop with ruby's IO event loop? |
| 22:22:16 | evan | yeah |
| 22:22:27 | slava | can you point me to your code, or a gtk api? |
| 22:22:34 | evan | glib (the lower part of gtk) had some hooks for integrating it's event loop with something else |
| 22:22:38 | evan | sure one sec |
| 22:22:42 | evan | i'll have to look it up again |
| 22:22:56 | slava | no rush |
| 22:23:12 | slava | a gtk binding was contributed to factor, and we need to sort out the event loop business |
| 22:23:24 | evan | there is http://library.gnome.org/devel/glib/unstable/glib-The-Main-Event-Loop.html#g-main-context-set-poll -func |
| 22:23:55 | evan | to switch threads within the poll func though, you'd have to save the stack |
| 22:23:59 | evan | which i think you do anyway |
| 22:24:36 | slava | actually, it looks like instead of replacing the poll func, I can just call g_main_context_add_poll () |
| 22:25:40 | slava | thanks |
| 22:26:40 | evan | are you going to use it's event loop then? |
| 22:28:09 | slava | yes |
| 22:28:15 | slava | and stick our epoll / kqueue into it |
| 22:28:17 | slava | with a callback |
| 22:28:19 | slava | we do the same thing on OS X |
| 22:28:20 | evan | ah cool |
| 22:28:22 | evan | aah |
| 22:28:28 | evan | didn't realize you inverted the loop that way |
| 22:28:30 | evan | makes sense |
| 22:28:34 | slava | we don't have to take over the event loop per se, just some mechanism to stick a bunch of FDs into it |
| 22:28:36 | evan | easy to graft your loop onto it |
| 22:28:39 | evan | than the other way around |
| 22:28:42 | slava | yeah |
| 22:28:44 | evan | s/easy/easier/ |
| 22:28:50 | slava | on OS X, you can't run the event loop yourself |
| 22:28:56 | slava | I already went through the pain of making everything generic here |
| 22:29:12 | evan | :) |
| 22:30:00 | evan | toulmean: figured it out |
| 22:30:10 | evan | for some reason, trace is being added a public method on Object |
| 22:30:21 | evan | which is keeping OpenStruct#method_missing from being run. |
| 22:30:47 | toulmean | evan: but, but, why can't I reproduce it then ? |
| 22:30:49 | toulmean | I don't get it. |
| 22:31:02 | evan | you can. |
| 22:31:15 | evan | http://gist.github.com/412510 |
| 22:31:17 | toulmean | sorry I meant: I tried to repro at a smaller scale |
| 22:31:25 | evan | i don't know what you changed |
| 22:31:27 | evan | so i can't say |
| 22:31:36 | evan | there is a bug somewhere |
| 22:31:43 | evan | that is causing trace to become public |
| 22:31:45 | toulmean | evan: sounds what I wanted to produce, however, you're not in a spec |
| 22:31:47 | evan | i'm working on finding it now. |
| 22:32:02 | evan | i asked for a repro |
| 22:32:03 | evan | not a bug fix |
| 22:32:18 | evan | i don't need the repro to be in the exact atmosphere of the bug |
| 22:32:20 | toulmean | I am thinking doing a def trace at the root of the spec method didn't trigger it |
| 22:32:24 | toulmean | oh sure |
| 22:32:26 | evan | just something that demo's the bug |
| 22:32:33 | toulmean | I know... I agree... |
| 22:32:41 | evan | i repro in the spec would be close to a bug fix |
| 22:32:49 | toulmean | I just wasn't able to reproduce within a spec file. |
| 22:32:51 | toulmean | oh ? |
| 22:32:53 | toulmean | ok |
| 22:32:53 | evan | why you can't repro in smaller in the spec? i don't know, thats what i'm working on. |
| 22:33:13 | toulmean | ok - hey don't get me wrong. I wish I had helped more. |
| 22:33:34 | evan | it's no problem. |
| 22:33:41 | evan | when someone can't get a smaller repro |
| 22:33:44 | evan | any repro is good. |
| 22:35:13 | toulmean | I'll keep that in mind. Thanks for sharing. |
| 22:35:46 | evan | no prob. |
| 22:35:54 | evan | i'll have the bug fixed shortly i hope. |
| 22:37:57 | toulmean | evan: just for the thrill I pasted your code inside a spec and could not reproduce then. My guess is that whenever inside a spec methods are defined on Object, rather in a contained space |
| 22:38:25 | evan | i don't follow you |
| 22:39:53 | toulmean | evan: I pasted your code at the end of spec/ruby/language/super_spec.rb |
| 22:40:14 | toulmean | inside a block: it "should call method_missing even though a method with the same name but different parameters is defined" do |
| 22:40:21 | toulmean | #paste Evan's code |
| 22:40:22 | toulmean | end |
| 22:40:32 | toulmean | run that with spec |
| 22:40:45 | evan | toulmean: why would you do that? |
| 22:41:06 | toulmean | evan: that's not how you reproduce bugs ? |
| 22:41:15 | evan | i repro them in a standalone script |
| 22:41:17 | evan | like I showed you |
| 22:41:22 | toulmean | my apologies. That's how we do it with buildr. |
| 22:41:30 | evan | running that straight in a spec might not work |
| 22:41:36 | toulmean | yes: we value specs as reproducible scenarios |
| 22:41:37 | evan | because it's got interactions with the toplevel |
| 22:41:40 | toulmean | yes, looks like it. |
| 22:41:43 | toulmean | yep... |
| 22:41:45 | evan | and specs are run in instance_eval |
| 22:42:11 | toulmean | evan: ok. Now I know why I could not repro in a spec. That was my interrogation. |
| 22:42:14 | brixen | evan: remember all methods at toplevel are private |
| 22:42:21 | brixen | we never fixed that |
| 22:42:24 | evan | brixen: they're supposed to be. |
| 22:42:29 | evan | but they don't appear to be. |
| 22:42:29 | brixen | yes |
| 22:42:33 | evan | oh wait |
| 22:42:33 | brixen | we don't do it right |
| 22:42:36 | evan | haha |
| 22:42:37 | evan | really? |
| 22:42:40 | evan | i thought we fixed this? |
| 22:42:40 | brixen | I had a half patch |
| 22:42:42 | brixen | yes, |
| 22:42:43 | brixen | on |
| 22:42:45 | brixen | er |
| 22:42:46 | brixen | no |
| 22:42:46 | evan | well shit on me. |
| 22:42:48 | brixen | :) |
| 22:42:49 | evan | thats the bug. |
| 22:42:52 | brixen | yes |
| 22:42:56 | slava | a half patch? |
| 22:43:00 | slava | is that a patch with just the - lines in it? |
| 22:43:00 | brixen | there's the issue of knowing when you are at the top |
| 22:43:07 | evan | there is an easy fix. |
| 22:43:08 | brixen | slava: no, it half worked |
| 22:43:12 | brixen | le'me see if I have it |
| 22:43:37 | evan | emit "push_variables; set_toplevel_scope" as bytecode at the top of a script |
| 22:44:02 | brixen | evan: very old but http://gist.github.com/412523 |
| 22:44:23 | brixen | there are complications |
| 22:44:39 | brixen | like the fact that eval("def foo; end") is not private |
| 22:44:48 | evan | ew. |
| 22:44:53 | evan | this is very complicated. |
| 22:44:53 | brixen | hah |
| 22:44:57 | brixen | eww |
| 22:45:07 | evan | ok, i'm going to ignore this |
| 22:45:08 | brixen | that's how you recommended trying to fix it |
| 22:45:09 | evan | sorry :) |
| 22:45:12 | evan | i was wrong. |
| 22:45:17 | brixen | now we know |
| 22:45:18 | evan | way too complicated. |
| 22:45:41 | evan | actually, i've got a quick fix i'll bet. |
| 22:45:46 | brixen | it was also 8 months ago |
| 22:46:01 | brixen | as long as it works |
| 22:46:08 | brixen | probably some specs for this missing |
| 22:46:14 | evan | why can't I do it even if it doesn't work? |
| 22:46:16 | evan | you're no fun. |
| 22:46:21 | brixen | :) |
| 22:47:52 | brixen | hmm, as I recall, I wanted to emit something at the top of a script |
| 22:47:56 | brixen | but you didn't want that |
| 22:48:07 | brixen | I guess we'll see what the fix is :) |
| 22:48:46 | evan | oh how the tides have turned Mr. Ford. |
| 22:48:52 | brixen | heh |
| 22:50:13 | brixen | toulmean: how much do you know about rjb C code? |
| 22:50:25 | toulmean | brixen: pretty much nothing. |
| 22:50:42 | toulmean | I know it segfaults on me every now and then. |
| 22:50:44 | dwaite | rjb? |
| 22:50:51 | brixen | toulmean: heh, ok |
| 22:50:54 | toulmean | I also listened carefully to you and your advices |
| 22:51:01 | toulmean | and plugged holes till it compiled. |
| 22:51:07 | dwaite | asks the googles |
| 22:51:26 | toulmean | dwaite: look for ruby java bridge |
| 22:51:26 | brixen | dwaite: ruby-java bridge |
| 22:51:36 | dwaite | oh :| |
| 22:51:39 | toulmean | yes. |
| 22:51:41 | brixen | dwaite: it loads the jvm in a C ext and does horrible things to it |
| 22:51:41 | dwaite | isn't that unmaintained? |
| 22:51:43 | brixen | I mean, with it |
| 22:51:52 | dwaite | that jvm totally had it coming |
| 22:51:57 | brixen | heh |
| 22:51:58 | slava | will jruby's upcoming C ext support be able to run rjb? |
| 22:52:00 | toulmean | dwaite: well the maintainer released 1.2.0 for SL |
| 22:52:10 | brixen | slava: hopefully! :) |
| 22:52:21 | toulmean | jruby uses FFI |
| 22:52:30 | toulmean | we don't rely on rjb with JRuby |
| 22:52:35 | toulmean | we tap in the JVM directly |
| 22:52:48 | toulmean | we have an interface to use either RJB or JRuby transparently |
| 22:52:48 | brixen | toulmean: don't you use JI on jruby? |
| 22:52:50 | dwaite | oh wow |
| 22:53:01 | toulmean | brixen: sorry ? Java Integration ? |
| 22:53:03 | toulmean | yes |
| 22:53:03 | dwaite | so it looks like it works fine as long as you stay away from the Thread class? |
| 22:53:08 | toulmean | yes |
| 22:53:11 | brixen | toulmean: ok, so JI not ffi? |
| 22:53:12 | toulmean | well we do javac |
| 22:53:19 | toulmean | brixen: correct. |
| 22:53:21 | brixen | ok |
| 22:53:28 | toulmean | though we also use FFI for other stuff |
| 22:53:32 | toulmean | oh well. |
| 22:53:33 | brixen | cool |
| 22:54:07 | toulmean | I hope the changes I made to rjb on your advice can be accepted by the maintainer. |
| 22:54:10 | evan | brixen: https://gist.github.com/6af3a63948cf384d9782 |
| 22:54:15 | toulmean | We can go over them together |
| 22:54:21 | dwaite | I must have been thinking of the ruby cocoa bridge |
| 22:54:22 | toulmean | or not. |
| 22:55:10 | brixen | toulmean: did you change it to HAVE_RB_HASH_FOREACH ? |
| 22:55:17 | toulmean | not yet. |
| 22:55:18 | brixen | toulmean: I can add that to rbx quickly |
| 22:55:21 | brixen | ok, you should |
| 22:55:29 | brixen | before you send a pull request |
| 22:55:37 | toulmean | brixen: ok. Let me give you a patch for it. |
| 22:55:54 | brixen | evan: woot! |
| 22:56:10 | brixen | evan: always love to see '# hack' in your commits :) |
| 22:56:19 | evan | :D |
| 22:56:20 | brixen | probably means loads of fun in the future for one of us |
| 22:56:23 | brixen | :) |
| 22:56:26 | evan | i'm going to extract it into a method |
| 22:56:30 | evan | #for_script? |
| 22:56:30 | brixen | heh ok |
| 22:56:36 | dwaite | def hack |
| 22:59:58 | toulmean | brixen: should I remove define RHASH_TBL 1 ? |
| 23:00:03 | brixen | toulmean: yes |
| 23:00:05 | toulmean | ok |
| 23:00:08 | toulmean | then readying. |
| 23:00:29 | brixen | should just be #ifdef HAVE_RB_HASH_FOREACH .... #else ... #endif |
| 23:00:52 | evan | oh, I think I had it as 1 so that the user would get a syntax error |
| 23:00:55 | evan | if they tried to use it. |
| 23:00:59 | brixen | yeah |
| 23:01:32 | toulmean | evan: why not do as you did for RHASH ? |
| 23:01:51 | evan | thats fine |
| 23:01:52 | evan | do that. |
| 23:01:56 | toulmean | #define RHASH(obj) assert("RHASH() is not supported") |
| 23:01:56 | evan | i don't recall off hand |
| 23:01:57 | evan | honestly. |
| 23:02:02 | toulmean | evan: ^^ |
| 23:02:04 | brixen | ok, so this is fun |
| 23:02:09 | evan | yeah, you can do that. |
| 23:02:24 | brixen | toulmean: see register_class in rjb.c |
| 23:02:29 | toulmean | ah I pushed already. I'll recommit and will rebase. |
| 23:02:42 | evan | ok, i get further into the buildr stuff |
| 23:02:44 | brixen | toulmean: it does rb_hash_aset, but rjb_loaded_classes is frozen |
| 23:02:44 | evan | and get a crash |
| 23:02:52 | evan | i'll be nice and continue to debug this new issue. |
| 23:02:53 | evan | :) |
| 23:03:01 | toulmean | evan: thx. |
| 23:03:05 | brixen | evan: what is your crash? |
| 23:03:11 | evan | one moment |
| 23:03:12 | evan | i'll show you. |
| 23:03:20 | toulmean | evan: you're on Mac right ? We have all our specs pass on Mac with JRuby and MRI |
| 23:03:23 | evan | something is rjb_s_load |
| 23:03:24 | evan | it appears. |
| 23:03:26 | evan | toulmean: yep. |
| 23:05:40 | brixen | toulmean: so, since this uses st_insert on MRI, it gets around this frozen hash of loaded classes |
| 23:05:54 | brixen | hates freakin frozen |
| 23:06:04 | toulmean | defreeze ? |
| 23:06:11 | brixen | to such thing |
| 23:06:18 | toulmean | it's a nice puzzle. |
| 23:06:21 | brixen | use of frozen is so lame |
| 23:06:29 | brixen | er no such thing |
| 23:07:06 | brixen | toulmean: see if he'll accept #ifndef RUBINIUS around OBJ_FREEZE in rbj.c |
| 23:07:08 | evan | calling initargs crashes. |
| 23:07:13 | brixen | there's only one use |
| 23:07:22 | evan | initargs = (GETDEFAULTJAVAVMINITARGS)NUM2ULONG(getdefaultjavavminitargsfunc); |
| 23:07:24 | evan | O_o |
| 23:07:46 | slava | why not make OBJ_FREEZE a no-op? |
| 23:08:07 | brixen | slava: because ppl use the fucking thing |
| 23:08:13 | evan | what the fuck rjb. |
| 23:08:18 | slava | and they rely on it failing if you mutate a frozen instance? |
| 23:08:25 | brixen | slava: we tried to avoid it |
| 23:08:37 | brixen | slava: no, in this case it's modifying the st table directly |
| 23:08:44 | brixen | slava: which has no frozen checks |
| 23:08:50 | brixen | slava: MRI is a ghetto of C code |
| 23:09:15 | brixen | slava: er, yes, they do rely on things failing |
| 23:09:17 | toulmean | lots of love in the air right now... |
| 23:09:23 | brixen | slava: or they spec that they fail |
| 23:09:31 | slava | but I mean from CAPI |
| 23:09:38 | slava | not calling freeze on an object in ruby code |
| 23:09:55 | brixen | ppl implement Ruby behavior from C code |
| 23:10:01 | slava | true |
| 23:10:04 | brixen | it wouldn't get us much but complaints |
| 23:10:19 | toulmean | for the pull request, ok if I list everyone in there ? That's a lot of people. |
| 23:10:36 | slava | you guys should write a paper about your CAPI work and publish it at some software engineering conference |
| 23:11:04 | evan | slava: might not be a bad idea. |
| 23:11:18 | brixen | that's a great idea |
| 23:11:44 | toulmean | k sending pull request |
| 23:11:46 | toulmean | have at it |
| 23:12:13 | toulmean | ok changing the rjb code to use the shiny new flag. |
| 23:12:30 | brixen | toulmean: did you push yet? |
| 23:12:48 | toulmean | brixen: pushed rubinius |
| 23:13:03 | toulmean | brixen: http://github.com/atoulme/rubinius/commit/ad7e95d3dff2f800581c0850c83b6f056eedd481 |
| 23:13:22 | brixen | toulmean: I mean rjb |
| 23:13:29 | toulmean | no, hey, on it |
| 23:13:55 | evan | oh my oh my oh my |
| 23:13:57 | evan | rjb. |
| 23:14:05 | evan | your disgusting. |
| 23:14:10 | evan | you're, rather. |
| 23:14:39 | evan | brixen: you were remarking about getdefaultjavavminitargsfunc = rb_funcall(rb_funcall(rb_funcall(jvmdll, rb_intern("[]"), 2, rb_str_new2(GETDEFAULTJVMINITARGS), rb_str_new2("IP")), rb_intern("to_ptr"), 0), rb_intern("to_i"), 0); |
| 23:14:42 | evan | weren't you? |
| 23:15:05 | brixen | evan: when I said I tried not to look directly at the code... yes |
| 23:15:20 | evan | I need to go get a welding mask |
| 23:15:31 | evan | or coffee. |
| 23:15:33 | evan | lets go with coffee. |
| 23:15:36 | brixen | that is why I elected to try running DL over converting to ffi :) |
| 23:15:37 | toulmean | :) |
| 23:15:49 | toulmean | brixen: got a small issue |
| 23:15:51 | toulmean | #ifdef HAVE_RB_HASH_FOREACH |
| 23:15:51 | toulmean | rb_hash_aset(rjb_loaded_classes, clsname, self); |
| 23:16:08 | brixen | toulmean: yeah, that's a problem |
| 23:16:13 | toulmean | this doesn't look quite right to me, that's the result of the permutation |
| 23:16:18 | toulmean | one more flag you think ? |
| 23:16:20 | brixen | I'll add RB_HASH_ASET |
| 23:16:21 | brixen | yes |
| 23:16:24 | brixen | er HAVE_ |
| 23:16:31 | toulmean | brixen: I can do it ? |
| 23:16:35 | evan | why in the name of all that is good in the universe do they call out to DL to get a symbol |
| 23:16:41 | evan | is fucking dlsym() to hard?!? |
| 23:16:44 | brixen | toulmean: I'm commiting your patch |
| 23:16:48 | toulmean | cool |
| 23:16:51 | brixen | toulmean: but you're not putting them in the right place |
| 23:17:10 | toulmean | I am not ? I reused the location of RHASH_TBL |
| 23:17:24 | brixen | yeah, the HAVE_ should go in defines.h |
| 23:17:28 | toulmean | damn |
| 23:17:32 | brixen | I'll push in a 1/2 sec |
| 23:17:34 | toulmean | ok |
| 23:18:00 | brixen | toulmean: push rjb so I can pull that and test |
| 23:18:04 | brixen | before I push to rbx |
| 23:23:39 | brixen | toulmean: what should I do after I run 'Rjb.load "", ["", ""]' ? |
| 23:29:48 | toulmean | one sec guys, got summoned back in java world |
| 23:30:01 | toulmean | brixen: after you did that, try loading a class |
| 23:30:19 | toulmean | let me see |
| 23:30:29 | toulmean | -> http://rjb.rubyforge.org/ |
| 23:30:53 | toulmean | Str = Rjb::import('java.lang.String') |
| 23:30:59 | toulmean | sounds like the right thing to test |
| 23:31:29 | boyscout | Added C-API HAVE_ macros for Hash. - 3540c3c - Brian Ford |
| 23:31:50 | brixen | toulmean: ok |
| 23:32:14 | evan | do you have rjb running? |
| 23:32:21 | evan | it's still crashing for me trying to open a JVM |
| 23:32:23 | brixen | evan: loads |
| 23:32:31 | evan | oh |
| 23:32:32 | evan | i know why. |
| 23:32:42 | evan | i've almost got this solved |
| 23:32:47 | evan | DL is truncating a void* to an int |
| 23:32:50 | evan | and loosing bits |
| 23:32:52 | evan | and you're on 32bit |
| 23:32:54 | brixen | ahh oops |
| 23:32:55 | brixen | yeah |
| 23:32:55 | evan | so it's not loosing bits. |
| 23:34:13 | slava | I wish C and C++ were stricter about their integer types |
| 23:34:17 | toulmean | is pulling rubinius real quick |
| 23:34:28 | evan | slava: me too. |
| 23:34:29 | toulmean | as soon as I have the right HAVE flags set, will push |
| 23:34:33 | evan | >> 4401926628.to_s(2).size |
| 23:34:34 | evan | => 33 |
| 23:34:41 | evan | brixen: ^^^ *eyeroll* |
| 23:34:55 | evan | who needs that 33rd bit anyway |
| 23:34:59 | evan | what a space hog. |
| 23:35:02 | brixen | heh |
| 23:36:20 | evan | it doesn't help that INT2NUM got implemented the way you'd think |
| 23:36:23 | evan | ie, taking an int |
| 23:36:30 | evan | where as in MRI, INT2NUM takes a long. |
| 23:36:59 | slava | does mri work on win64? it would have the same issue as above there because sizeof(long)==sizeof(int) |
| 23:37:09 | slava | presumably they want intptr_t but that is C99 |
| 23:37:33 | evan | in this case, i think dl would just fail. |
| 23:37:42 | evan | because it's casting the thing to long no matter what |
| 23:37:47 | evan | so dl is just busted on win64 |
| 23:38:25 | toulmean | we tend to recommend jruby on windows in general |
| 23:38:34 | toulmean | and win7 64 bits... jruby, definitely |
| 23:38:52 | toulmean | ok I pushed my rjb changes to take the latest flags into account. |
| 23:39:07 | slava | win7 64-bit is my fav OS at the moment :) |
| 23:39:15 | toulmean | slava: you too ? |
| 23:39:26 | toulmean | love it. Inside VirtualBox... in a managed, small window |
| 23:39:28 | slava | MS finally did something right |
| 23:39:31 | slava | ouch |
| 23:39:38 | slava | at least full screen it man |
| 23:40:03 | toulmean | slava: got two screens, one 24", the other 15. I don't care so much for Win7. |
| 23:40:05 | evan | hah |
| 23:43:21 | boyscout | CI: rubinius: 3540c3c successful: 3463 files, 13860 examples, 41514 expectations, 0 failures, 0 errors |
| 23:47:04 | evan | brixen: ok, I'm getting a "unable to modify frozen object (TypeError)" |
| 23:47:05 | evan | finally |
| 23:47:33 | brixen | evan: sweet |
| 23:47:38 | brixen | just comment it out :) |
| 23:48:19 | brixen | there's one use of OBJ_FREEZE and rjb uses st_insert on that hash |
| 23:48:31 | evan | *eyeroll* |
| 23:48:50 | brixen | I suppose we could add rb_hash_aset_I_dont_care_if_its_frozen_beatch |
| 23:49:47 | evan | rb_hash_set_this_shit |
| 23:49:54 | brixen | man, I have builder installed, I can load it... why can't buildr specs load it |
| 23:50:11 | evan | what do I comment out? |
| 23:50:15 | evan | to get past this frozen thing |
| 23:50:22 | brixen | grep OBJ_FREEZE |
| 23:50:25 | brixen | there is only one :) |
| 23:50:27 | evan | in rjb? |
| 23:50:30 | brixen | yes |
| 23:50:31 | brixen | rjb.c |
| 23:51:00 | evan | people are insane. |
| 23:52:29 | brixen | agreed |
| 23:52:39 | brixen | better... |
| 23:52:42 | brixen | other people are insane |
| 23:52:44 | brixen | :) |
| 23:54:33 | toulmean | brixen: so you have buildr installed ? |
| 23:54:59 | toulmean | maybe we can not freeze that stuff. What is it used for ? |
| 23:56:11 | evan | you can't |
| 23:56:17 | evan | it's totally invalid. |
| 23:56:19 | evan | it's freezing a hash |
| 23:56:22 | evan | then adding stuff to it. |
| 23:56:24 | toulmean | looks like they freeze the classes they load on initialization ? |
| 23:56:37 | toulmean | then we can change the code to not freeze the hash ? |
| 23:56:43 | evan | yes |
| 23:56:44 | evan | we should. |
| 23:56:49 | toulmean | ok let's do it ~! |
| 23:56:52 | evan | hey! |
| 23:57:16 | evan | kendall :: git/buildr ยป ~/git/rbx/bin/rbx -S spec spec/java/java_spec.rb ....... |
| 23:57:16 | evan | Finished in 0.187141 seconds |
| 23:57:16 | evan | 7 examples, 0 failures |
| 23:57:25 | toulmean | ah here we go |
| 23:57:38 | brixen | toulmean: http://gist.github.com/412578 |
| 23:57:53 | toulmean | brixen: oh nicer |
| 23:58:31 | toulmean | brixen: committing and pushing that |
| 23:58:32 | brixen | for the love of all things good, WTF |
| 23:58:42 | brixen | toulmean: ok |
| 23:59:20 | brixen | evan: what version of rspec did you install? |
| 23:59:32 | evan | 1.3.0 |
| 23:59:34 | evan | i changed the gemspec |
| 23:59:37 | brixen | argh |
| 23:59:40 | evan | to allow for >= 1.2.9 |
| 23:59:54 | brixen | I have 1.3.0 too |