Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Sep 30 17:44
    steviez closed #351
  • Sep 30 17:44
    steviez commented #351
  • Sep 30 00:25
    epage commented #351
  • Sep 29 23:24
    steviez opened #351
  • Sep 29 12:48
    mitsuhiko commented #346
  • Sep 27 14:11
    WhyNotHugo synchronize #349
  • Sep 27 14:10
    WhyNotHugo synchronize #349
  • Sep 27 06:58
    Kixunil commented #346
  • Sep 26 18:41
    epage commented #346
  • Sep 26 18:40
    epage edited #340
  • Sep 26 15:03
    epage edited #349
  • Sep 26 15:00
    epage closed #350
  • Sep 26 15:00

    epage on main

    refactor: Remove use of `extern… Merge pull request #350 from ep… (compare)

  • Sep 26 14:48
    epage synchronize #350
  • Sep 26 14:48

    epage on main

    fix(fuzz): Unbreak tests (compare)

  • Sep 26 14:41
    epage opened #350
  • Sep 26 14:34

    epage on main

    refactor(fuzz): Avoid breaking … (compare)

  • Sep 26 13:26
    WhyNotHugo opened #349
  • Sep 24 16:58

    ordian on main

    fix: Fuzz build error (#348) T… (compare)

  • Sep 24 16:58
    ordian closed #348
André Zanellato
@AZanellato
Nice :smile:
I'll try to check something later tonight after my working hours are done
ironyman
@ironyman
I would like to help too :D
Andronik Ordian
@ordian
@ironyman hello! Would you be interested in adding toml 0.5 support? ordian/toml_edit#58
This would require changing a parser (https://github.com/ordian/toml_edit/tree/master/src/parser) as well as e.g. adding new Value type "dotted keys".
André Zanellato
@AZanellato
Hi @ordian ! So, I'm checking the codebase and from what I am gathering I would need to change the document parser here: https://github.com/ordian/toml_edit/blob/master/src/parser/document.rs Which uses the macros defined here:
https://github.com/ordian/toml_edit/blob/master/src/parser/macros.rs
Is that it? :smile:
ironyman
@ironyman
sure
Andronik Ordian
@ordian
@AZanellato I guess that would require changing all the parsers, including the macros. The implementation of Document::from_str would first convert &str to Token stream and then use document parser on top of tokens. This probably means changing error type to include Token error.
André Zanellato
@AZanellato
Yeah, that makes sense :smile:
I have been reading the parser that you posted on #57 and taking a look at the codebase first but will let you know as soon as I made some progress :)
André Zanellato
@AZanellato
@ordian do you have any reading material on parsers I could use as well? :)
Andronik Ordian
@ordian
@AZanellato hey, for beginners I would recommend http://www.craftinginterpreters.com/contents.html chapters 4-6. Also searching for "parser combinator" would help, since it is related to the crate (combine) used for parsing. Hope that helps :)
André Zanellato
@AZanellato
Nice! Thank you very much. I was checking a lot of stuff about combine and that has been useful in understanding the code and how I can extend it
I was really hoping I could contribute faster, but I need to do some studying first :sweat_smile:
Andronik Ordian
@ordian
@AZanellato no worries, take your time and don't hesitate to ask any questions no matter how "dumb" they seem ;)
André Zanellato
@AZanellato
Thanks! :smile:
André Zanellato
@AZanellato
Just to keep you guys posted, I've been studying parser and am still interested in doing this
Been quite busy this last week with my masters, but will come back ASAP :)
ironyman
@ironyman
Hey @ordian , I have a WIP. I added a t! test. My test is failing because serde is serializing a more verbose string for the toml document than the json one but they seem to be equivalent. Do you have any advice? https://github.com/ironyman/toml_edit/blob/master/tests/test_valid.rs#L382
thread 'test_dotted_key' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
 Object(
     {
<        "name": String(
<            "Orange",
>        "name": Object(
>            {
>                "type": String(
>                    "string",
>                ),
>                "value": String(
>                    "Orange",
>                ),
>            },
Andronik Ordian
@ordian
@ironyman hey, thanks for the PR! Seems like you've figured it out already, added a comment on the general approach in the PR.
ironyman
@ironyman
@ordian do you mean a Value variant or make InternalString an enum here?
pub(crate) type KeyValuePairs = LinkedHashMap<InternalString, TableKeyValue>;
because value is the the rhs of the = and dotted key is on lhs/
?
Andronik Ordian
@ordian
@ironyman Ah, yes, you're right. It seems like we need to generalize the key type (lhs) to be an enum. Not sure if that's the most obvious and ergonomic way to implement dotted keys though.
Andronik Ordian
@ordian
Also see https://github.com/toml-lang/toml/issues/499#issuecomment-502408935 on what is allowed/disallowed with multiple dotted keys definitions.
ironyman
@ironyman
I'm trying to make key parser parse into Vec<Key> and it's breaking everything :|
Andronik Ordian
@ordian
@ironyman hey, thanks for reaching out, I'll try to reserve some time this week to help overcoming the difficulties
ironyman
@ironyman
I managed to fix most of the test failures
the remaining failures are caused by me misunderstanding what Key.raw means I think
basically I was trying to get add dotted key to work, to do that I had to make the key parser parse dotted keys
which by the way made the key_path parser a wrapper around the key parser
and I changed struct Key to this
#[derive(Debug, Eq, PartialEq, PartialOrd, Ord, Hash, Clone)]
pub struct KeyComp {
    // Repr.raw_value have things like single quotes.
    repr: Repr,
    key: InternalString,
}

#[derive(Debug, Eq, PartialEq, PartialOrd, Ord, Hash, Clone)]
pub struct Key {
    pub(crate) comp: Vec<KeyComp>,
    raw: InternalString,
}
I'll fix the comp visibility later
Andronik Ordian
@ordian
@ironyman hey, so regarding Key.raw
Key.keyis a rust string corresponding to the key, so that we can make a lookup on a table, independent of the it's representation in toml, e.g. toml "\t key" and ' key' have the same "rust" key representation, but differ in raw field.
Does that make sense?
Andronik Ordian
@ordian
Let me know if there is anything I can help you with.
The PR you submitted looks in the right direction btw.
Steve Degosserie
@stiiifff
Hi! @ordian re. issue #217 in cargo-edit about retaining the predominant string style, my understanding is that the toml output is generated in toml_edit::Document. to_string_in_original_order, correct ? So, cargo-edit doesn’t much control over the output.
Andronik Ordian
@ordian
@stiiifff hey, not exactly. Document::to_string just serializes whatever it has in the internal representation to a string. We set the string values here and there. They both accept a generic argument Into<Value>, which is implemented here for a string.
It parses the rust string and if it doesn't have quotes, it uses the default " double quotes. So you can create e.g. value("'0.2'"), see this method.
Steve Degosserie
@stiiifff
Awesome thanks 🙏 will look into it.
ironyman
@ironyman
@ordian right now, I can’t decide between putting the key a.b.c in x = { a.b.c = .... } into table x’s KeyValuePairs or creating sub tables for a, b in x then putting c in table b’s KeyValuePairs
the first method would break x[“a”][“b”][“c”]
and the second method breaks to_string and sorting by key
Andronik Ordian
@ordian
@ironyman hmm, it seems like dotted keys don't play nicely with our structured API, let me think this through and come back to you with ideas
SamedhG
@SamedhG
Hey, My friend and I was interested in helping out with the Cargo-edit project and would love to see if you guys need
Any help
Off this project too since it's part of the cargo-edit
Thomas Harmon
@goodSyntax808
I am that friend ^. We saw the two open issues in toml_edit and we were planning on reading through the toml v0.5 spec and figuring out what needs to be changed in toml_edit to support all of the v0.5 spec. If anyone could point us to a specific part of the spec we need to add support for to help us get started faster, that would be much appreciated
Andronik Ordian
@ordian
hey @SamedhG and @thomasharmon808 !Thank you for your interest in helping out with cargo-edit and toml-edit. Regarding toml v0.5, here is the list for things that were added to toml-rs: alexcrichton/toml-rs#224 (it's probably not an exhaustive list). Support for hex/octal/bin literals was already added in ordian/toml_edit#70, and dotted keys are being worked on in ordian/toml_edit#72.