Show enters and exits. Hide enters and exits.
| 17:05:22 | brixen | evan: seems the mongrel abort is a thread/timing issue |
| 17:05:24 | brixen | http://gist.github.com/100574 |
| 17:05:39 | brixen | it's behavior changed when I ran it under gdb |
| 17:05:54 | brixen | I was able to serve multiple files before getting the abort |
| 17:06:04 | sbryant_work | such are threads :( |
| 17:06:17 | brixen | not under gdb, it would almost always abort as soon as I tried to serve a file |
| 17:06:37 | brixen | run pup.rb and hit localhost:3000/files |
| 17:07:01 | sbryant_work | I'm on my work machine, don't have the project checkout out and built |
| 17:07:06 | sbryant_work | so wouldn't do much good right now. |
| 17:09:34 | sbryant_work | brixen: have you looked and each thread stack? |
| 17:12:16 | brixen | I haven't |
| 17:12:22 | brixen | working on something atm |
| 17:12:30 | brixen | what would I look for? |
| 17:12:53 | rue | thread apply is simplest if you just want the BTs |
| 17:13:43 | rue | Need a way to force ext rebuilds |
| 17:13:50 | sbryant_work | That's a good question, probably some bad locking |
| 17:14:09 | sbryant_work | but I haven't a clue honestly |
| 17:31:14 | tilman | brixen: seen something like this before? http://5fc925552726d5f8.paste.se/ |
| 17:39:50 | brixen | tilman: um, nope |
| 17:40:17 | brixen | what code did you run? |
| 17:40:52 | tilman | a test program for my xmms2 ruby bindings |
| 17:41:05 | tilman | i _think_ i've seen the same weirdness when profiling something like hello world |
| 17:41:06 | brixen | looks like it might be a bad bignum to double |
| 17:41:29 | brixen | how long did the run take? |
| 17:41:37 | tilman | 0.75s |
| 17:42:25 | brixen | hrm |
| 17:42:55 | brixen | if you give me the code, I can take a look at it |
| 17:43:25 | brixen | I ran -P -e 'p 1' plenty working on it and never saw anything like that |
| 17:43:33 | brixen | so it's probably not just a short run thing |
| 17:43:45 | tilman | let me try to build a simpler test case |
| 17:44:37 | brixen | if you create the profiler manually, you could p the lookuptable and inspect it directly |
| 17:45:00 | tilman | hehe, it went nuts on the first try: bin/rbx -P lib/bin/compile.rb kernel/common/array.rb /tmp/array.rbc |
| 17:45:18 | tilman | and that surely wasn't a short run :) |
| 17:45:21 | tilman | brixen: k |
| 17:46:53 | brixen | tilman: may be a gcc thing |
| 17:46:54 | brixen | http://gist.github.com/100594 |
| 17:47:17 | tilman | note that this doesn't happen all of the time |
| 17:47:42 | brixen | hm, that sounds like something uninitialized |
| 18:09:14 | rue | brixen: The mongrel file you gave runs for me |
| 18:10:13 | rue | Including navigation |
| 18:10:29 | rue | You need to reinstall Mongrel if you did not yet |
| 18:13:25 | brixen | rue: yeah, runs for me too |
| 18:13:28 | brixen | sometimes |
| 18:13:37 | brixen | I already rebuilt mongrel |
| 18:24:54 | rue | How "sometimes" |
| 18:25:32 | rue | Erm, how often is sometimes? |
| 18:28:18 | brixen | rue: scroll back |
| 18:33:47 | rue | Not under GDB I am now about 50 invocations into clicking around /files |
| 18:34:16 | rue | Maybe it is invocation frequency instead |
| 18:44:59 | boyscout | Reimport test/unit to aid in gem testing - b0c8d5f - Evan Phoenix |
| 18:44:59 | boyscout | Report Location entries for blocks correctly - 27683bd - Evan Phoenix |
| 18:44:59 | boyscout | Populate a StackError with a backtrace - 5d3b39f - Evan Phoenix |
| 18:44:59 | boyscout | Misc fixes to run the mocha tests - 059efb7 - Evan Phoenix |
| 18:44:59 | boyscout | Add new fast path Dir.glob implementation - 876652f - Evan Phoenix |
| 18:53:30 | boyscout | CI: 876652f success. 1503 files, 7245 examples, 23659 expectations, 0 failures, 0 errors |
| 18:54:21 | evan | brixen: i'm going to commit a little code to help track this down |
| 18:54:46 | brixen | ok cool |
| 18:55:21 | evan | it will abort closer to where the NULL is leaking out |
| 19:03:03 | rue | OK.. a fairly regular repro with file -> cancel -> dir |
| 19:03:11 | rue | file -> save -> dir seems fine |
| 19:06:11 | evan | ok, i've got this code in place |
| 19:06:14 | evan | i'm going to try pup.rb here |
| 19:07:38 | evan | not sure what you mean by file or cancel |
| 19:07:49 | evan | pup.rb just has /files and /test |
| 19:08:14 | rue | evan: I get a save dialog when clicking on a file |
| 19:08:16 | evan | ok, i got it to happen |
| 19:08:21 | evan | ah ah |
| 19:08:22 | evan | ok |
| 19:08:24 | rue | If I cancel, stuff fails |
| 19:08:28 | rue | If I save, seems to work |
| 19:09:31 | evan | weird, my new code isn't being hit... |
| 19:19:47 | brixen | dbussink: when is a new do_postgres gem going to be released that doesn't reassign rb_cTime? |
| 19:20:06 | brixen | dbussink: and compiles without warnings? :P |
| 19:20:29 | sbryant_work | How is rubinius doing these days? I haven't heard much about it recently |
| 19:21:46 | rue | Super duper, maybe |
| 19:21:52 | rue | It is a secret |
| 19:21:57 | sbryant_work | :( |
| 19:22:12 | sbryant_work | I tried to help in my spare time but that vanished. |
| 19:22:33 | rue | Yeah, not existing is the natural habitat of spare time |
| 19:23:26 | sbryant_work | rue: heh didn't know spare time had a habitat. |
| 19:23:44 | rue | sbryant_work: The status is pretty good, by and large I would say more complete than Shotgun ever was (even though there are still some bugs in running code, probably) |
| 19:24:06 | rue | For any short- or long-term plans, you will have to ask evan or brixen. |
| 19:24:50 | dbussink | brixen: any time soon, i've also been working on getting it to run on windows |
| 19:25:16 | dbussink | brixen: i'll check the current next branch i'm working on :) |
| 19:25:31 | brixen | dbussink: any tutorial for DO? |
| 19:25:34 | sbryant_work | rue: that's good, I'm glad the project is still alive. |
| 19:26:00 | brixen | dbussink: oh, give me your branch and I'll try building a gem from it and installing |
| 19:26:47 | dbussink | brixen: http://github.com/datamapper/do/tree/next |
| 19:27:16 | dbussink | brixen: it also has a bunch of shared specs that run against the adapters |
| 19:27:26 | dbussink | and shows a bunch of the api |
| 19:27:58 | brixen | dbussink: so what is the easiest way to build a do_postgres gem from this? |
| 19:28:18 | dbussink | brixen: switch to the next branch and do a rake gem |
| 19:28:36 | brixen | k |
| 19:28:41 | dbussink | you need data_objects installed first, which is also available in that repo |
| 19:29:56 | rue | sbryant_work: Kicking, indeed |
| 19:30:06 | dbussink | brixen: is the gem timeout still an issue when installing? |
| 19:30:15 | sbryant_work | rue: any low hanging fruit out there? |
| 19:30:18 | brixen | dbussink: nope |
| 19:30:38 | rue | Gem works nicely, so far as Gems can |
| 19:30:43 | brixen | dbussink: I've got do_postgres to build, except I have to remove the assign to rb_cTime |
| 19:31:21 | rue | sbryant_work: There are some specs that are failing, might have some relatively easy fixes there |
| 19:31:47 | dbussink | brixen: hmm, i didn't push that? |
| 19:31:55 | sbryant_work | rue: I'll check around there |
| 19:31:58 | brixen | is there a way to tell gem install to just continue where it left off before it failed? |
| 19:32:38 | rue | Probably not? Although I do not think it is cleaning build dirs or something |
| 19:33:17 | drbrain | gem install will skip deps and so-forth, but it'll always install everything for a named gem |
| 19:33:25 | drbrain | I think as of 1.3.2 it nukes the destination directory |
| 19:33:47 | drbrain | ... named on the command line |
| 19:43:29 | brixen | dbussink: http://tinyurl.com/cy5ova |
| 19:43:46 | dbussink | brixen: yeah, i saw it |
| 19:44:31 | brixen | I just installed data_objects-0.9.12 that I built from your next branch |
| 19:44:44 | dbussink | brixen: SystemCallError: dlopen(/Users/dirkjan/Documents/projects/rubinius/gems/1.8/gems/do_postgres-0.9.12/lib/do_postgres_e xt.bundle, 10): Symbol not found: _rb_cstr_to_dbl |
| 19:44:50 | dbussink | that's where i'm at now |
| 19:45:04 | dbussink | i grabbed extlib/next too btw |
| 19:45:41 | brixen | dbussink: yeah, I just fixed that stuff |
| 19:45:46 | brixen | haven't pushed yet |
| 19:46:05 | dbussink | brixen: ah ok |
| 19:46:11 | dbussink | you got to that point too? |
| 19:46:17 | brixen | yay, just installed do_postgres-0.9.12 |
| 19:46:24 | brixen | haven't tested it yet :P |
| 19:46:30 | dbussink | hehe |
| 19:46:36 | brixen | dbussink: I'll push this stuff |
| 19:46:55 | dbussink | brixen: how far is it from running rspec specs? |
| 19:47:12 | brixen | hm, good question |
| 19:47:24 | brixen | I've got profiler output from these 2 gem installs too |
| 19:47:39 | brixen | String#[] is taking quite a bit of time |
| 19:47:45 | dbussink | brixen: ah, well, the require 'data_objects' took ages for me |
| 19:47:49 | brixen | and Kernel#=== |
| 19:48:05 | brixen | dbussink: how long is ages? |
| 19:48:10 | brixen | I'll give it a try |
| 19:48:22 | dbussink | brixen: well, probably around 20 - 30 secs i think |
| 19:49:29 | brixen | ah, that's nothing :P |
| 19:50:24 | dbussink | brixen: you got the fix? i wanna try whether i can fire a query and get a result :) |
| 19:52:31 | brixen | ugh |
| 19:52:48 | brixen | is rake 0.8.4 what is causing all the build commands to spew forth now? |
| 19:54:32 | brixen | yes, it is |
| 19:54:34 | brixen | wtf |
| 20:03:36 | boyscout | Some capi fixes to compile do_postgres gem. - 2c016fa - Brian Ford |
| 20:08:35 | boyscout | CI: 2c016fa success. 1503 files, 7246 examples, 23660 expectations, 0 failures, 0 errors |
| 20:10:05 | dbussink | brixen: http://gist.github.com/100697 |
| 20:16:09 | brixen | hmm ok |
| 20:17:27 | brixen | dbussink: when is a new extlib gem being released? at the same time as the DO 0.9.12 gems? |
| 20:17:39 | dbussink | brixen: probably yeah |
| 20:17:52 | dbussink | brixen: if we can fix stuff in there that would be cool |
| 20:18:02 | dbussink | brixen: i'm planning on at least doing a release around euruko |
| 20:18:37 | dbussink | at least with windows one click installer support and hopefully full jruby/jdbc support |
| 20:18:44 | dbussink | adding rubinius to that would be cool too :) |
| 20:19:07 | brixen | indeed :) |
| 20:19:13 | brixen | the coolest ;) |
| 20:21:58 | dbussink | brixen: of course ;) |
| 20:33:06 | evan | brixen: i'm just running with rake -q now |
| 20:33:11 | evan | mostly |
| 20:34:26 | brixen | evan: ahh ok |
| 20:34:42 | brixen | I'll just chalk it up as another reason to use Tap :) |
| 20:34:57 | brixen | evan: so, I just moved ByteArray under Rubinius |
| 20:35:09 | brixen | I think I should do that for the rest of "our" classes |
| 20:35:18 | brixen | LookupTable, MethodTable, etc |
| 20:35:22 | brixen | what do you think? |
| 20:37:08 | dbussink | brixen: latest extlib actually moved ByteArray too as a good citizen :) |
| 20:37:20 | dbussink | brixen: any idea on that backtrace btw? |
| 20:37:36 | brixen | dbussink: haven't looked into it yet |
| 20:37:53 | brixen | dbussink: nice you moved BA, but we need to as well |
| 20:38:29 | dbussink | brixen: yeah, agree with all rubinius specific stuff being moved btw |
| 20:40:14 | evan | brixen: yeah |
| 20:40:15 | evan | we should. |
| 20:46:12 | brixen | evan: ok, I'll do it after lunch |
| 20:46:44 | evan | i'm working on the mongrel problem now. |
| 20:46:47 | evan | it's... weird. |
| 20:51:28 | rue | dbussink: Em, is that supposed to recurse? |
| 20:52:07 | rue | Oh, nm, I noticed the horrific magic |
| 20:54:43 | evan | ok, i've found the first data point on the mongrel crash |
| 20:54:51 | evan | reraise is being called when there is no existing exception |
| 20:56:25 | evan | I'm testing why now. |
| 21:08:30 | evan | ok, pretty sure i've solved it. |
| 21:11:31 | evan | i'm leaving in some guards to aid in debugging of this, if it comes up again. |
| 21:21:16 | rue | Mehee.. Sergeant Semicolon |
| 21:23:06 | dbussink | brixen: gcc 4.4 is out, maybe it introduces new fun ;) |
| 21:23:24 | brixen | dbussink: no doubt it does |
| 21:23:48 | brixen | every new release of gcc causes many kittens to die :( |
| 21:24:05 | evan | brixen: ok, mongrel is fixed. |
| 21:24:12 | brixen | sweet! |
| 21:24:16 | evan | about to push the fix |
| 21:24:28 | evan | what happened was |
| 21:24:36 | evan | ensure was entered because of a return or break |
| 21:24:48 | evan | the ensure code ended up calling clear_exception |
| 21:24:56 | evan | then the ensure code did reraise at the bottom |
| 21:25:02 | brixen | ahh |
| 21:25:11 | evan | so i've changed clear_exception to only clear when raise_reason is cException |
| 21:25:16 | brixen | interesting it didn't show up till now |
| 21:25:19 | evan | ie, ruby code can't clear return/breaks |
| 21:25:21 | evan | yeah |
| 21:30:12 | rue | Wait, ensure can re-raise? |
| 21:31:27 | evan | course |
| 21:31:28 | evan | they have to |
| 21:32:00 | evan | if they run as an exception is being raised, reraise the exception to keep it going |
| 21:33:02 | boyscout | Fix reraising off non-Exception raise values - 3d7bc75 - Evan Phoenix |
| 21:33:24 | rue | Yeah, I meant from the Ruby side? |
| 21:33:49 | evan | well |
| 21:34:05 | evan | not explicitly |
| 21:34:14 | evan | but the reraise instruction is used to do this |
| 21:34:20 | evan | which is the "Ruby side" for me |
| 21:38:26 | rue | Aha |
| 21:42:06 | boyscout | CI: 3d7bc75 success. 1503 files, 7246 examples, 23660 expectations, 0 failures, 0 errors |
| 21:58:41 | evan | brixen: doing a spec run |
| 21:58:59 | evan | there are 45486 methods that have less than 5 locals and less than 10 stack entries |
| 22:00:56 | evan | oh wait. |
| 22:00:58 | evan | hah |
| 22:01:00 | evan | i fucked it up... |
| 22:01:23 | evan | thats the total number of methods |
| 22:01:26 | evan | silly conditionals. |
| 22:02:24 | evan | wowzers |
| 22:02:32 | evan | it's now 43918 |
| 22:03:09 | rue | Wonder if the space tradeoff to scan instance vars from the first definition of a class into an index would be worth it |
| 22:03:27 | evan | we're going to do that |
| 22:03:30 | evan | have always planned to |
| 22:03:37 | evan | it's definitely worth it |
| 22:03:48 | evan | because the ratio of classes+methods to instances is very high |
| 22:04:19 | brixen | evan: how many methods in kernel? |
| 22:04:28 | evan | dunno off hand |
| 22:04:32 | evan | i put this code directly into the VM |
| 22:04:37 | evan | so it's firing on all methods as I run them. |
| 22:04:45 | brixen | that number seems huge |
| 22:04:51 | evan | thats what I thought |
| 22:04:54 | brixen | is it counting blocks? |
| 22:05:16 | evan | yeah |
| 22:05:20 | brixen | ahh |
| 22:05:25 | brixen | that makes sense then |
| 22:05:25 | rue | Plus class/module/script? |
| 22:05:40 | evan | rue: I would think so |
| 22:05:45 | evan | we won't know until we try |
| 22:07:32 | evan | brixen: it doesn't appear to make much of a difference though |
| 22:08:13 | brixen | you mean the special interp? |
| 22:08:45 | evan | having another template that contains VariableScope and CallFrame at fixed sizes |
| 22:08:48 | evan | ie, no alloca |
| 22:08:56 | brixen | ok |
| 22:09:25 | brixen | did you look at it in shark or just from the total spec run time? |
| 22:11:05 | evan | total spec runtime |
| 22:11:13 | rue | Alloca is pretty damn fast |
| 22:11:13 | evan | i'm writing a small benchmark now. |
| 22:11:29 | evan | yeah |
| 22:11:42 | evan | we're just curious to test it's profile |
| 22:11:53 | evan | performance wise |
| 22:14:03 | evan | the performance different is the equavilant of thermal noise |
| 22:14:06 | evan | difference |
| 22:14:47 | brixen | well, good to know |
| 22:15:06 | brixen | I wonder if moving all these constants under Rubinius is going to negatively impact perf |
| 22:15:31 | evan | we'll cross that bridge when we get to it |
| 22:15:42 | brixen | yeah |
| 22:15:43 | evan | we could speed up constants accessed under the Rubinius module |
| 22:15:53 | brixen | right |
| 22:16:26 | evan | hm, ok |
| 22:16:38 | evan | i ran 5 runs with small frames |
| 22:16:39 | evan | and 5 without |
| 22:16:56 | evan | on a loop of 10 million iterations |
| 22:17:09 | evan | the difference of a null loop is about 0.2 seconds |
| 22:17:27 | evan | and for calling a method that adds to locals |
| 22:17:46 | evan | again, about 0.2 or 0.3 |
| 22:17:50 | evan | with it varying a lot |
| 22:17:56 | brixen | interesting |
| 22:18:12 | evan | sometimes non-small was faster than small |
| 22:18:18 | brixen | this is how many calls there were compiling data_objects gem to require it the first time: 224,216,111 |
| 22:18:24 | evan | that tells me i need to either run more iterations to reduce the noise |
| 22:18:27 | evan | or it's all noise |
| 22:19:11 | brixen | evan: what does the machine code look like for the two cases? |
| 22:19:31 | brixen | if it's just a couple insns difference, it's probably all noise |
| 22:19:40 | evan | it's going to |
| 22:20:06 | evan | since the allocas will likely have an extra add, then an add of esp |
| 22:20:07 | evan | thats it. |
| 22:20:16 | brixen | ah, ok |
| 22:20:26 | evan | versus collapsing the add of esp into the prologue in the small case |
| 22:20:35 | evan | so all we save is 4 adds |
| 22:20:41 | evan | thats my guess |
| 22:20:46 | evan | i should check out the machine code though. |
| 22:21:04 | brixen | I wonder if the cpu then parallelizes that |
| 22:21:22 | evan | it's certainly got multiple ALUs |
| 22:21:26 | evan | so the adds are done in parallel |
| 22:21:42 | rue | There are tcmalloc and hoard, too, but dunno if either have usable components |
| 22:22:35 | evan | for this? probably not |
| 22:22:43 | evan | since we're literally as far down as we can go |
| 22:23:05 | evan | unless we wire static ram onto machines and use that somehow |
| 22:36:47 | evan | http://gist.github.com/100777 |
| 22:36:51 | evan | if anyone is curious |
| 22:37:36 | brixen | cool |
| 22:38:05 | evan | alright, off to pick up my car |
| 22:38:06 | evan | bbiab. |
| 22:38:11 | brixen | ok |
| 22:38:32 | brixen | running an errand, bbiab too |