Show enters and exits. Hide enters and exits.
| 00:00:09 | brixen | haha, no surprise :) |
| 00:01:21 | brixen | kronos_vano: are you on twitter? |
| 00:01:31 | kronos_vano | yep |
| 00:01:37 | brixen | nick? |
| 00:01:46 | kronos_vano | http://twitter.com/kronos_vano |
| 00:01:51 | brixen | hah |
| 00:01:59 | kronos_vano | :D |
| 00:02:00 | brixen | why don't you make hard for me, eh? |
| 00:03:04 | brixen | http://twitter.com/brixen/status/14065602684 |
| 00:03:10 | brixen | kronos_vano: pressure is on! :) |
| 00:03:18 | kronos_vano | superstar |
| 00:03:19 | kronos_vano | :D |
| 00:03:22 | brixen | heh |
| 00:03:33 | kronos_vano | brixen, Do you see #292 ? |
| 00:03:54 | brixen | yeah |
| 00:04:04 | kronos_vano | and? |
| 00:04:16 | brixen | I haven't looked into it |
| 00:04:21 | brixen | probably easy fix |
| 00:04:27 | kronos_vano | I'm about http://gist.github.com/402214 |
| 00:04:51 | brixen | ah yeah, just saw it |
| 00:05:02 | brixen | spec needs to be split, but looks fine |
| 00:05:52 | brixen | spec needs to be separate commit, I mean |
| 00:07:21 | kronos_vano | Of course. Just it is more easy to review spec & code in one patch |
| 00:07:50 | brixen | sure |
| 00:16:19 | slava | brixen: why do you put all spec changes in separate commits? |
| 00:17:59 | kronos_vano | slava, It is more simple to pull spec change into rubyspec. |
| 00:18:24 | slava | makes sense |
| 00:23:18 | boyscout | Spec for module: Module.include?(Module) should always be false - 9634d5c - Ivan Samsonov |
| 00:23:19 | boyscout | Fix edge case for Module#include?. Closes #292. - d3efd7b - Ivan Samsonov |
| 00:23:37 | slava | time for rbx 1.0.1? |
| 00:24:02 | brixen | slava: probably monday! |
| 00:25:21 | brixen | the time between a 1.0.0 and 1.0.1 is proportional to the size of your llvm context |
| 00:25:26 | brixen | or something like that |
| 00:29:54 | slava | heh |
| 00:31:07 | boyscout | CI: rubinius: d3efd7b successful: 3457 files, 13597 examples, 41217 expectations, 0 failures, 0 errors |
| 01:18:25 | kronos_vano | #303 :/ |
| 01:18:48 | postmodern | hey thanks for resolving that module.include? issue so fast |
| 01:18:55 | postmodern | i got plenty more thought :) |
| 01:18:57 | postmodern | *though |
| 01:19:16 | postmodern | i have a non-duplicatable issue with bundler and yard |
| 01:19:19 | postmodern | when i run rake spec |
| 01:19:41 | postmodern | http://pastie.org/962149 |
| 01:21:53 | postmodern | this appears to happen on most of my jeweler + bundler + yard projects |
| 02:56:04 | brixen | since when is a Set a sorted data structure? |
| 02:56:28 | brixen | that's a SortedSet |
| 04:18:19 | postmodern | brixen, haha, yeah idk |
| 04:18:31 | postmodern | brixen, i changed those specs to use =~ to get around it |
| 04:36:00 | postmodern | whats up with FFI on rubinius |
| 04:36:11 | postmodern | it fails like crazy when i attempt to run the specs for ffi-udis86 |
| 05:09:08 | brixen | postmodern: ruby-ffi deviated from the API that rubinius implemented |
| 05:09:25 | brixen | we have not yet implemented that deviant api |
| 05:09:40 | brixen | but once evan decides what he will or won't support, we will |
| 05:09:42 | postmodern | brixen, basic things like uint16 type are missing |
| 05:09:45 | brixen | which should be very soon |
| 05:09:50 | postmodern | cool cool |
| 05:09:58 | postmodern | yeah it would be nice if there was a unified FFI API |
| 05:10:05 | postmodern | that all imps had to support |
| 05:10:06 | brixen | there once was |
| 05:10:19 | brixen | and we hope there will be again |
| 05:10:23 | brixen | soon :) |
| 05:10:23 | postmodern | yes back in the days of middle earth |
| 05:10:28 | brixen | heh yeah |
| 05:10:46 | postmodern | got pretty much half of my code passing specs on 1.0 |
| 05:10:48 | postmodern | so that's good |
| 05:10:59 | brixen | that's awesome |
| 05:11:07 | brixen | I'm working on the Array subclass issue |
| 05:11:11 | brixen | need to write a bunch of specs |
| 05:11:38 | brixen | the loading .rbc requires some thought |
| 05:11:58 | brixen | technically, #require should not load a .rbc file |
| 05:12:22 | postmodern | it could be something weird YARD is doing |
| 05:12:23 | brixen | ie, #require only loads .rb files |
| 05:12:31 | postmodern | they load plugins using some Dir[] globbing |
| 05:12:32 | brixen | it's probably globbing to broadly |
| 05:12:39 | postmodern | but that should never hit core_ext/* |
| 05:12:40 | brixen | yeah, that's what I guessed |
| 05:12:44 | brixen | hmm |
| 05:12:49 | postmodern | it's a weird one |
| 05:13:02 | brixen | it shouldn't glob for other than .rb unless it is using #load |
| 05:14:00 | brixen | and again, load should only load Ruby source files |
| 05:14:18 | brixen | if you try to #load an ext, you get an exception |
| 05:14:24 | brixen | same should hold for .rbc files |
| 05:14:41 | brixen | I'll discuss with evan, but I'm against allowing loading .rbc files directly |
| 05:17:04 | postmodern | brixen, http://github.com/evanphx/rubinius/issues/#issue/305 |
| 05:17:06 | postmodern | brixen, ah ha |
| 05:18:45 | brixen | hmm |
| 05:19:11 | brixen | yeah, that's a pretty broken glob |
| 05:19:23 | brixen | amazing the stuff that just works by a prayer |
| 05:20:38 | brixen | why the hell would someone write: require file.gsub(/\.rb$/, '') ? |
| 05:20:43 | brixen | that is so funny |
| 05:21:52 | postmodern | no clue |
| 05:22:03 | postmodern | also the new style is to use chomp |
| 05:22:07 | postmodern | instead of gsub |
| 05:22:28 | dkubb | heh, as I mentioned in #datamapper, I would probably not even bother with that :P |
| 05:22:31 | brixen | um, you have a .rb file, why do anything but require it? |
| 05:23:07 | postmodern | yeah |
| 05:23:17 | postmodern | also the Dir.glob should do *.rb instead of just * |
| 05:23:28 | brixen | basically, you chop off .rb so that #require can go through some serious work to put it back on |
| 05:23:48 | dkubb | although in other cases I would much rather use string.chomp('.rb') than string.gsub(/\.rb$/, '') (why gsub too, sub would work just as well in this case) |
| 05:24:00 | brixen | why chomp anything?! |
| 05:24:10 | dkubb | oh I was talking about in other cases.. nothing at all related to this |
| 05:24:17 | postmodern | is require normally cleaver about detecting .rb? |
| 05:24:22 | dkubb | I've had cases where I needed to strip the end of a string by some pattern |
| 05:24:49 | brixen | postmodern: #require can only load 2 things: Ruby source and C exts |
| 05:24:54 | postmodern | ah |
| 05:25:03 | postmodern | ok i've notified argv[0] |
| 05:25:05 | brixen | if you don't give it a file ext, it has to search for one |
| 05:25:28 | brixen | and the only Ruby file it will load is one with a .rb ext |
| 05:25:34 | brixen | period, end of story |
| 05:25:48 | brixen | #load will load a Ruby source file with any ext |
| 05:25:56 | brixen | but only a Ruby source file |
| 05:29:06 | postmodern | there's probably a reason for globbing core_ext |
| 05:29:15 | postmodern | but i would normally just make a core_ext.rb file that loads everything |
| 05:29:18 | postmodern | and maintain that |
| 05:31:48 | brixen | I definitely prefer explicit over implicit |
| 05:32:03 | brixen | the glob is not unreasonable, but it should only glob .rb if it's going to use #require |
| 05:32:08 | brixen | and it should just require the file |
| 05:33:10 | postmodern | forked and changed |
| 05:33:29 | brixen | sweet :) |
| 05:37:31 | postmodern | still im a bit confused |
| 05:37:35 | postmodern | if it was gsubing off .rb |
| 05:38:07 | postmodern | how would "require 'yard/core_ext/symbol_hash'" end up loading the .rbc version |
| 05:38:49 | dkubb | gsub(/\.rb$/, '') won't match anything.rbc |
| 05:38:59 | postmodern | durp |
| 05:39:00 | brixen | the * would |
| 05:39:14 | brixen | but yes, the gsub would be a noop on that |
| 05:40:44 | postmodern | and sent |
| 06:09:10 | postmodern | brixen, and someone pulled in the commit |
| 06:09:17 | postmodern | brixen, edge yard should work now |
| 06:09:17 | brixen | cool beans |
| 06:09:21 | brixen | nice |
| 06:09:47 | brixen | now if ppl would quit writing very stupid subclasses of Array, I'd be much happier |
| 06:10:22 | brixen | it's like, "polymophism, what's that?" :( |
| 06:10:33 | brixen | well, polymorphism, but same diff :) |
| 06:10:36 | postmodern | i've done it before, and it's kind of hard actually |
| 06:11:10 | brixen | we can't write Array to be nice to your subclass if you break Array's contracts |
| 06:11:17 | postmodern | wow someone needs to look into running YARD specs on rubinius |
| 06:11:21 | postmodern | this one spec just hangs |
| 06:11:21 | brixen | because we can't dispatch polymorphically and hit your methods |
| 06:11:26 | postmodern | YARD::CodeObjects::Base#relative_path |
| 06:11:27 | brixen | we have to work around your methods |
| 06:12:00 | dkubb | whenever I find myself subclassing a ruby core class I usually change it to use composition.. I rarely need the full richness of an Array |
| 06:12:15 | brixen | dkubb: yes, that's another huge issue |
| 06:12:46 | dkubb | I only did it once where I actually did subclass Array for DataMapper, and I made sure all the original methods worked, and it sucked to get right |
| 06:12:53 | brixen | sadly, Ruby has semantics that are purely due to MRI's implementation |
| 06:13:00 | brixen | and it really impoverishes the language |
| 06:13:14 | brixen | because it let's really crappy architecture live |
| 06:13:49 | brixen | er lets |
| 06:14:00 | dkubb | brixen: I saw the Liskov tweet earlier ;) |
| 06:14:06 | brixen | heh |
| 06:14:08 | brixen | yeah |
| 06:14:17 | brixen | I'm hacking up Array right now |
| 06:14:20 | brixen | and it's making me sad |
| 06:14:49 | brixen | because one of the shitty things about MRI Array and Hash is that you *can't* subclass it correctly when you need to |
| 06:15:01 | brixen | sometimes you get an Array and sometimes a MyArray |
| 06:15:06 | brixen | and that's just fucked |
| 06:15:12 | brixen | from an OO perspective |
| 06:15:15 | brixen | le sigh :( |
| 06:16:24 | dkubb | when I was implementing Collection for DM, I wished that there was a shared spec I could use to test my code to see if it implemented Array's interface perfectly |
| 06:16:55 | dkubb | I've been thinking lately in my other projects that anytime I have a class I expect to be inherited, I'll put it's specs into shared specs and make sure all the subclasses pass with those too |
| 06:17:14 | brixen | oh, but there is! :) |
| 06:17:20 | dkubb | oh :D |
| 06:17:24 | brixen | rubyspec uses new_array helper |
| 06:17:29 | postmodern | for the low low price of 39.99 |
| 06:17:33 | brixen | oh wait, shit, I only did that for Hash |
| 06:17:41 | brixen | but I plan on doing it for Array too! |
| 06:17:45 | dkubb | cool |
| 06:17:52 | brixen | you should have bothered me :) |
| 06:18:02 | dkubb | I will definately give it a try |
| 06:18:21 | brixen | I just need to audit the specs for everywhere it uses a literal Array in the Array specs |
| 06:18:26 | dkubb | I worked really hard to make sure it worked the same as Array, but I'd bet there are still some edge cases I didn't cover |
| 06:18:30 | brixen | then you write your own #new_array and run them |
| 06:18:55 | brixen | I used this effectively to implement a half dozen different Hash classes |
| 06:19:01 | brixen | to test perf characteristics |
| 06:19:05 | brixen | worked well |
| 06:19:19 | brixen | but I have to edit the Array specs first |
| 06:23:05 | postmodern | There was a LoadError while evaluating yard.gemspec. |
| 06:23:05 | postmodern | Does it try to require a relative path? That doesn't work in Ruby 1.9. |
| 06:23:10 | postmodern | hmm looks like there's more issues with YARD |
| 06:23:24 | postmodern | or bundler + yard on rubinius |
| 06:54:24 | slava | hi brixen |
| 08:04:30 | fbuilesv | brixen: ping |
| 09:47:51 | dbussink | fbuilesv: why does sinatra want to load win32api? :) |
| 09:49:02 | fbuilesv | dbussink: no idea of what's going on there, I gave a quick look at Sinatra's source and found nothing, but it only happens with that lib :( |
| 09:49:14 | fbuilesv | maybe it's just that I'm sleepy at 5am and missing something |
| 09:50:21 | dbussink | fbuilesv: that's weird, i just tried a require 'sinatra' in an irb session and it worked fine |
| 09:51:05 | dbussink | fbuilesv: ah, wait, you added -vd to it i see |
| 09:51:30 | fbuilesv | dbussink: it works in an irb session here too, but when I try to run a script (or just require 'sinatra') it fails. |
| 09:51:59 | dbussink | fbuilesv: because if i run it with mri with -vd there are a bunch of errors whizzing by too |
| 09:52:01 | fbuilesv | not sure what the loader's trying to bring up (which reminds me, rbx could use a stub for Win32API) :) |
| 09:52:32 | dbussink | very similar errors actually |
| 09:53:01 | fbuilesv | dbussink: same here but it does start |
| 09:53:03 | dbussink | fbuilesv: https://gist.github.com/acf0eae2bcc2ad818bdc |
| 09:53:15 | dbussink | true, but that probably means those errors aren't related to the problem :) |
| 09:53:26 | fbuilesv | yup |
| 09:53:31 | fbuilesv | good point. |
| 09:54:14 | fbuilesv | dbussink: can ya run reproduce the error with any simple Sinatra app tho? I can't get it to load anything. |
| 09:55:12 | dbussink | fbuilesv: i also see it here that it just exits |
| 09:55:17 | dbussink | no error / warnings or whatever |
| 09:55:33 | fbuilesv | dbussink: ya, that's what's weird, I ended up doing -vd to see what was going wrong. |
| 09:58:31 | fbuilesv | dbussink: I'm off to bed now, I'll try to run this through the debugger tomorrow and see what I can come up with |
| 09:58:32 | fbuilesv | ttyl. |
| 09:58:42 | dbussink | fbuilesv: i've found some initial stuff |
| 09:58:51 | dbussink | seems like Application.run? returns false |
| 09:58:51 | fbuilesv | dbussink: what are you seeing? |
| 09:59:27 | dbussink | fbuilesv: that method is defined through some meta programming, probably goes wrong there |
| 10:01:39 | dbussink | fbuilesv: if you look at gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:1009 |
| 10:01:44 | dbussink | that metadef stuff |
| 10:01:50 | dbussink | that probably trips something up |
| 10:02:08 | fbuilesv | dbussink: you got latest version? I got a "subclass.reset!" there. |
| 10:02:15 | postmodern | if a ruby file is above 1k lines, something is probably up |
| 10:02:19 | dbussink | fbuilesv: i have 1.0 |
| 10:02:43 | fbuilesv | dbussink: I'm running head but I see the #metadef you m ention |
| 10:02:59 | dbussink | fbuilesv: ah ok, yeah, well, i guess there something going wrong there |
| 10:10:43 | fbuilesv | dbussink: I think it's borking the caller_files array. On the good side of things, I think I just found another bug with this. C-c won't stop think until you actually make a request to that port. |
| 10:11:19 | dbussink | fbuilesv: what is happening to that array? |
| 10:13:34 | fbuilesv | dbussink: thought $0 != app_file but I can't quite confirm it, it works fine if I run lib/sinatra.rb but I can't get it to load any external files. |
| 10:15:50 | dbussink | fbuilesv: ah, yeah, that seem to be it |
| 10:16:06 | dbussink | fbuilesv: https://gist.github.com/4607d8b8815d58137dbf |
| 10:16:15 | dbussink | that's $0 and app_file here for me |
| 10:16:31 | fbuilesv | dbussink: cool, how'd you get it to run? |
| 10:17:06 | dbussink | fbuilesv: just ignored it there and forced it to run :P |
| 10:17:10 | dbussink | to see where the issue was |
| 10:17:12 | fbuilesv | dbussink: that works :P |
| 10:17:22 | dbussink | but it's in the Application.run? check, that's where i started |
| 10:18:22 | dbussink | fbuilesv: for some reason app_file is the full path on rbx |
| 10:18:27 | dbussink | and not the relative one |
| 10:19:38 | fbuilesv | dbussink: I'm guessing it's the Kernel#caller impl on Rbx, I'll check the specs for that. |
| 10:20:16 | fbuilesv | nope, that seems fine. |
| 10:23:19 | dbussink | fbuilesv: looks like caller on rbx returns complete paths |
| 10:23:24 | dbussink | and relative ones on mri |
| 10:23:52 | fbuilesv | dbussink: inside Sinatra it does that, but in a regular irb I get relative paths too. |
| 10:24:14 | fbuilesv | I'm not entirely sure of how caller works when working with gems and stuff. |
| 10:24:54 | dbussink | fbuilesv: https://gist.github.com/904eb6552cdb141f9a13 |
| 10:26:59 | fbuilesv | dbussink: yup, you're right. I'll update the ticket and try to write a fix for that later today :) |
| 10:27:05 | fbuilesv | dbussink: thanks for the help :D |
| 10:38:56 | dbussink | fbuilesv: so annoying that stuff depends on caller() behavior like this :( |
| 10:41:37 | fbuilesv | dbussink: agreed but they might have a good reason to do that, I think I'll look a bit into it and see if it can be replaced for something a bit more robust. |
| 21:10:43 | fbuilesv | evan: ping |
| 21:11:15 | tarcieri | ding a ling |
| 21:18:28 | dbussink | fbuilesv: he's still partying because of the 1.0 release i guess ;) |