From Karchnu to ~arestifo/crystal-cbor
On 6/23/21 3:48 PM, ~karchnu wrote: > This time with the right formatting. > > I put tests in the same commit, > since this will be added this way in master. Just a reminder, there are a few patches waiting. ;-)
From Karchnu to ~arestifo/crystal-cbor
On 6/23/21 3:17 PM, Alberto Restifo wrote: > Path applied, > Thanks! Okay, so up to this point we have: - UUID and their tests merged in a single commit - tests for the CBOR user API - fixed source code formatting I hope the rest will come soon! :)
From Karchnu to ~arestifo/crystal-cbor
On 6/23/21 10:37 AM, Alberto Restifo wrote: > First of all, thanks a lot for the spending time on improving > the library, I appreciate! > >> - limiting hash >> keys to integers, floats, bytes and strings > > While I understand the idea behind this, > I think it’s actually against the CBOR RFC specs. > The spec says, when defining the maps data type: > >> Major type 5: a map of pairs of data items. > > A data item can be any of the CBOR supported data types,
From Karchnu to ~arestifo/crystal-cbor
On 6/23/21 10:23 AM, Alberto Restifo wrote: > Thanks for the patch! > > Personally, I see no advantages in making this functionality opt-in: > All the types are correctly scoped and will only act if used > with a cobr decoder/encoder. > > Can you move this logic to the from_cbor.cr and the to_cbor.cr > files respectively, so it’s always included and follows the rest > of the library pattern for those type extension. > Sure, I'm on it.
From Karchnu to ~arestifo/crystal-cbor
On 24/11/2020 16:07, Alberto Restifo wrote: > It would be great if you could add some tests for this I did, and there is a lot of code I didn't send, yet. Will do that probably this week-end, sooner if I find the motivation. It will be soon up to par with the JSON library (I hope, at least). For now, I do have something that is working, I did a few programs [1] but the API may be improved to be as simple as the JSON one. I think about the main loop in my `cq` command [2], which is way too complex for what I want to do. [1]: https://git.baguette.netlib.re/Baguette/cq [2]: https://git.baguette.netlib.re/Baguette/cq/src/branch/master/src/cq.cr#L23
From Karchnu to ~arestifo/crystal-cbor
Just to let you know, I don't push new PRs now because I wait for you to read my previous ones, but I implemented CBOR::Any. It is really useful to have the same API than JSON. I still didn't merge my code for Float16. I had more useful stuff to do, but it will surely be ready once we get the other PRs accepted. After that I will review the current code to check for possible security breaches. I will use this library for production, and I have to be confident that _at least_ the simplest attacks are mitigated.
From Karchnu to ~arestifo/crystal-cbor
On 11/11/2020 18:58, Alberto Restifo wrote: > I marked the first patch as rejected, so we can keep the conversation going in this patch. There was a problem with from_cbor on serialized objects with to_cbor. Here is a minimal working example of the problem: https://paste.ofcode.org/fjhC7SacFbkqSddxDuMy5Y First, a JSON representation, a CBOR representation after a to_cbor, and finally a CBOR representation after a from_cbor. The last one lacks the "location2" attribute. The current patch solves this by fixing the size of encoded hashes, but decoding unbounded hashes still is a problem. Will try to fix it maybe this weekend.
From Karchnu to ~arestifo/crystal-cbor
Hello all. Just want to say a few things. First, thanks for the effort, this is a great start for this kind of library. Second, I'm working on this CBOR library, and its integration into the language has to be almost as smooth as the JSON mapping for my needs. Let's try to get it working! Third, this is a first time for me on this platform, I hope you'll be indulgent. :) My first proposal include only the first commit, which didn't pass the tests. This proposal fixes everything.