Windows Support

[dabrahams]

I just deleted / commented out all the YAML stuff and all the tests pass on Windows. I only need CBOR support, and was wondering whether you'd consider breaking PotentCodables into separate packages?
Because Cfyaml uses autoconf, I anticipate difficulty porting it to Windows, but it's possible it could work if I can find a replacement unistd.h. But all of those are long-term solutions. I'd rather not fork your library, but it seems to be the only actively-maintained implementation of CBOR coding anywhere.

Although, now that I look at your docs, I'm not sure whether you actually supply the functionality I need. I want to accomplish essentially this (that package also has portability problems and is not currently passing its own tests).

Does PotentCodables do that? What I see in the docs (though I may have missed it) looks like it's for dynamically traversing already-serialized CBOR representations, but I have an existing Codable data structure that I want to serialize and deserialize.

Thanks!

[kdubb]

I only need CBOR support, and was wondering whether you'd consider breaking PotentCodables into separate packages?

This is something I had thought of but never implemented. If it's as easy as publishing multiple Package.swift files I'm onboard; but I never investigated what it would actually take.

now that I look at your docs, I'm not sure whether you actually supply the functionality I need

CBOR support should be complete; including CBOREncoder/CBORDecoder (we use them heavily). It even supports normal and deterministic encodings. Any other deficiencies should be considered a bug.

Does PotentCodables do that?

Apologies but I'm not exactly sure what "that" is that you are asking for but I'm guessing the answer it "it should already do that".

CBOREncoder/CBORDecoder get you "normal" Swift Codable support. CBOR gives you access to a decoded "tree" (usable via CBOREncoder.encodeTree and CBORDecoder.decodeTree.

[kdubb]

Also, if you are running into collisions (when testing multiple packages) CBOR.Encoder is an alias to the encoder and the same exists for the decoder.

If you want a deterministic encoding it's available as an option when creating the encoder or you can use CBOREncoder.deterministic as a statically available ready to encoder with otherwise default options (and CBOREncoder.default for the non-deterministic encoder).

[dabrahams]

If it's as easy as publishing multiple Package.swift files I'm onboard; but I never investigated what it would actually take.

Pretty sure you'd need to put them in separate repositories. You can look at CBORCoding and Half (on which it depends) for an example.

CBOREncoder/CBORDecoder get you "normal" Swift Codable support

I think that's all I'm after.

CBOR gives you access to a decoded "tree" (usable via CBOREncoder.encodeTree and CBORDecoder.decodeTree.

Is this “tree” essentially just a Codable type that can be decoded from any arbitrary CBOR-encoded data?

if you are running into collisions (when testing multiple packages)

Sorry, I don't know what you mean by that. Care to elaborate?

[kdubb]

Is this “tree” essentially just a Codable type that can be decoded from any arbitrary CBOR-encoded data?

Yes. CBOR is the in-memory representation of arbitrary CBOR values. Parsing/reading goes from Data to CBOR to Codable & writing goes from Codable to CBOR to Data.

If you want to have arbitrary CBOR values you can add a CBOR value to your struct/class .
E.g.

struct MyThing: Codable {
  var id: String
  var kind: ThingKind
  var data: CBOR
}

Allowing data to have an arbitrary value, or tree of values when considering maps/arrays.

Sorry, I don't know what you mean by that. Care to elaborate?

Haha sorry, I was just meaning if you were testing the other package and PotentCBOR together you can disambiguate easily between the different CBOREncoder/CBORDecoder implementations because PotentCodable aliases then nested in the CBOR enum as Encoder and Decoder. Saves you from having to make type aliases in a separate files.

[dabrahams]

Yes. CBOR is the in-memory representation of arbitrary CBOR values. Parsing/reading goes from Data to CBOR to Codable & writing goes from Codable to CBOR to Data.

Oh, it's rather a shame to have to pass through an intermediate format.

if you were testing the other package and PotentCBOR together

Heh, I don't think I'd try that. "Don't borrow trouble" as my mother-in-law used to say.