Show enters and exits. Hide enters and exits.
| 00:31:06 | evan | so |
| 00:31:14 | boyscout | Mark a thread as sleeping when waiting on a lock - aa74ac8 - Evan Phoenix (hydra) |
| 00:31:14 | boyscout | Handle bad unlocks properly - b5bbed6 - Evan Phoenix (hydra) |
| 00:31:14 | boyscout | Simple refactor - 1cc83d1 - Evan Phoenix (hydra) |
| 00:31:19 | evan | should locking an object be an operation that can be interrupted? |
| 00:49:05 | Defiler | evan: is there a timeout on that operation if it gets hung up? |
| 00:49:26 | evan | atm, no, but there could be. |
| 00:49:26 | Defiler | alterantely, what could make locking an object take an indeterminate amount of time |
| 00:49:39 | evan | another thread not giving up the lock. |
| 00:49:56 | Defiler | sounds like something you'd want to be able to cancel and give up on then |
| 00:50:11 | Defiler | but a timeout might be the right way, vs. an interruption |
| 00:50:26 | evan | well, i'll do them both if i do them |
| 00:50:28 | evan | they're nearly the same. |
| 00:50:51 | evan | because i have to use a condition variable to wait for a specific amount of time |
| 00:51:04 | evan | and a condition variable is what i'd use to be able to interrupt the operation. |
| 00:51:38 | evan | in which case, i could go ahead and implement JVM style Object#wait, #notify, #notifyAll |
| 00:51:51 | evan | since those are just condvar operations |
| 00:52:26 | Defiler | yeah |
| 00:52:38 | Defiler | I guess that sounds like something necessary |
| 00:56:26 | evan | ok |
| 00:56:27 | evan | doing it! |
| 00:58:52 | Defiler | cool |
| 01:03:53 | evan | hm, i guess a timeout in microseconds? |
| 01:13:13 | Defiler | that sounds like the right timescale, yeah |
| 01:14:33 | Defiler | how about a really opaque and tricky-to-initalize TAI64 struct? heh |
| 01:15:43 | Defiler | then you can specify it in attoseconds |
| 01:20:12 | evan | oh man |
| 01:20:25 | evan | TIA64 seems cool |
| 01:20:34 | Defiler | it is |
| 01:20:39 | Defiler | best time format |
| 01:21:02 | Defiler | I like how cleanly it extends to higher precision |
| 01:36:35 | evan | Defiler: yeah, doesn't it support the end of the universe? |
| 05:42:01 | dbussink | evan: ping? |
| 05:43:47 | slava | hi brixen |
| 05:44:05 | slava | you're such a google hater now :) |
| 05:47:28 | brixen | slava: haha |
| 05:50:14 | brixen | slava: don't worry, I know nice people who work at M$ too :) |
| 05:51:18 | dbussink | brixen: btw, going to talk about rbx at rubyandrails.eu in october :) |
| 05:51:36 | brixen | dbussink: woot! |
| 05:56:08 | dbussink | brixen: at least, the guy i asked about was enthousiastic about it, and since he's organizing it, that's probably going to be fine :P |
| 05:58:20 | brixen | dbussink: do you know what you'll be talking about? |
| 06:00:02 | dbussink | brixen: been thinking about it, more a general talk i think, explaining some concepts rbx uses to speed up ruby code etc. |
| 06:00:07 | dbussink | and show some examples of it in action |
| 06:00:18 | dbussink | i don't expect the audience to be too al knowing already |
| 06:00:22 | dbussink | but that's my guess atm |
| 06:00:27 | brixen | cool |
| 06:00:34 | dbussink | brixen: if you have tips, please tell them :) |
| 06:02:15 | brixen | dbussink: I'm thinking of proposing a talk for rubyconf uruguay |
| 06:02:33 | brixen | same deal, mostly beginners in the audience |
| 06:05:10 | dbussink | brixen: not a lot of die hard european devs in here normally, same for south america i guess :P |
| 06:07:03 | brixen | dbussink: yeah, interesting to understand that better |
| 06:07:18 | brixen | is it opportunity or exposure or something else |
| 06:08:06 | dbussink | brixen: also feels like a smaller ruby community in general here |
| 06:08:29 | brixen | probably, yeah |
| 06:09:18 | dbussink | but i'm going to head to the office |
| 06:09:20 | dbussink | back later |
| 07:36:34 | dbussink | guess everybody is asleep right now |
| 07:37:03 | slava | its half past midnight in the one true timezone |
| 07:41:09 | dbussink | slava: hehe, don't care that global stuff often happens on gmt base i guess :P |
| 11:50:56 | dbussink | yay: http://rubyandrails.eu/articles/dirkjan-bussink-explains-rubinius-at-rar10 |
| 12:19:33 | kronos_vano | dbussink, gratz |
| 12:24:44 | dbussink | kronos_vano: i know the guy organizing it though ;) |
| 12:24:53 | kronos_vano | :D |
| 16:01:21 | evan | morning. |
| 16:01:33 | mitchellh | good morning |
| 16:18:03 | evan | mitchellh: welcome, are you new? |
| 16:18:29 | mitchellh | I've been lurking, been wanting to help with FFI so I can get vagrant (vagrantup.com) working on rbx |
| 16:18:35 | mitchellh | but haven't had time :( |
| 16:18:39 | evan | ah cool |
| 16:20:58 | dbussink | evan: howdy :) |
| 16:21:18 | evan | heya. |
| 16:21:18 | dbussink | evan: proposal for the talk was accepted :) |
| 16:21:22 | evan | i saw! |
| 16:21:23 | evan | yay |
| 16:21:48 | dbussink | i had to poke the guy for spelling my name wrong though :P |
| 16:21:52 | dbussink | dutch people always do that |
| 16:22:02 | evan | ha |
| 16:22:11 | dbussink | no one else can pronounce it, but at least they write it right |
| 16:22:14 | evan | you'd be surprised |
| 16:22:16 | evan | i get that too. |
| 16:22:30 | evan | I get "even" sometimes |
| 16:22:32 | dbussink | isn't evan like the standard way to write your name? |
| 16:22:37 | evan | oh yeah, it is. |
| 16:22:42 | evan | people are just dumb. |
| 16:22:48 | dbussink | hehe, that's true yeah |
| 16:22:55 | evan | also, "fenix" for phoenix |
| 16:22:58 | evan | O_o |
| 16:23:02 | mitchellh | LOL |
| 16:23:18 | dbussink | we had someone complain today that we invaded his privacy because he could see his previous searches in a search input field :S |
| 16:23:32 | dbussink | that we should stop gathering information on him |
| 16:23:35 | evan | awesome |
| 16:23:41 | evan | those people are fun |
| 16:23:44 | evan | @_o |
| 16:23:50 | dbussink | hehe, yeah |
| 16:24:12 | dbussink | btw, i have some hydra crashes in caught in gdb if you're interested :) |
| 16:24:34 | evan | i am! |
| 16:24:48 | dbussink | evan: i have this one: https://gist.github.com/1df9f85239242f0ac214 |
| 16:25:14 | evan | mmm ok. |
| 16:25:14 | dbussink | evan: and this one: https://gist.github.com/afef744f25318f251313 |
| 16:25:43 | evan | hrm. |
| 16:25:43 | evan | ok. |
| 16:25:50 | evan | so |
| 16:25:54 | evan | from now on |
| 16:26:01 | evan | i need "thread appl all bt <number>" |
| 16:26:07 | evan | err "thread apply all bt <number>" |
| 16:26:13 | dbussink | evan: ok, will get you that :) |
| 16:26:16 | evan | k |
| 16:27:00 | dbussink | evan: this is one for the first error: https://gist.github.com/2ee25368d8449d74e66e |
| 16:27:20 | evan | YIKES |
| 16:27:21 | evan | 40 threads. |
| 16:27:22 | evan | :/ |
| 16:27:30 | dbussink | evan: hmm, looks like that was still with older code |
| 16:27:38 | dbussink | haven't closed any of the crashed rbx's |
| 16:27:40 | evan | 45 threads actually. |
| 16:27:48 | evan | ok |
| 16:27:53 | evan | try with the latest |
| 16:28:00 | evan | but I did fix some stuff. |
| 16:28:13 | dbussink | evan: the second error is with latest |
| 16:28:19 | evan | k |
| 16:28:23 | dbussink | evan: let me get the threads backtrace with that one |
| 16:28:27 | evan | k |
| 16:28:58 | dbussink | evan: https://gist.github.com/0cc09570340c620f5d35 |
| 16:29:27 | evan | ooh |
| 16:29:30 | evan | probably need a lock there. |
| 16:29:30 | dbussink | evan: that does show some concurrent activity |
| 16:29:38 | evan | inside add_cache |
| 16:29:47 | evan | i'll bet 2 methods code setup concurrently. |
| 16:29:54 | evan | and corrupted the IC registry. |
| 16:34:42 | dbussink | evan: that should be an easy fix then or does it entail more? |
| 16:35:30 | evan | easy |
| 16:44:46 | evan | nicksieger: morning nick. |
| 16:44:53 | nicksieger | hi evan |
| 16:45:01 | nicksieger | how's the hydra slaying coming |
| 16:45:23 | evan | i'm using the most powerful move the ancient world has to offer: the jump stab. |
| 16:45:24 | dbussink | i just pointed evan a head to be slain ;) |
| 16:46:22 | dbussink | evan: could i add this easily myself? |
| 16:46:46 | evan | sure |
| 16:47:12 | dbussink | evan: anywhere i could look for an example of how to properly lock stuff? |
| 16:47:26 | evan | sure, it's easy |
| 16:47:30 | evan | go into inline_cache.hpp |
| 16:47:40 | evan | and make InlineCacheRegistery a subclass of Lockable |
| 16:47:43 | evan | ie |
| 16:47:49 | evan | class ICR : public Lockable { |
| 16:48:09 | evan | then go into it's methods in inline_cache.cpp |
| 16:48:22 | dbussink | evan: it's now a Dispatch, is that a problem? |
| 16:48:29 | evan | huh? |
| 16:48:30 | evan | no |
| 16:48:33 | evan | InlineCacheRegistery |
| 16:48:35 | evan | not InlineCache |
| 16:48:41 | dbussink | ow, sorry, doh :) |
| 16:49:42 | evan | so, then, in ICR's methods in inline_cache.cpp |
| 16:49:46 | evan | make the first line |
| 16:49:48 | evan | SYNC_TL |
| 16:50:01 | evan | if STATE was passed into these, you could use SYNC(state) |
| 16:50:10 | evan | if you want to make that change too, go for it. |
| 16:50:31 | evan | SYNC_TL gets state from the thread local |
| 16:51:05 | dbussink | evan: ah ok, i was going to ask about that :) |
| 16:51:32 | dbussink | evan: do i need to explicitly unlock? |
| 16:51:40 | evan | nope! |
| 16:51:45 | dbussink | ok, cool :) |
| 16:51:47 | evan | awesome huh. |
| 16:51:54 | dbussink | i assume remove_cache also needs it then? :) |
| 16:51:58 | evan | SYNC in in lock.hpp if you want to check it out |
| 16:52:01 | evan | yeah, all of them need it. |
| 16:52:31 | evan | nicksieger: i have a java/jvm question for ya |
| 16:52:40 | nicksieger | sure, i'm game |
| 16:52:52 | evan | can you interrupt synchronizing on an object? |
| 16:53:10 | evan | T1 does synchronize(obj) { .... |
| 16:53:22 | nicksieger | yes, you can |
| 16:53:26 | nicksieger | Thread#interrupt |
| 16:53:29 | evan | T2 does has obj locked, and does T1.interrupt |
| 16:53:44 | evan | ok, so T1 wakes up then and raises a ThreadInterrupted exception |
| 16:53:51 | nicksieger | http://download.oracle.com/javase/6/docs/api/java/lang/Thread.html#interrupt() |
| 16:53:58 | evan | ok, i thought so |
| 16:53:59 | nicksieger | exactly |
| 16:54:01 | nicksieger | that's pretty muchit |
| 16:54:09 | evan | but I couldn't find out if synchronize checked the interrupted flag |
| 16:54:21 | nicksieger | i don't think so. |
| 16:54:29 | nicksieger | synchronized() { … } is syntax |
| 16:54:44 | nicksieger | in the VM it's MONITORENTER and MONITOREXIT instructions |
| 16:54:53 | evan | yeah, i know |
| 16:54:56 | nicksieger | ok |
| 16:55:04 | evan | but i couldn't find out if MONITORENTER checks the interrupted flag |
| 16:55:05 | nicksieger | yeah, so not sure about checking interrupt status |
| 16:55:20 | evan | ie, does MONITORENTER throw ThreadInterrupted |
| 16:55:24 | evan | google! |
| 16:55:39 | nicksieger | my guess is no. i've looked at some lock implementations and they do things like check interrupted status and bail early |
| 16:56:00 | evan | well, the impl also has to be implemented with a condition variable |
| 16:56:19 | evan | so that #interrupt can signal T1 via the condvar and check the flag |
| 17:08:36 | dbussink | evan: how does this look? https://gist.github.com/02e422e035a9cf08b8b4 |
| 17:09:03 | dbussink | evan: i see a global cache clear there btw, is that already thread safe? at the top there in vm/builtin/system.cpp |
| 17:09:16 | evan | probably not |
| 17:09:26 | evan | thats a little more tricky though |
| 17:09:47 | evan | because reading the global cache is in the fast path |
| 17:09:51 | evan | so we don't really want to lock it |
| 17:11:49 | nicksieger | evan: don't know if you looked in jdk sources yet |
| 17:12:02 | evan | i started to |
| 17:12:03 | nicksieger | i think http://hg.openjdk.java.net/jdk6/jdk6/hotspot/file/13f94cc87253/src/share/vm/runtime/synchronizer.cpp has some of the monitorenter stuff |
| 17:12:08 | nicksieger | search for "slow_enter" |
| 17:12:08 | evan | thanks! |
| 17:12:16 | nicksieger | doesn't look like any interrupt checking is in there |
| 17:12:17 | evan | i was hoping for a pointer |
| 17:14:17 | nicksieger | of course that's the higher level stuff. OS-specific code will be in src/<os>/ ... |
| 17:15:38 | brixen | back |
| 17:16:01 | brixen | an hour inverted in the dentist's chair and my back feels better than it has in a week |
| 17:16:16 | brixen | but now I can't eat anything for hours, and I'm hungry :) |
| 17:16:22 | evan | brixen: ha! |
| 17:16:31 | evan | well, at least your back feels great. |
| 17:16:42 | brixen | better, not great yet |
| 17:16:53 | brixen | maybe I should schedule another appt |
| 17:17:22 | dbussink | evan: but is the patch ok? |
| 17:29:01 | dbussink | evan: got a new one after that patch: https://gist.github.com/bb4254b8997c46737b33 |
| 17:30:39 | evan | got a what? |
| 17:30:45 | evan | you left off the reason it stopped |
| 17:32:37 | dbussink | evan: hmm, already cleared it out, tried it again but now i got this: https://gist.github.com/b2c360c8ee11c1781257 |
| 17:32:56 | evan | I gotta see all the threads |
| 17:32:56 | dbussink | evan: dunno if this is my change causing havoc though |
| 17:33:00 | evan | not just the current one. |
| 17:33:37 | dbussink | evan: i added to it now |
| 17:33:59 | evan | :/ |
| 17:34:02 | evan | makes no sense |
| 17:34:06 | evan | put a breakpoint on abort |
| 17:34:08 | evan | and run again. |
| 17:36:48 | dbussink | evan: that previous one also was in llvm, so seems something is up there |
| 17:36:56 | evan | doubtful. |
| 17:36:57 | dbussink | evan: shall i commit that patch i made or not? |
| 17:37:00 | evan | no. |
| 17:37:05 | evan | not if it crashes everytime. |
| 17:37:13 | evan | gist me the patch |
| 17:37:31 | dbussink | evan: https://gist.github.com/02e422e035a9cf08b8b4 |
| 17:38:34 | evan | hrm. |
| 17:39:09 | evan | i guess go ahead |
| 17:39:14 | evan | your crash must be unrelated. |
| 17:49:48 | jeremyevans | Just found a couple more C API methods that rubinius doesn't implement and I'm using in my extension: http://github.com/evanphx/rubinius/issues/issue/436 |
| 17:52:14 | evan | jeremyevans: those don't expose an re*, right? |
| 17:52:20 | evan | they take and return VALUEs |
| 17:52:21 | evan | ? |
| 17:53:15 | jeremyevans | evan: Yes |
| 17:53:22 | evan | k |
| 17:53:25 | evan | should be trivial then. |
| 17:54:25 | jeremyevans | evan: rb_reg new is VALUE (char*, long, long); and rb_reg_nth_match is VALUE (long, VALUE) |
| 17:54:47 | evan | k |
| 17:54:56 | brixen | jeremyevans: did you want to take a stab at implementing them? |
| 17:55:26 | jeremyevans | brixen: I suppose I could. |
| 17:55:39 | brixen | I can give you some pointers |
| 17:55:39 | dbussink | evan: ok, i'll commit it, so you can check it out then too |
| 17:55:49 | jeremyevans | brixen: Haven't hacked on rubinius before though. Should I read anything first? |
| 17:55:53 | dbussink | evan: this is running ci in gdb btw, but you probalby noticed that :) |
| 17:55:57 | brixen | jeremyevans: first, for the specs, check out spec/ruby/optional/capi |
| 17:56:11 | brixen | jeremyevans: I'm going to find a commit that you can follow along |
| 17:56:13 | evan | dbussink: right. |
| 17:56:16 | jeremyevans | brixen: Thanks |
| 17:56:58 | brixen | jeremyevans: git show 5bf23baa |
| 17:57:34 | brixen | jeremyevans: here's the code that goes with those specs: git show d14e77dfd28 |
| 17:58:27 | brixen | jeremyevans: have a quick read of doc/specs.txt |
| 17:58:45 | jeremyevans | brixen: Weird, I'm working with an .rvm rbx-head, which doesn't look like it has full history |
| 17:59:02 | jeremyevans | brixen: Let me do a full clone |
| 17:59:21 | evan | you'll need a normal clone, yes. |
| 18:00:08 | dbussink | evan: ok, pushed |
| 18:00:14 | boyscout | Add locks around modifying the InlineCacheRegistry - d46af39 - Dirkjan Bussink (hydra) |
| 18:00:17 | evan | k |
| 18:10:19 | dbussink | evan: i have to say that after this i did start to see more crashes, maybe it exposes an issue somewhere else? |
| 18:11:13 | evan | maybe. |
| 18:13:56 | dbussink | i already feel cool enough that i could actually fix something :P |
| 18:20:27 | dbussink | evan: are you seeing these crashes too? |
| 18:20:35 | evan | haven't updated |
| 18:20:40 | evan | in the middle of something else. |
| 18:20:44 | dbussink | ok, cool |
| 18:20:56 | evan | adding timeouts and the ability to interrupt locks |
| 18:22:51 | dbussink | ah, cool :) |
| 18:23:17 | evan | we'll probably also get the ability to use objects as condition variables |
| 18:23:30 | evan | since it goes with the arch required for timeouts and interrupts |
| 19:08:34 | dbussink | evan: btw, did someone mail you with a security issue? |
| 19:08:51 | evan | yep |
| 19:09:03 | dbussink | evan: ah ok, asked him on twitter to mail you directly |
| 19:09:12 | dbussink | since there's no security list or something |
| 19:09:17 | evan | ok cool. |
| 19:09:18 | evan | yeah |
| 19:15:46 | dbussink | evan: should we set up something for that or not worth it atm? |
| 19:36:37 | jeremyevans | brixen: Cloning finally finished and I have the spec created |
| 19:37:14 | jeremyevans | brixen: I don't have any recent C++ experience (C only), so I'm not sure how to create a Regexp using Rubinius's C++ API |
| 19:47:03 | brixen | jeremyevans: take a look at vm/capi/regexp.cpp |
| 19:47:14 | brixen | jeremyevans: you should be able to rb_funcall to Ruby code I'm thinking |
| 19:47:30 | brixen | jeremyevans: just getting some lunch, bbiab... |
| 19:47:41 | jeremyevans | brixen: I found that and I'm working with it. Thanks. |
| 19:47:50 | brixen | sweet |
| 19:50:32 | jeremyevans | brixen: My spec passes on mri, which is good :) |
| 19:54:03 | rue | Humm. Another .nl conf? Might make this one |
| 19:54:18 | rue | My flight prohibition ends in September too |
| 19:56:16 | dbussink | rue: flight prohibition? |
| 20:06:36 | rue | dbussink: My hematocrit was very high in the spring so I have not been allowed altitudes |
| 20:07:03 | dbussink | rue: doing epo? :P |
| 20:18:54 | jeremyevans | Is Qnil an integer, a rubinius::Object, or one of the two depending on context? |
| 20:19:32 | brixen | it's an immediate |
| 20:19:58 | brixen | it's a tagged pointer |
| 20:19:59 | jeremyevans | brixen: What's the appropriate rubinius::Object to use for nil? |
| 20:20:10 | brixen | it looks like a pointer but isn't a valid address |
| 20:20:11 | rue | dbussink: I wish! |
| 20:20:17 | brixen | jeremyevans: Qnil |
| 20:20:29 | rue | (Any WADA people reading: just kidding.) |
| 20:20:29 | jeremyevans | brixen: That's what I'm using and rake build is failing |
| 20:21:05 | brixen | jeremyevans: could you gist me your changes |
| 20:21:44 | jeremyevans | brixen: http://pastie.org/1089083 |
| 20:23:32 | brixen | jeremyevans: why not a rb_funcall? |
| 20:24:12 | jeremyevans | brixen: I suppose that would work, since I'm creating the string anyway. |
| 20:24:58 | brixen | that's the preferred way to do stuff in c-api |
| 20:25:04 | brixen | call a ruby method if you can |
| 20:26:26 | jeremyevans | brixen: Makes sense. |
| 20:28:05 | jeremyevans | brixen: That appears to work |
| 20:28:36 | jeremyevans | brixen: Let me finish compiling and run the specs to see if it works |
| 20:28:42 | dbussink | brixen: how big would the performance differ for the capi because of this? |
| 20:28:58 | dbussink | just curious :) |
| 20:29:08 | brixen | dbussink: dunno |
| 20:29:22 | brixen | jeremyevans: Qnil is different in c-api than in rbx |
| 20:29:29 | brixen | jeremyevans: look at ruby.h |
| 20:29:43 | brixen | jeremyevans: so, writing code for the c-api can be a little confusing |
| 20:30:02 | jeremyevans | brixen: That makes sense why code I copied from C++ to the CAPI wasn't working |
| 20:30:15 | brixen | yeah, that ain't gonna work :) |
| 20:30:28 | jeremyevans | brixen: So is there a CAPI version of C++ Qnil? |
| 20:30:50 | brixen | yes, but generally you want the c-api one |
| 20:31:52 | brixen | jeremyevans: you have to use RBX_Qnil in the c-api |
| 20:32:37 | jeremyevans | brixen: Noted. |
| 20:32:49 | brixen | but those cases are pretty rare |
| 20:32:59 | brixen | sorry, it's confusing :/ |
| 20:33:20 | jeremyevans | brixen: Running the specs now. The default task includes the capi specs, right? |
| 20:33:29 | brixen | yeah |
| 20:33:37 | dbussink | it does these days :P |
| 20:33:49 | brixen | you can always bin/mspec spec/ruby/optional/blah |
| 20:35:50 | phlebas | brixen: since your in capi mode, I have added a few capi specs to my fork on timfel/rubyspec since i started working on capi support for jruby |
| 20:36:18 | brixen | phlebas: oh cool |
| 20:36:26 | brixen | phlebas: could you git fp them? |
| 20:36:54 | phlebas | sure |
| 20:37:03 | brixen | sweet, appreciated |
| 20:37:42 | phlebas | send them to you directly? |
| 20:37:51 | phlebas | or to ml? |
| 20:38:15 | brixen | could you gist and link in a github issue? |
| 20:38:21 | phlebas | will do |
| 20:38:30 | brixen | thanks |
| 20:38:37 | jeremyevans | brixen: http://pastie.org/1089106 |
| 20:38:48 | jeremyevans | brixen: Looks like I'm doing something wrong |
| 20:39:19 | brixen | yeah |
| 20:39:32 | brixen | you need to use handles with C++ objects |
| 20:39:43 | jeremyevans | brixen: OK. How do I do that? |
| 20:40:04 | brixen | like env->get_handle(pat) |
| 20:41:14 | jeremyevans | brixen: That appears to have fixed it |
| 20:42:27 | brixen | cool |
| 21:05:04 | brixen | phlebas: looks like I just got you patch spam :D |
| 21:05:10 | brixen | er your* even |
| 21:05:15 | phlebas | you made me |
| 21:05:18 | brixen | heh |
| 21:05:23 | brixen | nah, thank you very much |
| 21:05:26 | phlebas | only three more to go |
| 21:05:31 | brixen | heh, ok |
| 21:07:45 | brixen | phlebas: I'll get these merged in tonight |
| 21:08:02 | jeremyevans | brixen: http://pastie.org/1089155.txt |
| 21:08:22 | jeremyevans | brixen: Will that work for patch submission? |
| 21:08:47 | brixen | jeremyevans: looking at it now |
| 21:11:22 | phlebas | brixen: thanks, I'm done posting for now, have to hunt a few segfaults :) |
| 21:14:47 | brixen | phlebas: fun! |
| 21:24:55 | jeremyevans | brixen: any thoughts? |
| 21:25:36 | brixen | yes |
| 21:25:59 | boyscout | Add spec for C API rb_reg_new - 82bb2f9 - Jeremy Evans |
| 21:25:59 | boyscout | Add C API function rb_reg_new - 2b1315f - Jeremy Evans |
| 21:25:59 | boyscout | Add spec for C API rb_reg_nth_match function - 8039442 - Jeremy Evans |
| 21:25:59 | boyscout | Add the C API rb_reg_nth_match method - 5975010 - Jeremy Evans |
| 21:25:59 | boyscout | A couple spec style cleanups. - cafdc59 - Brian Ford |
| 21:26:11 | jeremyevans | brixen: Awesome! |
| 21:26:11 | brixen | jeremyevans: ^^^ :D |
| 21:26:18 | brixen | jeremyevans: ask evan for a commit bit! |
| 21:26:24 | brixen | and thanks for diving into that! |
| 21:32:10 | brixen | grabbing coffee with an old friend, bbl... |
| 21:40:34 | jeremyevans | What's the rbx way of using rb_str_buf_new, writing into the pointer, and then using rb_str_set_len to set the length of the string? |
| 21:42:49 | dbussink | jeremyevans: i guess you don't |
| 21:42:50 | dbussink | but maybe brixen or evan know if you can |
| 21:43:30 | evan | jeremyevans: don't. |
| 21:43:33 | evan | is the way. |
| 21:43:46 | evan | but if you must, those 2 things should already work. |
| 21:43:53 | jeremyevans | evan: What's the recommended alternative? |
| 21:44:06 | evan | use a C buffer |
| 21:44:11 | jeremyevans | evan: It doesn't appear to be working for my extension. I'm getting empty strings |
| 21:44:20 | evan | use a normal C buffer |
| 21:44:23 | evan | build it |
| 21:44:28 | evan | call rb_str_new with it |
| 21:44:39 | evan | i thought we had that working |
| 21:44:40 | jeremyevans | evan: Doesn't that require copying the string? |
| 21:44:48 | evan | yes, it does. |
| 21:45:00 | evan | but i doubt you've benchmarked that copy :) |
| 21:45:08 | jeremyevans | evan: I have actually :) |
| 21:45:21 | evan | well, it doesn't matter rbx wise |
| 21:45:28 | jeremyevans | evan: It's the reason I went with the rb_str_buf_new for mri |
| 21:45:30 | evan | to support that, a copy is done behind the scenes |
| 21:46:28 | evan | we don't give you raw access to the data |
| 21:46:29 | evan | we can.t |
| 21:46:31 | jeremyevans | evan: I can understand it's no faster in rbx, but it is faster in MRI |
| 21:47:10 | evan | we can support those apis |
| 21:47:12 | evan | i thought we did. |
| 21:47:35 | jeremyevans | evan: and I'd prefer not to rewrite a bunch of existing code. Let me see if I can add a spec for it (unless there is one already) |
| 21:47:49 | evan | k |
| 21:47:51 | evan | thats fine. |
| 21:47:53 | evan | we should support it. |
| 21:49:10 | jeremyevans | evan: Doesn't appear to be an existing spec. I'll add one |
| 21:50:45 | evan | jeremyevans: what extension is this? |
| 21:51:36 | jeremyevans | evan: This is the rewrite of the stdlib Date/DateTime classes in C |
| 21:51:44 | evan | gotcha |
| 21:56:25 | boyscout | CI: Commit cafdc59 failed. http://github.com/evanphx/rubinius/commit/cafdc5992a8aef3f63738bcb062cf44ded945396 |
| 21:58:32 | evan | :/ |
| 21:59:09 | evan | why the fuck did that start failing. |
| 22:12:26 | jeremyevans | evan: http://pastie.org/1089312.txt <- Failing spec for rb_str_buf_new/rb_str_set_len combination |
| 22:13:10 | evan | ok |
| 22:14:08 | jeremyevans | evan: Found the problem, in rb_str_set_len |
| 22:14:37 | jeremyevans | evan: We check the existing length of the string, which is 0 for rb_str_buf_new |
| 22:14:48 | evan | fix it! |
| 22:14:49 | jeremyevans | evan: We probably should check the size of the buffer |
| 22:14:53 | evan | :) |
| 22:14:56 | evan | what line? |
| 22:15:10 | jeremyevans | evan: 370 |
| 22:15:20 | jeremyevans | evan: capi/string.cpp |
| 22:15:23 | evan | that seems fine. |
| 22:15:30 | evan | whats wrong with that? |
| 22:15:38 | evan | string is the buffer |
| 22:15:42 | jeremyevans | evan: string->size() is probably 0 |
| 22:15:48 | evan | ..... |
| 22:15:54 | evan | oh, i see. |
| 22:15:56 | jeremyevans | evan: In MRI, the size of the string is different than the size of the buffer |
| 22:16:00 | evan | yeah, that should be |
| 22:16:07 | evan | string->data()->num_bytes() |
| 22:16:11 | evan | right right |
| 22:16:26 | evan | size() here is the virtual size, not the size of the backing buffer. |
| 22:16:54 | evan | string->data()->size() |
| 22:16:56 | evan | should be used. |
| 22:17:03 | jeremyevans | evan: OK. |
| 22:17:49 | jeremyevans | evan: compiling now |
| 22:26:28 | jeremyevans | evan: Very weird. It passes the first line of the spec, but not the second |
| 22:26:46 | evan | fails how? |
| 22:26:46 | jeremyevans | evan: That makes no sense |
| 22:27:01 | jeremyevans | evan: it's empty . Let me pastie |
| 22:28:44 | jeremyevans | evan: http://pastie.org/1089338.txt |
| 22:30:49 | jeremyevans | evan: It appears to fail for more than 3 characters |
| 22:30:59 | evan | .... |
| 22:31:05 | jeremyevans | evan: 1, 2, 3 characters work, 4 and 5 given the empty string |
| 22:31:07 | evan | what is rb_str_buf_new doing? |
| 22:31:49 | evan | hrm. |
| 22:31:52 | evan | thats odd. |
| 22:31:55 | evan | should work... |
| 22:35:55 | jeremyevans | |Blaze|: Qnil is also 4 in MRI. Start your conspiracy theories :) |
| 22:38:03 | evan | jeremyevans: well, i'll bbiab. |
| 22:38:10 | evan | i'll take a look myself shortly. |
| 22:38:17 | jeremyevans | evan: OK. Thanks! |
| 22:38:42 | cremes | jeremyevans: slightly OT, but has ruby-core reconsidered your date perf patches that use a Hash? |
| 22:39:05 | jeremyevans | cremes: Haven't had any updates since my last post |
| 22:39:35 | cremes | hmm... so odd that they would reject it for a patch using Struct |
| 22:39:38 | cremes | mind boggles |
| 22:39:44 | cremes | anyway, thanks for the update |
| 22:39:52 | jeremyevans | cremes: ruby redmine doesn't allow us mortals to reopen tickets (I think), and I'm too polite to submit a new ticket :) |
| 22:40:29 | jeremyevans | cremes: Maybe tadf will take another look when he fixes the Date#rfc3339 issue I submitted |
| 22:49:38 | jeremyevans | evan: Found the bug |
| 22:50:34 | jeremyevans | evan: well, part of it at least |
| 22:51:03 | jeremyevans | evan: updating string->num_bytes outside of the if statement seems to work |
| 22:51:41 | jeremyevans | evan: I'm not sure if that will automatically resize the string, though |
| 22:52:08 | jeremyevans | evan: And you obviously don't want to increase the listed buffer size without increasing the size of the buffer |
| 22:52:39 | jeremyevans | evan: Since I'm don't know a great deal about rbx's string implementation, I'm not sure if my patch is correct |
| 22:53:54 | jeremyevans | evan: I'll leave it to you to decide: http://pastie.org/1089381.txt |