Show enters and exits. Hide enters and exits.
| 02:42:20 | manveru | good morning |
| 06:14:09 | manveru | that compile sure takes time |
| 06:15:02 | manveru | i just changed on line in vm/builtin/regexp.cpp and it takes 5 minutes or so :P |
| 06:15:23 | manveru | just to fail and tell me i should've switched to 1.8 first |
| 06:49:06 | manveru | brixen: around? |
| 06:56:03 | manveru | seems like i cannot use rb_const_get in builtin |
| 06:56:11 | manveru | and there is no rb_cRegexp |
| 06:57:02 | manveru | so i have no idea how to get the value of that constant |
| 06:57:42 | manveru | option_mask = rb_const_get(rb_cRegexp, rb_intern("OPTION_MASK")); |
| 06:57:44 | manveru | int result = ((int)onig_get_options(reg) & option_mask); |
| 06:57:47 | manveru | does that look right? |
| 07:06:53 | manveru | brixen: is it possible that the // syntax doesn't call Regexp.new but the C++ function instead? |
| 07:07:23 | manveru | that would explain the weird behaviour of the cgi specs |
| 07:08:46 | manveru | they should be //n but aren't adjusted to the 0 flag by C++, so they have the wrong flag |
| 07:29:30 | manveru | there seems to be a const_get in the helpers.cpp, and rbx_find_const in jit_util.cpp, but i'm not sure how to use either |
| 07:46:33 | dbussink | manveru: you probably should look how the other rb_c* values are defined |
| 07:46:36 | dbussink | manveru: and use that pattern |
| 07:47:33 | manveru | dbussink: but then i still can't use rb_const_get |
| 07:47:37 | dbussink | manveru: you should look at vm/capi/ruby.h and vm/capi/capi.cpp |
| 07:47:49 | manveru | i cannot use the capi in builtin |
| 07:47:56 | manveru | or so the compiler says |
| 07:47:56 | dbussink | manveru: why not? |
| 07:48:01 | manveru | or maybe my C just sucks |
| 07:48:11 | manveru | do i need to include something? |
| 07:48:27 | dbussink | manveru: can you show some code? |
| 07:48:51 | manveru | i pasted the two lines above |
| 07:48:59 | manveru | it's all i added |
| 07:49:13 | manveru | in vm/builtin/regexp.cpp that is |
| 07:49:39 | dbussink | manveru: you're mixing capi stuff and builtin's? |
| 07:49:52 | manveru | i'd like to |
| 07:50:01 | dbussink | that probably won't work |
| 07:50:23 | dbussink | manveru: let me check how to get to that properly |
| 07:51:20 | dbussink | manveru: why don't pass it down as an additional argument in the primitive? |
| 07:51:23 | manveru | dbussink: http://pastr.it/16649 |
| 07:52:18 | dbussink | manveru: it should probably be changed to the options parameter is used properly |
| 07:52:49 | manveru | i have no idea how those primitives work |
| 07:53:05 | manveru | or what holds all that magic fairy dust together |
| 07:53:55 | dbussink | if you look at kernel/common/regexp.rb:64 you see the same method signature as the primitive in vm/builtin/regexp.cpp |
| 07:54:20 | manveru | oh... |
| 07:54:31 | manveru | so you mean i could pass the value of the constant in directly? |
| 07:55:06 | dbussink | manveru: sorry, you should look at kernel/bootstrap/regexp.rb |
| 07:55:17 | dbussink | there you see the compile method which calls Ruby.primitive :regexp_initialize |
| 07:55:38 | dbussink | the arguments to the ruby method there are also the arguments passed down to the primitive |
| 07:56:00 | manveru | also, what is done when // syntax is encountered? |
| 07:57:31 | dbussink | so the fix should probably entail changing kernel/common/regexp.rb to pass in the right arguments to Regexp#compile |
| 07:58:14 | manveru | hm, k |
| 07:58:24 | manveru | i'll try that in a bit, busy with work right now |
| 11:45:18 | rue | manveru: There are a couple potential things you need to check if you mean to add //{g,G} option support. Adding it just for Regexp.new is slightly easier |
| 11:46:10 | rue | First, verify that lib/ext/melbourne/grammar does not restrict the options; same for lib/compiler/ast/literals.rb |
| 11:47:37 | rue | Then kernel/common/regexp.rb handles at least some of the option parsing; kernel/bootstrap/regexp.rb does not do anything but pass the options it has through to the primitive so that is not of much concern |
| 11:49:06 | rue | Then, in regexp.hpp, you see the // Ruby.primitive notation for Regexp::initialize(), which is defined in regexp.cpp |
| 11:50:16 | rue | The last hurdle there is that the OPTS_MASK needs to be changed to allow your option, after that it just gets passed down to onig |
| 12:24:09 | manveru | ah, i was wondering where the syntax is |
| 12:26:20 | manveru | i really don't need the /g syntax itself, just the ability to pass any valid oniguruma flag to Regexp.new |
| 12:27:22 | manveru | right now it's limited to the first 4 flags |
| 12:27:59 | manveru | none = 0, ignorecase = 1, extend = 2, multiline = 4 |
| 12:28:12 | manveru | i think that's how it is at least :) |
| 12:29:29 | manveru | personally i just need to pass the 256 flag, but the flag is going through the mask of 7 |
| 12:32:35 | manveru | anw, i'll see whether i can come up with something patchworthy |
| 12:35:17 | manveru | but apart from /g and /G, i don't know the usual names for the other flags |
| 12:45:26 | manveru | still not sure what mas would be ok to choose |
| 12:45:29 | manveru | *mask |
| 12:53:37 | manveru | hmm |
| 12:54:27 | manveru | so if i have a mask that can represent 11 options, i'd use 1<<11? |
| 12:54:47 | manveru | that way every bit can be 1 if the option is on |
| 12:55:10 | manveru | must be missing something |
| 13:00:24 | manveru | ah, the | combination of all possibilities must be the mask |
| 13:22:51 | manveru | (1<<11) & (2..11).inject(1){|s,n| s | (1<<n) } |
| 13:22:53 | manveru | # 2048 |
| 13:22:56 | manveru | that does the trick |
| 13:34:10 | dbussink | manveru: that's hard to comprehend :) |
| 13:34:21 | dbussink | manveru: what do you want? |
| 13:34:26 | dbussink | manveru: all 1's? |
| 13:36:04 | dbussink | manveru: that's equal to 1 << 11 btw... |
| 15:10:28 | rue | Heh |
| 15:12:28 | rue | Highest option * 2 - 1 also. |
| 17:00:09 | evan | morning |
| 17:01:49 | slava | yo |
| 17:01:56 | rue | Morning |
| 17:02:01 | rue | How was your first ski jumping? |
| 17:02:38 | evan | fun! |
| 17:02:43 | evan | the crowd was the fun part |
| 17:02:49 | evan | the swiss were hilarious. |
| 17:03:12 | rue | Not a terrible competition |
| 17:03:18 | rue | For that matter |
| 17:03:26 | evan | we saw the gold medalist (a swiss) being carried by a bunch of swiss on their shoulders to the swiss house |
| 17:03:46 | evan | while, on top of the house, some guys in leiterhoisen played those big mountain horns |
| 17:04:06 | evan | yeah, the jumps were good. |
| 17:04:12 | evan | the winner was just so much better than anyone else |
| 17:05:03 | slava | evan: I got the raytracer benchmark within 2x of hotspot server the other day |
| 17:05:20 | evan | ah! congrats! |
| 17:05:27 | evan | using your unboxed float array? |
| 17:05:45 | slava | using simd |
| 17:05:59 | evan | do you have specific simd words? |
| 17:06:12 | evan | or can you detect oppertunities to use it from normal math operations |
| 17:06:12 | slava | so the Java version defines a Vec class with float x, y, z members, and methods for adding, scaling, vectors |
| 17:06:41 | slava | my version uses the float-4 type instead defining its own; a float-4 looks like a 4-element array but it gets unboxed into registers |
| 17:07:14 | evan | clever |
| 17:07:20 | slava | we have a library of generic vector math operations; on normal arrays they just go component-wise, on simd types they become machine instructions |
| 17:07:42 | slava | just like generic arithmetic can do bignums and rationals, but is efficient on floats |
| 17:07:42 | evan | gotcha, so the float-4 type is a special simd type |
| 17:07:47 | evan | right |
| 17:07:51 | evan | makes sense |
| 17:07:52 | slava | yeah, and there's also short-8, int-4, etc |
| 17:08:08 | evan | thats rad. |
| 17:09:05 | slava | I don't think hotspot does any vectorization in this benchmark, but it wins because of superior register allocation I think |
| 17:09:21 | slava | when I looked at the factor compiler output for it, it had a lot of spills and reloads in the inner loops |
| 17:09:31 | slava | x86 :( |
| 17:10:13 | evan | :/ |
| 17:10:21 | evan | x86 or x86-64? |
| 17:10:35 | slava | I haven't tried on 64 yet actually -- it should run faster |
| 17:12:31 | brixen | morning |
| 17:12:55 | evan | yeah, i notice he says that linux/x86-32 is the only supported platform |
| 17:44:48 | evan | rue|W: yes, hopefully! |
| 17:45:55 | boyscout | Added specs for masgn with to_ary rhs not calling #to_a. - 3d9fca3 - Brian Ford |
| 17:45:55 | boyscout | Tag a, b = x failures pending decision on new insn. - 802d091 - Brian Ford |
| 17:45:55 | boyscout | Purged tags for non-matching specs. - fefa079 - Brian Ford |
| 17:45:55 | boyscout | Removed tags for passing specs. - 3bab2da - Brian Ford |
| 17:46:22 | brixen | pretty sure I didn't remove any platform sensitive tags, but we'll see what boyscout says |
| 17:49:37 | evan | k |
| 17:50:13 | brixen | running rubyspec on 1.9.2 head to see what I get on os x |
| 17:50:47 | evan | hm, you untagged Process#kill |
| 17:50:53 | evan | I wonder if those are still unstable |
| 17:50:57 | evan | if so, perhaps we should just remove them. |
| 17:51:03 | boyscout | CI: rubinius: 3bab2da successful: 3037 files, 11962 examples, 36256 expectations, 0 failures, 0 errors |
| 17:51:06 | evan | well, nm! |
| 17:51:32 | brixen | heh |
| 17:51:44 | brixen | I think you fixed them up pretty good |
| 17:51:59 | brixen | we'll just keep iterating |
| 17:52:03 | evan | k |
| 17:52:10 | brixen | spec runs for me locally have been very stable |
| 17:52:16 | evan | oh good. |
| 17:52:18 | brixen | we do have an issue with Kernel.abort |
| 17:52:23 | brixen | but that's tagged |
| 17:52:31 | evan | k |
| 17:52:46 | brixen | still 4f/1e for rubyspec on current 1.9 head |
| 17:53:01 | brixen | but that's amazing compared to what it was 6 months ago |
| 17:53:15 | evan | yeah, seriously. |
| 17:54:12 | dbussink | evan: i heard some potentially great news, ben & jerry were on the dutch radio yesterday |
| 17:54:21 | dbussink | evan: and the discussed a certain dutch treat... |
| 17:54:26 | evan | OH |
| 17:54:29 | evan | MY |
| 17:54:31 | evan | LEBRON |
| 17:54:32 | brixen | dbussink: seriously?! |
| 17:54:34 | evan | PLEAOSE SAY IT |
| 17:54:34 | brixen | heh |
| 17:54:36 | evan | PLEEEEEEASE |
| 17:54:42 | dbussink | stroopwafel ice cream! |
| 17:54:48 | evan | YESEEEEEEEEEEEESSSSSSSSSSSSSSSS!!! |
| 17:54:50 | brixen | SHUT UP! |
| 17:54:52 | brixen | haha |
| 17:55:23 | brixen | dbussink: that should lighten you load on US visits, eh :) |
| 17:55:29 | brixen | +r |
| 17:55:37 | dbussink | the biggest problem they saw was keeping the wafel parts crisp but they had some idea already |
| 17:55:50 | brixen | put them in little wrappers |
| 17:55:52 | dbussink | brixen: not if they only sell it here ;) |
| 17:56:03 | brixen | that would make eating it much more involved |
| 17:56:21 | brixen | burn some extra calories and combat the weigt problem in the US :) |
| 17:56:40 | brixen | dbussink: wait what what what? |
| 17:56:48 | brixen | dbussink: are they introducing it in the US or there? |
| 17:57:00 | dbussink | they didn't talk about that |
| 17:57:10 | evan | OH NO |
| 17:57:10 | brixen | oh pshow |
| 17:57:18 | evan | gets on the phone to ben&jerry |
| 17:57:23 | brixen | hahah |
| 17:57:29 | brixen | I was just typing that |
| 17:57:32 | brixen | damn |
| 17:58:10 | evan | brixen: does 1.9 still have #to_splat? |
| 17:58:45 | dbussink | friend of mine is doing some work for shopify in ottawa, also loaded some stroopwafels into his suitcase :) |
| 17:59:09 | brixen | evan: hm, looking |
| 18:00:28 | evan | hm, so with |
| 18:00:30 | evan | x, y = a |
| 18:00:41 | evan | iff a is already an Array is it unpacked |
| 18:00:49 | evan | otherwise, x = a, y = nil |
| 18:01:02 | brixen | yeah |
| 18:01:21 | evan | and x, y = *a |
| 18:01:33 | evan | calls #to_a/#to_ary iff a isn't an Array |
| 18:02:09 | evan | and it raises a TypeError if #to_a/#to_ary don't return an Array |
| 18:02:15 | evan | so we're missing a few things in the specs |
| 18:02:29 | evan | i'm finishing getting the openssl extension in |
| 18:02:36 | evan | then i'll take a look at that. |
| 18:02:48 | brixen | ok |
| 18:02:58 | evan | should be easy. |
| 18:10:35 | brixen | evan: best I can see from changelog, matz changed back to using to_a instead of to_splat in dec 2007 |
| 18:10:49 | evan | yep |
| 18:10:49 | evan | ok |
| 18:10:52 | brixen | testing with a, b = *x on 1.9 head seems to confirm this |
| 18:10:57 | evan | rue|W: nope |
| 18:11:09 | evan | brixen: i'll write a few more specs and get it sorted. |
| 18:11:14 | brixen | evan: ok, cool |
| 18:11:27 | brixen | going to retrieve my watch (hopefully), bbiab... |
| 18:11:36 | evan | k |
| 18:13:51 | evan | the division is certainly confusing |
| 18:19:46 | evan | check the archive, i think it has been. |
| 18:21:57 | evan | in which case? |
| 18:22:41 | evan | ah |
| 18:22:46 | evan | perhaps thats a clarification of the 1.8 behavior then. |
| 18:30:21 | evan | ok |
| 18:58:20 | manveru | dbussink: yeah... found that out too, but that was the way i was coming up with the solution |
| 18:59:35 | manveru | 1.9 BasicObject is so nice to find out what methods are called exactly :) |
| 19:08:02 | manveru | i'm happily hacking the syntax right now |
| 19:08:58 | manveru | never seen the /o option before... |
| 19:13:51 | manveru | and the specs for // and //o seem identical |
| 19:14:40 | rue | /o is once-only |
| 19:15:38 | manveru | it's the same flag as DONT_CAPTURE_GROUP |
| 19:16:21 | manveru | so i'm pondering what to do with it, as it seems to have no specs and no difference in behaviour |
| 19:16:58 | rue | ...It is? |
| 19:17:21 | rue | I never bothered with it, but there was some definite difference |
| 19:17:24 | manveru | well, oniguruma obviously has different flags than original ruby |
| 19:17:53 | rue | I assume it compiles the regexp once, which would affect interpolation and such |
| 19:19:28 | manveru | yeah... |
| 19:19:41 | manveru | the flag is 128, the mask is 7... |
| 19:19:57 | manveru | so it's ignored when passed to Regexp.new |
| 19:20:13 | manveru | makes sense in that case, i guess |
| 19:20:40 | evan | /o means expand it the first time only |
| 19:20:41 | evan | like |
| 19:21:00 | evan | def foo(a); /thing #{a}/o.match("hello"); end |
| 19:21:09 | evan | only one Regexp object is created |
| 19:21:35 | manveru | ? |
| 19:21:45 | evan | /o isn't a flag that effects the internal structure of the Regexp object itself |
| 19:21:55 | evan | just one that governs when it's created |
| 19:22:07 | evan | manveru: make sense? |
| 19:22:26 | manveru | well... it's created when it's encountered... same as normal? |
| 19:22:35 | evan | no |
| 19:22:44 | evan | well, it's created when it's encourtered |
| 19:22:46 | evan | but then memoized |
| 19:22:54 | evan | so future calls to foo use the same regexp as the first time |
| 19:23:08 | evan | ie, only the first a is used |
| 19:23:21 | evan | this is common when you're using a constant in a regexp |
| 19:23:22 | evan | like |
| 19:23:34 | evan | /#{SOME_PREFIX}*/o.match(str) |
| 19:23:40 | manveru | oh... |
| 19:23:47 | evan | you don't need to be creating a new Regexp everytime you hit that line |
| 19:24:03 | evan | so you can use /o to say "memoize the resulting regexp the first time" |
| 19:24:10 | manveru | ok, makes sense then |
| 19:24:21 | manveru | i've never seen or heard that option |
| 19:24:30 | rue | It is "somewhat" rarely used |
| 19:24:30 | evan | it's rarely used. |
| 19:24:36 | evan | but nice to have. |
| 19:24:47 | manveru | we need a spec for that |
| 19:24:54 | evan | we have one |
| 19:25:16 | evan | oh oh |
| 19:25:18 | evan | you're right |
| 19:25:29 | evan | someone used /o in a context that it's useless |
| 19:25:30 | evan | ha. |
| 19:25:45 | evan | in "/x/o" |
| 19:25:50 | manveru | yeah |
| 19:25:51 | evan | the /o is ignored |
| 19:25:57 | evan | because the regexp is already constant |
| 19:26:07 | manveru | as i said, the // spec equals the //o spec |
| 19:26:17 | evan | yep |
| 19:26:30 | evan | oh actually |
| 19:26:32 | evan | we do have as pec for this |
| 19:26:35 | evan | a spec |
| 19:26:39 | evan | it's in dregx_spec |
| 19:26:46 | evan | because /x #{a}/ is a dregx |
| 19:26:50 | evan | not a regx |
| 19:27:50 | manveru | all i can see is that it creates one, but doesn't check that it only creates it once |
| 19:28:13 | manveru | maybe i just don't know how to read those specs |
| 19:28:20 | evan | what specs are you looking at? |
| 19:28:34 | manveru | spec/compiler/dregx_spec.rb |
| 19:28:44 | evan | line 77 |
| 19:28:54 | evan | see the memoize helper? |
| 19:29:08 | manveru | yeah |
| 19:29:15 | evan | thats the difference |
| 19:29:27 | manveru | alright |
| 19:29:29 | evan | the memoize helper is the specs emits the code to save the top of the stack into a literal |
| 19:29:57 | manveru | so can i change the flag value? |
| 19:30:04 | evan | ? |
| 19:30:08 | evan | i need more context. |
| 19:30:12 | manveru | oh |
| 19:30:29 | manveru | well, oniguruma uses the flags up to 1<<11 |
| 19:30:46 | evan | ok.... |
| 19:30:46 | evan | so? |
| 19:30:50 | evan | is there a spec failure? |
| 19:30:57 | manveru | so this conflicts with an oniguruma flag that i'd like to expose |
| 19:31:11 | evan | what does? |
| 19:31:21 | manveru | RE_OPTION_ONCE |
| 19:31:29 | evan | conflicts how? |
| 19:31:31 | evan | where? |
| 19:31:40 | evan | /o isn't IN the Regexp at all. |
| 19:31:49 | manveru | it conflicts with ONIG_OPTION_DONT_CAPTURE_GROUP |
| 19:31:56 | evan | i don't understand |
| 19:32:00 | evan | how can it? |
| 19:32:08 | manveru | it has the same value |
| 19:32:11 | evan | where? |
| 19:32:14 | evan | the same value where? |
| 19:32:20 | manveru | in C, i guess |
| 19:32:25 | evan | no |
| 19:32:26 | evan | i mean |
| 19:32:30 | evan | where do you see it having the same value? |
| 19:32:35 | evan | Regexp#options ? |
| 19:32:49 | manveru | #define RE_OPTION_ONCE 0x80 |
| 19:33:10 | evan | Rubinius doesn't have a RE_OPTION_ONCE |
| 19:33:14 | evan | so i don't know what that means |
| 19:33:21 | manveru | it doesn't? |
| 19:33:25 | evan | course not. |
| 19:33:34 | evan | thats what i've been saying |
| 19:33:38 | manveru | it's in lib/ext/melbourne/grammar.cpp |
| 19:33:42 | evan | /o is handled entirely in bytecode |
| 19:34:27 | manveru | rue told me before i could change the grammar there to add the /g and /G flags |
| 19:34:28 | evan | ah, i guess the parser uses that to figure out if it should use dregx or regx |
| 19:34:36 | manveru | exactly |
| 19:34:48 | evan | you don't need to change anything |
| 19:34:52 | evan | it would be a pure addition |
| 19:34:59 | manveru | so it's used internally only, but goes into the same options value |
| 19:35:17 | evan | don't use the exact value of ONIG_OPTION_DONT_CAPTURE_GROUP in here |
| 19:35:21 | evan | use a different value |
| 19:35:25 | manveru | ok |
| 19:35:26 | evan | and translate it back later. |
| 19:35:43 | manveru | it's never seen through .options anyway |
| 19:35:53 | evan | right |
| 19:35:55 | evan | i wouldn't expect so |
| 19:36:19 | manveru | sorry... those are my first attempts at writing some c |
| 19:36:31 | manveru | and that for rbx... i must be insane |
| 19:36:46 | evan | heh |
| 19:36:55 | evan | what does ONIG_OPTION_DONT_CAPTURE_GROUP do? |
| 19:37:14 | manveru | it equals the /G flag |
| 19:37:43 | evan | i don't know what /G does either. |
| 19:37:45 | manveru | err |
| 19:37:46 | evan | tell me. |
| 19:37:48 | manveru | sorry, /g |
| 19:37:56 | evan | i don't know what /g does. |
| 19:38:00 | manveru | http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt |
| 19:38:08 | manveru | see at point 10 |
| 19:39:24 | manveru | it makes it possible to use named groups inside (?:) or avoid capture groups in () |
| 19:39:36 | brixen | evan: have you made any changes to language/variables_spec.rb? |
| 19:39:43 | evan | no |
| 19:39:45 | brixen | k |
| 19:39:58 | brixen | I'll push this spec then, a, b = x calls #to_ary on x |
| 19:40:12 | brixen | it does not call #to_a if #to_ary is undefined |
| 19:40:13 | evan | k |
| 19:40:21 | evan | brixen: did you get your watch? |
| 19:40:28 | brixen | yep! amazing |
| 19:40:32 | brixen | someone turned it in |
| 19:40:35 | evan | oh good. |
| 19:40:37 | manveru | evan: should i change the grammar.y or grammar.cpp ? |
| 19:40:41 | brixen | yeah, very nice of them |
| 19:40:41 | evan | .y |
| 19:40:45 | evan | never change grammar.cpp |
| 19:40:47 | evan | it's autogenerated. |
| 19:40:55 | manveru | oh, ok |
| 19:41:22 | manveru | grammar.y still has copyright by matz :) |
| 19:41:30 | brixen | manveru: but you include the changes to grammar.cpp in your patch, we check that into the repo |
| 19:41:32 | evan | as it should, he wrote it! |
| 19:42:45 | manveru | but it's the only one |
| 19:42:55 | evan | manveru: \g is for recursive regexps, yes? |
| 19:43:20 | manveru | evan: yes |
| 19:43:27 | evan | manveru: whats the only one? |
| 19:43:39 | manveru | the only copyright |
| 19:44:08 | evan | oh well |
| 19:47:04 | manveru | ok... let's try that |
| 19:47:04 | boyscout | Spec for a, b = x calling #to_ary on x. - 1249b2a - Brian Ford |
| 19:47:22 | brixen | evan: that spec is already in the variables_spec.rb file, but I'm not rewriting the crazy spec it's in atm |
| 19:47:34 | evan | k |
| 19:47:37 | brixen | so I just added it to the block of specs I pushed earlier |
| 19:47:39 | evan | thats a good policy. |
| 19:48:27 | brixen | for reference, the crazy spec is lines 441-490 |
| 19:51:56 | evan | i'm getting a spec failure in a rexml spec... |
| 19:52:11 | boyscout | CI: rubinius: 1249b2a successful: 3037 files, 11963 examples, 36259 expectations, 0 failures, 0 errors |
| 19:52:19 | brixen | hm, I may have seen a random one there recently actually |
| 19:52:23 | brixen | what's it look like? |
| 19:52:31 | evan | this is pretty regular |
| 19:52:36 | evan | it's related to something being frozen |
| 19:52:42 | evan | REXML::Element#cdatas freezes the returned array FAILED |
| 19:52:48 | brixen | weird |
| 19:53:02 | brixen | 64bit issue? |
| 19:53:19 | evan | hm. |
| 19:53:38 | brixen | i'm booting my ubuntu 64bit vbox |
| 19:53:46 | manveru | uh, oh |
| 19:53:54 | manveru | seems like i caused a segv |
| 19:54:03 | evan | brixen: hm |
| 19:54:07 | brixen | manveru: you're fired :) |
| 19:54:20 | evan | ok, i get it if i run 'ci net/telnet rexml' |
| 19:54:59 | evan | hrmph. |
| 19:55:06 | manveru | what does 1L mean in c? |
| 19:55:08 | evan | it disappears in some cases. |
| 19:55:14 | evan | manveru: 1 as a long |
| 19:55:23 | manveru | and how long is a long? |
| 19:55:38 | evan | long enough. |
| 19:55:51 | manveru | ok... |
| 19:55:51 | evan | 32bits on 32bit platform, 64bits on 64bit platform |
| 19:56:08 | evan | you rarely write 1L |
| 19:56:15 | evan | usually just long i = 1; |
| 19:56:20 | evan | or whatever. |
| 19:57:01 | manveru | #define RE_OPTION_IGNORECASE (1L) |
| 19:57:09 | manveru | that's the starting point |
| 19:57:19 | manveru | so i assume the <<1 use the same type |
| 19:57:22 | evan | don't worry about it. |
| 19:57:29 | manveru | ok |
| 19:57:31 | brixen | evan: btw, we need to push an rc3 tag but I'm not sure which commit you want to tag |
| 19:57:43 | evan | oh did I dont? |
| 19:57:47 | evan | oops. |
| 19:57:51 | brixen | heh |
| 19:57:56 | brixen | someone noticed yesterday |
| 19:58:21 | evan | ok, pushed. |
| 19:58:28 | evan | the tag is at the right place |
| 19:58:34 | evan | i just forgot to use 'git push --tags' |
| 19:58:52 | manveru | alright... all of the URI specs fail |
| 19:59:12 | manveru | pretty much every spec that uses regexp |
| 19:59:25 | manveru | lovely |
| 19:59:31 | evan | you made it run |
| 19:59:35 | evan | thats a step in the right direction |
| 19:59:39 | evan | whats your diff look like? |
| 19:59:52 | rue | Also, clear out all .rbc |
| 20:00:38 | manveru | http://pastr.it/16650 |
| 20:01:08 | evan | ug. |
| 20:01:08 | manveru | cleaned... rebuilding... |
| 20:01:25 | evan | you put a change in between white space change lines |
| 20:01:28 | evan | so hard to read |
| 20:01:54 | manveru | a change? |
| 20:02:11 | evan | and why did you change all the names of those options? |
| 20:02:44 | manveru | the ones used elsewhere in rubinius are the same |
| 20:02:55 | manveru | and the other ones now relate 1:1 to the oniguruma options |
| 20:03:20 | evan | i don't care about that |
| 20:03:21 | evan | at all. |
| 20:03:30 | evan | the parser is not tied to onigurama |
| 20:03:41 | evan | and if you could change the names of those #defines and not change anything else |
| 20:03:44 | evan | they should be deletede |
| 20:03:49 | evan | not just changed. |
| 20:04:21 | manveru | ok |
| 20:04:30 | manveru | they aren't used in the grammar |
| 20:04:34 | evan | delete them. |
| 20:04:34 | manveru | or anywhere |
| 20:04:53 | evan | grammar is purposely entirely isolated |
| 20:05:15 | evan | the regexp options are not entirely isolated though |
| 20:05:23 | evan | because just the numeric value is passed out |
| 20:05:32 | manveru | yeah |
| 20:05:36 | evan | so if you reorder that list |
| 20:05:39 | evan | you'll break stuff |
| 20:05:52 | manveru | but i'll use only those that the grammar cares about with the values oniguruma expects |
| 20:06:10 | manveru | is that better? |
| 20:06:19 | evan | i don't understand what you mean |
| 20:06:29 | manveru | one second |
| 20:06:39 | evan | do not change the values of #defines that are used in regexp options in grammar.y |
| 20:07:01 | evan | because those values are or'd together and the kernel expects certain bits to mean certain things |
| 20:07:15 | manveru | yeah |
| 20:07:30 | manveru | but kernel masks everything with 7 |
| 20:07:53 | manveru | so right now the higher flags just get lost |
| 20:07:53 | evan | thats fine |
| 20:07:57 | evan | don't change the low bits then. |
| 20:08:06 | manveru | yeah |
| 20:08:07 | evan | adding new set bits is ok |
| 20:08:11 | manveru | the low bits are identical |
| 20:08:16 | evan | but don't change the ones that are expected |
| 20:26:08 | manveru | sweet, lots and lots of dots |
| 20:26:19 | manveru | 3037 files, 11916 examples, 36160 expectations, 0 failures, 0 errors |
| 20:28:01 | manveru | now these options just need to be allowed in the regexp initialize... that's the tricky part |
| 20:28:30 | manveru | doing that tomorrow... it's almost 6am here |
| 20:28:39 | manveru | err, today, but after sleeping |
| 20:28:59 | manveru | http://pastr.it/16651 |
| 20:29:24 | evan | :D |
| 20:29:25 | evan | nite |
| 20:29:51 | manveru | thanks for all the help |
| 20:29:55 | evan | no prob. |
| 20:31:49 | evan | yay |
| 20:31:55 | evan | solved the random non-frozen problem |
| 20:32:05 | evan | seems that when i moved those flags to the header |
| 20:32:13 | evan | i wasn't copying them when i moved the object around! |
| 20:32:14 | evan | oops. |
| 20:33:29 | dbussink | evan: ah, i've seen those failures too :) |
| 20:34:18 | brixen | heh oops |
| 20:34:48 | evan | at least it was something easy. |
| 20:35:15 | evan | i think i need to redo object copying a little bit today |
| 20:35:22 | evan | there are a bunch of overlapping methods |
| 20:38:40 | evan | yeah |
| 20:38:49 | evan | moving an object from one address to another |
| 20:38:54 | evan | oh move. |
| 20:38:58 | evan | thats what i should call these methods. |
| 20:39:27 | evan | as opposed to creating a copy |
| 20:39:39 | evan | ug. |
| 20:39:42 | evan | EBADF |
| 20:39:43 | evan | :( |
| 20:43:43 | brixen | I think the IO specs that call IO.new(2) have to be changed |
| 20:44:06 | brixen | in fact, I don't know if we can spec IO.new |
| 20:45:02 | brixen | evan: are you following [ruby-core:28281] ? |
| 20:45:28 | evan | checking now. |
| 20:46:55 | evan | i see it |
| 20:46:55 | evan | yes |
| 20:47:00 | evan | i think that IO.new can't be spec'd then. |
| 20:47:11 | brixen | seems that way |
| 20:47:52 | brixen | at the same time, that seems sooo crazy |
| 20:48:03 | brixen | "here's some methods, they do things" |
| 20:51:27 | brixen | grabbing food, bbiab.. |
| 20:58:52 | dbussink | brixen: hmm, dangerous remark in the announcement that 1.9.2-trunk passes rubyspec that reminds of discussions that already took place on implementation details |
| 20:59:50 | brixen | dbussink: yeah, I was working on a response |
| 21:11:39 | boyscout | Begin pulling in the OpenSSL CAPI extension - fe79104 - Evan Phoenix |
| 21:11:39 | boyscout | Fix building the OpenSSL extension - efc231b - Evan Phoenix |
| 21:11:39 | boyscout | Force some regexp's to be in Ascii - 9d35459 - Evan Phoenix |
| 21:11:39 | boyscout | Add a reminder to update @config_version - eb135f8 - Evan Phoenix |
| 21:11:39 | boyscout | Fix copying Frozen and Tainted flags - 1ec70fc - Evan Phoenix |
| 21:11:39 | boyscout | Merge branch 'master' of git@github.com:evanphx/rubinius - 6be9d2a - Evan Phoenix |
| 21:18:08 | dbussink | evan: are you also testing with openssl 1.0 btw? |
| 21:18:19 | dbussink | evan: seen some activity on that recently in ruby-core |
| 21:18:48 | evan | kendall :: git/rbx ยป openssl version |
| 21:18:49 | evan | OpenSSL 0.9.8k 25 Mar 2009 |
| 21:18:53 | evan | ok, lunch time! bbiab. |
| 21:21:31 | boyscout | CI: rubinius: 6be9d2a successful: 3037 files, 11963 examples, 36259 expectations, 0 failures, 0 errors |
| 21:44:22 | Defiler | openssl 1.0 is a tricky upgrade |
| 21:44:39 | Defiler | They suddenly made the data structure everybody was using private |
| 21:44:56 | dbussink | well, hence my question |
| 21:45:22 | dbussink | Defiler: you are everywhere! ;) |
| 21:46:15 | Defiler | I AM THE NETWORK |
| 21:46:16 | Defiler | I mean yo |
| 21:49:49 | Defiler | http://25.media.tumblr.com/tumblr_kx7ugsKVbK1qz4crmo1_500.jpg |
| 21:49:57 | Defiler | ya know what I'm saying |
| 21:51:09 | BrianRice-work | hah! |
| 21:53:00 | brixen | heh |
| 21:55:00 | evan | Defiler: openssl is the worst API known to man |
| 21:55:08 | evan | so i'm surprised it doesn't break every version. |
| 21:55:46 | Defiler | It's like sitting down in a car that has four differently-sized bags of confetti instead of a steering wheel and pedals |
| 21:55:50 | evan | at lunch today i was thinking that someone should write an sanessl lib |
| 21:55:57 | evan | that is a wrapper for OpenSSL |
| 21:56:03 | evan | that has a normal, sane C API |
| 21:56:05 | Defiler | word |
| 21:57:04 | testerjoe | hm, even JRuby has jruby-openssl - why is there no generic crypto API for Ruby? - just curios |
| 21:57:28 | Defiler | ruby isn't big on generic interfaces that don't arise naturally out of competition |
| 21:57:31 | Defiler | Is my take on it |
| 21:58:17 | Defiler | it would be cool to have a nice high-level crypto middleware though |
| 21:58:27 | testerjoe | I'm just missing something like Java JCE which works on MRI and JRuby and... |
| 21:58:35 | evan | OpenSSL is actually pretty generic |
| 21:58:42 | Defiler | Yeah, ruby just uses openssl for that |
| 21:58:50 | evan | it hides a number of weird things about openssl, the C library. |
| 21:58:51 | Defiler | since it supports all the common crypto interchanges |
| 21:59:05 | evan | enough that jruby can present the same API and use the java crypto libs |
| 21:59:17 | evan | testerjoe: use OpenSSL for that. |
| 21:59:19 | evan | it's generic. |
| 21:59:24 | evan | just with a non-generic name. |
| 21:59:39 | evan | like buying Vodka brand Vodka. |
| 21:59:52 | testerjoe | yeah, maybe just I'm irritated by sseing OpenSSL in every Ruby impl. |
| 22:00:00 | testerjoe | the generic Digest interface I like :-) |
| 22:00:02 | evan | why irrated? |
| 22:00:12 | Defiler | Just pretend it is called ruby_crypto |
| 22:00:19 | testerjoe | will do :-) |
| 22:00:21 | Defiler | and that it is part of the API implementations are expectd to conform to |
| 22:00:23 | evan | require 'openssl' |
| 22:00:32 | evan | RubyCrypto = OpenSSL |
| 22:00:33 | evan | done! |
| 22:00:39 | testerjoe | he |
| 22:01:15 | Defiler | Though knowing ruby it would probably be called H4x0r |
| 22:01:59 | evan | heh |
| 22:03:08 | testerjoe | something completly different: Rubinius 1.9 support is... one_nine branch? |
| 22:03:17 | evan | yeah |
| 22:03:27 | evan | I need to merge it though |
| 22:03:31 | evan | but generally, yes. |
| 22:03:33 | testerjoe | how far is 1.9? I'm mainly need encoding stuff |
| 22:03:46 | evan | barely started. |
| 22:03:52 | testerjoe | ah, ok :-/ |
| 22:16:38 | brixen | heh configurator :) |
| 22:16:53 | brixen | openssl build is noisy |
| 22:17:18 | evan | i know. |
| 22:17:23 | evan | but at least it builds! |
| 22:17:43 | brixen | yes! |
| 22:18:28 | brixen | should we be checking in extconf.h |
| 22:18:37 | evan | no |
| 22:18:39 | evan | are we? |
| 22:18:41 | brixen | yeah |
| 22:18:42 | evan | thats a bug on my part if so. |
| 22:18:45 | brixen | k |
| 22:18:56 | brixen | want me to remove it or you? |
| 22:19:21 | evan | go ahead |
| 22:19:33 | brixen | k |
| 22:20:10 | evan | in this expression |
| 22:20:14 | evan | a, b = c.d |
| 22:20:45 | evan | the expression on the rhs of the = would be refered to as: |
| 22:20:59 | evan | multiple_return_value? |
| 22:21:09 | evan | i'm trying to figure out what to call this instruction |
| 22:21:34 | brixen | hmm |
| 22:21:43 | Defiler | multiple_return_source |
| 22:21:54 | brixen | masgn_rhs |
| 22:22:11 | evan | multi_value |
| 22:22:11 | evan | ? |
| 22:22:12 | brixen | evan: you don't mean only c.d but any masgn rhs right? |
| 22:22:20 | evan | brixen: yes. |
| 22:22:22 | brixen | multi_value is good |
| 22:22:32 | brixen | masgn_value ? |
| 22:22:39 | evan | ok, so, cast_multi_value or make_multi_value? |
| 22:22:53 | evan | i prefer multi_value to masgn anything |
| 22:22:55 | brixen | it's more a cast than a make I think |
| 22:23:03 | evan | so cast_multi_value |
| 22:23:04 | brixen | since it may not change the value |
| 22:23:05 | Defiler | masgn would be a bad name for it |
| 22:23:07 | evan | right |
| 22:23:08 | brixen | sounds good to me |
| 22:23:09 | evan | k |
| 22:23:15 | Defiler | because this is quite specifically about a thing that happens prior to masgn |
| 22:23:23 | brixen | Defiler: good point |
| 22:23:24 | Defiler | it would be like, actively misleading to put masgn in the name |
| 22:23:47 | brixen | Defiler: it's the value to be masgned, but I get your point |
| 22:35:33 | boyscout | Removed extconf.h from openssl. - 88edf9a - Brian Ford |
| 22:44:18 | dbussink | "No rule to make target `extconf.h', needed by `openssl_missing.o'" |
| 22:44:25 | brixen | arg, I did a build, clean build, and distclean build successfully but now it's complaining about not finding extconf.h ? |
| 22:44:41 | evan | don't worry |
| 22:44:42 | brixen | dbussink: yeah, just got that too after switching back to my topic branch |
| 22:44:47 | evan | thats just a make screwup |
| 22:44:52 | boyscout | CI: Commit 88edf9a failed. http://github.com/evanphx/rubinius/commit/88edf9a7eaf5a34c7f9e20046e7c9e1a90ba75a8 |
| 22:44:56 | evan | ack |
| 22:45:02 | evan | git removed the generated extconf.h |
| 22:45:11 | evan | and extconf.rb isn't being rerun |
| 22:45:14 | evan | because Makefile is already there |
| 22:45:34 | brixen | hmm |
| 22:45:39 | evan | easy fix is to change extensions.rake |
| 22:45:47 | evan | to run extconf.rb is Makefile or extconf.h are missing |
| 22:45:54 | evan | er. |
| 22:45:57 | evan | if Makefile or ... |
| 22:46:32 | brixen | k |
| 22:50:19 | agib | sorry if this is an out of place question, but I don't know where to turn... I can't for the life of me figure out why I'm getting these weird thread exceptions: https://gist.github.com/5f3ef687e2d4c3516d6f#file_workling_deadlock.output -- threaded_poller.rb fails silently without the puts statements on threaded_poller.rb:29... and fails loudly with it.. |
| 22:50:31 | agib | anyone know where I can dig? |
| 22:51:27 | evan | agib: this is running under rubinius? |
| 22:51:30 | rue | On Rubinius? |
| 22:51:34 | agib | REE |
| 22:51:41 | evan | why would we know? |
| 22:51:48 | evan | sorry, no idea. |
| 22:52:02 | rue | Could dig a shallow grave, dump REE in it |
| 22:52:07 | agib | haha |
| 22:52:10 | agib | kk no worries -- just thought I'd try... |
| 22:52:22 | rue | Pretty sure there is a #ree or #passenger? |
| 22:52:58 | agib | kk I'll check -- those are usually really quiet |
| 22:54:48 | boyscout | Fix building ext if extconf.h is missing but Makefile exists. - fd49c2d - Brian Ford |
| 22:57:55 | brixen | avoiding File.exists? and File.directory? etc in rakefiles was one reason I attempted to rewrite the ext building stuff in the first place |
| 22:58:18 | brixen | alas, as good as rake is, it is not a build tool |
| 22:58:23 | brixen | not sure what it is actually |
| 22:59:06 | rue | Rake has file and directory tasks? |
| 22:59:11 | rue | Or rules |
| 22:59:22 | brixen | yes, indeed it does |
| 23:00:20 | rue | Using the methods seems an instance of doing it wrong...Rake is, perhaps surprisingly, intended specifically as a Make replacement after all |
| 23:01:16 | brixen | of course it's doing it wrong, until that's the only thing you can do |
| 23:01:28 | brixen | which was my initial point after all |
| 23:01:55 | boyscout | CI: rubinius: fd49c2d successful: 3037 files, 11963 examples, 36259 expectations, 0 failures, 0 errors |
| 23:04:15 | rue | My point, me being entirely unaware of the finer details of the genesis of your point, is that someone using those methods does not mean Rake is not a build tool |
| 23:08:49 | evan | it's got major issues are a large scale build tool |
| 23:08:55 | evan | that we've been dealing with for years. |
| 23:10:52 | rue | I think it is fair to say that Rake has major issues in applications other than a straightforward build tool |
| 23:11:29 | rue | Than as* |
| 23:11:32 | Defiler | rake is the devil :( |
| 23:11:44 | Defiler | I am thinking of switching to what Unicorn does for my own stuff |
| 23:12:01 | evan | what does Unicorn do? |
| 23:12:02 | Defiler | (run test/spec suite via gnu make instead of rake, and never load rubygems) |
| 23:12:17 | Defiler | so they can just do make -j4 and run their tests on 4 cores |
| 23:13:20 | evan | *eyeroll* |
| 23:13:36 | rue | The problem is not so much that Rake cannot hack building, it is that it is being used for purposes other than that :) |
| 23:13:46 | Defiler | right |
| 23:13:51 | brixen | it cannot hack building period |
| 23:13:56 | Defiler | it works great for 'turn .foo files into .zazz files' |
| 23:14:16 | evan | rake's dependencies resolution is pretty busted |
| 23:14:21 | evan | thats the source of our problem. |
| 23:14:32 | Defiler | it really doesn't have anything that you could call a 'dependency resolver' |
| 23:14:46 | evan | thats why you can'd do |
| 23:14:47 | Defiler | It just follows things as it runs into them and tries to just run them once |
| 23:14:48 | evan | rake clean build |
| 23:14:56 | evan | rake loses it's shit |
| 23:16:25 | maharg | make is the worst build tool except for all the others |
| 23:24:33 | brixen | evan: if I have 2 threads (according to gdb), should they both be in ___spin_lock () at the same time? |
| 23:24:43 | evan | maybe? |
| 23:24:50 | evan | you can get the backtraces of both them |
| 23:24:51 | brixen | hmm |
| 23:24:53 | evan | using info thread |
| 23:24:53 | brixen | yeah |
| 23:24:56 | brixen | sec |
| 23:25:33 | brixen | http://gist.github.com/314012 |
| 23:26:04 | evan | hm |
| 23:26:07 | evan | doesn't seem right |
| 23:26:14 | brixen | yeah |
| 23:46:25 | Defiler | everything was 0x0 once, and to 0x0 all shall return |
| 23:47:04 | brixen | unless your name is hey seuss |
| 23:47:17 | brixen | or so they tell me |