Show enters and exits. Hide enters and exits.
| 18:54:08 | danlucraft | testy test test |
| 18:55:38 | someoneelse | Hi, i am new to rubinius. I've written, that rubinius code is compiled to machine code and then executed. The example (puts 'Hello World') on the webpage looks like beeing compiled to assembly code?? Is that correct or did i misanderstand? |
| 18:56:19 | evan | someoneelse: we have a JIT compiler which compiles ruby code to machine code, yes. |
| 18:56:27 | evan | we also have an interpretter |
| 18:57:40 | someoneelse | So would it be possible to compile code before running the whole stuff and like that not haveing the compile-time when beeing executed? Will the code being compiled each time it is executed or will the same code being compiled only once?? |
| 18:59:10 | someoneelse | i mean this is not what most expect when useing ruby but in some cases it would be really interesting to compile only once, not each time it is executed... |
| 18:59:33 | evan | we don't support saving the compiled code between executions atm, no. |
| 18:59:38 | brixen | someoneelse: we don't have ahead-of-time compilation to machine code |
| 18:59:40 | evan | and it's tricky to do so |
| 18:59:55 | evan | because ruby is so dynamic, the machine code makes assumptions about the state of things |
| 19:00:09 | someoneelse | 'and it's tricky to do so' .... what a pitty :) |
| 19:00:20 | evan | even if things were compiled up front, you'd still need the JIT and interpretter |
| 19:00:34 | someoneelse | why?? |
| 19:00:36 | evan | because any compiled code can become wrong at any time |
| 19:00:52 | evan | so you need a way to continue to run if you decide the compiled code is wrong. |
| 19:00:53 | someoneelse | why? |
| 19:00:58 | evan | because ruby is dynamic. |
| 19:01:18 | evan | we do method inlining, for example. |
| 19:01:37 | evan | if you were to compile each ruby method to machine code naively |
| 19:01:45 | evan | ie, with all method calls being opaque |
| 19:01:53 | evan | you wouldn't see a very big speedup |
| 19:02:00 | brixen | dbussink: it appears that using Process.kill(:KILL, $$) will work in both *nix and windows, but windows does not appear to be setting $? correctly |
| 19:02:03 | scoopr | eval(gets) |
| 19:02:05 | evan | beacuse right away you're bottlenecked on dispatch then. |
| 19:02:21 | brixen | dbussink: ie, $? has the right PID, but none of the correct state, like signaled? |
| 19:02:47 | evan | brixen: thats expected. |
| 19:02:50 | brixen | dbussink: atm, I don't know if this is a bug or windows limitation, but it highlights why we need thes specs running |
| 19:02:53 | someoneelse | ok. That's true for sure! and that's why i love ruby (for the dynamic thing). But in some cases it could be helpful to say 'this code want change while running - so compile once only'.... Wouldn't this be possible? |
| 19:02:54 | evan | brixen: as I believe. |
| 19:02:59 | brixen | evan: why expect? |
| 19:03:12 | evan | I don't think that windows exposes a bunch of that state |
| 19:03:21 | evan | so ruby also can't. |
| 19:03:27 | brixen | hrm |
| 19:03:36 | evan | someoneelse: why would that be useful? |
| 19:03:40 | evan | why not just let the JIT figure it for you/ |
| 19:03:45 | evan | ? |
| 19:04:15 | someoneelse | performance reasons |
| 19:04:30 | someoneelse | that the only reason |
| 19:04:32 | evan | you'd be wrong then. |
| 19:04:41 | someoneelse | ok..... why? |
| 19:04:48 | evan | the JIT yields better performance than trying to allow for the code to be compiled ahead of time |
| 19:04:56 | someoneelse | ok. |
| 19:05:04 | evan | because the JIT can leverage direct pointers and information about the running of the current process |
| 19:05:08 | someoneelse | then it's nice how it is :) |
| 19:05:12 | evan | inlining different methods, etc. |
| 19:05:21 | evan | :D |
| 19:05:25 | evan | i should probably write this up! |
| 19:05:43 | evan | but, i have to grab some lunch first, since it appears i have to do some last minute babysitting today |
| 19:06:43 | someoneelse | 'i should probably write this up!' : Yes that would be nice to read on the webpage. I am probably not the only one think like this :) |
| 19:11:49 | dbussink | brixen: did you test it with mri i guess? |
| 19:11:56 | dbussink | assume it's a windows limitation then |
| 19:13:29 | brixen | someoneelse: http://www.engineyard.com/blog/2009/the-anatomy-of-a-ruby-jit-compile/ |
| 19:13:59 | brixen | someoneelse: that permalink is wrong, the article is about bytecode, but read it |
| 19:14:03 | brixen | someoneelse: http://www.engineyard.com/blog/2010/making-ruby-fast-the-rubinius-jit/ |
| 19:14:12 | brixen | someoneelse: that one is about the jit :) |
| 19:14:32 | brixen | dbussink: well, even if it is, we need these specs running on windows |
| 19:14:38 | brixen | so folks can see what's up |
| 19:15:02 | brixen | I haven't looked into the windows limitations yet |
| 19:17:30 | someoneelse | oh i need a running ruby vm to install rubinius? Or did i do something wrong? |
| 19:19:34 | someoneelse | oh i see i need version 1.8.7 of MRI.... ok. |
| 19:26:20 | dbussink | someoneelse: 1.9 should also work these days btw |
| 19:26:29 | dbussink | but yeah, you need an existing ruby atm |
| 19:26:41 | someoneelse | ok thy |
| 19:26:42 | someoneelse | thx |
| 19:36:05 | cremes | is rbx self-hosted? meaning that if i have a binary version of rbx installed somewhere that it can build rbx from source? |
| 19:36:11 | cremes | or does it only like mri these days? |
| 19:36:18 | cremes | just curious... :) |
| 19:40:17 | dbussink | cremes: afaik it's possible yeah |
| 19:40:26 | dbussink | i might have tried at some point in the past |
| 19:40:37 | dbussink | evan: is bootstrapping still on the planned to do list? |
| 19:41:18 | cremes | i'm trying it right now |
| 19:41:22 | cremes | i'll let you know what i find |
| 19:41:48 | dbussink | cremes: bootstrapping != self hosting btw :) |
| 19:42:00 | dbussink | but i guess you know the difference :) |
| 19:42:06 | cremes | that's why i provided my own definition! |
| 19:42:13 | cremes | i was pretty sure that was the wrong nomenclature |
| 19:42:37 | dbussink | cremes: well, bootstrapping would mean it's not dependent on any external ruby version |
| 19:42:50 | dbussink | cremes: self hosting is that it can compile itself i guess, or that's how i see it at least ;) |
| 19:48:32 | dbussink | brixen: ok, so on those specs, what does Process.kill(:KILL, $$) exactly do? |
| 19:52:26 | dbussink | brixen: nvm, found it :) |
| 19:57:12 | duncan | does the C api has any testsuite? |
| 19:57:29 | brixen | duncan__: yes, spec/ruby/optional/capi |
| 19:57:58 | sbryant | it's not really different from the regular test suite, unless its changed alot since I last worked on it |
| 19:58:12 | brixen | cremes: rbx should biuld rbx just fine |
| 19:58:18 | brixen | cremes: also build :) |
| 19:58:26 | duncan | Socket#getaddrinfo gets the address information FAILED |
| 19:58:34 | duncan | 3516 files, 15152 examples, 43017 expectations, 1 failure, 0 errors |
| 19:59:11 | brixen | duncan__: could you gist the failure? |
| 19:59:56 | dbussink | brixen: ok, also checked with windows, `ruby -e 'Process.kill(:KILL, $$); exit 1` gives me exit status 0 and no signal given |
| 20:00:07 | brixen | dbussink: yep |
| 20:00:11 | duncan | http://gist.github.com/546213 |
| 20:00:25 | dbussink | brixen: so windows can probably not support that |
| 20:00:42 | dbussink | also checked with the rubyinstaller versions, since they use a much more recent compiler |
| 20:00:50 | dbussink | but that doesn't make a difference |
| 20:00:58 | brixen | duncan__: yeah, incomplete spec, could you open a ticket for that? |
| 20:01:20 | brixen | dbussink: either way, we need the specs running on windows |
| 20:01:36 | cremes | fyi, rubyinstaller is using gcc 4.5.0 as of a few days ago |
| 20:01:40 | brixen | grabbing food, bbiab... |
| 20:02:04 | duncan | can it be that rb_yield_values is not in 1.0.x but on HEAD? |
| 20:02:10 | duncan | brixen: sure |
| 20:02:56 | mylarry | Hi! i tried to download and run rubinius. ./configure was successfull. but then running just 'rake' failed. what can i do? is there any paste-page where i can paste the error log? so that someone can have a look at what has happened? Or can paste here in the IRC?? |
| 20:03:49 | cremes | mylarry: to build you should just run "rake" |
| 20:03:57 | cremes | no need to run configure on your own |
| 20:04:06 | cremes | the rake task makes sure to set everything up |
| 20:04:12 | brixen | cremes: not true |
| 20:04:18 | brixen | you have to run configure |
| 20:04:33 | brixen | mylarry: could you gist what your terminal output is when you run rake? |
| 20:04:33 | cremes | harumph |
| 20:04:50 | dbussink | duncanmv: master has quite a bit more capi stuff yeah |
| 20:04:56 | brixen | mylarry: use pastie or gist.github.com |
| 20:05:26 | dbussink | pasting it directly in here will make people go haywire :P |
| 20:05:41 | dbussink | brixen: well, i guess parts of the specs should run on windows then |
| 20:05:48 | dbussink | since it can't pass all assertions |
| 20:05:59 | brixen | well, it'll likely get you kicked automatically |
| 20:06:18 | brixen | dbussink: the specs describe what MRI does ;) |
| 20:06:36 | brixen | if it does different things on windows, that's what platform_is :windows is for |
| 20:06:46 | duncanmv | ok done http://github.com/evanphx/rubinius/issues/issue/444 |
| 20:06:46 | mylarry | error is on: http://gist.github.com/546233 |
| 20:07:00 | duncanmv | will try his gems with HEAD |
| 20:07:05 | brixen | duncanmv: thanks |
| 20:07:30 | brixen | mylarry: what version of gcc are you using? |
| 20:08:30 | mylarry | Thread model: posix |
| 20:08:31 | mylarry | gcc version 3.4.4 |
| 20:08:42 | brixen | mylarry: you need 4.0 or greater |
| 20:08:51 | mylarry | ahhh ok. THX! |
| 20:08:56 | brixen | mylarry: what is your OS/platformm btw? |
| 20:09:11 | mylarry | puppy linux 4.xx |
| 20:09:34 | brixen | googles :) |
| 20:09:59 | mylarry | so it has a quite new Kernel.... but old gcc :( |
| 20:10:18 | brixen | ok |
| 20:11:19 | brixen | mylarry: just fyi, doc/getting_started.txt lists requirements |
| 20:11:38 | brixen | gcc 4.x is in there as well as a number of packages you may need on linux |
| 20:11:46 | dbussink | mylarry: looks like puppy 5.1 is a lot more up to date with software |
| 20:13:55 | mylarry | ohhh sorry. i was wrong. I use puppy 4.x a lot but now i am on puppy 2.17 which is a bit older (and has the old gcc version). Maybe 4.x comes with a newer gcc version! |
| 20:16:53 | dbussink | brixen: first step is that i can see to remove the fork and use `` |
| 20:17:16 | dbussink | brixen: btw, how actively is rubyspec now used with windows too? |
| 20:19:32 | duncanmv | I guess capi is a good think to backport for 1.0.x releases or? |
| 20:20:04 | evan | i'm back |
| 20:20:10 | evan | and don't have to babysit |
| 20:22:55 | duncanmv | will probably try to backport HEAD capi to rubinius 1.0.x openSUSE package. I wonder if it would be straightforward. |
| 20:23:02 | evan | why? |
| 20:23:08 | evan | better would be to wait for 1.1 |
| 20:23:12 | evan | which will be out in a couple weeks. |
| 20:23:15 | duncanmv | really? |
| 20:23:18 | duncanmv | oh, that is nice |
| 20:23:27 | duncanmv | uhm , it seems sfcc gem works with HEAD |
| 20:23:32 | evan | we're getting close to finalizing it up. |
| 20:23:38 | dbussink | brixen: https://gist.github.com/051f7dd9af757b1230cc already looks nicer :) |
| 20:23:45 | duncanmv | rpm gem will need more work. now on HEAD I get unresolved rb_hash |
| 20:24:28 | dbussink | brixen: should there be a platform is windows block too? since it also feels a bit as something that is missing because windows can't provide that information |
| 20:24:48 | dbussink | just feels wrong to write a spec that says it cleanly exited there if it doesn't on windows |
| 20:24:52 | duncanmv | will proudly add to the ruby-sfcc README that it builds and pass testsuite with rubinius |
| 20:25:50 | dbussink | evan: how old is the kid you might had to babysit? |
| 20:26:04 | evan | 7 months |
| 20:26:18 | dbussink | ah, really baby then :) |
| 20:26:28 | evan | heh, yeah, actual babysitting. |
| 20:26:37 | dbussink | if they get like 2 years old they start to play with your iphone :P |
| 20:26:47 | dbussink | or whatever touch device you have :P |
| 20:26:50 | evan | ha |
| 20:26:52 | evan | well actually |
| 20:26:56 | evan | she loves my iphone |
| 20:27:00 | evan | especially the 4 |
| 20:27:07 | evan | because i can put the front camera on |
| 20:27:13 | evan | and she can watch herself |
| 20:27:23 | evan | but other than that, she wants to put it in her mouth |
| 20:27:24 | dbussink | my gf's nephews apparently started calling people when we didn't pay attention |
| 20:27:32 | dbussink | without telling them a thing |
| 20:27:36 | evan | hah |
| 20:27:48 | brixen | dbussink: try not to editorialize in specs :) it "returns true" is accurate |
| 20:27:53 | dbussink | figured out the screen unllock etc on themselves |
| 20:29:07 | dbussink | brixen: but it already looks a lot nicer yeah :) |
| 20:29:31 | brixen | dbussink: also, make sure your describe strings concatenate to readable strings |
| 20:29:33 | dbussink | brixen: how about those windows blocks? spec the unsupported behavior explicitly? or just leave it at those regularly exiting processes? |
| 20:30:25 | brixen | the specs need to describe what MRI actually does |
| 20:30:34 | dbussink | brixen: i've updated it: https://gist.github.com/051f7dd9af757b1230cc |
| 20:32:09 | brixen | dbussink: ok, we need to spec windows too |
| 20:33:41 | dbussink | brixen: https://gist.github.com/051f7dd9af757b1230cc |
| 20:33:49 | dbussink | i'm still a bit unsure on the exact wording |
| 20:34:02 | dbussink | i'd like to make clear that whatever you do on windows, you always get true back |
| 20:34:49 | dbussink | (which isn't inline with the documentation btw) |
| 20:35:00 | dbussink | so that's something i'd prefer to be clear from it |
| 20:35:06 | dbussink | but i can also add a comment |
| 20:35:12 | dbussink | or just don't bother with it |
| 20:37:35 | brixen | dbussink: the spec already says that |
| 20:38:19 | brixen | dbussink: describe "for a terminated child" sounds better than "after..." |
| 20:39:22 | brixen | dbussink: also, describe "for a child that exited normally" |
| 20:41:03 | dbussink | brixen: ok, but i'll update those others with this style too then |
| 20:41:06 | dbussink | for now, first some sleep |
| 20:43:11 | brixen | dbussink: ok, thanks! |
| 20:44:43 | wyhaines | Does Rubinius have any known issues with being built under GCC 4.3.x? |
| 20:45:36 | brixen | wyhaines: I don't see any tickets for issues |
| 20:47:44 | brixen | wyhaines: what platform are you on? |
| 20:48:10 | evan | dbussink: i'm giving up on this bug for now and switching back to 1.1 work |
| 20:51:03 | wyhaines | brixen: A few different ones. I was testing on an Ubuntu based system. It builds, but some of the threading tests are incredibly slow. Running the tests on a relatively slow AWS instance is an order of magnitude faster than the fastest test run I've seen off of a dedicated Ubuntu box that should be faster than the AWS instance. |
| 20:51:33 | wyhaines | Just speculating about possible causes. The compiler version is one difference. |
| 20:52:04 | brixen | odd |
| 20:52:04 | evan | wyhaines: very unlikely. |
| 20:52:17 | evan | it being a compiler performance issue |
| 20:52:23 | evan | never seen that |
| 20:52:31 | evan | rbx isn't as compiler dependent as MRI |
| 20:52:52 | evan | because we don't blindly scan the call stack |
| 20:53:43 | wyhaines | evan: *nod* That's good to know. |
| 21:00:54 | duncanmv | man the capi testsuite is so clever |
| 21:01:05 | duncanmv | I would had never came up with such thing to test a C api |
| 21:01:31 | evan | duncanmv: well, we wanted to write the tests in ruby |
| 21:01:34 | evan | this was the best way. |
| 21:01:35 | duncanmv | prepares his first patch |
| 21:16:58 | dwaite | duncanmv: you never forget your first |
| 21:18:14 | evan | krrrronos: you around? |
| 21:18:22 | krrrronos | yep |
| 21:18:31 | evan | for ticket http://github.com/evanphx/rubinius/issues/#issue/371 |
| 21:18:36 | evan | did that code come from somewhere? |
| 21:18:45 | evan | i'm trying to decide if it needs to be in 1.1 or not. |
| 21:19:02 | krrrronos | mmm from somewhere? |
| 21:19:07 | krrrronos | what do you mean? |
| 21:19:14 | evan | yeah |
| 21:19:21 | brixen | from an app? |
| 21:19:22 | evan | did you see it in someones ruby code in a gem? |
| 21:19:25 | evan | yeah or an app |
| 21:19:29 | krrrronos | It's mine |
| 21:19:43 | evan | so you do that in some real code of yours? |
| 21:23:11 | krrrronos | You confused me :/ I just fix the reported issue. I never use the code somewhere else. |
| 21:23:45 | evan | krrrronos: sorry |
| 21:23:48 | evan | let me start over |
| 21:24:12 | evan | where did the code for this ticket come from? did you see it in a gem or app? |
| 21:24:32 | evan | how did you find it? |
| 21:24:57 | krrrronos | Are you talking about 1st comment in the ticket? |
| 21:25:09 | evan | no |
| 21:25:15 | evan | i'm talking about the ticket itself |
| 21:25:17 | evan | that you openned |
| 21:25:36 | krrrronos | arrr |
| 21:25:37 | krrrronos | sorry |
| 21:26:37 | krrrronos | No it is not from gem |
| 21:28:09 | krrrronos | My friend asked why the code works the way. I checked it and figured out, that the result in MRI and rubinius are different. |
| 21:29:24 | krrrronos | I've never seen it anywhere else. |
| 21:29:42 | krrrronos | do you understand me? |
| 21:29:57 | evan | yep |
| 21:30:52 | duncanmv | is under the impresion that he compiled rubinius HEAD using 1.0.1 |
| 21:31:27 | brixen | duncanmv: rbx -v should tell you |
| 21:31:40 | brixen | duncanmv: or do you mean you built rbx using rbx? |
| 21:32:43 | duncanmv | false alarm |
| 21:33:01 | duncanmv | rbx from head says 1.0.1 |
| 21:33:02 | duncanmv | rubinius 1.0.1 (1.8.7 6e7c8e82 2010-06-03 JI) [x86_64-unknown-linux-gnu] |
| 21:33:16 | duncanmv | 's new method in C API passed the spec |
| 21:34:27 | brixen | duncanmv: ahh yeah, our version doesn't change until the next release |
| 21:34:31 | brixen | potentially confusing |
| 21:34:51 | evan | we were just discussing that :) |
| 21:37:10 | duncanmv | realizes he has a old fork of rubinius on github with a llvm doc update |
| 21:40:37 | krrrronos | will hydra be merged in 1.1 ? |
| 21:40:50 | evan | no |
| 21:40:58 | krrrronos | ok |
| 21:43:29 | duncanmv | what is hydra? no GL? |
| 21:43:42 | evan | duncanmv: yep. |
| 21:43:59 | evan | that work is happening in parallel with 1.1 |
| 21:44:04 | evan | on the hydra branch |
| 21:45:14 | duncanmv | who is the "C API guy?" (for a pull request) |
| 21:45:51 | evan | me probably. |
| 21:46:22 | duncanmv | sent :-) |
| 21:46:44 | evan | ok, i've got some bad news. |
| 21:46:52 | evan | you need to split up the specs from the change |
| 21:46:53 | evan | into 2 commits |
| 21:46:59 | evan | before I can merge it in |
| 21:47:09 | duncanmv | argh |
| 21:47:17 | evan | all changes to the spec/ruby/ dir have to occur isolated. |
| 21:47:23 | evan | so that brixen can easily merge it with rubyspec |
| 21:47:26 | evan | sorry about that. |
| 21:47:39 | duncanmv | wipes the git repo again |
| 21:47:45 | evan | wait wait |
| 21:47:50 | evan | you don't need to do that at all |
| 21:47:57 | duncanmv | what should I do? |
| 21:48:05 | evan | git reset HEAD^ |
| 21:48:09 | evan | make the 2 commits |
| 21:48:11 | evan | then |
| 21:48:13 | evan | git push --force |
| 21:48:20 | duncanmv | ok |
| 21:48:41 | duncanmv | so spec/ and vm/ separated |
| 21:48:49 | evan | no |
| 21:48:54 | evan | spec/ruby seperate from everything else |
| 21:49:31 | evan | it's similar, but not the same. |
| 21:51:00 | duncanmv | resent |
| 21:52:34 | duncanmv | evan: my next patch will be to document that in docs/contributing.txt |
| 21:52:41 | evan | ok |
| 21:53:37 | duncanmv | symlinked .rvm/repos/rbx-head to his local git and found the perfect workflow to fix rbx and test his gems |
| 21:54:38 | duncanmv | evan: I guess I forgot to expose the method in ruby.h |
| 21:54:45 | evan | yep |
| 21:54:50 | evan | good catch |
| 21:55:13 | duncanmv | need to git reset HEAD^1 again? |
| 21:56:22 | duncanmv | evan: in MRI it is in intern.h |
| 21:56:30 | duncanmv | should I add it there or in ruby.h? |
| 21:56:34 | evan | ruby.h |
| 21:56:37 | duncanmv | ok |
| 21:56:38 | evan | we don't put anything in intern.h |
| 21:56:56 | evan | you don't need to git reset |
| 21:56:59 | evan | just do another commit |
| 21:57:18 | bdheeman | dbussink: hi |
| 21:58:46 | bdheeman | dbussink: I successfully build rubinius from git as a debian package, see http://pastebin.com/M08e39wa |
| 22:00:47 | evan | bdheeman: talk to srbaker |
| 22:00:50 | evan | he was doing the same thing |
| 22:01:08 | bdheeman | evan: ok |
| 22:01:12 | srbaker | yes is. |
| 22:01:16 | brixen | duncanmv: it's documented in doc/specs.txt |
| 22:01:27 | srbaker | bdheeman: where'd you put "runtime" for FHS compliance? |
| 22:02:02 | bdheeman | srbaker: /usr/lib/rubinius/1.0/runtime |
| 22:02:20 | srbaker | ah, same, sans 1.0 for me. prob a good idea |
| 22:02:44 | srbaker | i'm just waiting for my desktop to get here so i can run a bunch of tests before uploading |
| 22:02:48 | srbaker | (into debian, that is) |
| 22:02:59 | bdheeman | srbaker: please try or inspect the deb from http://anu.homelinux.net/pub/Debian/ |
| 22:03:24 | srbaker | will do |
| 22:04:59 | bdheeman | srbaker: thanks, I have build a source.deb as yet; still need to improve the get-git-source stanza a bit |
| 22:05:15 | bdheeman | s/have/have not/ |
| 22:05:32 | srbaker | okay. we've probably duplicated a lot of effort |
| 22:05:47 | srbaker | if you have the dsc qnd the diff, i'll look at and attribute when i upload into the archive if i use anything |
| 22:05:48 | bdheeman | srbaker: :) |
| 22:06:24 | srbaker | or just tar up your archive with changes and email it to me, steven@stevenrbaker.com |
| 22:06:29 | bdheeman | srbaker: sure, shall try making these available by tomorrow |
| 22:06:32 | srbaker | thanks |
| 22:06:43 | bdheeman | srbaker: you're welcome :) |
| 22:07:12 | srbaker | i've just been being lazy until my computer shows up here :) |
| 22:07:25 | srbaker | i also have goods packages, and the rest of the cucumber dependencies pretty well ready to go |
| 22:07:53 | bdheeman | srbaker: same here, I also was postponing it since long |
| 22:12:56 | bdheeman | /me date -R |
| 22:12:57 | bdheeman | Tue, 24 Aug 2010 03:42:56 +0530 |
| 22:13:34 | brixen | bdheeman: you come from the future! |
| 22:13:34 | bdheeman | it is 3.43 AM here, bye all :) |
| 22:13:36 | brixen | :) |
| 22:13:49 | brixen | bdheeman: thanks for the rbx love |
| 22:13:58 | bdheeman | brixen: you're welcome :) |
| 22:15:52 | boyscout | Add spec for method visibility inside a closure - c83fb52 - Evan Phoenix |
| 22:15:53 | boyscout | Add tag def in a closure spec - 207a62b - Evan Phoenix |
| 22:16:42 | evan | these fucking Socket specs. |
| 22:16:43 | evan | arg. |
| 22:21:45 | evan | is dmacvicar in here? |
| 22:21:54 | duncanmv | yes |
| 22:21:57 | duncanmv | its me |
| 22:22:10 | duncanmv | evan: I opened a ticket for the socket spec |
| 22:22:13 | evan | i'm looking at your spec failure wrt getaddrinfo |
| 22:22:14 | evan | yeah |
| 22:22:17 | evan | i'm looking at it |
| 22:22:20 | duncanmv | brixen: told me to |
| 22:22:23 | evan | wtf is ip protocol 132?! |
| 22:23:17 | evan | it's not in netinet/in.h |
| 22:23:23 | evan | and your getaddrinfo is reporting it |
| 22:23:45 | evan | mmm, it appears to be SCTP |
| 22:24:43 | evan | uuuuum |
| 22:24:48 | evan | i really don't like these spec. |
| 22:24:52 | evan | it's so brittle. |
| 22:33:19 | duncanmv | night guys |
| 22:35:02 | brixen | pack, unpack with float... #tears |
| 22:35:54 | evan | :( |
| 22:35:55 | evan | i'll bet. |
| 22:36:18 | evan | brixen: i'm going to make this getaddrinfo spec less brittle but spec'ing less |
| 22:36:39 | evan | ie, i'm only going to check return values that have TCP or UDP as a protocol |
| 22:36:57 | evan | since starting to add stuff like SCTP seems like the way of madness. |
| 22:37:21 | brixen | ok, sounds reasonable |
| 22:37:25 | evan | k |
| 22:37:38 | brixen | I probably need to write a specfic matcher for them |
| 22:37:47 | brixen | them == this sort of spec |
| 22:38:10 | evan | hm, ok |
| 22:41:35 | boyscout | Narrow the spec field for getaddrinfo. Fixes #444 - d4bdcaf - Evan Phoenix |
| 22:44:22 | boyscout | CI: Commit 207a62b failed. http://github.com/evanphx/rubinius/commit/207a62bee02503a40a82fce5d30a904531cc264b |
| 22:45:34 | evan | hrm |
| 22:45:51 | evan | fuck that spec. |
| 22:45:53 | evan | GRRRRRRRRRRRRRRRRRRRR |
| 23:16:06 | boyscout | Add spec for return in a sclass - 55ae4b0 - Evan Phoenix |
| 23:16:06 | boyscout | Add tag for return in sclass spec - 6c2a368 - Evan Phoenix |
| 23:16:07 | boyscout | quarantine bad spec - cca1e20 - Evan Phoenix |
| 23:25:37 | boyscout | CI: rubinius: cca1e20 successful: 3516 files, 15129 examples, 42978 expectations, 0 failures, 0 errors |