Show enters and exits. Hide enters and exits.
| 06:13:34 | boyscout | Added be_computed_by matcher. - f738f37 - Brian Ford |
| 06:13:34 | boyscout | Fixed String#inspect specs. - 22e6c9e - Brian Ford |
| 06:13:34 | boyscout | Updated CI tag for changed spec description. - 0c6ccdf - Brian Ford |
| 06:13:34 | boyscout | Fixed String#inspect handling of '#'. - a26c83a - Brian Ford |
| 06:13:34 | boyscout | Updated CType specs for '#' String#inspect mapping. - 5e70490 - Brian Ford |
| 07:09:08 | brianmario | is there an equiv of rubysig.h in rbx at the moment? |
| 07:09:19 | brianmario | I'm specifically looking for TRAP_BEG and TRAP_END |
| 15:03:30 | brixen | what the hell boyscout |
| 15:03:42 | brixen | glad I didn't wait all night for results |
| 15:05:23 | matthewd | brixen: I thought that was an odd time for you to be committing :) |
| 15:05:45 | brixen | matthewd: heh, not that odd, just unusual these days :) |
| 15:06:01 | brixen | used to be a prime commit time |
| 15:06:39 | matthewd | Well yeah, that. And admittedly I didn't actually do the math to work out what time it was. |
| 15:07:52 | brixen | heh |
| 15:08:35 | brixen | I ran the specs with those commits on the CI server first |
| 15:08:45 | brixen | so dunno what's up with boyscout |
| 15:31:52 | kronos_vano | boyscout, We need you! Come back, dear! |
| 16:33:59 | evan | CI got hung for some reason. |
| 16:46:10 | brixen | evan: got this the other day http://gist.github.com/394434 |
| 16:46:21 | brixen | dunno why both threads in that process were in spin_lock |
| 16:46:54 | evan | looks normal actually |
| 16:46:54 | brixen | also, need to track down why I can't get print_backtrace to work in these situations |
| 16:47:00 | brixen | really? |
| 16:47:03 | evan | yeah |
| 16:47:07 | brixen | both threads would be in spin_lock? |
| 16:47:09 | evan | because you've got one thread waiting in wait() |
| 16:47:25 | brixen | that's a different process though |
| 16:47:32 | evan | sure |
| 16:47:38 | evan | thats why it's not moving forward |
| 16:47:42 | evan | it's waiting for another process |
| 16:47:46 | brixen | right |
| 16:47:50 | evan | you didn't get backtraces from the threads using spinlock |
| 16:47:56 | brixen | the other process has both threads in spinlock |
| 16:47:56 | evan | so i have no way to know if it's expected or not |
| 16:47:59 | brixen | ok |
| 16:48:07 | evan | given that at least one thread is in pretty normal code |
| 16:48:09 | brixen | well, how would I get bts? |
| 16:48:12 | evan | i'd assume it's normal. |
| 16:48:29 | evan | oh, weird |
| 16:48:32 | evan | i see there are backtraces |
| 16:48:33 | brixen | well, something must be abnormal here |
| 16:48:35 | evan | but with ?? in them |
| 16:48:38 | evan | so no clue how to get them |
| 16:48:41 | brixen | because rbx should not just hang |
| 16:48:51 | evan | well, sure. |
| 16:49:06 | evan | but I can't say the spinlock'd threads have anything to do with that |
| 16:49:19 | evan | in this case |
| 16:49:20 | brixen | that seems to be a deadlock to me |
| 16:49:24 | evan | you need to look at the OTHER rbx process |
| 16:49:26 | evan | it does? |
| 16:49:27 | evan | not to me |
| 16:49:32 | evan | why didn't the subprocess exit? |
| 16:49:35 | evan | thats the real question |
| 16:49:37 | brixen | there are 2 rbx processes in that gist |
| 16:49:42 | evan | right |
| 16:49:51 | brixen | the wait process is waiting on the one with both threads in spin_lock |
| 16:49:53 | evan | oh wait. |
| 16:49:54 | evan | one sec. |
| 16:50:00 | evan | i didn't realize there were 2 processes |
| 16:50:01 | evan | hold on. |
| 16:50:27 | evan | huh. |
| 16:50:28 | evan | ok |
| 16:50:29 | evan | yeah |
| 16:50:33 | evan | nevermind what I said |
| 16:50:37 | evan | something is wonky |
| 16:50:40 | evan | no fucking clue though. |
| 16:50:52 | brixen | ok |
| 16:51:14 | brixen | I also could not attach to the rbx CI on elle, so no info about why it was hung |
| 16:53:01 | evan | hrm |
| 16:59:08 | evan | bakkdoor: well, should we worry about this for rc5? |
| 16:59:32 | evan | ack |
| 16:59:35 | brixen | heh |
| 16:59:37 | evan | brixen: should we worry about this for rc5? |
| 16:59:44 | brixen | probably not, I get it rarely |
| 16:59:48 | evan | k |
| 17:00:05 | evan | so, is there any outstanding items for 1.0 then? |
| 17:00:49 | brixen | not that I know of |
| 17:01:00 | brixen | I'm looking at redmine tests again, but i wouldn't worry about that |
| 17:01:04 | evan | k |
| 17:01:10 | evan | i'm running ci on elle now |
| 17:01:14 | evan | if that comes up clean |
| 17:01:17 | brixen | k |
| 17:01:20 | evan | i'll start cutting rc5! |
| 17:01:27 | brixen | I ran it last night before I pushed and it was clean |
| 17:01:31 | evan | k |
| 17:07:57 | evan | brixen: so, i decided to read over some of macruby |
| 17:08:01 | evan | which I do once in a while |
| 17:08:14 | evan | and I'm completly baffled by their method cache setup |
| 17:08:27 | ezmobius | evan, brixen rubinus report was awesome thanks |
| 17:08:35 | evan | ezmobius: great! |
| 17:09:07 | brixen | ezmobius: super |
| 17:09:18 | brixen | evan: where are you looking? |
| 17:09:43 | evan | compile_mcache and method_cache_get |
| 17:09:49 | evan | in compiler.cpp and vm.cpp |
| 17:09:58 | brixen | k |
| 17:10:02 | evan | it appears they use a single cache struct for every use of a selector |
| 17:10:17 | evan | ie, everywhere #== is used, they use the same cache entry |
| 17:10:22 | evan | which makes absolutely no sense at all. |
| 17:11:16 | brixen | is updating source |
| 17:11:20 | brixen | gotta love svn |
| 17:12:34 | evan | seriously, it's so wrong I'm trying to figure out of i'm reading it wrong. |
| 17:14:51 | boyscout | CI: rubinius: 5e70490 successful: 3457 files, 13596 examples, 41216 expectations, 0 failures, 0 errors |
| 17:23:23 | brixen | what do the SEL sel actually look like? |
| 17:24:12 | brixen | unless the sel has more info than just the method name, the single mcache map is searched only for sel |
| 17:24:21 | brixen | so what you said seems like the way it works |
| 17:24:29 | brixen | builds macruby |
| 17:24:35 | evan | a SEL is a symbol basicaly |
| 17:24:46 | brixen | but I wonder what it actually looks like |
| 17:24:49 | evan | it's a uniqued char* is all. |
| 17:24:52 | brixen | hmm |
| 17:25:11 | evan | the only thing you can do is compare it against other SEL's |
| 17:25:16 | evan | it's got no data value |
| 17:25:53 | brixen | are you building macruby? |
| 17:26:41 | brixen | I wish they'd bundle llvm or make it as easy to build as we do |
| 17:26:51 | brixen | what is it with painful build processes |
| 17:26:54 | Malediktus | hi all, I'm trying to reproduce the libexecinfo stuff on freebsd. I'm doing a clean build. It fails here right now:http://bsdpaste.bsdgroup.de/14903 but I'm going to add -fPIC |
| 17:26:59 | evan | no, i'm not building it. |
| 17:27:34 | evan | hrm. |
| 17:27:41 | evan | thats in building the openssl extension... |
| 17:28:57 | Malediktus | with -fPIC it works |
| 17:29:11 | evan | with -fPIC where? |
| 17:29:14 | evan | patch please! |
| 17:29:45 | Malediktus | working on it. But I'm not sure how to handle the other OSes. maybe just add -fPIC for them too? |
| 17:32:04 | evan | Malediktus: hurry! i'm in the process of doing the rc5 release |
| 17:32:08 | evan | i can sneak this in |
| 17:32:20 | evan | i just need to know where you put the -fPIC |
| 17:33:48 | Malediktus | http://bsdpaste.bsdgroup.de/14904 |
| 17:35:52 | Malediktus | evan: I think it shouldn't brake anywhere. |
| 17:36:02 | evan | brake? |
| 17:36:05 | evan | you mean break? |
| 17:36:06 | Malediktus | break |
| 17:36:09 | Malediktus | sorry |
| 17:40:50 | evan | Malediktus: yeah, I think that should be fine |
| 17:40:54 | evan | Malediktus: anything else? |
| 17:43:16 | Malediktus | http://github.com/evanphx/rubinius/issues/issue/272/#comment_236721 |
| 17:43:19 | Malediktus | just sent it :) |
| 17:43:20 | evan | well, we can't put it into the Makefile, since the makefile is autogenerated. |
| 17:43:29 | Malediktus | uh |
| 17:43:31 | Malediktus | ok |
| 17:43:35 | Malediktus | from where? |
| 17:43:49 | Malediktus | ah, I see |
| 17:44:03 | evan | needs to be in extconf.rb |
| 17:44:05 | evan | which is easy. |
| 17:44:13 | Malediktus | ok |
| 17:45:46 | Malediktus | evan: what do you think about the omit-frame-pointer situation? |
| 17:45:57 | evan | freebsd is broken |
| 17:46:02 | evan | is my opinion on it. |
| 17:46:06 | Malediktus | kinda |
| 17:46:27 | evan | backtrace() should certainly not just randomly segfault |
| 17:46:29 | Malediktus | I don't know why it does that. I didn't find any place where it's defined by defualt |
| 17:46:39 | evan | and we're not going to build with -fno-omit-frame-pointer by default |
| 17:46:46 | Malediktus | it's not randomly |
| 17:46:53 | evan | we use trampolines in critical places |
| 17:47:17 | Malediktus | you need the frame pointer for that too I guess? |
| 17:49:59 | evan | just the opposite |
| 17:50:08 | evan | we need to allow gcc to not have a frame pointer for that |
| 17:50:38 | evan | using backtrace() isn't critical at all |
| 17:50:44 | evan | it just aids in debugging |
| 17:50:54 | evan | thats all. |
| 17:50:59 | evan | VM debugging, that il. |
| 17:51:32 | Malediktus | ah, hmm. and backtrace() works on mac and linux without frame-pointers? |
| 17:52:24 | evan | yep |
| 17:54:16 | Malediktus | interesting |
| 18:02:30 | evan | Malediktus: so, the better fix is to put -fPIC into rbconfig.rb |
| 18:02:33 | evan | which i'm doing |
| 18:02:41 | evan | otherwise you won't be able to build other extensions either |
| 18:02:56 | Malediktus | thank you |
| 18:05:38 | brixen | I thought I added -fPIC to rbconfig.rb |
| 18:06:11 | evan | only for linux |
| 18:06:12 | brixen | oh, for linux |
| 18:06:14 | brixen | yeah |
| 18:06:14 | evan | i'm adding it for everyone |
| 18:06:25 | evan | since we hardcode gcc atm anyway |
| 18:06:29 | brixen | sure |
| 18:06:48 | Malediktus | anyone tried using clang to compile the vm? |
| 18:07:18 | evan | i haven't |
| 18:07:24 | evan | i'd be interested to hear how it goes though |
| 18:07:43 | Malediktus | c++ support is not really complete afaik |
| 18:07:59 | boyscout | Use -fPIC on all platforms since we mandate gcc atm - c7c7d02 - Evan Phoenix |
| 18:08:01 | evan | they're getting there |
| 18:08:01 | brixen | it compiles llvm itself I believe |
| 18:08:05 | evan | but yeah, they've still got holes |
| 18:08:10 | brixen | or does it just parse it all |
| 18:08:14 | evan | we're pretty conservative with our c++ usage |
| 18:08:28 | evan | brixen: no, they can code gen it too |
| 18:08:32 | brixen | sweet |
| 18:08:43 | Malediktus | brixen: yes it does. there is a freebsd branch, it can compile all of freebsd too (very little c++ though) |
| 18:08:48 | brixen | seems like 2.7 would probably compile rbx |
| 18:09:24 | Malediktus | what about using llvm 2.7 for the jit stuff like now with 2.6 does that work already? |
| 18:10:01 | scoopr | I've been using self-hosting clang for a while testing stuff |
| 18:10:18 | scoopr | they've got fair bit of boost working |
| 18:10:21 | Malediktus | scoopr: nice, rubinius too? |
| 18:10:23 | Malediktus | or mri |
| 18:10:53 | evan | Malediktus: you mean upgrade to 2.7? |
| 18:10:57 | Malediktus | yes |
| 18:11:04 | evan | post 1.0 |
| 18:11:06 | evan | i'll be doing that. |
| 18:11:07 | Malediktus | ok |
| 18:11:42 | scoopr | nah, not rbx or mri |
| 18:11:47 | scoopr | yet at least |
| 18:16:09 | evan | so, i'm not going to do OS X packages for rc5 |
| 18:16:23 | evan | since we're going to turn around and (hopefully) make it 1.0 in a few days |
| 18:16:57 | boyscout | CI: rubinius: c7c7d02 successful: 3457 files, 13596 examples, 41216 expectations, 0 failures, 0 errors |
| 18:21:27 | evan | ok, testing a release build... |
| 18:28:23 | Malediktus | evan: I get a SIGBUS while executing mspec ci with this backtrace: http://bsdpaste.bsdgroup.de/14911 |
| 18:28:44 | Malediktus | frame #8 and higher are not known |
| 18:28:55 | Malediktus | like ?? () |
| 18:29:00 | evan | umm. |
| 18:29:06 | evan | do |
| 18:29:08 | evan | frame 4 |
| 18:29:14 | evan | p call_frame->print_backtrace(state) |
| 18:29:33 | Malediktus | You can't do that without a process to debug. |
| 18:29:38 | Malediktus | I only have the .core |
| 18:29:53 | Malediktus | can I start mspec in gdb? |
| 18:30:47 | evan | bin/mspec ci --gdb |
| 18:31:06 | Malediktus | running |
| 18:32:17 | Malediktus | Program received signal SIGEMT, Emulation trap. |
| 18:32:22 | Malediktus | ok, never seen that before |
| 18:32:47 | Malediktus | http://bsdpaste.bsdgroup.de/14912 |
| 18:32:53 | evan | thats probably ok |
| 18:32:59 | Malediktus | continue? |
| 18:33:00 | evan | yeah |
| 18:33:02 | evan | continue |
| 18:34:05 | brianmario | anyone happen to see my question from last night about TRAP_BEG/TRAP_END in rbx? |
| 18:34:16 | brianmario | or rubysig.h for that matter |
| 18:34:21 | evan | brianmario: we don't support it. |
| 18:34:24 | brianmario | ah ok |
| 18:34:27 | brianmario | anything similar? |
| 18:34:30 | evan | no. |
| 18:34:32 | brianmario | k |
| 18:34:45 | evan | we can support something similar |
| 18:35:02 | evan | but otherwise those could be noops pretty safely |
| 18:35:10 | brianmario | trying to get mysql2 compatible with rbx |
| 18:35:30 | brianmario | eric wong contributed some patches, one of which "emulates" rb_thread_blocking_region for 1.8 |
| 18:35:41 | brianmario | using those trap macros |
| 18:36:15 | evan | where are you putting that? |
| 18:36:21 | evan | around blocking mysql calls? |
| 18:36:26 | brianmario | yeah |
| 18:37:02 | evan | TRAP_BEG and TRAP_END aren't really the equiv |
| 18:37:16 | evan | and they're likely to screw up mysql |
| 18:37:44 | evan | because what those say is that it's the process should be sent a unix signal if it waits too long |
| 18:37:54 | brianmario | from his email: "Since 1.8 doesn't use native threads, the emulated 1.8 version just defers signal handling until TRAP_END. Having Ruby signal handlers fire while executing blocking C functions is dangerous, since they can clobber errno and the thread stack. If you look at the MRI 1.8 code, you can see it's used in every place where the interpreter makes an interruptible system call." |
| 18:37:57 | evan | i doubt any mysql function wil handle them properly. |
| 18:38:53 | brianmario | he was diving pretty deep into the mysql C api sources to see how things worked, and these patches were sortof the bi-product of his findings |
| 18:39:29 | Malediktus | http://bsdpaste.bsdgroup.de/14913 |
| 18:39:49 | evan | brianmario: could I see the patch? |
| 18:40:19 | brianmario | sure sec |
| 18:40:33 | evan | Malediktus: hrm. |
| 18:40:43 | evan | Malediktus: well, it's really too late in the release cycle to fix these. |
| 18:40:55 | evan | we're going to have to tear a bunch of stuff apart to figure out whats up |
| 18:41:33 | Malediktus | evan: ok, no problem |
| 18:42:01 | brianmario | evan: http://github.com/brianmario/mysql2/commit/fa213c9892e7f11d0fdbc3e514f2bd3c3313b110 |
| 18:42:25 | brianmario | there's a few more, mostly wrapping the rest of the [potentially] blocking calls |
| 18:42:49 | evan | i have a bad feeling about it |
| 18:43:44 | evan | what does mysql_query do when the process is sent SIGVTALRM? |
| 18:44:35 | brianmario | to be honest, I know very little about his research into the C api or how things work for that matter |
| 18:44:49 | brianmario | but I'll definitely ask him these questions |
| 18:46:11 | evan | also, if mysql_query is going to return early |
| 18:46:19 | evan | then you need to put code in place to have it retry |
| 18:46:38 | evan | atm, the code assumes that mysql_query actually ignores the signal and will alway return a result |
| 18:46:58 | evan | but if TRAP_BEG actually causes mysql_query to return early, then the return value will be invalid |
| 18:47:01 | evan | and you'll need to retry |
| 18:47:36 | evan | so there is one of 2 bugs here |
| 18:47:44 | brianmario | I'm not using mysql_query, using mysql_send_query, which always returns immediately (I'm pretty sure at least) |
| 18:47:57 | brianmario | if that matters |
| 18:48:05 | evan | mysql_query ignores the signal or you don't redo a query |
| 18:48:20 | evan | well, something in here must be blocking |
| 18:48:24 | evan | mysql_connect is at least |
| 18:48:27 | brianmario | yeah |
| 18:48:32 | brianmario | that one is |
| 18:48:40 | evan | so if mysql_connect honors the signal |
| 18:48:44 | evan | you have a bug because you assume it worked |
| 18:50:18 | boyscout | Update version number to rc5 - 214e23b - Evan Phoenix |
| 18:52:10 | brianmario | evan: will definitely look into all this, maybe I should revert these patches and keep em in a branch for now |
| 18:52:21 | evan | well, if you want |
| 18:52:34 | evan | remove the TRAP_BEG and TRAP_END and just put CHECK_INT after TRAP_END |
| 18:52:36 | evan | er. |
| 18:52:41 | evan | where TRAP_END is. |
| 18:52:59 | brianmario | so only CHECK_INT after the blocking call? |
| 18:53:06 | evan | er, CHECK_INTS |
| 18:53:09 | evan | yeah |
| 18:53:30 | brianmario | since I'm new to all this - what's the diff? |
| 18:53:36 | evan | that will at least catch if the user hits ^C while mysql_connect is blocked |
| 18:53:42 | brianmario | ah |
| 18:55:02 | brianmario | my goal ultimately is to be compatible with rbx, 1.9.x, 1.8.6+, and maybe macruby - but to also release the GVL where at all possible for blocking C calls |
| 18:55:41 | brianmario | release the GVL might not be the right terminology, but I think you get what I mean :P |
| 18:55:55 | Defiler | unleash the hounds |
| 18:56:40 | evan | brianmario: we can certainly provide a rb_block_region call |
| 18:56:45 | evan | thats what you'd use in rbx |
| 18:57:03 | brianmario | that exists today/ |
| 18:57:09 | brianmario | ? |
| 18:57:10 | evan | negative. |
| 18:57:15 | brianmario | k |
| 18:57:17 | evan | we'd need to add it. |
| 18:58:17 | boyscout | CI: rubinius: 214e23b successful: 3457 files, 13596 examples, 41216 expectations, 0 failures, 0 errors |
| 19:16:21 | kronos_vano | oh. I should fix bug with shifting bits for negative numbers before 1.0 is out |
| 19:16:30 | evan | um |
| 19:16:31 | evan | no. |
| 19:16:34 | evan | it's too late. |
| 19:16:37 | evan | you've missed the window. |
| 19:16:56 | kronos_vano | So you will release with known bug? |
| 19:16:59 | evan | yep |
| 19:17:14 | evan | only critical fixes for the rest of the week |
| 19:18:42 | evan | we can't do everything before 1.0 |
| 19:18:47 | evan | i have to draw the line somewhere |
| 19:19:20 | kronos_vano | np, I'll commit after 1.0 :) |
| 19:54:09 | evan | yep |
| 19:54:22 | evan | i'm going to delay doing so unless we need to |
| 19:54:48 | evan | there will be a 1.0.x branch though |
| 19:57:26 | radarek | I have some trouble with running rbx tests after building, it just hangs |
| 19:57:34 | radarek | http://pastie.org/private/c0val4spwt5rf3gnrdwnw |
| 19:57:42 | radarek | it hangs after last F |
| 19:58:03 | evan | radarek: you're going to have to debug it |
| 19:58:07 | evan | find out what spec is hanging. |
| 19:58:30 | radarek | is there easy way to do it? |
| 19:58:32 | brixen | radarek: run bin/mspec ci -V -fs |
| 19:58:38 | radarek | ok |
| 20:02:16 | radarek | ok found |
| 20:02:20 | radarek | TCPSocket.new |
| 20:02:20 | radarek | - requires a hostname and a port as arguments |
| 20:02:21 | radarek | - refuses the connection when there is no server to connect to |
| 20:02:21 | radarek | - connects to a listening server |
| 20:02:23 | radarek | the last one |
| 20:04:16 | brixen | radarek: when it is hung, do ps ux | grep rbx, then gdb -p <pid> for each rbx process |
| 20:04:37 | brixen | radarek: do info threads, the thr N and bt |
| 20:04:46 | brixen | when N is the thread number |
| 20:04:50 | radarek | k |
| 20:06:21 | radarek | http://pastie.org/private/j81rudarnwwrtyrnhfhdq |
| 20:06:21 | gnufied | congratulations guys, giving master a spin. |
| 20:06:33 | radarek | brixen: is it ok? |
| 20:07:25 | brixen | radarek: was that the only rbx process? |
| 20:07:41 | brixen | I mean, that part is good, but is there another? |
| 20:08:11 | radarek | no there is only one rbx process |
| 20:08:12 | brixen | radarek: also, paste everything from the invocation of the command on |
| 20:08:14 | brixen | hmm |
| 20:08:31 | radarek | $ ps ax | grep rbx | grep -v grep |
| 20:08:31 | radarek | 24327 s001 RN+ 1:17.47 bin/rbx -v /Users/radarek/opt/src/rubinius/mspec/bin/mspec-ci -V -fs |
| 20:08:59 | brixen | interesting |
| 20:09:01 | radarek | brixen: whic command? mspec or gdb? |
| 20:09:06 | radarek | *which |
| 20:09:16 | brixen | gdb |
| 20:09:23 | radarek | ok |
| 20:09:28 | brixen | radarek: does this happen every time? |
| 20:09:35 | brixen | ie, is it easily repeatable? |
| 20:10:14 | radarek | brixen: http://pastie.org/private/nrpml0yijdxjhnct41kmna |
| 20:10:19 | brixen | radarek: which spec file was this in? |
| 20:10:29 | radarek | brixen: yes, it's repeatable |
| 20:10:48 | brixen | k |
| 20:10:48 | evan | oh, it might be a DNS timeout issue |
| 20:10:50 | evan | in the specs |
| 20:10:55 | radarek | brixen: /Users/radarek/opt/src/rubinius/spec/ruby/library/socket/tcpsocket/new_spec.rb |
| 20:10:58 | evan | given that it's waiting in connect. |
| 20:13:09 | evan | radarek: run just that one file |
| 20:13:13 | evan | and see if it hangs. |
| 20:15:05 | radarek | evan: yes, it does |
| 20:15:12 | evan | which spec |
| 20:15:19 | evan | -fs should show you which it line is hanging. |
| 20:15:26 | radarek | bin/mspec ci -V -fs spec/ruby/library/socket/tcpsocket/new_spec.rb |
| 20:15:29 | evan | no |
| 20:15:31 | evan | which line. |
| 20:15:34 | radarek | - connects to a listening server |
| 20:15:38 | radarek | that spec |
| 20:15:45 | radarek | there is no line |
| 20:15:49 | radarek | just name of spec |
| 20:15:51 | evan | thats what i mean. |
| 20:15:54 | radarek | ok |
| 20:15:59 | brixen | evan: it's in spec/ruby/library/socket/tcpsocket/shared/new.rb |
| 20:16:02 | evan | yep |
| 20:16:03 | evan | i know. |
| 20:16:21 | evan | i don't know why this would hang |
| 20:16:27 | evan | in connect no less |
| 20:16:38 | evan | other than your machine has some really strange hostname setup |
| 20:17:09 | brixen | that's what I was wondering |
| 20:17:28 | radarek | it hangs on: conn = server.accept |
| 20:17:40 | radarek | (i did simple puts debugging) |
| 20:18:00 | evan | well |
| 20:18:00 | evan | thats not a hang |
| 20:18:04 | evan | because it waiting for someone to connect |
| 20:18:08 | evan | what about the other thread |
| 20:18:11 | evan | the main thread |
| 20:18:13 | radarek | ah right |
| 20:18:26 | evan | i'd imagine it gets to right before TCPSocket.send |
| 20:18:28 | radarek | so where is the other thread which trys to connect?:) |
| 20:18:41 | evan | print out @hostname and SocketSpecs.port |
| 20:18:46 | evan | what are those values? |
| 20:19:07 | radarek | 192.150.8.118 |
| 20:19:08 | radarek | 40001 |
| 20:19:31 | evan | is that your ip address? |
| 20:20:11 | radarek | IP Information: 89.75.43.221, local is 10.0.0.100 |
| 20:20:12 | radarek | :) |
| 20:20:35 | evan | well what the hell. |
| 20:20:44 | evan | you sure? |
| 20:20:55 | evan | this is using Socket.getaddrinfo to figure out your address |
| 20:21:04 | evan | please try that in MRI |
| 20:21:05 | evan | Socket.getaddrinfo("127.0.0.1", nil)[0][2] |
| 20:21:12 | radarek | external checked with http://whatismyipaddress.com/, local with ifconfig |
| 20:21:36 | radarek | wow |
| 20:21:37 | radarek | >> Socket.getaddrinfo("127.0.0.1", nil)[0][2] |
| 20:21:37 | radarek | => "192.150.8.118" |
| 20:21:42 | radarek | ruby 1.8.7 |
| 20:21:43 | evan | there ya go. |
| 20:21:48 | radarek | wtf? |
| 20:21:49 | evan | that is your address. |
| 20:22:14 | evan | i do see a potential issue in socket wrt. connect |
| 20:22:20 | evan | that i'll investigate after lunch. |
| 20:22:26 | Defiler | ifconfig -a |grep 192 |
| 20:22:31 | Defiler | grep 192 /etc/hosts |
| 20:22:32 | Defiler | heh |
| 20:22:50 | Defiler | the first entry in /etc/hosts for localhost will be the one picked up by getaddrinfo for 127, on most systems |
| 20:22:53 | Defiler | (including mac os) |
| 20:23:04 | slava | yo evan |
| 20:23:14 | slava | I'm rewriting my FFI so that parameter boxing and unboxing is done inline rather than with subroutine calls |
| 20:23:31 | radarek | Defiler: ah, there it is, but first entry in my /etc/hosts point to 127.0.0.1 |
| 20:23:51 | Defiler | is it 'localhost 127.0.0.1'? |
| 20:23:56 | Defiler | or is it a different name? |
| 20:24:05 | radarek | Defiler: but there are other ips which point to localhost and one of them is 192.150.8.118 |
| 20:24:25 | radarek | Defiler: first uncommeted line is: 127.0.0.1 localhost |
| 20:24:36 | Defiler | huh. what os is this? |
| 20:24:43 | radarek | mac os x |
| 20:25:03 | Defiler | interesting; I've only observed it picking up the first one, but it wouldn't surprise me if that changed with every release |
| 20:25:26 | Defiler | at first I was thinking it was a byte order deal, so I converted 192.150.8.118 to binary and reversed it |
| 20:25:32 | Defiler | but that is 154.210.212.187 heh |
| 20:25:37 | radarek | it doesn't make sense |
| 20:26:00 | radarek | why it picks random one? |
| 20:26:00 | evan | radarek: remove the "or !ready" in that spec and see if it fixes your issue |
| 20:26:46 | evan | be back shortly. |
| 20:27:38 | radarek | evan: no, it doesn't, still hangs |
| 20:28:46 | radarek | evan: but when I delete all entries from /etc/hosts and leave only one with 127.0.0.1 localhost it works |
| 20:30:48 | radarek | ok, all spec passes |
| 20:30:54 | radarek | sorry for trouble |
| 20:34:38 | brixen | radarek: good news |
| 21:01:06 | gnufied | did anyone got rcov working on rubinius ? |
| 21:01:24 | Defiler | gnufied: not supported |
| 21:01:42 | Defiler | It uses tracing features of the MRI C API that rubinius does not have |
| 21:03:11 | gnufied | Defiler: what rubinius provide as an alternative? (not rcov alternative, but tracing features) |
| 21:03:39 | Defiler | rubinius has a full-speed debugger and a full-speed sampling profiler |
| 21:03:57 | Defiler | someone just needs to use those parts to implement an rcov-compatible lib that does the same stuff |
| 21:04:22 | gnufied | okay point taken. |
| 21:04:41 | gnufied | one more thing, is there any alternative of "re.h" ? |
| 21:04:53 | gnufied | I can't build some extensions because of that. |
| 21:05:12 | Defiler | That, I don't know; brixen may know though |
| 21:05:23 | gnufied | fail enough. |
| 21:06:18 | gnufied | s/fail/fair |
| 21:16:26 | evan | Defiler: we'll likely never support re.h |
| 21:16:42 | evan | i guess we could bundle 1.8's regex library and let people use it. |
| 21:16:59 | evan | but if they want to do re_search(RREGEXP(thing)->blah, ...) |
| 21:17:01 | evan | that won't work. |
| 21:17:27 | Defiler | yeah |
| 21:24:56 | radarek | cucumber depends on gherkin gem which use C ext which use re.h :( |
| 21:26:30 | Defiler | does polyglot even run on rbx? |
| 21:29:48 | evan | well that was a bad move on gherkin's part. |
| 21:30:02 | evan | Defiler: it should. |
| 21:30:55 | Defiler | http://github.com/cjheath/polyglot/blob/master/lib/polyglot.rb |
| 21:30:58 | Defiler | yeah, looks fine I guess |
| 21:31:31 | Defiler | That NestedLoadError#reraise will be interesting |
| 21:31:40 | Defiler | but should be fine |
| 21:32:36 | evan | radarek: is there no pure ruby version of gherkin? |
| 21:32:41 | evan | it appears to be a ragel parser |
| 21:32:51 | evan | and I see something about ruby output |
| 21:33:14 | evan | and it appears to only support 1.9 |
| 21:33:18 | evan | oh aslak... |
| 21:33:40 | Defiler | I sat next to him at my very first rubyconf |
| 21:33:53 | Defiler | and I see he is still aslak'in it up :) |
| 21:34:43 | radarek | Defiler: examples from homepage http://polyglot.rubyforge.org/ works fine on rbx (there is one error there, it should be passed TOPLEVEL_BINGING to Kernel.eval method) |
| 21:34:56 | radarek | evan: dunno |
| 21:35:33 | evan | radarek: i haven't had anyone ask about it up to now |
| 21:35:38 | evan | so we didn't spend any time on it |
| 21:35:44 | evan | we'll check it out post 1.0 |
| 21:35:53 | radarek | ok, np |
| 21:36:35 | radarek | I try to run my rails app with rbx and the first step is install bundler and try to install rbx -S bundle install |
| 21:36:43 | radarek | now I have problem with libxml-ruby |
| 21:36:44 | radarek | ruby_xml_xpath_context.c: In function ‘rxml_xpath_context_register_namespaces’: |
| 21:36:44 | radarek | ruby_xml_xpath_context.c:223: error: called object ‘1’ is not a function |
| 21:36:58 | radarek | and that line is: st_foreach(RHASH_TBL(nslist), iterate_ns_hash, self); |
| 21:37:01 | radarek | weird |
| 21:37:48 | brixen | ugh |
| 21:38:00 | radarek | I see... |
| 21:38:04 | radarek | ./vm/capi/mri/compat.h: * Never use RHASH(obj)->tbl or RHASH_TBL(). |
| 21:38:05 | radarek | :) |
| 21:38:10 | brixen | exactly |
| 21:38:12 | radarek | libxml-ruby use it |
| 21:38:29 | radarek | it's nightmare |
| 21:38:59 | brixen | why does libxml-ruby exist? |
| 21:39:52 | brixen | that's a rhetorical question |
| 21:40:18 | radarek | from description: "The Libxml-Ruby project provides Ruby language bindings for the GNOME Libxml2 XML toolkit. It is free software, released under the MIT License. Libxml-ruby's primary advantage over REXML is performance - if speed is your need, these are good libraries to consider, as demonstrated by the informal benchmark below. " |
| 21:40:36 | brixen | blah blah blah :) |
| 21:40:39 | radarek | : |
| 21:40:40 | radarek | :) |
| 21:41:05 | brixen | anyway, real issue is that most people wrote their C extensions without the slightest regard for portability |
| 21:41:12 | slava | hi brixen |
| 21:41:17 | brixen | reaching into the object layout on MRI is insane |
| 21:41:21 | brixen | even if MRI allows it |
| 21:41:24 | brixen | hi slava |
| 21:41:41 | brixen | slava: your Smalltalk impl in Factor came up on the FoNC list this weekend |
| 21:41:50 | brixen | slava: I had forgotten about it :) |
| 21:41:59 | radarek | brixen: yep, it's true |
| 21:42:06 | slava | brixen: its a pretty useless impl |
| 21:42:13 | slava | I postponed work on it until our VM can do fast non-local returns |
| 21:42:21 | brixen | slava: heh, well it's a nice PoC |
| 21:42:35 | evan | there was talk by Alan Kay about a OMeta lib for Factor even |
| 21:42:41 | brixen | yeah |
| 21:42:44 | slava | the vpri guys are pretty opaque |
| 21:42:48 | slava | nobody really knows that they're working on |
| 21:42:54 | brixen | not exactly |
| 21:43:10 | brixen | lots of newer stuff here http://www.vpri.org/html/writings.php |
| 21:43:23 | brixen | and Alan has been writing volumes on the ML this weekend |
| 21:43:35 | slava | the Nile DSL for graphics code mentioned in their 2009 report looks neat |
| 21:43:41 | brixen | yeah |
| 21:43:48 | evan | yeah, Dan, who wrote it, is/was a ruby programmer |
| 21:43:55 | evan | I went and had lunch with those guys a couple years ago |
| 21:44:08 | evan | Dan said we had met at a RubyConf |
| 21:51:23 | radarek | ok I had to commet out almost all gems from Gemfile which use native c ext because they didn't compile |
| 21:51:44 | radarek | mysql, nokogiri, hpricot, happymapper (use libxml-ruby) |
| 21:51:49 | radarek | and cucumber |
| 21:52:46 | Defiler | mysql and nokogiri should work fine |
| 21:53:21 | evan | yes, mysql and nokogiri are tested |
| 21:53:41 | radarek | ok I'll try install it separately without bundler |
| 21:55:16 | radarek | where gems are installed? (without sudo) I cannot find it in ~/.gem/rbx/**/ |
| 21:55:49 | evan | why would they be in .gem? |
| 21:55:53 | evan | bundler puts them there i think |
| 21:55:57 | evan | but thats not where they go normally |
| 21:56:11 | evan | if you installed rubinius, it's under the install dir |
| 21:57:27 | radarek | evan: I mean when I install it by: rbx -S gem install (without sudo and bundler's help), I though that they should go to ~/.gem/rbx/ |
| 21:57:35 | Defiler | radarek: bundle exec gem env |
| 21:57:38 | Defiler | rbx -S gem env |
| 21:57:44 | evan | radarek: no |
| 21:57:44 | Defiler | ..and compare |
| 21:57:52 | evan | bundler puts stuff in ~/.gem/rbx only |
| 21:57:59 | evan | thats never where stuff goes normally. |
| 21:58:03 | Defiler | depends, actually |
| 21:58:17 | Defiler | rvm, for example, has a special install path for bundler-installed gems |
| 21:58:22 | evan | oh oh |
| 21:58:25 | evan | i'm sorry. |
| 21:58:27 | evan | i'm confused. |
| 21:58:43 | Defiler | e.g. /Users/wilson/.rvm/gems/ruby-1.8.7-p249/bundler/gems vs. /Users/wilson/.rvm/gems/ruby-1.8.7-p249 |
| 21:58:45 | evan | rubygems has the user install stuff that will use ~/.gem I believe. |
| 21:58:47 | Defiler | (in my case) |
| 21:58:56 | evan | which I believe rbx will use. |
| 21:59:06 | Defiler | It does for me, yeah |
| 21:59:17 | Defiler | though these days I'm using rbx via rvm generally |
| 22:00:43 | radarek | it install gems to /Users/radarek/opt/src/rubinius/gems/ directory, strange :) |
| 22:01:45 | radarek | ok mysql installed without errors (I had to put --with-mysql-dir with custom path) |
| 22:03:59 | radarek | ok, nokogiri also works fine, it was false alarm for mysql and nokogiri not working on rbx :) |
| 22:04:21 | evan | :) |
| 22:04:34 | evan | we had to release 1.0 before we dealt with all extensions |
| 22:04:42 | evan | the list is just too long for us to deal with 100% of them |
| 22:04:45 | evan | we'll get better over time. |
| 22:05:32 | radarek | yes, you are right, it will be never ending story with fixing those c ext |
| 22:06:05 | slava | when is 1.0 due? |
| 22:06:29 | radarek | I think that when peaple will start using rbx they also will be fixing those c ext |
| 22:06:31 | slava | man, I need some architecture block diagrams for the factor home page |
| 22:06:34 | evan | slava: probably friday. |
| 22:06:43 | slava | in fact, the exact same ones from rubini.us apply 100% |
| 22:06:44 | evan | radarek: i hope so. |
| 22:06:59 | evan | slava: :D |
| 22:07:17 | evan | just put a "see http://rubini.us block diagram" note on your webpage |
| 22:07:18 | evan | :) |
| 22:07:26 | slava | haha |
| 22:08:46 | radarek | wow, rbx handle my not so small rails app and it can display login page without error :) (there are used many gems and rails plugins) |
| 22:09:59 | evan | woo! |
| 22:10:59 | radarek | evan: rbx says for one model file that there is syntax error but with MRI it's ok |
| 22:11:09 | evan | hm, interesting... |
| 22:11:23 | evan | could you paste the file and/or the syntax error? |
| 22:11:51 | radarek | but I have to cut it to smallest case becasue I cannot paste whole file (it's my company app) |
| 22:12:21 | evan | ok |
| 22:12:22 | evan | sure |
| 22:12:24 | radarek | evan: error is |
| 22:12:26 | radarek | A syntax error has occured: |
| 22:12:26 | radarek | app/models/website.rb:703: expecting $end |
| 22:12:26 | evan | if you could isolate the error |
| 22:12:26 | radarek | near line app/models/website.rb:703, column 31 |
| 22:12:26 | radarek | Code: |
| 22:12:27 | radarek | negative_dimensions.each do |dimension| |
| 22:12:27 | radarek | ^ |
| 22:12:37 | evan | :/ |
| 22:12:43 | radarek | but I guess it doesn't make sense to you :) |
| 22:12:45 | evan | no |
| 22:12:48 | evan | it doesn't |
| 22:12:55 | radarek | ok try to cut it |
| 22:12:58 | evan | k |
| 22:23:13 | radarek | evan: the problem is that when I try cut it there show different syntax error |
| 22:23:22 | radarek | so I have that one (different than before I show) |
| 22:23:23 | radarek | http://pastie.org/private/egotsxhdynm9mwjyy3tna |
| 22:23:58 | radarek | when you fix that one I will try one more time to check whole file |
| 22:25:37 | evan | ha |
| 22:25:41 | evan | well, lets... |
| 22:26:43 | evan | ug. |
| 22:26:49 | evan | the :do confused things |
| 22:26:51 | evan | thats... weird. |
| 22:28:44 | evan | ok |
| 22:28:45 | evan | after_transition :do => :update_chcecked_at |
| 22:28:50 | evan | is a minimum repro |
| 22:29:59 | Defiler | does rbx still support the colon-delimited where clauses and stuff? |
| 22:30:05 | Defiler | could be an issue related to that grammar |
| 22:30:10 | evan | i believe so. |
| 22:53:01 | radarek | evan: is it hard to fix? |
| 22:53:08 | evan | it's not simple. |
| 22:53:10 | evan | i'm working on it now. |
| 22:53:18 | evan | i have to track it through the parser. |
| 22:53:18 | radarek | ok |
| 22:53:54 | radarek | parsers are for me black magic :) |
| 22:58:15 | radarek | ok, I have to go sleep (GMT +2h), bye |
| 22:58:19 | evan | nite |
| 23:06:11 | brixen | zoinks http://gist.github.com/396662 |
| 23:07:29 | evan | *facepalm* |
| 23:07:45 | brixen | haha |
| 23:17:19 | kronos_vano | :D |
| 23:20:04 | evan | ok, this syntax error is critical enough to fix |
| 23:20:07 | evan | and I believe I have a fix |
| 23:20:23 | evan | additionally, i'm going to slip a trivial fix for -c in |
| 23:20:30 | evan | it's off by one because 0 was passed in as the start line |
| 23:20:40 | brixen | ahh |
| 23:20:49 | evan | seem ok? |
| 23:21:39 | brixen | yeah |
| 23:36:53 | boyscout | Handle :do in a method call properly - 5b99467 - Evan Phoenix |
| 23:47:06 | boyscout | CI: rubinius: 5b99467 successful: 3457 files, 13596 examples, 41216 expectations, 0 failures, 0 errors |