Show enters and exits. Hide enters and exits.
| 00:09:38 | rue | New as in "contains new information"? |
| 00:10:17 | rue | evan: Also, update the (c) |
| 00:10:40 | evan | no, pretty much no new info. |
| 00:10:59 | evan | which sucks, but we need to at least get it to a stage where we were comfortable changing it |
| 00:12:15 | rue | OK, but I am not supposed to see some web 2.5-ized version, right? Pretty much the same it was designwise at least |
| 00:12:37 | evan | i don't know what you're seeing |
| 00:12:41 | evan | is it mostly white? |
| 00:12:57 | rue | Black-grey-mostly white, yes |
| 00:13:00 | evan | with a 1.0rc2 in the upper right corner |
| 00:13:05 | rue | Yef |
| 00:13:09 | rue | Maybe it had some blue before |
| 00:13:26 | evan | and the twitter stream on the right about halfway down |
| 00:13:38 | BrianRice-work | looks good, but the navbar at top is wrapping around the "How to Install" item at the end no matter how I resize the window (chrome) |
| 00:13:59 | rue | Mm, no |
| 00:14:38 | evan | BrianRice-work: ok, must be something specific to chrom. |
| 00:14:40 | evan | chrome. |
| 00:14:53 | BrianRice-work | evan: seems like it. I don't see the issue in FF3 |
| 00:15:27 | rue | Oh! |
| 00:15:35 | rue | evan: www. works, plain not |
| 00:15:41 | rue | Works == has new stuff |
| 00:15:53 | evan | probably DNS |
| 00:16:47 | jarib | oh, there's stuff below the fold on the front page. hard to notice on my 15" MBP |
| 00:16:59 | brixen | yeah, page layout needs work |
| 00:16:59 | rue | Yes |
| 00:17:01 | evan | there is no fold. |
| 00:17:02 | brixen | it's a WIP |
| 00:17:05 | evan | :D |
| 00:17:13 | brixen | there is though |
| 00:17:15 | rue | The top could use a big arrow, or then pull the bottom up a little bit |
| 00:17:19 | evan | or did you print out the website onto newsprint? |
| 00:17:20 | evan | :D |
| 00:17:36 | dwaite | waves |
| 00:17:39 | dwaite | congrats on rc2 |
| 00:17:45 | evan | thanks. |
| 00:19:08 | jarib | what's with all the Object#id warnings when loading irb? |
| 00:19:22 | evan | you tell me |
| 00:19:26 | evan | you're code is calling #id |
| 00:19:29 | evan | i'm assuming. |
| 00:19:44 | evan | wow. |
| 00:19:45 | evan | wtf. |
| 00:19:45 | jarib | rbx -S irb -f is the same |
| 00:19:48 | evan | i just got it to. |
| 00:19:50 | jarib | k |
| 00:19:50 | evan | thats... new. |
| 00:20:07 | evan | one sec, lets find out. |
| 00:20:14 | jarib | yep |
| 00:20:50 | evan | BAH |
| 00:20:57 | evan | someone commited code that uses just .id |
| 00:20:58 | evan | FAIL. |
| 00:21:39 | evan | marc-andre did it |
| 00:21:41 | evan | shame on him. |
| 00:22:00 | evan | why the heck did he redo this... |
| 00:22:01 | dwaite | tsk tsk |
| 00:22:08 | dwaite | should have used .ego |
| 00:22:21 | evan | whats worse |
| 00:22:27 | evan | he obviously didn't test this code. |
| 00:22:33 | evan | or he would have seen the warnings. |
| 00:23:01 | rue | Do the warnings actually show running the specs? |
| 00:23:12 | evan | perhaps. |
| 00:23:41 | evan | oh come on marcandre |
| 00:23:42 | evan | wtf. |
| 00:23:49 | evan | using catch/throw in kernel code?! |
| 00:23:59 | evan | is not amused. |
| 00:26:33 | evan | why the fuck does this code take the object_id of a symbol. |
| 00:28:28 | evan | this recursion guard code is... |
| 00:28:52 | dwaite | gives evan some room |
| 00:29:05 | evan | go find out what recursive_objects is in Thread |
| 00:29:20 | evan | it's never set. |
| 00:29:42 | evan | oh, ok, it's in C++ |
| 00:29:44 | evan | why though.... |
| 00:29:55 | dwaite | I used floating point in linux kernel code once. couldn't quite figure out why all of a sudden random programs started breaking so horribly |
| 00:33:27 | dwaite | (the kernel does not preserve any floating point info) |
| 00:33:57 | boyscout | Remove using Object#id - 8bb9008 - Evan Phoenix |
| 00:34:08 | evan | marc-andre has some explaining to do. |
| 00:36:31 | jarib | i also have a SIGSEV when i run tests for a lib i wrote. is there some way i can get a ruby backtrace to reduce it a little? |
| 00:36:44 | jarib | *SEGV |
| 00:37:21 | boyscout | CI: rubinius: 8bb9008 successful: 3022 files, 11689 examples, 35887 expectations, 0 failures, 0 errors |
| 00:37:46 | evan | inside gdb you probably can. |
| 00:38:01 | jarib | ok? i know how to get inside gdb |
| 00:39:57 | evan | in gdb, find a CallFrame* on the stack, and do |
| 00:40:01 | brixen | jarib: if you are building from source, rake clean; rake build:debug; gdb --args vm/vm path/to/your/file.rb |
| 00:40:02 | evan | p call_frame->print_backtrace(state) |
| 00:40:10 | brixen | and then that |
| 00:40:11 | evan | he doesn't need to do it in debug mode. |
| 00:40:15 | evan | try without first. |
| 00:40:34 | jarib | ok |
| 00:42:02 | evan | ARG. the code that I was sure wouldn't work isn't even run. |
| 00:42:07 | evan | wtf marc-andre. |
| 00:42:29 | rue | It is just there to throw you off |
| 00:42:37 | evan | it did not succeed |
| 00:42:44 | evan | i saw through it's clever ruse. |
| 00:43:31 | evan | fuck this |
| 00:43:35 | evan | i'm going for a run. |
| 00:44:04 | rue | Good thing you have kept that up |
| 00:46:05 | rue | http://journal.kittensoft.org/2010/01/03/winters.html |
| 01:01:35 | jarib | hmpf, went away when i installed rack |
| 01:02:00 | jarib | here's the gdb backtrace http://gist.github.com/269909 |
| 01:36:29 | boyscout | Updated MSpec source to ddf4bd5a. - 3412412 - Brian Ford |
| 01:36:29 | boyscout | Updated CI specs to RubySpec cdce2bd0. - 09e533b - Brian Ford |
| 01:36:29 | boyscout | Updated CI tags for merged rubyspecs. - 621ee6d - Brian Ford |
| 01:40:01 | boyscout | CI: rubinius: 621ee6d successful: 3022 files, 11692 examples, 35890 expectations, 0 failures, 0 errors |
| 05:03:24 | brixen | marcandre: gotta run but you have a conference with evan about 09d1824d0 |
| 05:25:53 | evan | marcandre: you there? |
| 05:40:25 | vano | hey guys, just a quick question about libraries ( not gems ). what is the path rubinius use for them? for gems, i figured out ln -s ~/.gem/{ruby,rbx} would be ok, but how should I load gtk2 lib ( already installed for mri ) using rubinius? |
| 05:40:36 | evan | no |
| 05:40:38 | evan | not ok |
| 05:40:39 | evan | never ok. |
| 05:40:44 | evan | do NOT do that. |
| 05:40:58 | evan | gem install gtk2 |
| 05:41:01 | evan | if it's a gem |
| 05:41:07 | evan | otherwise, use rbx extconf.rb |
| 05:41:35 | evan | all C extensions must be explicitly compiled for rubinius to work |
| 05:41:43 | vano | not ok - you mean even for pure ruby gems, without c extensions ? |
| 05:41:59 | evan | for pure ruby gems it's ok |
| 05:42:01 | evan | but it always blows up for people |
| 05:42:03 | evan | because they forget |
| 05:42:09 | evan | and have a C extension gem they didn't realize |
| 05:42:17 | evan | and then it explodes. |
| 05:42:29 | evan | so we just tell people to never do it. |
| 05:42:33 | evan | install things explicitly for rubinius |
| 05:42:38 | evan | just like you'd do for 1.9 or jruby |
| 05:44:01 | vano | should I do the same in the future, when everybody will use new FFI system? |
| 05:44:16 | evan | it's the most sane thing to do, yes. |
| 05:44:29 | evan | it shouldn't be a hardship |
| 05:44:33 | evan | unless you have a 100M harddrive. |
| 05:44:57 | vano | ok, big thanks for quick answer, evan! |
| 05:45:03 | evan | no prob. |
| 05:45:52 | imajes | vano: take a look at rvm, it might help you out |
| 05:46:54 | imajes | evan: and shouldn't penalize me just because i have a small disk :( |
| 05:47:16 | evan | i doubt the .rb files on your disk are taking up significant space. |
| 05:47:17 | evan | :) |
| 05:47:42 | imajes | heh |
| 05:47:46 | imajes | whips out find and du |
| 05:48:20 | imajes | evan: actually, it's surprising how many Apps are shipping with ruby scripts in them now |
| 05:48:30 | evan | oh? thats cool. |
| 05:48:46 | vano | thanks imajes, looks quite nifty |
| 05:48:58 | imajes | well i guess since leo ships with a reasonably new version of mri and has a decent api |
| 05:49:59 | imajes | oh, w00tage! i can reclaim 2.5GB by deleting my old /opt -- totally forgot about that |
| 05:50:01 | imajes | thanks evan |
| 05:50:13 | evan | hah |
| 05:50:31 | imajes | find came to the rescue |
| 05:51:23 | imajes | w00t. 22GB free. |
| 06:52:59 | somebody | evan, Are you here? |
| 11:09:26 | haruki_zaemon | I'm seeing an error running rake: Tried to use object of type Class (14) as type String (48) |
| 11:09:34 | haruki_zaemon | Worked in rc1 |
| 11:09:41 | haruki_zaemon | Should I raise an issue? |
| 11:11:33 | haruki_zaemon | did anyway :/ |
| 11:28:33 | cyndis | try removing all *.rbc files |
| 11:28:38 | haruki_zaemon | ahhh! |
| 11:28:41 | haruki_zaemon | will do |
| 11:29:22 | haruki_zaemon | ok that did it! |
| 11:29:25 | haruki_zaemon | thanks |
| 11:29:32 | cyndis | np :) |
| 11:31:00 | haruki_zaemon | It looks as though rubinius doesn't (yet?) support to_ary for implicit call argument conversion? |
| 11:32:48 | cyndis | if you mean stuff like [1,2,3].zip(object which responds to to_ary), that does work |
| 11:36:18 | haruki_zaemon | [object that responds to to_ary].each { |a, b, c| … } fails |
| 11:36:30 | haruki_zaemon | well |
| 11:36:32 | haruki_zaemon | doesn;t fail |
| 11:36:38 | haruki_zaemon | just behaves differently than on MRI |
| 11:37:00 | cyndis | i see |
| 11:38:49 | haruki_zaemon | I have a test case |
| 11:38:58 | haruki_zaemon | Maybe I'll try fix it ... |
| 12:02:26 | haruki_zaemon | ok, I have a tes that fails in rubinius but passes in MRI |
| 12:24:16 | haruki_zaemon | cyndis_: I've created a patch for a failing spec but GitHb issues doesn't seem to allow attachments |
| 12:24:24 | haruki_zaemon | So I've just pasted it into the issue |
| 12:24:32 | haruki_zaemon | Is there something else I should have done? |
| 12:24:35 | cyndis | best way probably is to make gist and link to that |
| 12:24:39 | cyndis | +a |
| 12:24:53 | haruki_zaemon | ahh |
| 12:24:57 | haruki_zaemon | OK, I'll make a gist |
| 12:26:32 | haruki_zaemon | thanks |
| 13:54:22 | rue | haruki_zaemon: Why would that work? |
| 13:54:35 | rue | Oh, wait, misread...nevermind |
| 13:57:18 | haruki_zaemon | rue: I know it's kooky but it does work :) |
| 14:02:16 | rue | I did not notice it was inside an Array already |
| 14:48:19 | cremes | /away |
| 15:37:58 | boyscout | CI: rubinius: 621ee6d successful: 3022 files, 11692 examples, 35890 expectations, 0 failures, 0 errors |
| 17:23:56 | Defiler | aaaaah http://github.com/rails/arel/blob/master/lib/arel/algebra/core_extensions/class.rb |
| 17:24:16 | Defiler | seriously? |
| 17:27:00 | evan | i really do not get why rails feels the need to add shit to every class like that |
| 18:44:33 | dbussink | evening |
| 18:47:42 | evan | hi hi |
| 18:49:17 | evan | FUUUUUUUUCK |
| 18:49:33 | evan | gets blame and the cluebat out. |
| 18:50:45 | dbussink | is missing something |
| 18:50:55 | evan | go look at kernel/platform/file.rb |
| 18:50:58 | evan | specificly basename |
| 18:51:05 | evan | and tell me why this is THE SLOWEST METHOD IN THE WORLD |
| 18:51:20 | evan | first of all, why the fuck is this is Platform. |
| 18:51:34 | evan | 2nd of all |
| 18:51:42 | evan | it creates 3 regexps everytime it's called. |
| 18:51:46 | evan | MEGA FAIL. |
| 18:52:07 | dbussink | hey, i was going to say 4 regexpes :P |
| 18:52:16 | evan | 4! |
| 18:52:17 | evan | you're right |
| 18:52:20 | evan | *facepalm* |
| 18:52:29 | dbussink | quatro facepalm |
| 18:52:38 | evan | hah |
| 18:52:45 | brixen | 4.times { facepalm } |
| 18:52:58 | evan | so not only is it ultra slow |
| 18:53:05 | brixen | gets in line to borrow the cluebat |
| 18:53:09 | evan | but the logic is horrid. |
| 18:57:02 | evan | just adding /o to those regexs speeds this up by 2x |
| 18:57:40 | evan | why the fuck is this MODIFYING the string passed in?! |
| 18:58:09 | evan | normally, i'd be miffed about this |
| 18:58:11 | evan | and i am |
| 18:58:18 | evan | but instead i'm going to look at it as a challenge to destroy this code |
| 18:58:21 | evan | and increase performance 10x |
| 18:58:28 | brixen | yeah |
| 18:58:48 | brixen | it's the only way to stay sane |
| 18:58:58 | brixen | learns |
| 18:59:00 | evan | this code is so fucked. |
| 18:59:01 | evan | man. |
| 19:05:04 | BrianRice-work | I approve of this attitude, but only as an outsider ;) |
| 19:12:09 | dbussink | evan: i think you've mentioned this one before too actually |
| 19:12:15 | dbussink | evan: you're horification |
| 19:22:51 | evan | 4 regexps with string substitutions |
| 19:23:02 | evan | just to search from the front to the back, then optionally search again |
| 19:24:53 | evan | *eyeroll* |
| 19:24:58 | evan | MRI: 0.5s, RBX: 12s |
| 19:25:00 | evan | er |
| 19:25:04 | evan | MRI: 0.5s, RBX: 19s |
| 19:25:11 | evan | for File.basename. |
| 19:26:59 | dbussink | evan: you made a benchmark? |
| 19:27:05 | evan | course. |
| 19:27:13 | evan | i need to know how awesome I am at making it faster. |
| 19:27:18 | dbussink | evan: looks like 10x faster is underachieving ;) |
| 19:27:24 | evan | bigtime. |
| 19:27:30 | evan | thats AFTER I added /o btw |
| 19:27:32 | evan | lets try without /o |
| 19:29:07 | evan | ok, read for this? |
| 19:29:16 | evan | the version of basename you guys have |
| 19:29:20 | evan | none of my changes |
| 19:29:25 | evan | 58s |
| 19:29:29 | ezmobius | hah |
| 19:29:59 | evan | new rule: if you use a Regexp in krenel code, it must be approved by another developer. |
| 19:30:05 | evan | and you should probably never use one. |
| 19:30:38 | dbussink | evan: i reset the goal at 100x faster from initial version ;) |
| 19:31:11 | evan | yep. |
| 19:34:48 | dbussink | is grepping through kernel code looking for regexpses :P |
| 19:34:54 | evan | good. |
| 19:35:03 | evan | thats going to be what i advise us to do next. |
| 19:41:14 | rue | Well, back then regexps quite likely were much faster than anything else :P |
| 19:41:51 | evan | this usage was never faster than anything. |
| 19:51:26 | dbussink | evan: what do you think of changes like this: https://gist.github.com/23ccfe493f655ce9fa18 |
| 19:51:58 | evan | fail |
| 19:52:04 | evan | that whole line can go anyway |
| 19:52:10 | evan | there are no secret locals. |
| 19:52:12 | evan | anymore. |
| 19:52:23 | dbussink | ah ok |
| 19:52:30 | evan | for 2 things |
| 19:52:34 | evan | just compare both of them directly |
| 19:55:10 | boyscout | Fix String#hex spec - 8b99fe4 - Ivan Samsonov |
| 19:55:10 | boyscout | There are no secret locals anymore - 13e814e - Dirkjan Bussink |
| 19:58:40 | boyscout | CI: rubinius: 13e814e successful: 3022 files, 11693 examples, 35893 expectations, 0 failures, 0 errors |
| 20:06:33 | evan | new File.basename that passes all specs: 1.5s |
| 20:08:10 | brixen | sweet |
| 20:08:19 | evan | still 3x slower than MRI |
| 20:08:27 | evan | lets see if i can squeeze a little more out. |
| 20:08:37 | Defiler | What's the new code look like? |
| 20:09:01 | evan | Defiler: uses #rindex and #substring |
| 20:09:59 | Defiler | The rbx method call overhead is so low, maybe it would pay off to have a quick exit to the 'no second argument given' version |
| 20:10:16 | evan | it's close to that |
| 20:10:26 | evan | i instead ignore it entirely until the end |
| 20:10:33 | evan | then do a quick exit if ext == undefined |
| 20:10:43 | Defiler | Cool |
| 20:11:08 | Defiler | rindex sounds like the fastest way to me.. hrm |
| 20:11:38 | evan | woop. |
| 20:11:47 | evan | down to 0.8s |
| 20:11:57 | evan | MRI is 0.56s |
| 20:12:43 | evan | i've got a whole bag of tricks. |
| 20:13:13 | evan | the pathname benchmark is now only 2x slower on rbx |
| 20:13:19 | evan | it was like 30x when I started |
| 20:21:05 | evan | boya |
| 20:21:13 | evan | just need to unfuck File.dirname now |
| 20:22:15 | dbussink | evan: Dir.glob might be fun too ;) |
| 20:22:41 | evan | i've acutally been over Dir.glob many times |
| 20:22:44 | evan | it's decent now. |
| 20:22:53 | evan | File.fnmatch uses a C version now |
| 20:23:16 | evan | and Dir.glob can parse the pattern into objects |
| 20:23:28 | evan | and then the tree can run itself to generate the list |
| 21:39:55 | dbussink | evan: do you think the profiler could be fixed easily? |
| 21:40:28 | dbussink | made a ticket for it a while back and i've seen other people ask about it too |
| 21:40:35 | evan | it's not broken. |
| 21:40:58 | evan | you just need to be sure to run it with -Xint |
| 21:41:50 | dbussink | evan: ah ok, well, is that fixable or is profiler + jit incompatible? |
| 21:41:57 | evan | it's fixed actually. |
| 21:42:04 | evan | it's just there is a mismatch |
| 21:42:06 | evan | i need to remove -P |
| 21:42:16 | evan | and move starting the profiler into the -X range |
| 21:42:23 | evan | because you can profile jit'd code |
| 21:42:32 | evan | but you have to set a flag BEFORE you start the JIT |
| 21:42:36 | dbussink | evan: this is the ticket btw: http://github.com/evanphx/rubinius/issues#issue/115 |
| 21:42:40 | evan | so inside the loader is too late |
| 21:42:53 | evan | um |
| 21:42:57 | evan | that ticket is unrelated. |
| 21:43:00 | evan | almost certainly. |
| 21:43:20 | evan | thats a explicit bug in the profiler. |
| 21:43:25 | evan | ignore everything I just said. |
| 21:43:34 | evan | completely different. case |
| 21:43:44 | evan | though you still need to use -Xint to get decent results from the profiler atm |
| 21:43:58 | brianmario | new site looks great guys |
| 21:44:02 | evan | brianmario: thanks! |
| 21:44:26 | dbussink | i do see some jruby similarities :P |
| 21:44:35 | evan | huh? |
| 21:44:46 | dbussink | the general layout |
| 21:44:58 | dbussink | large banner, menu above it |
| 21:45:02 | evan | i doubt shane has even seen the jruby site |
| 21:45:03 | dbussink | three columns below it |
| 21:45:03 | brixen | that's a pretty general style |
| 21:45:08 | evan | so thats pure coincindence. |
| 21:45:18 | dbussink | just something that triggered |
| 21:45:49 | dbussink | maybe it's me though |
| 21:45:51 | evan | but you are right |
| 21:45:55 | evan | they're similar layout wise |
| 21:53:24 | VVSiz | dbussink, evan: we were discussing the new site over #jruby as well (noted the similar layout too) :) nice site overall. The Rubinius High Level Overview diagram is a bit buzzword-heavy: "Extensive Built in Functionality" - huh? :) |
| 21:53:53 | evan | i didn't redo all the copy |
| 21:53:57 | evan | from the design copy |
| 21:54:10 | evan | ruby has extensive builtin functionality itself |
| 21:54:14 | evan | so yes, so does rubinius. |
| 22:06:42 | dbussink | evan: what could be causing the following script to keep growing in memory usage? https://gist.github.com/fbe80a99655056d01b3c |
| 22:06:54 | evan | no clue |
| 22:07:40 | dbussink | evan: ah, well, it is on rubinius, what would be a good way to investigate? |
| 22:07:53 | evan | look what sleep does |
| 22:07:55 | evan | in the code |
| 22:08:00 | evan | see if you can identify a memory leak |
| 22:08:13 | evan | if it uses Channels (it might) i think there is a memory leak there |
| 22:08:23 | Defiler | Isn't that going to create a Float in every loop? |
| 22:08:30 | evan | there are 2 big leaks that i'm going to do deal with once i finish this performance tuning |
| 22:08:46 | Defiler | and will GC ever get a chance to run in that code? |
| 22:09:18 | dbussink | Defiler: apparenlty it gets to run in mri |
| 22:09:30 | dbussink | not seeing memory growth there |
| 22:09:32 | evan | what MRI does for this is not useful |
| 22:09:39 | evan | it's obviously a rubinius bug |
| 22:09:51 | evan | i doubt "growing memory in a loop" is a expected behavior. |
| 22:09:52 | evan | anyway |
| 22:10:18 | evan | i see a check_interrupts instruction in the loop |
| 22:10:24 | evan | so yes, the GC is being run. |
| 22:11:15 | dbussink | still grows if i put the timeout value in a variable |
| 22:11:55 | evan | very unlikely it's Float related. |
| 22:12:02 | evan | go look at sleep. |
| 22:13:06 | dbussink | it's sleep yeah |
| 22:13:34 | dbussink | if i remove it keeps looping and gobbles up 96% cpu, but no leak |
| 22:15:27 | evan | put Object.new in the loop. |
| 22:15:34 | evan | a hot loop with no body tests nothing. |
| 22:19:21 | dbussink | evan: no growth either |
| 22:19:33 | evan | it's sleep |
| 22:19:35 | evan | as I suspected. |
| 22:20:25 | evan | woop |
| 22:20:32 | evan | MRI: 0.98s |
| 22:20:38 | evan | RBX: 1.06s |
| 22:20:41 | evan | for the pathname benchmark. |
| 22:21:09 | dbussink | cool! |
| 22:22:03 | dbussink | anyway, sleepy time for me |
| 22:22:49 | evan | nite |
| 22:24:02 | evan | rad |
| 22:24:09 | evan | 10x speed improvement in pathname over rc2 |
| 22:24:15 | Defiler | Sweet |
| 22:24:16 | brixen | heh awesome |
| 22:24:23 | Defiler | Wait, more than that, right? |
| 22:24:26 | Defiler | Like 20x? |
| 22:24:40 | evan | way more in a bunch of lowlevel stuff |
| 22:24:48 | evan | that all contributed to pathname |
| 22:25:03 | dbussink | evan: ok, one more thing, also already happens when doing chan = Rubinius::Channel.new in the loop |
| 22:25:14 | evan | yep |
| 22:25:18 | evan | i know about that one |
| 22:25:43 | dbussink | ah ok |
| 22:26:21 | dbussink | got to this by looking at #154, but i think i'll add a safety check for the thread creation and throw an error like mri does there |
| 22:26:27 | dbussink | shouldn't be too hard to add |
| 22:27:00 | evan | k |
| 22:27:03 | dbussink | but i guess the leak was also playing a part there, but if you know what it is, better to leave it then i guess |
| 22:27:13 | dbussink | but anyway, real sleep now |
| 22:27:19 | dbussink | nite! |
| 22:27:48 | evan | Defiler: File.basename is 75x faster |
| 22:27:58 | evan | 61s on rc2, 0.8s on master |
| 22:28:41 | rue | Hooray for algorithmic (?) optimisation |
| 22:28:44 | Defiler | Nice |
| 22:28:51 | evan | yep |
| 22:28:57 | evan | entirely algorithmic |
| 22:48:10 | evan | ok, wtf. |
| 22:48:19 | evan | getting ArgumentError on time again. |
| 22:48:30 | brixen | le sigh |
| 22:48:34 | brixen | goddammit |
| 22:48:38 | evan | i got it. |
| 22:48:50 | evan | something is up with not the specs |
| 22:48:54 | evan | because i did test this yesterday |
| 22:49:02 | brixen | hrm |
| 22:49:32 | evan | yep, ok. |
| 22:49:34 | evan | it's rubinius |
| 22:49:51 | brixen | ok, so passing MRI? |
| 22:49:53 | evan | https://gist.github.com/061c3a12951252f8f0a7 |
| 22:50:03 | brixen | hm |
| 22:50:19 | evan | and if I run the spec under MRI |
| 22:50:20 | evan | it's fine. |
| 22:50:22 | evan | so it's just rbx |
| 22:50:23 | brixen | ok |
| 22:50:41 | evan | i'll figure out why. |
| 22:51:02 | brixen | did we switch that to a primitive? |
| 22:51:06 | brixen | looks |
| 22:51:17 | evan | mktime is a prim, yes. |
| 22:52:23 | brixen | yeah |
| 22:52:42 | evan | i wonder... |
| 22:53:06 | evan | hm |
| 22:53:23 | brixen | I see a to_native() there |
| 22:53:36 | brixen | is tm.tm_sec 32bit? |
| 22:53:58 | evan | not sure. |
| 22:54:11 | brixen | me neither for 64bit |
| 22:54:26 | brixen | really must install SL soon |
| 22:54:43 | brixen | I've got my old mbp backed up, just need to install it |
| 22:54:52 | evan | well do it! |
| 22:54:53 | evan | :) |
| 22:54:55 | brixen | heh |
| 22:55:10 | brixen | this randomness hints 64bit shit to me |
| 22:55:17 | brixen | like that profiler bug I tracked |
| 22:55:51 | brixen | where it was precisely a to_native() instead of a to_ulong_long() call |
| 22:55:59 | evan | ah |
| 22:56:01 | evan | yeah |
| 22:56:13 | evan | well |
| 22:56:17 | evan | all of tm is int's |
| 22:56:25 | evan | so 32bit |
| 22:56:42 | evan | so the compiler is truncating the native_int to an int |
| 22:56:45 | evan | before assigning it. |
| 22:58:12 | brixen | hm |
| 23:06:59 | evan | oh holy fuck. |
| 23:07:17 | evan | MRI reimplement their own mktime |
| 23:07:27 | evan | that understands pre-1969 years. |
| 23:08:05 | brixen | packs MRI for time travel to before his birthday |
| 23:08:43 | brixen | Ruby could corner the archeology app market |
| 23:08:50 | evan | hah |
| 23:09:02 | evan | i guess i'll just forklift this code from MRI |
| 23:09:12 | evan | i'm in no mood to go through it all. |
| 23:09:16 | brixen | heh |
| 23:09:18 | brixen | sounds good |
| 23:11:22 | evan | yeah, wow. |
| 23:11:23 | evan | this code... |
| 23:11:25 | evan | wow. |
| 23:15:23 | brixen | heh, pretty much need a costco-size pallet of wows for any such code spelunking |
| 23:15:35 | evan | yeah. |
| 23:22:25 | rue | You all want to forward critique to Shane? |
| 23:22:55 | brixen | rue: you could open a ticket |
| 23:23:51 | rue | Novel thought! |
| 23:26:06 | rue | In the logo section, the whitespace is not balanced. The top navigation is good, but the logo text could either be a bit smaller and further to the left, allowing dropping the rc2 tab downward, or then the kerning could be increased a bit. The font is slightly awkward against the logo r - and maybe a lowercase rubinius would be better. |
| 23:26:55 | evan | i'll take them into consideration |
| 23:27:02 | evan | but i disagree on some of these |
| 23:29:42 | rue | The tagline colour-matched to the reflection, slightly smaller/italicised/script font. I am not a big fan of the light-blue abstract horizontal, particularly the colour but also the whitespace around it. The first three-column section is good, though the grey could be a bit darker. The "fold" effect should be removed, possibly by hitching the blue panel up a bit to clearly indicate continuation. |
| 23:30:26 | rue | That section is otherwise good except for the (lack of) whitespace around the "high-level overview" header |
| 23:30:37 | rue | evan: Sure, these are just my impressions |
| 23:30:39 | brixen | rue: oh, when you said 'novel' I thought you meant 'new' haha |
| 23:30:56 | rue | Nicely done |
| 23:31:14 | brixen | heh |
| 23:31:15 | rue | I can stick that in a ticket, easier to share |
| 23:31:19 | brixen | I agree with most of these |
| 23:31:42 | brixen | but design esthetic is such a fickle beast |
| 23:31:49 | brixen | anyway, tickets are good |
| 23:37:18 | rue | #156 |
| 23:38:04 | brixen | heh the title of #666 is reserved for "Rubinius is evil" |
| 23:38:11 | brixen | just a heads up :) |
| 23:38:18 | evan | hah |
| 23:38:46 | evan | INCOMING |
| 23:38:51 | boyscout | Improve File.join performance 5x - 1f544cf - Evan Phoenix |
| 23:38:51 | boyscout | Try and report the class a block is in better - 027ce39 - Evan Phoenix |
| 23:38:51 | boyscout | Add String#find_string_reverse - 9e11e88 - Evan Phoenix |
| 23:38:51 | boyscout | Improve String#rindex significantly - d4b4013 - Evan Phoenix |
| 23:38:51 | boyscout | Style fix - 03ad9ff - Evan Phoenix |
| 23:38:52 | boyscout | Remove -P argument, it never worked right - eda6417 - Evan Phoenix |
| 23:38:54 | boyscout | Fix Pathname performance bug - 6eedafc - Evan Phoenix |
| 23:38:56 | boyscout | Add missing File.dirname test case - 0889ef8 - Evan Phoenix |
| 23:38:58 | boyscout | Don't bother outputting anything in benchmarks - 33ad916 - Evan Phoenix |
| 23:39:00 | boyscout | Improve File.basename and File.dirname by 75x - 49d87b8 - Evan Phoenix |
| 23:39:02 | boyscout | Incorporate MRI's custom time_t calculator - 155e42c - Evan Phoenix |
| 23:40:04 | brixen | sweet |
| 23:40:12 | rue | 9e11e8857 |
| 23:40:25 | rue | 4e11e would have been apropos, but oh well |
| 23:42:02 | evan | pretty close though. |
| 23:43:28 | rue | Ugh, singleton/eigen/meta bikeshed |
| 23:43:48 | evan | I extracted MRI's search_time_t into our util/time.c, calling it mktime_extended |
| 23:44:00 | evan | if you wanna go "HUH?" you should check it out. |
| 23:46:32 | boyscout | CI: rubinius: 155e42c successful: 3022 files, 11694 examples, 35894 expectations, 0 failures, 0 errors |
| 23:46:36 | brixen | was just looking at it |
| 23:51:11 | evan | from the svn logs |
| 23:51:15 | evan | it's been in there for quite a while |
| 23:56:58 | evan | ok, coffee time. |