Show enters and exits. Hide enters and exits.
| 00:01:46 | evan | brixen: poke. |
| 00:01:51 | brixen | evan: thoughts on how you want to handle "#/[$@{]/".inspect |
| 00:01:52 | brixen | haha |
| 00:01:56 | brixen | yes? |
| 00:02:09 | brixen | the // is not literal in that string |
| 00:02:27 | brixen | "#$" => "\#$" etc |
| 00:02:37 | brixen | this blows our table transform approach |
| 00:02:47 | brixen | unless we make the table 2d or something |
| 00:03:33 | brixen | I'm working on a table-based matcher/helper for these sort of specs |
| 00:11:52 | evan | hm |
| 00:12:14 | evan | well, let me ask my question: |
| 00:12:18 | brixen | k |
| 00:12:30 | evan | why did we decide to use a primitive failure in vm_const_defined_under? |
| 00:12:35 | evan | why not jsut return true or false? |
| 00:12:46 | brixen | hm |
| 00:13:31 | evan | I ask because i'm pretty sure it's the source of a bug |
| 00:13:39 | evan | if it fails, it's trampling on the current exception |
| 00:13:48 | evan | i can fix that by saving the exception to the stack and restoring it |
| 00:14:30 | evan | but it made me wonder why not just return true/false |
| 00:16:10 | brixen | seems like returning true or false would work |
| 00:16:25 | brixen | I can't see a reason for primitive failure reviewing the commits |
| 00:16:56 | evan | you had a reason, i just don't recall what it was |
| 00:16:59 | brixen | because we are not attaching to a method, just calling from the compiler |
| 00:17:36 | brixen | well, it either returns the const, returns the value from const_missing, or ... |
| 00:18:32 | evan | any non-exception is eaten and a string is left for the user |
| 00:30:27 | brixen | evan: this is what I'm thinking about: http://gist.github.com/392864 |
| 00:30:45 | brixen | this would be useful for #pack, #unpack, and #regexp too |
| 00:30:47 | evan | sure |
| 00:31:00 | brixen | I want something inside the it block in case it needs more stuff |
| 00:31:09 | evan | pretty clear that you're saying inspect should transform the left to the right |
| 00:31:16 | brixen | rather than an it_is_computed_xxx like it_behaves_like |
| 00:31:20 | brixen | yeah, exactly |
| 00:31:28 | brixen | I want the side-by-side comparison |
| 00:31:33 | evan | yep. |
| 00:31:36 | brixen | ok |
| 00:32:12 | evan | back to my problem: |
| 00:32:36 | evan | what is value_defined supposed to leave on the stack? |
| 00:32:54 | brixen | the value of the expression |
| 00:33:12 | brixen | but executing the expression may cause an exception |
| 00:33:24 | brixen | which is what the handler is for |
| 00:33:34 | evan | the label passed in is what ya mean |
| 00:33:35 | evan | right? |
| 00:33:38 | brixen | yeah |
| 00:33:47 | brixen | well, let me look |
| 00:34:05 | evan | crap. |
| 00:34:21 | evan | all of these value_defined usages of setup_unwind are buggy |
| 00:34:27 | evan | they all trample on the current exception |
| 00:35:03 | brixen | no, the label passed in is generally for the fail case |
| 00:35:15 | brixen | ie, returning nil from the defined?() |
| 00:35:38 | brixen | the handler block is in case executing expr in defined?(expr) raises |
| 00:36:02 | evan | handler block? |
| 00:36:21 | brixen | eg, constants.rb 53 |
| 00:36:37 | evan | i've been mucking in there |
| 00:36:37 | brixen | that setup_unwind is in case finding the const raises |
| 00:36:42 | brixen | one sec.. |
| 00:36:52 | evan | whats the case where it would raise? |
| 00:37:08 | evan | seems to only be because the vm_const_defined_under raises PrimitiveFailure |
| 00:37:13 | brixen | http://gist.github.com/392874 |
| 00:37:15 | evan | there is no other exception that could come out of there |
| 00:37:23 | brixen | const_missing could raise |
| 00:37:55 | evan | ooh. |
| 00:38:02 | evan | and you shouldn't expose that raise |
| 00:38:03 | evan | right? |
| 00:38:07 | brixen | right |
| 00:38:14 | evan | you should just say "nope, not defined" |
| 00:38:17 | brixen | yes |
| 00:38:23 | brixen | return nil, essentially |
| 00:38:46 | evan | ok |
| 00:38:56 | evan | i'll add the code to prevent the trampeling then |
| 00:39:08 | evan | keeping the setup_unwinds |
| 00:39:11 | brixen | I see the problem with this though |
| 00:39:29 | brixen | returning primitive failure is not == to raising an exception here |
| 00:39:30 | evan | oh? |
| 00:39:39 | evan | it is |
| 00:39:40 | brixen | this gist is better http://gist.github.com/392874 |
| 00:39:43 | evan | because invoke_primitive is used. |
| 00:39:43 | brixen | is it? |
| 00:39:47 | brixen | ahh yes |
| 00:39:47 | brixen | ok |
| 00:39:50 | evan | which raises an exception if the primitive fails |
| 00:39:54 | brixen | man, I was really like wtf was I thinking |
| 00:39:56 | brixen | hehe |
| 00:40:01 | evan | :) |
| 00:40:27 | evan | basically, we have to be careful with exception handlers |
| 00:40:34 | brixen | so, in that gist, if value_defined at line 5 raises, you should end up at 11 |
| 00:40:41 | evan | we've forgot that they can also run in the context of an existing exception |
| 00:40:45 | evan | and need to preserve that. |
| 00:40:46 | brixen | ok |
| 00:41:01 | evan | sure, i follow the control flow fine. |
| 00:41:13 | brixen | ok |
| 00:43:00 | brixen | well, I'm heading out for a ride, but I'll push this spec stuff later |
| 00:43:17 | brixen | not sure what to do with #inspect yet :/ |
| 00:43:32 | evan | so in inspect |
| 00:43:36 | evan | "#" => "#" |
| 00:43:40 | evan | and "#$" => "\#$" |
| 00:43:43 | brixen | yes |
| 00:43:44 | evan | thats the issue, right? |
| 00:43:51 | brixen | #@ and #{ too |
| 00:43:55 | evan | sure sure |
| 00:43:56 | brixen | mri uses IS_EVSTR |
| 00:43:57 | brixen | yeh |
| 00:44:19 | brixen | I should look at transform |
| 00:44:25 | evan | and i'm using my table transformer primitive for this, aren't I? |
| 00:44:25 | brixen | daes it do string match or char match? |
| 00:44:28 | brixen | yes |
| 00:44:51 | brixen | if string match, we can just use "#$" => "\#$" |
| 00:45:14 | evan | feel free to extend it |
| 00:45:27 | evan | it should be easy to add another dimension |
| 00:45:29 | evan | ie |
| 00:46:07 | evan | tbl[?#] = LookupTable.new("#$" => "\#$") |
| 00:46:20 | evan | probably don't want to use a Tuple for the new dimension though |
| 00:46:23 | evan | we'll waste a lot of space |
| 00:46:29 | brixen | that's what I was thinking too |
| 00:46:44 | evan | or use a key, val Tuple |
| 00:46:45 | evan | ie |
| 00:47:03 | evan | tbl[?#] = Tuple.from("#$", "\#$", "#{", "\#{") |
| 00:47:08 | brixen | right, if ?# => Tuple then switch |
| 00:47:09 | brixen | yeah |
| 00:47:27 | evan | thats fine |
| 00:47:36 | evan | probably won't slow down the matcher |
| 00:47:43 | brixen | but that still precludes precalculating the size of the output |
| 00:47:46 | evan | it will be a simple condition in the replacement code |
| 00:47:59 | evan | why? |
| 00:48:13 | brixen | because you don't know yet |
| 00:48:29 | evan | what precalculation code to dyou mean? |
| 00:48:30 | brixen | #x => #x but #$ => \\#$ |
| 00:48:35 | evan | we already support that |
| 00:48:39 | evan | or rather, it does. |
| 00:48:49 | evan | because you can have [?#] = "whatever" |
| 00:49:05 | evan | the keys are always strings of unknown length |
| 00:49:08 | evan | so it should be the same |
| 00:49:17 | evan | brb |
| 00:49:17 | brixen | I'll look at it |
| 00:50:56 | evan | back |
| 00:50:57 | evan | ok |
| 00:55:21 | brixen | the tuple approach would work fine, yes |
| 00:55:30 | brixen | I can do that later unless you want to |
| 01:38:27 | boyscout | Keep the current exception from being trampled on - a3f6a6b - Evan Phoenix |
| 01:48:13 | boyscout | CI: rubinius: a3f6a6b successful: 3457 files, 13581 examples, 41201 expectations, 0 failures, 0 errors |
| 03:58:29 | brixen | 24 mi of fun |
| 03:58:45 | brixen | crazy that it will be 39 F tonight |
| 03:58:59 | brixen | what kind of may is this |
| 16:10:59 | evan | morning. |
| 16:12:29 | brixen | morning |
| 16:13:32 | brixen | evan: was this what you had in mind? http://gist.github.com/393642 |
| 16:14:11 | evan | well, not exactly |
| 16:14:20 | brixen | seems like we should write into a malloc'd buffer that could be reallocted and finally memcpy'd into a ByteArray |
| 16:14:23 | evan | that says, to me, that you replace #$ with \# |
| 16:14:29 | evan | where did the $ go? |
| 16:14:39 | brixen | it's the next char to be processed |
| 16:15:04 | brixen | but yeah, you could consume len of the input str and replace it with the value in the map |
| 16:15:19 | brixen | but that doesn't fundamentally change much |
| 16:15:25 | brixen | I can add that |
| 16:15:47 | brixen | still seems pretty complex |
| 16:17:10 | evan | but more powerful |
| 16:17:12 | evan | imho. |
| 16:17:25 | evan | because it lets you consume N characters at once in the loop |
| 16:17:33 | brixen | that's fine |
| 16:17:40 | brixen | I'm more talking about precalculating the size |
| 16:17:47 | brixen | that seems unnecessarily complex |
| 16:18:02 | evan | ah |
| 16:18:09 | evan | well, how big do you make it then? |
| 16:18:27 | evan | you wanna realloc space if you run out? |
| 16:18:41 | brixen | start with an optimistic guess that that output will be 1-1.25 or something |
| 16:18:44 | brixen | then realloc, yes |
| 16:18:46 | brixen | if needed |
| 16:19:05 | brixen | finally memcpy into a bytearray |
| 16:19:31 | brixen | since you have to cast every key in the table now |
| 16:19:39 | brixen | to make sure it's a String or Tuple |
| 16:19:42 | brixen | then do it again |
| 16:20:00 | evan | sure |
| 16:20:07 | evan | i don't have an issue with doing that |
| 16:20:37 | brixen | I could bench it, but generating realistic strings to test is not real easy |
| 16:20:58 | brixen | like, I don't know how much people are using KCODE=u |
| 16:21:27 | Defiler | I've been setting that as my default for years now |
| 16:21:55 | Defiler | (usually in the actual configure options to MRI, but usually also in rubyopt etc etc) |
| 16:21:57 | brixen | good to know |
| 16:22:19 | evan | brixen: i think doing 1.25x then reallocing if necessary is fine |
| 16:22:27 | evan | doing the strict calculation was originally pretty easy |
| 16:22:30 | brixen | evan: ok |
| 16:22:38 | brixen | yeah, it's much more complicated now |
| 16:22:43 | brixen | that's all I meant |
| 16:38:06 | cremes | does rbx up to date with ffi support? |
| 16:41:18 | brixen | cremes: rbx ffi is not fully compatible with ruby-ffi, no |
| 16:41:39 | brixen | cremes: post 1.0 we will address it |
| 16:42:07 | cremes | okay then i won't list it as compatible with my zeromq ffi bindings yet |
| 16:42:40 | evan | cremes: did you figure out your memory leak? |
| 16:43:08 | cremes | nope, not yet |
| 16:43:21 | cremes | i was hoping to run it under rbx and see if it gave me any insight |
| 16:46:03 | evan | you might as well try it. |
| 16:46:06 | evan | under rbx |
| 16:46:18 | cremes | okay |
| 16:46:19 | evan | seems like you're using the basics of FFI, which rbx supports fine. |
| 16:46:47 | cremes | is there an rbx memory profiler or leak detector? |
| 16:47:22 | brixen | cremes: if you have tests for zeromq, you should definitely run it on rbx |
| 16:47:58 | cremes | brixen: i don't have any tests or specs for it... :( |
| 16:48:05 | brixen | would leaks(1) work for this on os x? |
| 16:48:13 | brixen | cremes: what what wot? :P |
| 16:48:19 | evan | sure |
| 16:48:22 | evan | leaks(1) works |
| 16:48:33 | cremes | i usually write perfect code :-\ |
| 16:48:40 | evan | FRIDAY ZING! |
| 16:48:44 | brixen | cremes: hahah |
| 17:02:34 | cremes | i get an error when trying to install my gem which is dependent on the ffi gem: http://pastie.org/950359 |
| 17:02:56 | cremes | do i need to remove the ffi dependency first? can i make it optional? |
| 17:05:25 | brixen | cremes: I don't know what the error is, can you use -V on install |
| 17:05:34 | evan | you need to remove it. |
| 17:10:08 | cremes | i must be using some new ffi syntax that rbx doesn't like: http://gist.github.com/393723 |
| 17:11:23 | evan | hm, no, thats the same. |
| 17:11:27 | evan | should work fine... |
| 17:13:10 | evan | oh, it's passing an array for ffi_lib |
| 17:13:22 | evan | man, i wish that they hadn't change ruby-ffi so much from my original API |
| 17:14:37 | evan | cremes: i guess ruby-ffi supports passing a array there |
| 17:14:43 | evan | you should be splatting it for compat though |
| 17:14:57 | evan | ie, the ffi_lib api was originally: ffi_lib "this", "that", "other thing" |
| 17:21:52 | rue | I think it was just "this" originally originally |
| 17:24:29 | evan | rue: true |
| 17:38:39 | cremes | it still chokes; it looks like it is loading the lib but now i can't find any functions: http://gist.github.com/393723 |
| 18:08:46 | evan | BOO |
| 18:08:59 | evan | the remove_instance_variable spec is basically empty. :/ |
| 18:09:04 | evan | and we have a bug in it |
| 18:09:10 | evan | well, no time like the present! |
| 18:11:11 | brixen | heh |
| 18:11:23 | brixen | man, how is it empty though |
| 18:11:41 | evan | yeah |
| 18:11:41 | evan | :/ |
| 18:12:07 | brixen | I guess none of the other impls have ever hit a bug in that method |
| 18:12:18 | evan | guess not |
| 18:12:19 | brixen | cus I'm sure they would have contributed some specs for it |
| 18:12:20 | brixen | :/ |
| 18:12:23 | evan | we're returning self |
| 18:12:26 | evan | rather than the deleted value |
| 18:12:42 | brixen | welp, rubyspec wins again |
| 18:12:59 | brixen | ain't nothing like some good tests |
| 19:40:52 | cremes | found my FFI memory leak; it was *my* fault! Yay! |
| 19:42:16 | brixen | sweet |
| 19:53:12 | cremes | still doesn't need specs or tests... |
| 19:56:29 | Defiler | Does Time have an API for asking whether a given string is parseable as a Time object? |
| 19:56:40 | Defiler | or do you really have to do Time.parse(input) rescue nil ? |
| 19:58:24 | evan | pretty sure thats it. |
| 20:07:59 | Defiler | def i_know_and_i_am_sorry;end Time.parse(input) rescue i_know_and_i_am_sorry |
| 20:20:09 | evan | Time.☹parse(input) could be equiv to Time.parse(input) rescue nil |
| 23:33:09 | boyscout | Add spec for sorting a large array - e6bb6eb - Evan Phoenix |
| 23:33:10 | boyscout | Flesh out Kernel#remove_instance_variable spec - 5761bb0 - Evan Phoenix |
| 23:33:10 | boyscout | Fix sorting of a large array with a shifted start - 7bb5b3e - Evan Phoenix |
| 23:33:10 | boyscout | Fix Kernel#remove_instance_variable - c3001bb - Evan Phoenix |
| 23:33:10 | boyscout | Fix checking for if protected is allowed - 673aa09 - Evan Phoenix |
| 23:35:44 | evan | only 2 harmless generator rails 3 tests failing now |
| 23:45:18 | brixen | sweet |
| 23:51:00 | boyscout | CI: Commit 673aa09 failed. http://github.com/evanphx/rubinius/commit/673aa09260403a03a043c75f268818d1f6070fe6 |