avitex / rust-dangerous

Rust library for safely and explicitly parsing untrusted data
MIT License
51 stars 4 forks source link

It has begun… #15

Closed Byron closed 3 years ago

Byron commented 3 years ago

…and I hope you don't mind using this raw clickbait title to inform you about current events involving the awesome dangerous crate.

Currently there are two projects wanting to use gitoxide for cloning repositories, which is, among other things, blocked by implementing a git-config parser. One of these is the to my mind very promising [radicle][https://radicle.xzy], and the other one I am not sure to what extend I am supposed to talk about it :D.

Now that @crutchcorn has started the implementation, dangerous will be powering a state of the art (and hopefully even more user friendly) parser for git config files.

Since you have been super enthusiastic for your work here and helped me so much in the process of finding the right crate for the job I was hoping there is a chance to extend this welcoming attitude towards @crutchcorn in case he has any questions regarding dangerous on his exciting journey this weekend.

PS: I saw there now even is a solution for zero copy self-referential structures which might even be something for use in git-config eventually. My guess is though that these won't be movable, which is something I believe is needed for parsed git-config files. Maybe this is entirely incorrect though, and if so please let me know 😅.

avitex commented 3 years ago

Hey Byron, I don't mind at all. You flatter me :') and sorry for the late response.

This is fantastic news, and I'm interested to see where your project's leads (will perhaps be powering my workflow in the future!). Radicle looks very interesting. Have never seen this project before, will keep my eyes on it.

I'm more that happy to help @crutchcorn on his implementation. There is more I wish to flesh out in this library as seen in the issues and whatever usability issues may arise I'd like to see fixed.

Ahhhh, the zc crate. Seems so simple yet has an lifetime issue I need to fix. I haven't touched code since I released it due to feeling stupid I made the mistake I did. The library works safely as is.. if you don't plan on using interior mutable structures like in this failing test. I do have an idea for a fix which I'll test in the next few days for it. The Zc structure on another note is movable, as the self-referential part refers to referring to the owned data within the same structure, as of which via the Storage trait must be stable/on the heap.

Thanks for letting me know about the progress! I'd love to help where I can

Byron commented 3 years ago

Hey Byron, I don't mind at all. You flatter me :') and sorry for the late response.

Same here 😅

Radicle looks very interesting. Have never seen this project before, will keep my eyes on it.

Actually it's already in Beta and available for download. Gitoxide is available there as well and the process was absolutely simple. For now, it's certainly not supporting full collaboration workflows comfortably, but it's a great show of what's possible, like… instant response to clicks in the GUI :D.

Ahhhh, the zc crate. Seems so simple yet has an lifetime issue I need to fix. I haven't touched code since I released it due to feeling stupid I made the mistake I did.

I think I remember that one, and I hope you won't be too hard on yourself as well as that the responses remained civil. I for one don't know many people who would even know how to start solving this.

The Zc structure on another note is movable, as the self-referential part refers to referring to the owned data within the same structure, as of which via the Storage trait must be stable/on the heap.

Right! I keep forgetting that the referenced data doesn't necessarily have to be living in the structure itself, but is most likely on the heap anyway. My head keeps equalling this with pins, which do allow exactly that, referring to structures on the stack, by temporarily disallowing the pinned objects to move…somehow :D. pin-project anyone :D?

This would also mean that in fact, zc would be usable for git-config, even though I have feeling the compile times would increase quite a bit due to the derive implementation that I have seen there. Clearly this is dangerous incomplete knowledge as my look was cursory at best. Anyway, @crutchcorn is definitely at liberty to implement it in any way that seems fitting and/or simple.

Exciting times!