Show enters and exits. Hide enters and exits.
| 00:09:07 | brixen | unpack X* is just bazinga dinga |
| 00:10:22 | evan | bazinga dinga? |
| 00:11:25 | brixen | yeah, that's MRI dialect for "you so fucking crazy" |
| 00:11:37 | evan | aah. |
| 00:13:35 | evan | i have no clue why X and x are even in there |
| 00:13:40 | evan | why would you want to skip backward? |
| 00:14:04 | evan | to interprete the same bytes as 2 different types? |
| 00:14:25 | brixen | who knows |
| 00:14:30 | brixen | ask Larry |
| 00:15:29 | evan | wait |
| 00:15:33 | evan | what does X* do? |
| 00:15:36 | evan | go to the beginning? |
| 00:15:42 | brixen | if you are at the end |
| 00:15:47 | brixen | but it doesn't really |
| 00:16:06 | brixen | eg "abc".unpack('C*X*C') |
| 00:16:14 | brixen | it's just stupid |
| 00:16:40 | brixen | basically, raises an ArgumentError unless you are at the end, then no-op |
| 00:19:47 | brixen | ah yes, I get this code now |
| 00:21:09 | brixen | it's even dumber |
| 00:21:21 | evan | rad. |
| 00:21:37 | brixen | X* backs up the delta between where you are now and the end of the string |
| 00:22:45 | brixen | ie "abcd".unpack('C3X*C') == 'C3X1C' |
| 00:23:02 | evan | @_o |
| 00:23:07 | brixen | yeah |
| 00:23:15 | brixen | puts gun to head |
| 00:30:43 | brixen | the existing spec for this behavior (vaguely accurate) was buried in: String#unpack with 'a', 'X' and 'x' directives returns an array by decoding self according to the format string |
| 00:30:59 | brixen | basically, it "does correctly" |
| 00:31:16 | brixen | win |
| 00:31:22 | evan | :/ |
| 01:29:07 | boyscout | Specs for String#unpack @Xx. - 7246b8f - Brian Ford |
| 01:29:07 | boyscout | String#unpack @Xx. - 69d4c72 - Brian Ford |
| 01:29:07 | boyscout | Specs for Array#pack AaZ. - 7880624 - Brian Ford |
| 01:29:07 | boyscout | Array#pack AaZ. - 6fcddfe - Brian Ford |
| 01:29:07 | boyscout | Benchmark for Array#pack AaZ. - 6120ef0 - Brian Ford |
| 03:50:48 | boyscout | Fix for the following Marshal.load specs: - 06919d8 - Jose Narvaez |
| 03:50:48 | boyscout | Remove tags for passing Marshal.load specs - b5f0a3a - Jose Narvaez |
| 03:59:49 | goyox86 | fades |
| 04:29:17 | cremes | brixen: your work on pack/unpack is superlative... many thanks |
| 04:33:00 | brixen | cremes: thank you! |
| 04:33:08 | brixen | it's moving along |
| 04:33:13 | brixen | specs are the hardest part |
| 04:33:32 | brixen | once I get them cleaned up or added, the implementation has been pretty straightforward |
| 05:27:38 | brixen | evan: so I has an issues |
| 05:27:44 | evan | k |
| 05:27:46 | evan | wassup |
| 05:27:52 | brixen | http://gist.github.com/493523 |
| 05:27:58 | brixen | see the 14 sec entries |
| 05:28:09 | brixen | according to shark, 0.4% of that is Array::pack |
| 05:28:23 | brixen | the rest is mostly _memcpy |
| 05:28:42 | brixen | because pack is called with a 86,580 char directives string |
| 05:29:02 | brixen | which I make a std::string to be GC safe and cleaned up when the scope exits |
| 05:29:49 | evan | ok |
| 05:29:54 | evan | you can save the shark output as text |
| 05:29:55 | evan | do so |
| 05:29:58 | evan | so I can see. |
| 05:30:16 | brixen | I can just cp the session file to elle right? and you could load it? |
| 05:30:21 | evan | no |
| 05:30:22 | evan | it's huge. |
| 05:30:29 | evan | just save to text so I can see the output |
| 05:30:47 | brixen | it's only 2541102 |
| 05:31:02 | evan | thats 2M |
| 05:31:04 | brixen | yeah |
| 05:31:06 | evan | the text will be 15k |
| 05:31:29 | evan | i've had issues openning session files before |
| 05:31:35 | evan | is why I'd prefer not to. |
| 05:31:39 | brixen | k |
| 05:31:40 | evan | we'd spend a bunch of time |
| 05:31:44 | evan | and get nothing out of it. |
| 05:32:03 | evan | let me go look at the code |
| 05:32:48 | evan | ok |
| 05:32:49 | evan | yeah |
| 05:32:56 | evan | you're using of std::string |
| 05:32:58 | evan | is the problem. |
| 05:33:08 | brixen | yeah, that's what I said :) |
| 05:33:14 | evan | the push_back is likely causing it to reallocate and copy EVERY call |
| 05:33:25 | evan | ie, it's not using a bigger buffer than needed |
| 05:34:47 | brixen | well, I need to separate this |
| 05:34:47 | evan | try putting str.reserve(4069) at the top |
| 05:34:59 | evan | er. 4096 |
| 05:35:07 | brixen | look at the benchmark, there is the :fast_rgba that is way faster |
| 05:35:08 | evan | to force it to grab a big backing buffer |
| 05:35:12 | brixen | run on the same image |
| 05:35:21 | brixen | but its directives string is way shorter |
| 05:35:29 | evan | right. |
| 05:35:41 | brixen | http://gist.github.com/497277 |
| 05:35:44 | brixen | see these two |
| 05:36:01 | evan | seriously?! |
| 05:36:03 | evan | thats the pattern?! |
| 05:36:23 | brixen | yes |
| 05:37:14 | brixen | this is the bench http://gist.github.com/497335 |
| 05:37:18 | brixen | the same image is used |
| 05:37:41 | evan | std::string might not be the tool for this. |
| 05:39:48 | evan | it very likely is std::string sucking ass. |
| 05:39:59 | evan | it's just not built to do this. |
| 05:40:22 | brixen | actually, I just realized what it is |
| 05:40:30 | brixen | the difference between these 2 is X and x |
| 05:40:39 | brixen | I implemented X very naively |
| 05:40:43 | brixen | :) |
| 05:40:44 | brixen | sorry |
| 05:41:15 | brixen | anything will suck ass if you copy it 86,580 times |
| 05:42:30 | brixen | if you think something would be rather nonsensical to use, someone will use it... heavily |
| 05:42:46 | brixen | like, for every pixel in an image |
| 05:43:25 | evan | i'd like for us to figure out a better way to organize this code |
| 05:43:46 | evan | after looking at for the last 10 minutes |
| 05:43:52 | evan | i can barely understand it. |
| 05:44:08 | brixen | which part are you looking at |
| 05:44:28 | evan | the whole thing. |
| 05:44:31 | brixen | it's one line in pack_actions.rl |
| 05:44:37 | evan | part of this is I don't understand ragel. |
| 05:44:41 | evan | don't explain it to me over IRC either. |
| 05:44:42 | evan | :) |
| 05:45:03 | evan | if you write some comments about what, for instance, setting index does |
| 05:45:04 | brixen | well, you need to start at machine/pack.rl |
| 05:45:06 | evan | that would help. :) |
| 05:45:34 | brixen | sure, I will doc it |
| 05:46:21 | evan | for the time being, i can only provide cursory help |
| 05:46:27 | evan | and thats by looking at the generated output. |
| 05:46:32 | brixen | anyway: pack_actions.rl:98: str = str.substr(0, str.size() - count); |
| 05:46:57 | brixen | I need to back up the insertion point in the output string by count bytes |
| 05:47:13 | evan | pack? I thought we were doing unpack |
| 05:47:17 | evan | thats why i'm so lost. |
| 05:49:07 | brixen | looks like resize should do it |
| 05:49:25 | evan | reserve you mean? |
| 05:49:33 | evan | resize is different |
| 05:49:44 | brixen | no, I mean chop the string down |
| 05:49:53 | brixen | the example for resize looks right |
| 05:50:21 | evan | i really feel like str::string is not the thing to use |
| 05:50:23 | evan | personally. |
| 05:50:33 | brixen | well, it's working great so far |
| 05:50:37 | brixen | I'm open to suggestions |
| 05:50:45 | brixen | but I'm not inclined to change it right now |
| 05:50:50 | brixen | this was my fault |
| 05:51:07 | evan | ok |
| 05:51:09 | brixen | 1. for a naive impl, and 2. for not realizing someone would actually do this pattern |
| 05:51:21 | brixen | I mean, write 4 bytes, back up one |
| 05:51:27 | brixen | for a whole image? |
| 05:51:33 | evan | wtf seriously |
| 05:51:35 | brixen | *eyeroll* |
| 05:52:45 | brixen | the perf in this http://gist.github.com/493523 is on par with 1.9 |
| 05:52:56 | evan | ok |
| 05:52:57 | evan | well |
| 05:53:02 | brixen | it's just the two crazy directives strings |
| 05:53:26 | evan | isn't that the same one? |
| 05:53:29 | evan | i don't see any change |
| 05:53:42 | brixen | bingo |
| 05:54:04 | brixen | http://gist.github.com/493523 |
| 05:54:27 | brixen | actually, let me kill ff and run that again |
| 05:55:44 | brixen | dbussink: here are your chunky_png encoding benchmarks http://gist.github.com/493523 |
| 05:56:53 | brixen | we can tweak the impl of #pack as much as we want once the stuff is working |
| 05:59:16 | evan | i think at least some docs |
| 05:59:23 | evan | trying to sort out it put me in a bad mood :( |
| 06:00:16 | brixen | sure, you need to know where to start |
| 06:01:43 | brixen | one issue that would need to be addressed for an alt impl is that there is a lot of state |
| 06:02:12 | brixen | thus, a "create an object for a directive and call methods on it" approach seems dubious to me |
| 06:02:31 | brixen | but again, that's open to demonstration |
| 06:02:44 | evan | well |
| 06:02:51 | evan | it doesn't appear to be reusable at all atm. |
| 06:02:57 | evan | maybe that one machine/pack.rl file |
| 06:02:57 | brixen | basically though, rules are in machines/*.rl, actions are in actions/rubinius/*_actions.rl |
| 06:03:13 | brixen | code wrappers are in *_code.rl |
| 06:03:21 | evan | what is a "code wrapper" ? |
| 06:03:37 | brixen | String* Array::pack(STATE...) |
| 06:04:11 | brixen | start in machines/pack.rl |
| 06:04:28 | brixen | find a directive, they are named just like the Ruby code |
| 06:04:31 | evan | i don't like that the code in rubinius is an autogenerated soup |
| 06:04:35 | brixen | each has 1+ actions |
| 06:04:38 | evan | for releases, we should be including the .rl files too. |
| 06:04:54 | brixen | that's fine |
| 06:05:06 | brixen | it's a separate dir for other projects to collab on |
| 06:05:11 | brixen | we can copy it in just like mspec |
| 06:05:29 | brixen | anyway, for eg the X action, pack_actions.rl -> action X |
| 06:05:30 | evan | why is actions/rubinius in rapa at all? |
| 06:05:33 | brixen | it's super easy |
| 06:05:41 | evan | seems like that should live aways inside the rubinius tree |
| 06:05:48 | brixen | why? |
| 06:06:19 | evan | they're 100% rubinius specific |
| 06:06:21 | evan | it appears |
| 06:06:28 | evan | i thought rapa was the generic project |
| 06:06:35 | brixen | um... |
| 06:06:42 | brixen | ok, I'm tired |
| 06:06:48 | brixen | let's talk tomorrow |
| 06:06:49 | evan | yeah, me too. |
| 06:06:51 | evan | k |
| 06:06:53 | evan | sorry :( |
| 06:07:43 | brixen | CI is hung btw |
| 06:08:30 | evan | fucking a. |
| 06:08:32 | evan | something is up. |
| 06:08:33 | evan | bigtime. |
| 06:08:47 | evan | started when dbussink untagged all those specs. |
| 06:08:53 | evan | something is unstable. |
| 06:09:01 | boyscout | Fixed degenerative X case for Array#pack. - 49f6d09 - Brian Ford |
| 06:36:52 | boyscout | CI: rubinius: 9a9062d successful: 3498 files, 14668 examples, 42466 expectations, 0 failures, 0 errors |
| 06:57:06 | dbussink | evan: hmm, any ideas which tags? |
| 06:57:21 | evan | check ci.rubini.us |
| 06:57:22 | dbussink | since i ran them for quite a while and never got an issue here |
| 06:57:28 | dbussink | but maybe there's some difference on linux |
| 06:57:32 | evan | there is a backtrace in the middle of the output |
| 06:57:36 | evan | which I did when it was hung |
| 06:58:10 | dbussink | evan: ah, i see yeah |
| 06:58:24 | dbussink | must be some linux / thread issue probably then |
| 06:58:56 | dbussink | i did run them a few times on a debian lenny 64 bit box too before removing the tags :S |
| 07:05:00 | evan | did you remove a Thread#exit tag? |
| 07:05:21 | evan | which is what that hang appears to be in |
| 07:05:26 | evan | oh wait |
| 07:05:29 | evan | i'll bet I know whats up. |
| 07:05:33 | evan | let me check something. |
| 07:07:52 | evan | dbussink: ack, yes. |
| 07:07:54 | evan | my screw up. |
| 07:08:01 | evan | dbussink: i'm on my hydra branch |
| 07:08:13 | evan | could you add get_attention(); |
| 07:08:19 | evan | to the last line of VM::register_raise |
| 07:09:58 | evan | test that |
| 07:09:59 | evan | and commit it. |
| 07:10:03 | evan | should fix the issue. |
| 07:10:15 | evan | i'm off to bed. |
| 07:11:39 | dbussink | evan: ok, i'll do that :) |
| 07:13:12 | dbussink | evan: nite! |
| 07:18:56 | boyscout | Potential fix for spurious CI hangs - 702e649 - Dirkjan Bussink |
| 07:23:04 | brixen | dbussink: I think you mean sporadic, those are not false or fake hangs :) |
| 07:23:57 | dbussink | brixen: ah, yeah, true :) |
| 07:24:09 | dbussink | but let's see whether it runs through now |
| 07:24:53 | dbussink | brixen: even installed an old gutsy to test these specs now :) |
| 07:24:53 | dbussink | unstable(Causes mspec to exit with 'Hangup' on freebsd/ubuntu gutsy):Process.kill sends the given signal to the current process if pid is zero |
| 07:25:18 | dbussink | brixen: bit nice packing performance numbers :) |
| 07:25:42 | dbussink | brixen: the chunky png guy knows about those nasty pattern strings, but he couldn't find another way :) |
| 07:28:08 | boyscout | CI: rubinius: 702e649 successful: 3502 files, 14746 examples, 42553 expectations, 0 failures, 0 errors |
| 07:29:04 | brixen | dbussink: yeah, that was just a dumb way for me to implement X |
| 07:29:28 | brixen | dbussink: I have a couple more things for unpack to do and then I'll run the decode benches |
| 07:29:42 | brixen | but so far, rbx perf is on par with 1.9 in that encode bench |
| 07:29:48 | brixen | so that's good |
| 07:29:56 | brixen | if he has other benches, let me know |
| 07:30:00 | brixen | anyway, night |
| 07:30:04 | dbussink | brixen: i'll let him know :) |
| 07:30:12 | dbussink | brixen: this is already a very nice improvement :) |
| 07:30:17 | dbussink | brixen: still happy with the code? |
| 07:30:25 | brixen | happy with what? |
| 07:30:58 | tarcieri | boing |
| 07:31:11 | brixen | dbussink: here's some other benches http://gist.github.com/496620 |
| 07:32:17 | dbussink | brixen: with how this approach works out |
| 07:32:46 | brixen | dunno, it's 100x faster |
| 07:33:02 | brixen | I don't really care actually, could copy MRI for all I care :) |
| 07:33:08 | brixen | anyway, night for reals :) |
| 07:33:18 | dbussink | brixen: nite! |
| 09:58:00 | boyscout | Remove tags for passing Process#kill specs - b3daf38 - Dirkjan Bussink |
| 10:07:03 | boyscout | CI: rubinius: b3daf38 successful: 3502 files, 14746 examples, 42553 expectations, 0 failures, 0 errors |
| 13:45:03 | goyox86 | Morning! |
| 14:49:59 | dbussink | goyox86: g'day sir |
| 14:50:33 | goyox86 | dbussink: how r you doing? |
| 14:52:29 | dbussink | goyox86: good, nothing special, just cranking out some ugly near deadline code :P |
| 14:52:43 | goyox86 | dbussink: :s |
| 14:53:14 | goyox86 | dbussink: some CI hangs yerterday :] |
| 14:53:50 | dbussink | goyox86: hopefully they are gone now :) |
| 14:53:55 | dbussink | goyox86: did you have them too? |
| 14:55:42 | goyox86 | dbussink: yesterday i made a commit, and no CI ran, i mean no boyscout output, i just got slept waiting for it |
| 14:56:48 | dbussink | goyox86: ah ok, yeah, well, pushed a commit today that hopefully fixes it :) |
| 14:56:57 | dbussink | goyox86: it ran the last few times through |
| 14:58:39 | goyox86 | dbussink: i saw your fix, what does get_attention() do? |
| 15:49:13 | evan | morning |
| 15:52:55 | brixen | morning |
| 15:54:09 | evan | brixen: again, sorry about last night |
| 15:54:16 | evan | i was in a really bad mood! geez evan! |
| 15:55:12 | brixen | ok |
| 15:58:56 | goyox86 | brixen, evan: morning! |
| 15:59:24 | brixen | hi goyox86 |
| 15:59:55 | evan | goyox86: hi hi |
| 16:01:04 | evan | brixen: at any rate, I should go read the ragel docs to figure out the grammar? |
| 16:01:36 | brixen | well, you should have some familiarity with it, but I can write a short tutorial |
| 16:02:09 | evan | it's short enough that I'd imagine if I skim the ragal docs I'll get it |
| 16:02:12 | brixen | where do you want the files in the rbx tree? |
| 16:02:41 | evan | vm/builtin/ragel seems logical |
| 16:03:03 | brixen | really? |
| 16:03:37 | brixen | so, if you look at machines/pack.rl |
| 16:03:52 | brixen | each 'ident =' defines a machine |
| 16:04:08 | brixen | % @ > attach actions on a transition |
| 16:04:18 | brixen | so <sigil><name> |
| 16:04:27 | brixen | where <name> is the action |
| 16:04:42 | brixen | those are all defined in actions/rubinius/pack_actions.rl |
| 16:05:27 | brixen | % means a leaving transition, > is an entering transition, @ happens each time the state is entered |
| 16:05:32 | evan | I don't really see % @ |
| 16:05:37 | evan | I see @ |
| 16:05:37 | brixen | a very simple example is count |
| 16:05:39 | evan | and % % |
| 16:05:44 | brixen | what file? |
| 16:05:52 | jakedouglas | good morning |
| 16:05:53 | evan | wait, do you mean |
| 16:05:59 | brixen | loook at line 11 of pack.rl |
| 16:06:01 | evan | "%, @, and > attach actions ..." |
| 16:06:04 | brixen | yes |
| 16:06:08 | evan | ah |
| 16:06:11 | brixen | count = is a simple atoi |
| 16:06:13 | evan | i thought you meant them in series |
| 16:06:23 | brixen | digit is a built in machine [0-9] |
| 16:06:39 | brixen | when it recognizes the first digit, >start action runs |
| 16:06:52 | evan | is count referencing itself then? |
| 16:06:53 | brixen | for each successive digit @count action runs |
| 16:06:57 | evan | because it's count = ... @count |
| 16:06:58 | brixen | yes |
| 16:07:00 | brixen | no |
| 16:07:01 | brixen | no |
| 16:07:06 | brixen | @count is an action |
| 16:07:28 | evan | ah ah |
| 16:07:29 | evan | ok |
| 16:07:38 | evan | the rules are in a different namespace than the actions |
| 16:07:43 | brixen | yes |
| 16:07:46 | evan | you're saying that the count rule should run the count action |
| 16:07:50 | brixen | yes |
| 16:08:55 | brixen | well, no |
| 16:09:04 | brixen | digit* runs the count action |
| 16:09:15 | brixen | actions are left associative |
| 16:09:25 | brixen | you have to use () to group expressions |
| 16:09:28 | evan | umm |
| 16:09:30 | evan | ok, in |
| 16:09:31 | evan | count = digit >start_digit digit* @count; |
| 16:09:43 | evan | is @count attached to count or digit* |
| 16:09:43 | evan | ? |
| 16:09:47 | brixen | digit* |
| 16:09:53 | evan | i assume that count is run in order |
| 16:09:56 | evan | left to right |
| 16:10:18 | evan | so you're saying "when you match a kleene star of digits, run the count action" |
| 16:10:28 | brixen | count says: recognize a single digit, run start_digit, recognize 0 or more digits, run count action |
| 16:10:41 | brixen | 0 or more additional digits |
| 16:10:44 | evan | ok, in the count action |
| 16:10:46 | evan | what is fc? |
| 16:10:49 | brixen | x y => x then y |
| 16:10:55 | brixen | the current character |
| 16:11:19 | brixen | in pack, the machine is running on the directives string |
| 16:11:35 | evan | so |
| 16:11:44 | evan | is the count action run for each digit matched by digit* |
| 16:11:46 | evan | or once? |
| 16:11:55 | brixen | [1].pack('C3') => C rule runs => 'C' ... |
| 16:12:00 | brixen | each digit |
| 16:12:14 | brixen | per the @ |
| 16:12:22 | brixen | which says, each time you enter the state |
| 16:12:29 | brixen | the "state" is "a digit" |
| 16:12:37 | evan | and "count" in the count action is a local variable within the generated output? |
| 16:12:44 | evan | there are 3 things named count |
| 16:12:47 | brixen | yes |
| 16:12:50 | evan | which is part of my confusion |
| 16:13:06 | brixen | count is defined in actions/rubinius/pack_code.rl |
| 16:13:16 | evan | yeah, i'm looking at it. |
| 16:13:25 | brixen | well, it's quite clear if you know ragel |
| 16:13:38 | brixen | not inclined to name it count_var, count_action, count_rule |
| 16:14:42 | brixen | all transition and state actions must be introduced by a sigil |
| 16:14:51 | brixen | there is no confusing which namespace you're in |
| 16:14:52 | evan | no no it's fine |
| 16:14:56 | evan | there are 3 contexts anyway |
| 16:15:02 | brixen | of course |
| 16:15:04 | evan | and a different count ofr each context |
| 16:15:08 | evan | well, you say of course |
| 16:15:13 | evan | but it's not clear to a newbie like me :) |
| 16:15:28 | evan | i'm getting it now. |
| 16:15:32 | brixen | I realize that, which is why I can write a tutorial |
| 16:15:42 | brixen | but something isn't just a priori confusing |
| 16:15:52 | brixen | llvm is pretty damn confusing except to you ;) |
| 16:16:02 | evan | it was confusing to me at first too |
| 16:16:05 | evan | just took learning it |
| 16:16:08 | evan | I totally understand |
| 16:16:10 | brixen | yeah |
| 16:16:16 | evan | just giving you a "first look" reaction |
| 16:16:29 | brixen | right, and with no tutorial |
| 16:17:28 | evan | in actions/unpack_code.rl |
| 16:17:41 | evan | include "unpack.rl"; |
| 16:17:46 | evan | thats machines/unpack.rl |
| 16:17:46 | evan | ? |
| 16:17:54 | brixen | yes |
| 16:18:07 | brixen | the code wrapper imports the machine, which imports the actions |
| 16:18:18 | brixen | the actions to import are specified by the directory to search |
| 16:19:08 | brixen | unpack_code.rl is === to grammar.y |
| 16:19:16 | evan | right |
| 16:19:22 | brixen | where instead of embedding the grammar rule, it's imported |
| 16:19:38 | evan | so one thing i just realized is that actions have no way to express state within ragel |
| 16:19:47 | evan | so they share state between them in the generated output only |
| 16:20:09 | evan | thus the building of the count local to be a number |
| 16:20:16 | evan | and then someone reading it later |
| 16:20:27 | brixen | basically, yes |
| 16:20:42 | evan | so |
| 16:20:51 | brixen | of course, that could all be via some function interface to get/set objects etc |
| 16:20:57 | brixen | but I don't see the point |
| 16:21:30 | evan | ok |
| 16:21:36 | evan | if you were going to write some docs |
| 16:21:56 | evan | write one sentense on what each local is |
| 16:21:59 | evan | and what it's used for |
| 16:22:07 | evan | i think that would clear it up a bunch |
| 16:22:13 | brixen | sure |
| 16:22:57 | brixen | also, the flow to look at this is generally: pack.rl, pack_actions.rl, pack_code.rl |
| 16:23:11 | brixen | if you don't follow that path, you're probably going to get confused |
| 16:23:23 | evan | well |
| 16:23:27 | brixen | a rule has actions, actions have implementations |
| 16:23:27 | evan | i have to look at pack_code.rl first |
| 16:23:31 | evan | to know what is a local |
| 16:23:47 | evan | then go back to pack_actions.rl to see how the locals are used |
| 16:23:57 | brixen | you don't see a local till you look at an action |
| 16:24:17 | evan | well, i know there are going to be locals in actions.rl |
| 16:24:41 | evan | i suppose I could just assume that anything like "[a-z]+ = " is setting a normal state local |
| 16:24:50 | evan | i feel like I'm missing the bigger picture though |
| 16:24:55 | brixen | hmm |
| 16:24:56 | brixen | yeah |
| 16:25:05 | brixen | that sentence didn't parse |
| 16:25:08 | evan | the bigger picture is here this code is actually running |
| 16:25:16 | brixen | the assignments in pack.rl are just rules |
| 16:25:16 | evan | which is in _code.rl |
| 16:25:26 | brixen | there are no "locals" in any code sense |
| 16:25:32 | evan | right |
| 16:25:39 | evan | that i've gotten |
| 16:25:45 | brixen | the rules are state machines/regular expressions |
| 16:25:47 | brixen | ok |
| 16:26:11 | brixen | so, to find out how [1].pack('C3') works, you have to find the rule for 'C3' |
| 16:26:14 | brixen | so you start in pack.rl |
| 16:26:45 | brixen | C as a rule is defined as (('C' | 'c') modifier) %check_size %C; |
| 16:26:56 | brixen | modifier is another rule |
| 16:27:22 | brixen | which is count_modifier | [_!] |
| 16:27:27 | evan | yep |
| 16:27:31 | evan | i followed that back up |
| 16:27:37 | evan | i think i'm getting the hang of ragel. |
| 16:27:44 | brixen | count_modifier is '*' %rest | count? |
| 16:27:44 | evan | from the rule perspective |
| 16:27:53 | brixen | at %rest you get your first action to look at |
| 16:28:44 | brixen | which has rest = true, and now you have a local to puzzle over :) |
| 16:29:00 | evan | right |
| 16:30:00 | evan | so now I hold in my head "res is set" |
| 16:30:02 | evan | rest |
| 16:30:13 | evan | and kick back out to %C |
| 16:30:32 | brixen | well, to %check_size then %C |
| 16:30:34 | evan | well, in the case of C3 |
| 16:30:38 | evan | rest isn't set, right? |
| 16:30:46 | brixen | right, because there's no * |
| 16:30:56 | brixen | '*' fails, so count? rule runs |
| 16:31:06 | evan | instead, %count kicks in via the count rule |
| 16:31:09 | brixen | which means 0 or 1 count rules |
| 16:31:12 | evan | which sets the count local |
| 16:31:21 | brixen | right |
| 16:31:49 | brixen | count rule itself is 1 or more digits |
| 16:32:22 | brixen | for something like 'C2C5C3' count has to be initialized for each directive |
| 16:32:37 | brixen | that's why >start_digit action exists |
| 16:32:50 | brixen | and @count action accumulates |
| 16:33:06 | evan | AAH |
| 16:33:10 | evan | i was wondering how count was reset. |
| 16:33:21 | evan | whats the > mean? |
| 16:33:30 | brixen | > means the transition into the state |
| 16:33:42 | evan | into which state? |
| 16:33:47 | brixen | like only once at the very beginning |
| 16:33:48 | evan | go to start_digit? |
| 16:33:53 | brixen | "state" is any machine |
| 16:34:02 | brixen | in this case, the digit machine |
| 16:34:04 | evan | is that refering to the CURRENT state? |
| 16:34:11 | brixen | ie recognize [0-9] |
| 16:34:45 | brixen | well, this is the slightly confusing part IMO |
| 16:35:09 | brixen | digit = [0-9]; digits = digit+ |
| 16:35:22 | brixen | digit is a machine (ie has a state, only one) |
| 16:35:40 | brixen | digits is a machine, has 1 + states if you linearize it |
| 16:36:00 | brixen | it's just a state with a transition back to itself and one out for a non-digit char |
| 16:36:11 | evan | ok sure |
| 16:36:15 | evan | kleene star style. |
| 16:36:16 | brixen | you can generate .dot output if that would help |
| 16:36:36 | evan | i've drawn the kleene star match |
| 16:36:48 | evan | but we could generate the .dot and post it somewhere for people to see |
| 16:36:55 | evan | as a png |
| 16:36:57 | brixen | it's humungous |
| 16:37:02 | evan | i'll bet. |
| 16:41:16 | evan | brixen: ok, i think i've got it a lot better |
| 16:41:28 | evan | i'll this thinking in parallel for hydra has gotten my head twisted |
| 16:41:35 | evan | i need a twin |
| 16:41:44 | evan | he can keep track of a parallel thread |
| 16:41:48 | evan | while i do the current thread |
| 16:43:18 | brixen | yeah, concurrency is like time just disappeared except not because somethings are seqential accidentally or on purpose |
| 16:43:42 | evan | well, i've got a good rhythm now using CAS |
| 16:43:57 | evan | you get the current value, you change it to what you want it to be, then you do |
| 16:44:16 | evan | if(!CAS(&location, original, new_value)) goto redo; |
| 16:44:48 | evan | so i've gotten in the habit of thinking that only a CAS an atomic operation |
| 16:45:03 | evan | and that every other line of code could be running simultaniously on another thread |
| 16:45:32 | brixen | nice |
| 16:48:56 | evan | brixen: so, what was the issue with X yesterday? |
| 16:49:00 | evan | i should go look at your commit |
| 16:49:01 | evan | one sec. |
| 16:49:44 | evan | oh, just that you were copying the string to be a smaller version of itself each time |
| 16:49:52 | brixen | I was copying the string |
| 16:49:53 | evan | rather than rewinding it |
| 16:49:59 | brixen | right |
| 16:50:15 | brixen | the std::string is performing very well in all my benches |
| 16:50:26 | brixen | I didn't have a bench for X yesterday :( |
| 16:50:37 | brixen | but I've written one this morning |
| 16:51:37 | evan | k |
| 16:53:19 | brixen | so vm/builtin/ragel seems a poor choice because this is just "a" ragel project |
| 16:53:35 | brixen | and we need a general place for included code |
| 16:53:54 | brixen | like code for the rbx doc system |
| 16:53:57 | evan | ok |
| 16:54:06 | brixen | or bundling Gauge |
| 16:54:16 | evan | ok |
| 16:54:23 | evan | how about /projects/ |
| 16:54:33 | evan | outside vm entirely |
| 16:54:40 | brixen | that seems good |
| 17:01:27 | evan | go for it. |
| 17:01:43 | evan | brixen: bakkdoor is arriving at union station at 11 |
| 17:01:51 | evan | so i'm going to head down there in about 30 mins |
| 17:01:56 | brixen | cool! |
| 17:02:02 | brixen | he's fun to hang out with |
| 17:02:09 | evan | oh good! |
| 17:02:24 | evan | sadly, ricky's fish tacos doesn't appear to be open today though :/ |
| 17:02:33 | brixen | :( |
| 17:02:42 | brixen | I'm sure you'll find something |
| 17:02:49 | evan | yeah |
| 17:54:52 | dbussink | evan: how's hydra looking? |
| 17:59:06 | goyox86 | dbussink: i think evan is in mission burritos/tacos with bakkdoor, isn't brixen? |
| 18:08:50 | brixen | dbussink: evan pushed the hydra branch |
| 18:12:41 | dbussink | brixen: ah, going to take a look then :) |
| 18:12:51 | jakedouglas | HYYDDRRAAA |
| 18:52:19 | dbussink | i already crashed the hydra branch :P |
| 19:02:57 | brixen | dbussink: you are a spoil-sport |
| 19:03:29 | JamesKilton | so what is Hydra? I saw the commits about removing the GIL |
| 19:03:56 | brixen | it's a branch to work on removing the GIL :) |
| 19:04:13 | JamesKilton | Ok was wondering if there was more to it than that |
| 19:04:14 | dbussink | brixen: i'm too good at it ;) |
| 19:04:28 | brixen | probably taken from http://en.wikipedia.org/wiki/Hydra |
| 19:04:45 | brixen | dbussink: you know what they say, you break it, you fix it :) |
| 19:05:20 | JamesKilton | there is a parallel test runner system called Hydra, for running tests across multiple systems |
| 19:07:03 | brixen | kitties! http://gist.github.com/498949 |
| 19:07:07 | brixen | and it runs on rbx |
| 19:07:25 | brixen | rbx gem install kitty; rbx -S kitty |
| 19:07:28 | brixen | don't delay! |
| 19:07:46 | brixen | also, cats rule, dogs drool |
| 19:07:56 | brixen | in case someone wants to make a dog gem |
| 19:10:40 | dbussink | brixen: if i could i would fix it ;) |
| 19:11:25 | brixen | dbussink: I detect a spirit of defeatism there, if at first you don't succeed... :) |
| 19:11:58 | dbussink | brixen: i should get some more simple vm exercise first :P |
| 19:12:24 | JamesKilton | brixen: haha you bored? |
| 19:12:35 | brixen | JamesKilton: not at all :) |
| 19:13:04 | brixen | JamesKilton: I'm making sure popular gems run on rbx :) |
| 19:13:09 | brixen | http://github.com/bryanwoods/kitty |
| 19:13:27 | JamesKilton | gotcha |
| 19:15:30 | brixen | JamesKilton: also, someone suggested kitty gem might be as awesome as all of github put together |
| 19:15:39 | brixen | so of course I had to see if it runs on rbx |
| 19:15:55 | JamesKilton | haha, well it's first I've heard of it =/ Might need to install it now |
| 21:14:56 | evan | yay! bakkdoor and I got fish tacos! |
| 21:15:15 | brixen | yum |