Extract the `parser` and `validator` from the `pest_derive` crate into `pest_meta` #159

Victor-Savu · 2017-10-08T16:49:51Z

This is the first step towards #158 . It provides the new crate pest_meta, which grants access to the implementations of the parser and validator used by pest_derive. However, in order to declare them usable, there needs to be some experimentation outside their original intended use.

This PR is a WIP mainly to get early feedback and to prevent working inside the proverbial cave for too long.

Open questions:

I am not sure how versioning should work. I just put the same version for pest_meta as for all the other crates in the pest workspace but I am not sure if that's what I was supposed to do 😃

Once the design & implementation kinks are ironed out and any new ideas are implemented (or postponed, dropped), this PR still needs:

documentation for pest_meta targeted at people who want to use it for building tools for pest (syntax highlighting, linting, completion, etc.)

Victor-Savu · 2017-10-08T18:12:35Z

Just a note on bootstrapping:

Pest itself uses a language for defining the grammar rules for generating a parser. A parser for said language could even be generated by Pest from a description of the language, written in the Pest language itself. That parser could, in turn, be used to implement a new version of Pest. This process is called bootstrapping.

The problem is that the new version of Pest would depend on the old version of Pest, both of which would need to be compiled. Assuming this worked (which is still unclear at the moment), the users of the pest library would have to incur at least the extra compilation time required for the bootstrapping operation. Unless there can be a way around this (e.g. cargo starts shipping binary artifacts), the benefits of bootstrapping would need to outweigh the compilation time costs.

Another problem is that the parser for the new version of the language would be generated from a description written in an older version of the language. This means that the language itself would need versioning in order to avoid confusion and incompatibilities.

In general, the benefits of bootstrapping the Pest language are:

The language proves it is usable in non-trivial scenarios. [There are arguably more complex languages which can be used to prove the prowess of a grammar definition language]
Contributors to the language are likely users of the language, so they may be more familiar with the language.

dragostis

Very nice job with extracting this!

Versioning for the beta is a bit dirty: I've been publishing new versions of each crate even when not fully required, so I guess that can work out until 1.0 is launched.

dragostis · 2017-10-08T19:36:15Z

pest_derive/src/lib.rs

-    let (ast, defaults) = parser::consume_rules(pairs);
+    fn format_errors<Errors: IntoIterator>(errors: Errors) -> String where Errors::Item: Display {
+        errors.into_iter()
+            .map(|error| { format!("{}", error) })


The usual style I used was to align methods calls vertically.

Yep, I tried to do that as well, but I think I missed this one :) I really need to get Vim to do it for me :)

dragostis · 2017-10-08T19:39:37Z

pest_meta/Cargo.toml

+
+[dependencies]
+quote = "^0.3"
+maplit = "^0.1.5"


I would optimize for having as few dependencies as possible in order to facilitate compile times for end users. The pest crates compile somewhat slowly and the grammars can also take quite a bit during the first compilation.

maplit is just a bunch of macros, so it doesn't really take any compilation time at all aside from downloading it (<200 lines of code including tests and documentation).

I thought you meant "quote", which is quite a bit of an annoyance since we only use one struct: quote::Ident. Of course, quote is already a dependency of pest_derive, so for that use case there's no added cost, but for projects who don't care much about producing a rust plugin it may be annoying.

I meant both, actually. The only reason I'd give up on maplit is because it's easy to replace and one request less to worry about when compiling big projects with a lot of dependencies.

About quote, it may be a smart idea to give up on using quote::Ident in pest_meta since it doesn't make sense at all.

I would add the circumvention of the quote crate as a second to do.

dragostis · 2017-10-08T19:42:39Z

pest_meta/src/parser.rs

        ) -> Result<Position<I>, Position<I>> {
            pos.sequence(|pos| {
-                soi(pos, state).and_then(|pos| {


This is a funny change. :D I used to have this whole file as close to what the generator would spit out, hoping to be able to bootstrap it completely sooner or later, but of course it makes no sense.

I was actually going to ask about this one, because I wasn't sure if it was there for historical reasons or if was written in expectation of an upcoming feature. Is it OK that I took it out?

dragostis · 2017-10-08T19:47:26Z

pest_meta/src/parser.rs

-                GrammarRule::expression => expression(pos, &mut state),
-                GrammarRule::term => term(pos, &mut state),
-                GrammarRule::positive_predicate_operator => {
+                PestRule::grammar_rules => grammar_rules(pos, &mut state),


I guess this could be transformed into a macro since it got quite big since I started.

Yeah, that is a lot of repetition a lot of repetition.

This comment is so meta. haha.

New macro pushed :)

dragostis · 2017-10-08T19:55:54Z

pest_meta/src/validator.rs

+use super::parser::{PestRule, ParserExpr, ParserNode, ParserRule};
+
+pub fn validate_pairs<I: Input>(pairs: Pairs<PestRule, I>) -> Result<Vec<Ident>, Vec<Error<PestRule, I>>> {
+    let rust_keywords = hashset!{


This does look good. I think it would be very easy to just have a macro for this defined in the crate.

Sure! But I would really hope you gave maplit another thought. The code for this macro (16 lines) is more than 25% of the library code (16 + 16 + 13 + 14 lines).

Sure. I guess this is a perfect use case and there is pretty much no other dependency.

dragostis · 2017-10-08T19:58:53Z

pest_meta/src/validator.rs

+    Ok(defaults.into_iter().map(|string| Ident::new(*string)).collect())
+}
+
+pub fn validate_rust_keywords<'a, I: Input+'a, Definitions: IntoIterator<Item=&'a Span<I>>>(


I would normally used spaces around the + in types as well, but guess it really depends. Also, I would put the lifetimes before types.

Sure thing! I tried rustfmt, but had to revert because it had some very different opinions 😄 and I really wanted to reproduce the style of the other crates as much as possible. Is there any plan to use it at some point when it is stable (and consistent) enough?

The issue with rustfmt is an old one.

Ah, whoops! it was right there! Good thing rustfmt is open source.

Yes, but, unfortunately, the hang bug seems to be pretty non-trivial.

dragostis · 2017-10-08T20:30:16Z

I guess bootstrapping can currently stay in its current form. The reason bootstrapping might make more sense in the future would if pest will gain error-flexible parsing capabilities.

dragostis · 2017-10-09T18:56:26Z

pest_meta/src/parser.rs

+        }
+
+        pest::state(input, move |mut state, pos| parse_rule!{
+            pos, state for rule in {


Nice, creative syntax! 😃

Yeah, I like rust macros! They can allow for some really intuitive and readable code.

Come to think about it, maybe something with match in the syntax might be more appropriate, as the rule is only matched to exactly one of the variants.

dragostis · 2017-10-15T09:47:58Z

The match syntax does look a bit better.

Victor-Savu · 2017-10-15T12:11:49Z

@dragostis any idea what I did to bring the code coverage down so much? I think it might be due to all of the text I removed when I made the validator return Result instead of panicking in a2a2980. I guess those cases tested both the validator and the parser at once.

dragostis · 2017-10-15T12:21:12Z

@Victor-Savu It seems to be the case, yes. The integration tests in pest_derive don't seem to produce coverage for pest_meta. The ideal solution would be to have a way to get the coverage back instead of writing extra tests. Maybe there's a way to fix it in travis.yaml.

dragostis · 2017-10-15T13:59:24Z

@Victor-Savu tarpaulin might help. I don't have a machine to test it on right now, so maybe you could try cargo tarpaulin -v -p pest pest_derive pest_grammars pest_meta on your banch?

dragostis · 2017-10-15T14:21:35Z


~~~It seems like tarpaulin produces low coverage as well. This requires further investigation.~~~

I forgot the extra `pest_meta` argument. tarpaulin is gold. I'll open up a [PR](https://github.com/pest-parser/pest/pull/162).

As `quote::Ident` is the only thing from `quote` used by `pest_meta`, the dependency on `quote` is overkill. Replace uses of `quote::Ident` by `String` and remove the dependency on `quote`. As `pest_derive` relies on `quote::Ident` for the code generation part, it is OK to keep `quote` as a dependency. Create the required `quote::Ident` instances from the identifier names which are now provided by `pest_meta` as `String`.

Victor-Savu · 2017-10-21T14:07:40Z

Wow! Tarpaulin is awesome!

Victor-Savu · 2017-10-22T22:45:31Z

Does the example tick the documentation box?

Victor-Savu · 2017-10-29T15:03:04Z

Hi, @dragostis! I am not sure what would be left to do for this PR and I'd like to do hear your thoughts.

dragostis

First, sorry for the late reply. Had a pretty crazy week.

This looks really good and is very close to being merged modulo some small issues. I've tried the colorized example and it looks absolutely sweet!

dragostis · 2017-10-29T17:36:48Z

pest_meta/Cargo.toml

@@ -12,3 +12,9 @@ readme = "_README.md"
 [dependencies]
 maplit = "^0.1.5"
 pest = { path = "../pest", version = "^1.0.0-beta" }
+
+[[example]]
+name="colorize"


I'm not completely sure, but the example entry seems to be redundant.

dragostis · 2017-10-29T17:37:59Z

pest_meta/examples/colorize.rs

+    // processed (styled), in order to:
+    // - skip sub-trees which overlap with already styled ones to avoid duplicating the text
+    // - print the input spans between the styled sub-trees
+    // .


The period here seems a bit too much. 😛

We are linguists -- of sorts :)

dragostis · 2017-10-29T17:46:44Z

pest_meta/examples/colorize.rs

+        // Now, we print everything between the last processed code point and the beginning of the
+        // current sub-tree span using the default text output style. Then we print the span of the
+        // sub-tree itself using the selected style.
+        print!("{}{}", unsafe {input.slice(processed, span.start())}, style(span.as_str()));


The rest of the code leave spaces around the unsafe {} braces. (still a muddy affair until rustfmt will work)

dragostis · 2017-10-29T17:47:22Z

pest_meta/examples/colorize.rs

+        processed = span.end();
+    }
+    // To finish up, we print whatever is left from the input using the default style.
+    println!("{}", unsafe {input.slice(processed, input.len())});


Victor-Savu · 2017-10-29T23:24:59Z

@dragostis No worries! Thanks a lot for taking the time to review this! I applied the fixes (I hope 🤞)

dragostis

This looks good to me. Would you like to merge this PR as is for now and leave documentation for later or do you think it's best to do it here?

Victor-Savu · 2017-10-30T09:32:22Z

Great! If you think the current interface looks good, I can get to the documentation.

I think documentation should be part of the PR. The example colorizer was the first step in that direction, but I feel there needs to be a way for people to find it. Should I add a small section in the top-level README.md? If that gets too long, maybe a dedicated README.md to replace the symbolic link in pest_meta and a back reference from the main one could work.

In the meantime, I will write the rust API documentation.

Victor-Savu · 2018-02-02T00:45:35Z

Ah, very good point, the benchmark should include both debug and release builds.

Your point regarding when this change should land brought up a rather scary question to mind: Can the bootstrapped parser benefit from other advances in pest_derive, such as improvements in the optimization or code generation phase. In its current design, that would not be the case, so the parsing phase of any future pest_derive would only be as good as what pest_derive v1.0.* was able to produce. I find this thought disturbing. There is hope if at some point in the future cargo would stop building the entire dependency and would instead rely on pre-built signed versions of those dependencies.

dragostis · 2018-02-02T10:25:08Z

It would be stuck in the 1.0 era, yes. But this might not be such a huge issue since the grammar should be stable from now on. However, this means that 1.0 will have to be supported indefinitely. As for the case of pre-built binaries, I don't think this will hit Cargo anytime soon.

Victor-Savu · 2018-02-03T01:32:49Z

I finally bootstrapped the parser, but I am getting two errors that I don't really know how to fix. I suspect they have similar causes (at least in spirit).
Would you mind having a look?

dragostis · 2018-02-03T12:00:23Z

pest_meta/src/grammar/pest.pest

@@ -0,0 +1,99 @@
+grammar_rules = _{ soi ~ grammar_rule* ~ eoi }


This should be grammar_rules = _{ soi ~ grammar_rule+ ~ eoi }.

dragostis

The grammar looks good. This should improve maintainability quite a bit. Unfortunately, there is quite a bit more work to be able to merge this on v1.1 mainly concerning the changes to the AST.

dragostis · 2018-02-03T12:04:33Z

pest_derive/src/lib.rs

-                GrammarRule::range_operator => "`..`".to_owned(),
-                GrammarRule::single_quote => "`'`".to_owned(),
+            error.renamed_rules(|rule| { match *rule {
+                Rule::grammar_rule => "rule".to_owned(),


A translation rule for _push would also be needed.

dragostis · 2018-02-03T12:05:35Z

pest_derive/src/optimizer.rs

-                name: Ident::new("rule"),
-                ty: RuleType::Atomic,
+                name: "rule",
+                ty:   RuleType::Atomic,


Space here is not needed per rustfmt.

If I run rustfmt on this file, I get a bunch of changes (many not related to the changes I made) Should I just go ahead and use rustfmt, or should I just remove these spaces? I am using rustfmt 0.8.0

dragostis · 2018-02-03T12:05:42Z

pest_derive/src/optimizer.rs

-                name: Ident::new("rule"),
-                ty: RuleType::Atomic,
+                name: "rule",
+                ty:   RuleType::Atomic,


dragostis · 2018-02-03T12:05:54Z

pest_derive/src/optimizer.rs

-                name: Ident::new("rule"),
-                ty: RuleType::Atomic,
+                name: "rule",
+                ty:   RuleType::Atomic,


dragostis · 2018-02-03T12:06:00Z

pest_derive/src/optimizer.rs

-                name: Ident::new("rule"),
-                ty: RuleType::Atomic,
+                name: "rule",
+                ty:   RuleType::Atomic,


dragostis · 2018-02-03T12:09:07Z

pest_meta/Cargo.toml

+pest_derive = "1.0.3"
+pest = "1.0.3"
+
+[dev_dependencies]


This should be dev-dependencies. Not sure I'd keep this here though. It's kind of pointless to have every debug build download a copy of colored.

Any suggestions as to what to do with the example code that depends on colored?

dragostis · 2018-02-03T12:09:35Z

pest_meta/Cargo.toml

+
+[dependencies]
+maplit = "^0.1.5"
+pest_derive = "1.0.3"


pest dependencies here should be ^1.0.

Yup! I suppose 1.1 would already be available by the time this PR lands, so it might make sense to use that instead and release these changes as v 1.2. (same reasoning if 1.2 is released as well before this PR)

dragostis · 2018-02-03T12:10:53Z

pest_meta/src/ast.rs

@@ -26,33 +24,33 @@ pub enum RuleType {
 }

 #[derive(Clone, Debug, Eq, PartialEq)]
-pub enum Expr {
+pub enum Expr<'i> {
    Str(String),


Since the lifetime was added, it probably makes sense to make Str(&'i str), Insens(&'i str) and Range(&'i str, &'i str).

Ahh, yes! :) I was wondering why this wasn't part of the PR which introduced lifetimes to begin with. I will put it in, though it does feel a bit out of scope for this PR.

dragostis · 2018-02-03T12:11:53Z

pest_meta/src/lib.rs

+
+pub fn unwrap_or_report<T, E>(res: Result<T, E>) -> T where E: IntoIterator, E::Item: Display {
+    res.unwrap_or_else(|e| panic!("grammar error\n\n".to_owned() + &e.into_iter()
+              .map(|error| { format!("{}", error) })


Not sure about this formatting. Maybe a newer version of rustfmt needed?

I will use rustfmt on this file. Would you recommend using cargo fmt to format all 4 crates? That would create a lot of changes, and in some places arguably wrong formatting. I feel like rustfmt is not really ready for prime time yet.

Yeah, rustfmt is not ready for prime-time. :/ I'm still kind of torn between whether or not to use it, but for now, I guess it's fine. I expect formatting to get better in time. Anyway, I definitely don't mind the changes if they're concentrated in a last commit.

We could do a cargo fmt as part of a dedicated PR which only deals with formatting. Merging (non-fast-forward) can be quite difficult after such changes since there would be conflicts on so many lines.

dragostis · 2018-02-03T12:14:00Z

pest_meta/src/validator.rs

-        rules: &HashMap<Ident, &ParserNode<'i>>,
-        trace: &mut Vec<Ident>
-    ) -> Option<Error<'i, GrammarRule>> {
+fn left_recursion<'a, 'i: 'a>(rules: HashMap<&'i str, &'a ParserNode<'i>>) -> Vec<Error<'i, Rule>> {


Does 'a need to be introduced here? I would have imagined that using 'i everywhere would work.

The second lifetime is needed because the nodes can't live as long as the slices they reference. If we forced &'i ParserNode<'i> the nodes referenced in the HashMap would need to live at least as long as lifetime 'i, which is also the lifetime of the slice that they reference. This, however, is not possible, since the node cannot live beyond the input as that would invalidate the references that it holds to the input.

Victor-Savu · 2018-02-03T17:21:05Z

Thanks for the review! Any suggestions regarding the two failing tests? I really don't know why it tries to match those extra rules.

dragostis · 2018-02-03T17:59:46Z

Any suggestions regarding the two failing tests? I really don't know why it tries to match those extra rules.

Yes, it's the first comment. 😛

This should be grammar_rules = _{ soi ~ grammar_rule+ ~ eoi }.

The error reporting can be a bit flaky, I suppose. The problem is that the logic doesn't expect multiple reports on the same exact position the way it happens here. Anyway, this is a paper cut for a subsequent release.

I feel like it doesn't make sense to release v1.1 without this fix and the interactive website.

By the way, I really like your work with the PR and I think it makes sense for you to join the team if you want to continue developing pest. I definitely have high hopes for the future of the project!

Victor-Savu · 2018-02-03T18:27:42Z

Thanks! I think I missed that comment. Al green now!

Thank you very much for the invitation! I'd be happy to contribute more!

Victor-Savu · 2018-02-11T19:52:39Z

I did some measurements for the build times from scratch of the entire cargo workspace and this change increases the build time by 50% on average both in debug (from 16.3s to 24.6s) as well as in release (from 52.6s to 76.2s).
However, there is no change in the build time of the client crates. For example, the individual build time for the pest_grammars crate is still at about 3s in debug and 19s in release before and after this change.

Victor-Savu · 2018-02-11T21:14:28Z

I did some measurements for the build times from scratch of the entire cargo workspace and this change increases the build time by 50% on average both in debug (from 16.3s to 24.6s) as well as in release (from 52.6s to 76.2s).
However, there is no change in the build time of the client crates. For example, the individual build time for the pest_grammars crate is still at about 3s in debug and 19s in release before and after this change.

dragostis · 2018-02-12T09:56:56Z

I think that's fine. This number is only problematic when using cargo install, since you only build once, with release, and some crates do take a very long time to compile due to a large number of dependencies. For example, depending on Cargo for some very small amount of API used means that your executable will take minutes to compile.

dragostis

I'm trying to merge this on v1.1. The borrowed strings in the AST are the only blockers and it seems like all of them will need to be changed, unless we want to duplicate work in the optimizer by having another to convert to.

dragostis · 2018-02-12T14:42:40Z

pest_derive/src/optimizer.rs

@@ -91,23 +91,6 @@ pub fn optimize(rules: Vec<Rule>) -> Vec<Rule> {
                    ty,
                    expr: expr.map_bottom_up(rotate_right)
                        .map_bottom_up(unroll_loops)
-                        .map_bottom_up(|expr| {


I see the issue here: since strings are not owned anymore, concatenation is not possible. Seems like we'll have to revert this change.

Do you happen to have any measurements comparing the string concatenation optimization with the slice optimization? The slice optimization prevents memory allocation, prevents copying and improves referential locality, whereas the string concatenation optimization reduces the number of nodes. On first glance I don't really see a clear cut advantage of one optimization over another. However, they can coexist :)
My proposal would be to keep the string slice references and to postpone the concatenation optimization for a separate PR. The reason for this is that the The concatenated strings could be represented later using another Rule variant containing a String (or another data structure, such as a Vec[&'i str]).

The slice optimization happens to make compilation faster, while the concatenation works on improving parse performance once the actual code is generated which is why I would definitely go for the latter. Apart from that, the actual grammar parsing/optimization/generation step is very small during the whole compilation phase which is why I didn't bother at all to do any optimizations on this side and went for code clarity. (as best as I could while still trying to get features out 😃)

Having another variant for concatenations is not a bad idea, but wouldn't it flood the optimization and generation steps too much? Since this would require you to deal with multiple cases that, in the end, reach the same point. The reason why I find the &str to be advantageous is because it is way easier to write tests without all the ugly .to_owned() labels everywhere. However, this could be improved by writing some macros for test improvement. Quite frankly, tests are extremely verbose since I haven't had the time to invest in making them a bit nicer. However, I find their explicitness to be rather helpful. (if you kind of know your way around the code)

So, I would definitely go for the owned approach.

Victor-Savu · 2018-02-12T17:44:17Z

I'm trying to merge this on v1.1

If there is any way I can help with that, please let me know.

I wanted to ask if pest is using a particular branching model. If not, I would highly recommend GitFlow. Adopting such a well known branching model could benefit the project development in the long term by providing contributors a familiar way of working.

Victor-Savu · 2018-02-12T18:04:41Z

Also, Hipchat or another chat service for development would be useful :) I have really abused this PR thread for discussions which are not related to the changes, but rather to the pest development as a whole.

dragostis · 2018-02-12T18:25:22Z

If there is any way I can help with that, please let me know.

I wanted to ask if pest is using a particular branching model. If not, I would highly recommend GitFlow. Adopting such a well known branching model could benefit the project development in the long term by providing contributors a familiar way of working.

I'm aware of GitFlow, but I guess I got sidetracked at one particular point. I'll merge v1.1 on master, then branch out v1.0 for backward compatibility.

Also, Hipchat or another chat service for development would be useful :) I have really abused this PR thread for discussions which are not related to the changes, but rather to the pest development as a whole.

The Gitter channel is in active use. :D

This reverts commit dae7e88.

dragostis reviewed Oct 8, 2017

View reviewed changes

dragostis reviewed Oct 9, 2017

View reviewed changes

Victor-Savu added 10 commits October 21, 2017 15:48

Extract ast, parser and validator into pest_meta

c1e30aa

Separate defaults generation from consume_rules

5525216

Rename Grammar{Parser,Rule} -> Pest{Parser/Rule}

1319bde

Use the maplit crate for defining keyword sets

02d445d

Remove unused rules soi and eoi

47cfdbd

Use functional style for validation

927ac86

Make validator return Result instead of panicking

d718e67

Add macro for PestParser rules

f0337c3

Use match in the state parsing macro syntax

b934c5a

Add use-case for pest_meta as a syntax colorizer

7387dde

Victor-Savu changed the title ~~[WIP] Extract the parser and validator from the pest_derive crate into pest_meta~~ Extract the parser and validator from the pest_derive crate into pest_meta Oct 22, 2017

dragostis reviewed Oct 29, 2017

View reviewed changes

Victor-Savu added 2 commits October 30, 2017 00:16

Remove redundant example section in Cargo.toml

49e39e0

Put spaces inside braces in all the unsafe places

7c44ad9

dragostis approved these changes Oct 30, 2017

View reviewed changes

Bootstrap pest parser using pest_derive v1.0.3

4a07821

dragostis reviewed Feb 3, 2018

View reviewed changes

dragostis requested changes Feb 3, 2018

View reviewed changes

Victor-Savu added 3 commits February 3, 2018 06:37

Reference strings, idents and ranges in the AST nodes

dae7e88

Change pest_meta licence to MIT/Appache-2.0

4d7fe48

Format according to review

4d0448b

Fix failing tests

33195d7

Victor-Savu mentioned this pull request Feb 4, 2018

Pluggable Backends #178

Open

Merge branch 'master' into feature/meta

03515ab

dragostis reviewed Feb 12, 2018

View reviewed changes

Victor-Savu and others added 6 commits February 12, 2018 20:45

Revert "Reference strings, idents and ranges in the AST nodes"

55f0098

This reverts commit dae7e88.

Merge branch 'master' into feature/meta

2057588

Removed meta example, for now.

95c5e5f

Improved formatting.

333c9d8

Renames grammar file.

9b044a5

Added pest_meta to projects.

c5e533a

dragostis merged commit ec9a98c into pest-parser:master Feb 18, 2018

Victor-Savu deleted the feature/meta branch February 19, 2018 09:20

		@@ -0,0 +1,99 @@
		grammar_rules = _{ soi ~ grammar_rule* ~ eoi }

Extract the parser and validator from the pest_derive crate into pest_meta #159

Extract the parser and validator from the pest_derive crate into pest_meta #159

Conversation

Victor-Savu commented Oct 8, 2017 • edited Loading

Victor-Savu commented Oct 8, 2017

dragostis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Victor-Savu Oct 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dragostis commented Oct 8, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dragostis commented Oct 15, 2017

Victor-Savu commented Oct 15, 2017

dragostis commented Oct 15, 2017

dragostis commented Oct 15, 2017 • edited Loading

dragostis commented Oct 15, 2017 • edited Loading

Victor-Savu commented Oct 21, 2017

Victor-Savu commented Oct 22, 2017

Victor-Savu commented Oct 29, 2017

dragostis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Victor-Savu commented Oct 29, 2017

dragostis left a comment

Choose a reason for hiding this comment

Victor-Savu commented Oct 30, 2017

Victor-Savu commented Feb 2, 2018

dragostis commented Feb 2, 2018

Victor-Savu commented Feb 3, 2018

Choose a reason for hiding this comment

dragostis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Victor-Savu commented Feb 3, 2018

dragostis commented Feb 3, 2018

Victor-Savu commented Feb 3, 2018

Victor-Savu commented Feb 11, 2018

Extract the `parser` and `validator` from the `pest_derive` crate into `pest_meta` #159

Extract the `parser` and `validator` from the `pest_derive` crate into `pest_meta` #159

Victor-Savu commented Oct 8, 2017 •

edited

Loading

Victor-Savu Oct 9, 2017 •

edited

Loading

dragostis commented Oct 15, 2017 •

edited

Loading

dragostis commented Oct 15, 2017 •

edited

Loading