Show enters and exits. Hide enters and exits.
| 00:12:51 | evan | dbussink: no segfault here in do_sqlite3 |
| 00:12:57 | evan | try a rake clean. |
| 00:14:42 | brixen | hrm, you know what, I bet the ext are not rebuilding when there are changes to native method stuff |
| 00:15:03 | brixen | I got a segfault trying to run gem last night, and I rebuilt with a rake extensions:clean |
| 00:15:16 | evan | ooh |
| 00:15:18 | evan | could very well be. |
| 00:15:24 | evan | poopsy |
| 00:16:12 | brixen | but I'm not sure why that would matter |
| 00:17:16 | evan | dbussink's issue though is GC related |
| 00:18:08 | brixen | yeah, could be totally unrelated to what I observed |
| 00:18:14 | brixen | just that it was in the syck ext |
| 00:18:39 | brixen | and that's where I was getting a segfault too, but not just there |
| 00:18:56 | brixen | I thought i'd f'd up my .gemrc at first, because I had just edited it |
| 00:20:46 | evan | what character should I start "hidden" methods with? |
| 00:20:51 | evan | $ ? |
| 00:20:57 | evan | * ? |
| 00:21:18 | brixen | hm |
| 00:21:29 | brixen | % |
| 00:21:47 | evan | you think % eh? |
| 00:22:05 | brixen | oh oh or # :D |
| 00:22:12 | evan | I thought about that |
| 00:22:16 | evan | but we use # in docs |
| 00:22:18 | evan | it would be confusing. |
| 00:22:22 | brixen | true |
| 00:22:26 | brixen | I like % |
| 00:22:33 | evan | Class##allocate |
| 00:22:37 | evan | looks like a typo |
| 00:22:38 | brixen | yeah |
| 00:22:46 | evan | Class#%allocate |
| 00:22:50 | evan | isn't bad |
| 00:23:14 | brixen | I worry about $*@ being confusing |
| 00:23:22 | evan | right |
| 00:23:23 | brixen | since they are prefix sigils |
| 00:23:27 | evan | Class#-allocate |
| 00:23:32 | evan | looks like ObjC |
| 00:23:36 | brixen | % is an operator, but not often used |
| 00:23:45 | evan | oh oh |
| 00:23:49 | evan | Class#~allocate |
| 00:23:54 | brixen | yeah |
| 00:23:59 | evan | ~ |
| 00:24:04 | brixen | but that is a unary op too |
| 00:24:09 | evan | right |
| 00:24:12 | evan | well, in ruby, they all are. |
| 00:24:22 | evan | oh also |
| 00:24:27 | evan | it's not directly callable obviously |
| 00:24:30 | evan | thats fine. |
| 00:24:40 | evan | because it doesn't parse |
| 00:24:52 | evan | but you'd be able to invoke them directly via bytecode |
| 00:24:58 | brixen | cool |
| 00:24:58 | evan | and internally |
| 00:25:37 | brixen | ~ isn't bad, I thought about it too |
| 00:26:46 | brixen | ~>foo |
| 00:27:20 | goyox86 | evan: what do you mean with "hidden" methods (sorry for mi ignorance)? |
| 00:27:39 | evan | goyox86: well, in this case |
| 00:27:49 | evan | MRI actually has a hidden method thats the allocator for a class |
| 00:27:57 | evan | that you can't define from ruby-land |
| 00:28:09 | evan | i'm considering doing the same |
| 00:28:40 | evan | we've had the need for hidden methods before also |
| 00:28:48 | evan | that can be called if you know they're there |
| 00:28:50 | goyox86 | evan: mmm i see |
| 00:29:11 | evan | but don't show up in #methods and can't be accidentally overriden/called by user code |
| 00:30:34 | goyox86 | evan: got ya, oh seems to be pretty dificult to decide the prefix since in ruby as you said almost every char is used :s |
| 00:30:47 | evan | right |
| 00:30:52 | evan | it shouldn't look terrible either |
| 00:30:56 | evan | thats why i'm asking for opinions. |
| 00:32:09 | brixen | I still like % over ~ since % is not a unary op |
| 00:32:20 | goyox86 | % seems to be good to me |
| 00:34:15 | goyox86 | people, is there something like http://isitruby19.com/ to keep track of which exts, are supported by rbx? |
| 00:34:35 | brixen | not that we know of |
| 00:34:42 | brixen | you could start it :) |
| 00:34:45 | goyox86 | i think this could be useful |
| 00:36:23 | goyox86 | brixen: thats why i ask, today when i ws walking work-home, i was asking myself if RubyInline works in Rubinius for example |
| 00:38:19 | brixen | yeah, someone just needs to do it |
| 00:38:49 | goyox86 | brixen: and now i was researching about it, and "why do not keep track of waht works or not in rbx", i'll be researching on it :-) |
| 00:39:50 | brixen | maybe brightbox wants to do isitrubinius.com |
| 00:41:14 | goyox86 | yep |
| 00:41:47 | goyox86 | or isitrbx.com :] |
| 00:41:56 | brixen | sure :) |
| 00:42:14 | brixen | or isitarrbeexxx.com |
| 01:54:32 | toulmean | brixen, evan, I get this exception now running rake test with rubinius head on vanity head: |
| 01:54:33 | toulmean | no method 'match?' on 3:Fixnum. |
| 01:54:45 | toulmean | do you want a full gist ? |
| 02:00:34 | toulmean | hmmm. Thinking I should do a gist. |
| 02:01:24 | toulmean | ok here is the gist: v |
| 02:01:26 | toulmean | http://gist.github.com/470351 |
| 02:19:17 | evan | toulmean_: thats pretty weird. |
| 02:19:22 | evan | does it happen everytime? |
| 02:19:39 | toulmean | evan: yes. |
| 02:19:53 | evan | very odd. |
| 02:20:37 | evan | how would a fixnum show up there... |
| 02:20:54 | toulmean | evan: I think it's the key of the hash ? |
| 02:21:29 | evan | no |
| 02:21:36 | evan | it's the next Hash::Entry object |
| 02:21:41 | evan | or, rather, it should be. |
| 02:21:49 | evan | why it's getting a 3 there though... |
| 02:21:59 | evan | i'll have to try and repro it |
| 02:22:09 | evan | could you provide me repro steps? |
| 02:22:22 | toulmean | sure |
| 02:22:26 | toulmean | get the vanity head |
| 02:22:40 | toulmean | git clone http://github.com/assaf/vanity.git |
| 02:22:43 | toulmean | then install gems: |
| 02:22:55 | toulmean | gem install rails redis redis-namespace sqlite3-ruby timecop mocha passenger |
| 02:22:59 | toulmean | then run rake test |
| 02:25:06 | evan | ok |
| 02:25:13 | evan | could you put those steps at the top of the gist? |
| 02:25:17 | evan | so i don't forget them. |
| 02:25:31 | evan | i'll take a look later today, this weekend, or monday. |
| 02:25:32 | evan | :) |
| 02:40:11 | toulmean | evan: sure |
| 02:41:20 | toulmean | evan: done. |
| 07:54:50 | dbussink | evan: hmmm, i'm still getting it here consistently |
| 07:55:05 | dbussink | that segfault |
| 07:55:08 | evan | can you run it under gdb and get a gdb backtrace? |
| 07:55:13 | dbussink | i've caught it with gdb now |
| 07:55:55 | dbussink | evan: https://gist.github.com/9ced3d72e054a664e54f |
| 07:56:48 | evan | can you do "p *obj" |
| 07:58:28 | dbussink | hmm, it crashed somewhere else now :S |
| 07:58:57 | dbussink | evan: https://gist.github.com/4c025d5dd354c1d742d3 |
| 07:59:02 | dbussink | i still have that one open now :) |
| 07:59:55 | evan | huh? |
| 08:00:11 | dbussink | accidently closed the previous session |
| 08:00:24 | dbussink | but ran one again and it's slightly different |
| 08:01:21 | evan | hm |
| 08:02:03 | dbussink | but the weirdest thing is still is that if i run the command that rake executes manually, it doesn't crash |
| 08:02:10 | dbussink | any idea what could be a difference there? |
| 08:02:25 | dbussink | already did a rake clean for both rbx and the do_sqlite3 stuff |
| 08:02:32 | evan | hmm |
| 08:05:46 | evan | you're on 10.6 yes? |
| 08:05:58 | dbussink | yeah |
| 08:06:50 | evan | hm |
| 08:07:58 | evan | dbussink: lets try something. |
| 08:08:27 | dbussink | ok, cool |
| 08:08:39 | evan | in objectmemory.cpp, run_finalizers |
| 08:08:46 | evan | put a return; at the top |
| 08:08:50 | evan | ie, don't run finalizers. |
| 08:08:53 | evan | see if that fixes it. |
| 08:09:55 | dbussink | evan: yeps, doesn't crash then |
| 08:10:18 | dbussink | so it's related to finalizers |
| 08:10:35 | evan | before, we weren't running finalizers for Data objects |
| 08:10:41 | evan | because of a few bugs |
| 08:11:29 | evan | I have since fixed that, but clearly made other things surface. |
| 08:11:32 | dbussink | but how could the differences running it from rake and the same command by hand be created? |
| 08:11:41 | dbussink | or be explained |
| 08:12:08 | evan | well, more code would run |
| 08:12:12 | evan | and thus different GC effects. |
| 08:12:29 | dbussink | but rake shells out for this :S |
| 08:12:47 | evan | *shrug* |
| 08:12:58 | evan | if the parser data is freed, and then used again |
| 08:13:02 | evan | the crash could be pretty random |
| 08:13:10 | evan | because we'd be using freed memory |
| 08:13:19 | evan | which doesn't always result in crashes |
| 08:13:42 | dbussink | but the weird thing is that it crashes consistently for me through rake, but consisntly doesn't crash when the command is run by hand |
| 08:13:45 | dbussink | but anyway |
| 08:13:51 | dbussink | could do remote debugging if you want? |
| 08:14:35 | evan | hm |
| 08:14:40 | evan | let me poke around |
| 08:15:25 | dbussink | evan: btw, i noticed that melbourne is compiled without debugging symbols |
| 08:15:37 | evan | feel free to fix that |
| 08:31:49 | dbussink | evan: if i should get some more information out, let me know |
| 08:31:56 | evan | k |
| 08:31:59 | evan | i'm going to run a few tests. |
| 08:32:54 | dbussink | i'm going to get a shower, guess you might get to bed in the mean while |
| 08:56:56 | dbussink | evan: back |
| 09:36:26 | evan | dbussink: so |
| 09:36:30 | evan | i've repro'd it |
| 09:36:32 | evan | minimally |
| 09:36:45 | evan | it's pretty late here |
| 09:36:51 | evan | so i'll hopefully get it fixed tomorrow. |
| 09:36:58 | evan | er. later today :) |
| 10:00:51 | evan | dbussink: fixed. |
| 10:00:57 | boyscout | Fix finalizer/C-API handle bug. - 42a550a - Evan Phoenix |
| 10:00:59 | evan | bed time. |
| 10:01:00 | evan | nite. |
| 10:05:21 | dbussink | evan: nite! |
| 10:09:14 | boyscout | CI: rubinius: 42a550a successful: 3458 files, 13692 examples, 41271 expectations, 0 failures, 0 errors |
| 10:17:58 | dbussink | evan: for if you wake up, i'm still seeing a segfault :( |
| 10:18:33 | dbussink | evan: https://gist.github.com/c3cce0cab5a89b39cb49 |
| 10:21:41 | mendelbenjamin | hello all, was the screencast from last wednesday recorded? |
| 11:01:44 | dbussink | pcapriotti: ping? |
| 11:04:45 | pcapriotti | dbussink: pong |
| 11:11:06 | dbussink | pcapriotti: got remark on those rb_throw specs, those hash control flow things aren't really necessary i think |
| 11:11:13 | dbussink | or there are better ways to do that |
| 11:11:52 | dbussink | pcapriotti: and that rb_flow broken stuff can probably go too :) |
| 11:12:17 | pcapriotti | dbussink: I copied from rb_raise |
| 11:15:06 | pcapriotti | dbussink: what's rb_flow? |
| 11:15:23 | dbussink | pcapriotti: i mean using a hash to spec that control flow there |
| 11:16:14 | pcapriotti | dbussink: what's the best way? add a 'fail' after throw in the ruby code? |
| 11:16:30 | dbussink | pcapriotti: yeah, that's probably a better way |
| 11:17:01 | pcapriotti | dbussink: and same for rb_raise? |
| 11:17:02 | dbussink | pcapriotti: you can also see how the ruby version is specced |
| 11:17:33 | dbussink | pcapriotti: ah, wait, i think i'm talking about a different thing : |
| 11:17:35 | dbussink | :_ |
| 11:17:49 | dbussink | i was talking about http://gist.github.com/470137 line 22 and 24 |
| 11:19:06 | pcapriotti | dbussink: yes, me too, kernel_spec_rb_raise works the same, that's why I'm asking if you want that to be changed as well |
| 11:20:20 | dbussink | pcapriotti: ah ok, yeah, probably better to explicitly fail there then |
| 11:21:04 | dbussink | pcapriotti: you can also return a value there and check the block doesn't return that |
| 11:21:28 | pcapriotti | ok |
| 11:22:22 | dbussink | just trying to keep quality up, not all specs are as good as they should be |
| 11:22:38 | dbussink | which is annoying because people use it as a reference example too |
| 11:22:46 | dbussink | which is completely understandable |
| 11:22:59 | dbussink | not blaming you in that regard :) |
| 11:23:50 | pcapriotti | dbussink: yeah, I undestand, np :) |
| 11:29:09 | boyscout | New spec: rb_class2name should accept a Module argument. - 33e1cc9 - Paolo Capriotti |
| 11:29:09 | boyscout | Fix spec for rb_class2name accepting a Module argument. - 4ac62ed - Paolo Capriotti |
| 11:29:22 | dbussink | pcapriotti: already applied those patches :) |
| 11:29:46 | pcapriotti | dbussink: cool, thanks |
| 11:37:24 | boyscout | CI: rubinius: 4ac62ed successful: 3458 files, 13692 examples, 41271 expectations, 0 failures, 0 errors |
| 11:51:18 | pcapriotti | dbussink: I updated the patch |
| 11:53:18 | dbussink | pcapriotti: cool, i'll check it out :) |
| 11:54:39 | dbussink | pcapriotti: ok, cool, looks a lot better imho :) |
| 11:55:08 | pcapriotti | dbussink: great |
| 11:55:25 | dbussink | pcapriotti: or don't you think it does? ;) |
| 11:56:43 | pcapriotti | dbussink: yeah, the hask thing was kind of a hack, but the code is so short that it's clear what it's testing anyway |
| 11:56:57 | pcapriotti | *hash |
| 11:57:31 | dbussink | true, but i had to think more about it than this implementation :) |
| 12:29:22 | boyscout | Do not swallow LoadError exceptions when loading extensions. - 76472ed - Paolo Capriotti |
| 12:37:28 | boyscout | CI: rubinius: 76472ed successful: 3458 files, 13692 examples, 41271 expectations, 0 failures, 0 errors |
| 13:17:27 | boyscout | Be sure to add debugging information for extensions and same optimization level as rbx uses - 8e3d583 - Dirkjan Bussink |
| 13:25:38 | boyscout | CI: rubinius: 8e3d583 successful: 3458 files, 13692 examples, 41271 expectations, 0 failures, 0 errors |
| 14:00:15 | dbussink | fbuilesv: you irc works again? :P |
| 14:33:11 | boyscout | Add spec for C API rb_throw. - 74dae4c - Paolo Capriotti |
| 14:33:11 | boyscout | Add rb_throw to the C API. - 752c3af - Paolo Capriotti |
| 14:33:11 | boyscout | The CAPI specs weren't part of CI anymore do to the move to spec/ruby/optional - 21719ad - Dirkjan Bussink |
| 14:33:16 | dbussink | pcapriotti: there you go :) |
| 14:33:50 | pcapriotti | dbussink: cool! |
| 14:34:05 | dbussink | pcapriotti: you can ask evan for a commit bit if you want |
| 14:35:47 | dbussink | pcapriotti: this all you need for qtruby? |
| 14:36:35 | pcapriotti | dbussink: not sure, maybe rb_during_gc if it makes sense in rbx |
| 14:36:49 | dbussink | pcapriotti: why does qtruby need it? |
| 14:36:50 | pcapriotti | being able to compile it without modifications would be nice |
| 14:37:07 | dbussink | because anything that peeks into the gc of mri directly is probably a no go for rbx |
| 14:37:08 | pcapriotti | dbussink: I don't know, I tried asking the maintainer, but he's not responding |
| 14:37:14 | dbussink | it could be a noop perhaps |
| 14:37:21 | dbussink | a bunch of the gc methods already are |
| 14:38:43 | pcapriotti | anyway, right now any nontrivial qtruby application crashes, I'll look into that and see if there's any other missing stuff |
| 14:39:10 | dbussink | pcapriotti: can you catch it in gdb? |
| 14:39:21 | pcapriotti | I haven't tried yet |
| 14:53:59 | dbussink | pcapriotti: that could give some valuable information as to what's up |
| 15:00:59 | boyscout | CI: Commit 21719ad failed. http://github.com/evanphx/rubinius/commit/21719ad51a75b20ccc13e1b0a47eda3c8d3aa54e |
| 15:04:27 | pcapriotti | dbussink: btw, it's actually better than I though. The classic Qt tutorials work flawlessly up to the 10th chapter. That means signals and slots are working ok. The 11th tutorial crashes during GC, though |
| 15:04:47 | dbussink | pcapriotti: do you have a backtrace? |
| 15:04:51 | pcapriotti | yup |
| 15:06:05 | pcapriotti | dbussink: http://gist.github.com/470762 |
| 15:06:40 | dbussink | pcapriotti: what's the message above the trace? |
| 15:07:21 | pcapriotti | nothing, just SIGSEGV |
| 15:07:26 | pcapriotti | Error: signal SIGSEGV |
| 15:08:23 | dbussink | no address specified? |
| 15:09:04 | dbussink | guess this is not easy to reproduce right? |
| 15:09:10 | dbussink | needing a setup of qt etc? |
| 15:10:32 | pcapriotti | dbussink: shouldn't be too hard |
| 15:10:41 | pcapriotti | dbussink: what pltaform are you in? |
| 15:10:50 | dbussink | os x 10.5 |
| 15:10:52 | dbussink | 10.6 |
| 15:11:14 | pcapriotti | uhm, no idea, then :) |
| 15:11:30 | pcapriotti | but with patience, it should be possible |
| 15:11:47 | pcapriotti | you need to get kdebindings from the kde SVN repository |
| 15:12:06 | pcapriotti | and of course you need qt + headers |
| 15:12:09 | dbussink | hmm, doesn't segfault with just doing qt stuff? |
| 15:12:17 | dbussink | i could install qt4 relatively easy |
| 15:14:31 | pcapriotti | yes, it's just qt stuff, but qtruby lives in the kde repository |
| 15:14:39 | pcapriotti | but it's possible to build it without any kde stuff |
| 15:17:26 | dbussink | pcapriotti: could try adding a return at vm/objectmemory.cpp at run_finalizers ? |
| 15:17:32 | dbussink | so that they don't run |
| 15:17:45 | dbussink | just to see if it's also an issue in there |
| 15:18:08 | pcapriotti | ok |
| 15:19:57 | pcapriotti | dbussink: same thing |
| 15:20:07 | dbussink | ah ok, then it's something else |
| 15:20:27 | dbussink | pcapriotti: does qtruby do things that depends on having a non moving gc? |
| 15:20:39 | dbussink | so keeping a reference to some object global? |
| 15:20:41 | pcapriotti | dbussink: ah! |
| 15:20:48 | pcapriotti | dbussink: yes |
| 15:20:56 | pcapriotti | dbussink: isn't that supported? |
| 15:21:02 | pcapriotti | I thought it was |
| 15:21:35 | dbussink | are the registered through rb_global_variable or rb_gc_register_address ? |
| 15:21:43 | dbussink | they registered |
| 15:27:29 | pcapriotti | uhm... I don't think so |
| 15:27:46 | pcapriotti | qtruby maintains map from qt objects to ruby VALUE's |
| 15:30:13 | pcapriotti | so that when it finds a qt object that was already wrapped, it reuses the old VALUE |
| 15:32:00 | pcapriotti | it shouldn't prevent those objects from being GC'ed, btw... it just removes them from the mapping whenever they are collected by using a finalizer |
| 15:33:23 | pcapriotti | dbussink: is keeping VALUE's around supported in rubinius? |
| 15:34:43 | dbussink | pcapriotti: hmm, you register a finalizer for ruby to call? |
| 15:35:37 | pcapriotti | yes |
| 15:35:49 | dbussink | pcapriotti: how is that set up? |
| 15:35:56 | dbussink | dunno if rbx supports that already |
| 15:38:30 | pcapriotti | dbussink: it's passed to Data_Wrap_Struct |
| 15:40:59 | dbussink | pcapriotti: do you think you're able to reproduce a smaller test case with this? |
| 15:41:30 | pcapriotti | not sure |
| 15:41:38 | pcapriotti | I'll see what I can do |
| 15:43:49 | pcapriotti | dbussink: what kind of thing that depends on having a non-moving gc wouldn't be supported in rubinius? |
| 15:44:25 | dbussink | pcapriotti: well, rubinius uses handles that should work properly and should be updated when stuff is moved |
| 15:44:39 | dbussink | but if you refer to more internal mri structures it's problematic |
| 15:44:53 | dbussink | if it for examples uses things like RSTRING()->ptr |
| 15:45:16 | dbussink | or RHASH for example |
| 15:45:53 | pcapriotti | yup, plenty of those :) |
| 15:46:21 | pcapriotti | why does rubinius define them at all, if they can't possibly work safely? |
| 15:53:00 | dbussink | pcapriotti: it should blow up if those are used |
| 15:53:11 | dbussink | vm/capi/include/ruby.h:356 |
| 15:55:04 | pcapriotti | dbussink: oh, no, I meant RSTRING()->ptr |
| 15:55:22 | dbussink | well, RSTRING()->ptr can be easily replaced with RSTRING_PTR |
| 15:55:22 | pcapriotti | it's actually using RSTRING_PTR |
| 15:55:28 | pcapriotti | ok |
| 15:55:29 | dbussink | ah, that's fine |
| 15:55:36 | pcapriotti | so that's not the problem |
| 16:20:06 | brixen | dbussink: ping |
| 16:22:46 | dbussink | brixen: pong |
| 16:23:35 | brixen | hi |
| 16:23:46 | brixen | a note about spec'ing control flow |
| 16:23:51 | brixen | do not use fail |
| 16:24:01 | brixen | use ScratchPad to annotate the paths |
| 16:24:17 | brixen | and an expectation against the values ScratchPad accumulates |
| 16:24:19 | dbussink | ah ok, any examples of that? |
| 16:24:27 | brixen | you can see how this is done in break, next specs |
| 16:25:10 | dbussink | ah, well, it's already better than the first version |
| 16:25:20 | brixen | sure |
| 16:25:21 | dbussink | but i'll also point people at that then |
| 16:25:40 | brixen | but in general, don't override the fail mechanism for this |
| 16:25:49 | dbussink | hmm, the guy already left |
| 16:25:50 | brixen | specs are about data |
| 16:26:35 | brixen | dbussink: gotta run for a few, would you be able to check on that CI failure? |
| 16:26:47 | brixen | oh, and nice catch on the capi specs, what was I thinking :P |
| 16:27:10 | dbussink | brixen: probably a capi thing that now fails on linux |
| 16:27:23 | brixen | dbussink: http://ci.rubini.us/ |
| 16:27:27 | brixen | it's only one spec |
| 16:27:27 | dbussink | brixen: i'll tag that failing one |
| 16:27:35 | brixen | ok |
| 16:27:46 | dbussink | brixen: i wasn't seeing increasing spec assertion numbers when this was added :) |
| 16:27:50 | dbussink | so that got me thinking |
| 16:28:13 | brixen | ok, gotta run, bbl... |
| 16:28:16 | brixen | thanks dbussink! |
| 16:37:14 | boyscout | Don't spec MRI warnings. - acdbf1d - Brian Ford |
| 16:37:25 | brixen | dbussink: actually, there you go |
| 16:37:31 | brixen | is out |
| 16:37:38 | dbussink | brixen: heh |
| 16:37:43 | dbussink | brixen: have a nice day |
| 16:45:27 | boyscout | CI: rubinius: acdbf1d successful: 3481 files, 14070 examples, 41803 expectations, 0 failures, 0 errors |
| 18:06:58 | dbussink | evan: ping? |