Show enters and exits. Hide enters and exits.
| 02:06:56 | ajsie | hi |
| 02:07:08 | ajsie | are there any reasons i should use rubinius instead of mri? |
| 02:07:29 | ajsie | which one would i get if i just type rvm install ruby-1.9.2? |
| 02:34:02 | andrewvc | Hi all, I'm trying to get the ffi-rzmq gem running on rubinius, and I was wondering if anyone had any idea about an error I'm getting |
| 02:35:42 | andrewvc | http://github.com/chuckremes/ffi-rzmq/blob/master/lib/ffi-rzmq/wrapper.rb#L57 I get an error, no method '+' on flags:Symbol. |
| 02:44:02 | Defiler | ffi gem changed the api without contributing back :( |
| 02:44:16 | Defiler | so there are things that depend on ffi now that don't work suddenly on rbx |
| 02:44:21 | Defiler | needs to be reconciled |
| 02:51:43 | andrewvc | ah |
| 02:52:00 | andrewvc | so, is this something I should wait for RBX to fix then? |
| 03:06:08 | cremes | andrewvc: if you really need it i suggest working on a patch for rbx yourself |
| 03:06:14 | cremes | i would certainly appreciate it! |
| 03:06:26 | andrewvc | hi Chuck, fancy seeing you here :) |
| 03:06:37 | cremes | i'm everywhere... ;) |
| 03:06:55 | andrewvc | apparently, hehe |
| 03:07:25 | cremes | the problem is that the ffi gem changed its api about 9 months ago; rbx has its own implementation and the api hasn't been updated to match yet |
| 03:07:41 | cremes | evan already added callbacks which is the really hard one |
| 03:07:57 | cremes | the remaining issues are related to parsing FFI::Struct layouts (i think) |
| 03:08:19 | andrewvc | gotcha, unfortunately, seeing as how I don't know C, and have no FFI experience, this might be out of my reach. |
| 03:08:45 | andrewvc | but it does seem like a challenge for a later day :) |
| 03:08:58 | cremes | luckily the code in question is all in ruby |
| 03:09:11 | andrewvc | really, hmmm, when I have some time I'd like to dive in then |
| 03:09:11 | cremes | no C required |
| 03:09:35 | cremes | cool; if you write the patch, you'll get a commit bit to rubinius which is nice |
| 03:09:46 | andrewvc | nice |
| 03:09:48 | cremes | oh, and don't forget the specs (the hard part) |
| 03:09:51 | andrewvc | lol |
| 03:09:54 | andrewvc | yes |
| 03:09:57 | andrewvc | btw, how's xreq/xrep support in ffi-rzmq? I've been meaning to take a look at that |
| 03:10:17 | cremes | it's in there now in master |
| 03:10:30 | cremes | i need to cut a new release but i wanted to add some specs first |
| 03:10:49 | cremes | clone master and build a gem from there; it should work fine |
| 03:10:53 | cremes | i use xreq/xrep daily now |
| 03:10:57 | andrewvc | did that this afternoon |
| 03:11:05 | cremes | ok |
| 03:11:09 | andrewvc | had a question about it though |
| 03:11:17 | cremes | it is? |
| 03:11:43 | andrewvc | I mean, there are no official docs about using it yet, correct? |
| 03:11:50 | andrewvc | or is my google-fu failing me |
| 03:12:17 | cremes | using which? |
| 03:12:25 | cremes | the ffi-rzmq gem or 0mq in general? |
| 03:12:31 | andrewvc | oh, no, xreq/xrep |
| 03:12:44 | cremes | you are in luck; they just committed some docs this morning |
| 03:13:00 | cremes | they are a bit sparse but better than nothing |
| 03:13:19 | cremes | take a look at the 2.0.8 release; it has the improved docs |
| 03:13:33 | andrewvc | cool, downloading now |
| 03:13:52 | cremes | also, pieter has been working on a 0mq guide (examples in C) |
| 03:14:09 | cremes | it's really quite good and it's applicable to any language bindings |
| 03:14:35 | andrewvc | sweet, I need to take a look at that |
| 03:14:59 | andrewvc | maybe translate that into ffi-rzmq for others |
| 03:15:06 | andrewvc | I've just been using your stuff from example/ |
| 03:15:37 | cremes | yeah, sorry those examples kind of suck... |
| 03:15:51 | andrewvc | hehe, well, thanks for writing the gem, it's pretty awesome |
| 03:15:54 | cremes | i wrote them in about 10 minutes |
| 03:16:09 | cremes | you are welcome; keep building cool stuff with it and that's thanks enough |
| 03:16:23 | cremes | btw, i just committed the first attempt at some 0mq devices to zmqmachine |
| 03:16:29 | andrewvc | sweet |
| 03:16:31 | cremes | specifically the queue and forwarder devices |
| 03:16:33 | cremes | *very* useful |
| 03:16:41 | cremes | plus i fixed a nasty bug in the timers |
| 03:16:48 | andrewvc | I've been meaning to let you know, I found a bug in zmqmachine |
| 03:16:59 | cremes | i'd be surprised if you hadn't! |
| 03:17:08 | andrewvc | I wasn't able to instantiate two sub sockets in one process both subscribing to a single publisher |
| 03:17:22 | andrewvc | Not sure if that was intentional |
| 03:17:42 | cremes | was the publisher binding to a socket and the sub sockets were connecting? that should work. |
| 03:17:54 | cremes | but flip it around and that won't work regardless of langugage binding |
| 03:18:06 | andrewvc | no, the publisher was bound |
| 03:18:20 | cremes | if you have a small example, open an issue on it and i'll get it fixed |
| 03:18:26 | andrewvc | sure thing |
| 03:18:26 | cremes | that should definitely work |
| 03:18:46 | andrewvc | so, question, why ZMQ::Machine from scratch instead of EventMachine ? |
| 03:19:15 | cremes | because hacking on EM requires more c++ skill than i currently posess |
| 03:19:34 | cremes | and 0mq sockets don't play well with the select/epoll/kqueue event handling in EM |
| 03:19:48 | andrewvc | interesting |
| 03:20:03 | cremes | the upcoming 0mq 2.1 should resolve some of that problem in which case i'll add support for regular sockets to zmqmachine |
| 03:20:05 | andrewvc | I've been mixing EM and ffi-rzmq |
| 03:20:17 | cremes | should work |
| 03:20:18 | andrewvc | but just running the zmq stuff in a separate thread, nothing fancy |
| 03:20:56 | cremes | yep |
| 03:21:14 | cremes | i think we've hijacked this channel long enough... see you in the 0mq channel |
| 03:21:22 | andrewvc | sure |
| 06:05:13 | boyscout | Specs for String#unpack DdEeFfGg. - ffd51b7 - Brian Ford |
| 06:05:13 | boyscout | Fixed Config deprecation warning for 1.9.3. - 49d57e2 - Brian Ford |
| 06:05:13 | boyscout | Added pack DdEeFfGg. - 0467a74 - Brian Ford |
| 06:05:37 | boyscout | CI: Commit 0467a74 failed. http://github.com/evanphx/rubinius/commit/0467a74e6986e67b72058ca968fe73b87bc6827b |
| 06:06:00 | brixen | um... |
| 06:11:02 | brixen | gcc is such a pile |
| 06:18:37 | postmodern | brixen, good job, down to 5 failin specs with Process.kill |
| 06:18:48 | postmodern | brixen, almost all of my code passes their specs on rubinius |
| 06:19:26 | brixen | postmodern: sweet |
| 06:19:32 | brixen | you mean, you app code? |
| 06:19:41 | brixen | er your app code |
| 06:19:51 | brixen | also, what are the failures on Process.kill? |
| 06:20:39 | boyscout | Removed function confusing GCC. - b3033b4 - Brian Ford |
| 06:20:52 | postmodern | rubinius specs have those 5 issues with Process.kill |
| 06:21:03 | postmodern | expected nil, got 55 |
| 06:21:06 | postmodern | er 99 |
| 06:21:13 | postmodern | er expected nil to equal 99 |
| 06:22:21 | brixen | on what platform? |
| 06:23:10 | brixen | erg, this is the selinux thing, right? |
| 06:26:52 | postmodern | brixen, correct, selinux amd64 |
| 06:27:00 | brixen | k |
| 06:27:03 | brixen | what distro? |
| 06:27:04 | postmodern | brixen, still the Process.wait specs now pass |
| 06:27:13 | postmodern | brixen, fedora 13 |
| 06:27:24 | brixen | hmm, I think I have that... |
| 06:27:29 | brixen | fires up vbox |
| 06:28:17 | postmodern | brixen, make sure to update to the latest changes, new kernel just got released |
| 06:39:53 | boyscout | CI: rubinius: b3033b4 successful: 3520 files, 15244 examples, 43093 expectations, 0 failures, 0 errors |
| 06:55:32 | dbussink | postmodern: that selinux issue is likely a bug in libffi though |
| 06:55:52 | dbussink | postmodern: evan had to fix things there for the non selinux case |
| 06:57:59 | postmodern | makes sense |
| 06:58:19 | dbussink | so i don't know how much we can do to fix it |
| 06:58:34 | dbussink | apart from not using ffi :P |
| 07:00:49 | postmodern | well Process.wait specs used to fail, now they do not |
| 07:00:58 | postmodern | im guessing those are related to the Process.kill specs |
| 07:01:01 | postmodern | and somehow fixable |
| 07:04:20 | brixen | postmodern: we'll fix them |
| 07:05:24 | brixen | postmodern: I ran software update, but don't see anything about a new kernel |
| 07:05:55 | postmodern | brixen, it should probably update yum first |
| 07:06:08 | postmodern | brixen, then it should reload the update program, and you'll see ~70 packages |
| 07:06:18 | brixen | ok |
| 07:06:34 | brixen | bingo |
| 07:06:39 | brixen | 391 updates |
| 07:06:43 | postmodern | haha |
| 07:06:44 | brixen | yowza |
| 07:06:55 | postmodern | hope that's running on an SSD :) |
| 07:07:02 | brixen | :( |
| 07:07:50 | brixen | I'll just let it run overnight |
| 08:01:48 | dbussink | brixen: still there? |
| 16:38:21 | brixen | dbussink: I am now :) |
| 16:38:41 | brixen | silly fedora, I let you run all night and you're still not done? :( |
| 16:41:40 | dbussink | brixen: i went through rbx a bit and also changed Config to RbConfig where needed, ok if i commit that? |
| 16:41:42 | dbussink | brixen: it's still working? that's nasty :) |
| 16:41:59 | brixen | yeah, I just rebooted it |
| 16:42:07 | brixen | yeah, that's fine to change |
| 16:42:15 | brixen | 1.9.3 deprecates Config |
| 16:42:39 | brixen | RbConfig has been available for years |
| 16:42:54 | brixen | as long as we still provide Config, it's fine to use RbConfig |
| 16:43:25 | dbussink | brixen: yeah, i just switch the alias |
| 16:43:34 | dbussink | brixen: Config = RbConfig and use RbConfig everywhere |
| 16:43:46 | brixen | ok |
| 16:55:05 | boyscout | Use RbConfig instead of Config - bd6aef7 - Dirkjan Bussink |
| 16:55:14 | dbussink | evan: ping? |
| 16:55:22 | evan | hey |
| 16:58:22 | dbussink | evan: i made this change in hydra, but this is also an issue in master |
| 16:58:33 | evan | what change? |
| 16:58:40 | dbussink | argh |
| 16:58:43 | dbussink | http://github.com/evanphx/rubinius/commit/ff3dedc1865feac144eacc8849c5aaf24d63b31e |
| 16:58:44 | dbussink | that one |
| 16:58:57 | dbussink | does this make sense as the master version of that fix? https://gist.github.com/ce0c459a342c8bb95897 |
| 16:59:00 | evan | ah right |
| 16:59:16 | evan | yeah |
| 16:59:18 | evan | that looks fine. |
| 16:59:20 | dbussink | is passes the torture test with that change |
| 16:59:22 | dbussink | :) |
| 17:00:12 | dbussink | evan: so what's to do for a 1.1 release? |
| 17:00:31 | evan | well |
| 17:00:39 | evan | i'm working on fixing the GIL problem |
| 17:00:46 | boyscout | Fix fallback to ObjectMemory allocation if no new slab can be allocated - 52e591c - Dirkjan Bussink |
| 17:00:48 | evan | we need to get the FFI::Struct API issue sorted |
| 17:01:19 | evan | and we need to go through the docs and just fix/delete outdated ones |
| 17:02:41 | dbussink | man, crazy weather here today |
| 17:02:44 | dbussink | streets are flooded |
| 17:02:56 | dbussink | as much rain in a day as usually in a month |
| 17:03:58 | brixen | dbussink: hopefully they make wooden boots, those shoes would get pretty wet :) |
| 17:04:16 | dbussink | brixen: i'm wearing mine as we speak of course :P |
| 17:04:20 | brixen | heh |
| 17:05:52 | dbussink | on http://github.com/evanphx/rubinius/issues#issue/437, would we want to define RUBY_VM ? |
| 17:06:03 | dbussink | or should we tell oci8 people to do a proper HAVE_ test? |
| 17:07:03 | boyscout | CI: rubinius: bd6aef7 successful: 3520 files, 15244 examples, 43093 expectations, 0 failures, 0 errors |
| 17:10:43 | brixen | dbussink: that needs proper HAVE_ defines, tests |
| 17:11:14 | dbussink | brixen: well, it borks because they do weird checks whether rb_blocking_function_t is available or not |
| 17:11:49 | brixen | yes, they need to fix that |
| 17:12:01 | brixen | and we need to ensure we have the proper HAVE_ defines for it |
| 17:12:38 | dbussink | there's already a HAVE_RB_THREAD_BLOCKING_REGION defined |
| 17:12:43 | dbussink | so that should be ok |
| 17:14:38 | brixen | k |
| 17:22:30 | dbussink | brixen: also mailed a guy who might know some of the oci8 people |
| 17:22:51 | brixen | cool |
| 18:33:54 | wyhaines | evan: Making any progress on the GIL bug? |
| 18:34:46 | evan | wyhaines: getting ther.. |
| 18:34:49 | evan | there |
| 18:35:43 | evan | I was reading http://bugs.python.org/issue7946 |
| 18:36:03 | evan | it discusses how the new python GIL effects IO bound threads |
| 18:37:17 | wyhaines | Cool. I am taking a look. |
| 18:37:39 | evan | basically, the old behavior might have better IO performance |
| 18:37:59 | evan | because a thread could unlock the GIL, do some IO that doesn't block, then lock the GIL |
| 18:38:05 | evan | without giving another thread a chance to run |
| 18:39:24 | evan | where as making sure there are equatible distributions mean that unlocking the GIL forces another thread to run |
| 18:42:16 | evan | i think there is a way to allow for that behavior still though |
| 18:43:34 | evan | this is all making it crystal clear how important hydra is now too. |
| 18:49:14 | evan | wyhaines: poke |
| 18:49:17 | evan | wyhaines: could you apply http://gist.github.com/551957 |
| 18:49:24 | evan | and see what the results are like on that ubuntu machine |
| 18:51:13 | wyhaines | evan. Sure |
| 20:33:53 | evan | wyhaines: any results? |
| 21:28:07 | pyonpyon | hehe got it working on the iphone (both emulator and device), seems very slow to boot though |
| 21:29:15 | pyonpyon | i just love the iphone platform, it runs everything i throw at it, porting is virtually effortless |
| 21:32:04 | BrianRice-work | rubinius/rbx on iOS? |
| 21:32:20 | BrianRice-work | is that in jailbreak or using the SDK? |
| 21:32:37 | pyonpyon | yeah, no jailbreak needed |
| 21:33:23 | BrianRice-work | nice |
| 21:35:06 | evan | pyonpyon: awesome! |
| 21:35:21 | pyonpyon | hehe not really it was quite straightforward |
| 21:37:04 | pyonpyon | besides it's not using llvm jit, which i kind of doubt could be used, given the mprotect issue. i'll see how it compares to yarv |
| 21:38:11 | pyonpyon | and kudos to you guys for writing portable code :3 |
| 21:42:42 | brixen | gcc keeps getting more stupid with every release |
| 21:43:23 | brixen | evan: to build your gil patch on 4.4.4 (fedora 13), global_lock.hpp needs to include stdint.h |
| 21:43:54 | rue | s/stupid/strict/ |
| 21:43:56 | brixen | if you try to include cstdint, gcc fails with a warning about having to explicitly turn on -std=gnu++0x |
| 21:44:36 | brixen | rue: stupid |
| 21:45:03 | evan | brixen: k |
| 21:46:42 | brixen | evan: I'll give you a diff once I get it to build |
| 21:46:48 | evan | k |
| 21:46:51 | evan | there is still some bugs |
| 21:46:53 | evan | i'm sorting out |
| 21:46:55 | brixen | ok |
| 21:46:56 | devinus | the gil is being removed!? |
| 21:46:57 | evan | so it's not a final thing |
| 21:47:03 | rue | I prefer not being able to do willy-nilly stuff but whatever |
| 21:47:04 | evan | devinus: yep! |
| 21:47:08 | devinus | oh joy!!! |
| 21:47:13 | evan | devinus: not for 1.1 |
| 21:47:18 | evan | but it's in the hydra branch |
| 21:47:21 | evan | if you wanna check it out. |
| 21:47:54 | evan | rue: eh? |
| 21:48:06 | brixen | rue: there's no willy-nilly about it, cstdint has been around for a long time, if 4.4.whatever wants to put c++0x shit in it, it should conditionalize it |
| 21:48:09 | brixen | not just fail |
| 21:48:10 | evan | rue: oh, gcc |
| 21:48:12 | evan | gotcha |
| 21:48:44 | devinus | it's going to be hard to ignore rubinius as a real contender now |
| 21:48:53 | evan | devinus: we hope so! |
| 21:49:54 | devinus | evan: weren't you also working on upgrading to latest llvm as well? |
| 21:50:03 | evan | yep |
| 21:50:13 | evan | it fell by the wayside slightly |
| 21:50:15 | devinus | nice |
| 21:50:17 | evan | probably won't be in 1.1 now |
| 21:50:22 | evan | but i might get it in |
| 21:50:29 | evan | it was an easy upgrade to 2.7 actually |
| 21:50:46 | devinus | meh, as both are in 1.2 or 1.5 or whatever the next version after 1.0 then that's great |
| 21:50:56 | devinus | after 1.1 i mean |
| 21:51:25 | evan | yeah, the LLVM upgrade will be quite soon after 1.1 i'm guessing if i don't get it in before. |
| 21:54:16 | brixen | evan: ok, looks like just stdint.h and sys/time.h needed in vm/global_lock.hpp |
| 21:54:21 | evan | k |
| 21:54:30 | wyhaines | evan: Yeah. I didn't have a copy of the repo, and I appear to be bandwidth-poor today. Taking forever to get it cloned. I'll let you know for sure as soon as possible. |
| 21:54:43 | evan | wyhaines: ok, no prob. |
| 21:54:59 | evan | wyhaines: i've got to sit on it until you can give me the thumbs up |
| 22:00:16 | evan | interestingly |
| 22:00:21 | brixen | evan: looks like I have a hang |
| 22:00:29 | evan | the new GIL handshake protocol makes some specs run slower |
| 22:00:34 | brixen | hmm |
| 22:00:36 | evan | but thats because the spec is silly. |
| 22:00:37 | evan | yeah |
| 22:00:43 | evan | let me get you a new patch |
| 22:00:45 | evan | it fixes that hang. |
| 22:00:45 | brixen | ok |
| 22:02:45 | evan | previously, Thread.pass was, well, it was a misnomer. |
| 22:03:03 | evan | we'd unlock and then relock the GIL so quickly |
| 22:03:08 | evan | it would rarely actually pass control |
| 22:03:22 | evan | the handshake means that Thread.pass actually passes everytime. |
| 22:03:57 | brixen | sounds better |
| 22:04:01 | evan | brixen: try http://gist.github.com/552349 |
| 22:04:05 | brixen | k |
| 22:04:09 | evan | I added those includes |
| 22:04:14 | brixen | cool |
| 22:04:20 | evan | there is still some debugging output |
| 22:04:21 | evan | btw. |
| 22:06:12 | brixen | k |
| 22:19:37 | evan | ok, i have to pick up abby's car |
| 22:19:39 | evan | bbiab. |
| 22:19:44 | brixen | k |
| 22:20:56 | evan | brixen: let me know how that patch works out. |
| 22:21:06 | brixen | running specs now |
| 22:21:51 | brixen | I see mostly timeout requesting drop, with a few waiting on handshake |
| 22:22:04 | brixen | most of the really slow specs have no gil related debug output |
| 22:22:59 | brixen | I need to find out what these really slow specs are |
| 22:23:31 | brixen | ok, even with the debug output, this ran in 353s vs ~370s before the patch |
| 22:23:34 | brixen | I'll rerun both |
| 22:43:14 | brixen | evan: 343s with gil patch, 368s without on 2nd runs |