01:56 <Tekk_> Hey, not sure if I'm just not seeing it in the docs but is there a way to derive a yojson serializer for an external type?

01:56 <Tekk_> Like ppx comes with the yojson plugin, but my structs contain UUID types and Uuidm doesn't slap a deriving on Uuidm.t

05:56 <Tekk_> I found the "working with existing types" bit for ppx deriving but it doesn't seem to work right? Went and created a new module with t = [%import: Uuidm.t] [@@deriving yojson], changed preprocess to staged_pps with ppx_import at the front of the list, but it complains that there's no value Uuidm.to_yojson.

06:06 <Tekk_> I'm guessing that failure is probably to do with the fact that a Uuidm.t = string rather than some record, but then I'm not sure why yojson isn't able to generate the serializers for it.

06:40 <Tekk_> I've worked around this by just defining in my own module to_yojson and of_yojson functions which ought to do the right thing (still not sure about of_yojson atm). It seems like you're not allowed to provide both a to_yojson and of_yojson override though? I've tried pretty much every variant of the [@to_yojson: ...]line I can think of.

16:46 <Tekk_> Alright, guess it's been 12 hours or so and plenty of joins: Anyone know the proper way to do yojson serialization on types you don't control which aren't records? The deriving import method seems to get confused because the backing type of a Uuidm.t is a string, and I can't figure out what the syntax is to specify both an overridden to_yojson and of_yojson on the field proper.

16:46 <Tekk_> Plus it'd make me specify those on every serializable field of the type which isn't great, but I can live with it.

21:57 <flux1> Tekk_: you can override both

21:59 <flux1> hmm, I was looking for an example from my own code soo.. :)

21:59 <flux1> (didn't find it)

22:00 <Tekk_> I'd appreciate it if you know how off the top of your head. obviously I've been changing the file around but I think I've tried foo: Uuidm.t [@to_yojson: ...] [@of_yojson: ...], [@to_yojson: ..., of_yojson: ...], and [@to_yojson: ..., @of_yojson: ...]

22:00 <flux1> how did you create that new module?

22:01 <Tekk_> For the new module I just created a new file. Let me recreate that since I gave up on it.

22:01 <Tekk_> For trying to get derive to derive deserializers

22:01 <Tekk_> I think it was literally just type uuid = [%import Uuidm.t] [@@deriving yojson] in a new file?

22:02 <flux1> you might get better results by defining a module with another name, put the variant module inside it with the correct name and then 'open' it where needed

22:02 <Tekk_> Why's that?

22:03 <flux1> also: I think you can use type my_uuid_type = Uuid.t and if you elsewhere then use my_uuid_type, it will try to use My_uuid_module.of_yojson etc

22:03 <flux1> well, usually it's bad business having duplicate module names

22:03 <flux1> in particualr in the top level scope where there are interface descriptions involved

22:03 <Tekk_> That's fair. It's not duplicated in this case (uuidm vs uuid)

22:03 <flux1> oh, so your module was Uuidm, but it was Uuid you are wrapping?

22:03 <Tekk_> Other way around.

22:03 <Tekk_> ca.desrt.dconf.service org.gnome.GConf.service org.gtk.vfs.UDisks2VolumeMonitor.service

22:04 <Tekk_> Whoa

22:04 <Tekk_> Sorry about that, wrong thing in the paste buffer.

22:04 <Tekk_> https://erratique.ch/software/uuidm/doc/Uuidm

22:04 <Tekk_> To wrap that I just made a uuid.ml in my project with the wrap.

22:04 <flux1> ok, so you created uuid.ml that does "include Uuid" and then does the of-json/to_json-stuff?

22:05 <Tekk_> Oh no, 2 diferent attempts

22:05 <flux1> and then all your data types refer to Uuid.t instead of Uuidm.t ?

22:05 <Tekk_> First I followed the instructions on the ppx readme about applying annotations to types you don't control

22:06 <Tekk_> Which would be ideal because then I don't have to annotate every use.

22:06 <Tekk_> https://github.com/ocaml-ppx/ppx_deriving Under working with existing types here.

22:08 <Tekk_> If I follow those instructions I get "Unbound value Uuidm.to_yojson" on a _none_ file

22:09 <Tekk_> Which I assumed was something to do with the fact that the underlying type of Uuidm.t is a string, not a record or anything like that.

22:10 <flux1> so do you refer to type Uuidm.t in your records?

22:10 <flux1> or Uuid.t

22:10 <Tekk_> Normally yes. Just to try it out I changed Uuidm.t to Uuid.t and it has the same error

22:11 <Tekk_> type t = [%import: Uuidm.t] [@@deriving yojson]

22:11 <Tekk_> That's the exact line in uuid.ml

22:11 <Tekk_> No difference whether I import or just have Uuidm.t there

22:12 <flux1> you get the error when compiling some module other than your Uuid?

22:13 <Tekk_> I'm actually not sure. The filename is _none_ (I assume due to preprocessing) when I dune build.

22:14 <flux1> did you say you define your own of_yojson/to_yojson for that Uuidm.t?

22:14 <Tekk_> That was plan B,

22:14 <Tekk_> Define an of_yojson and to_yojson in my own module and manually override it every time a record contains a Uuidm.t

22:15 <flux1> well that's not the only option

22:15 <flux1> you can dro pthat [@@deriving yojso], which I believe is the source of the problem

22:15 <flux1> and then define those functions once-and-for-all in your Uuid module

22:15 <flux1> and then use Uuid.t from there on

22:16 <flux1> ok, so the reason why that simple approach fails is because the type Uuidm.t is abstract; it cannot generate the functions for it

22:17 <Tekk_> Is it?

22:17 <Tekk_> I could've sworn that I looked in the source and there was literally type t = string

22:17 <flux1> you maybe looked at the implementation

22:17 <flux1> but the .mli exposes only 'type t'

22:18 <Tekk_> Ahh

22:18 <Tekk_> Alright, so now let's see if my deserializer is wrong.

22:20 <flux1> also about defining both to and of, this works: let foo_of_yojson _ = Ok 42 let yojson_of_foo _ = `String "helo" type t = { foo: int [@of_yojson foo_of_yojson] [@to_yojson yojson_of_foo] } [@@deriving yojson]

22:21 <flux1> of_yojson (`Assoc ["foo", `String "foo"]) and to_yojson { foo = 42 } then work as expected (that is to say: incorrectly :))

22:23 <Tekk_> Mhm, but at least it'd compile. I think I'm just down to my serde functions being bad so I'm going to stub that out like this.

22:24 <flux1> victory is nigh :)

22:24 <flux1> trick if you don't in particular case about the exact format: define a new type that incorporates yjson-compatible types and construct that record, etc

22:26 <Tekk_> Well now I'm onto some weird errors but I can stare at them for a bit. Thanks for the help flux1 c:

22:29 <flux1> good luck :). I guess I need to get some sleep, first work day starts in around 8 hours after a 4-week vacation..

22:32 <Tekk_> Ouch. Good luck playing catchup tomorrow :)

22:37 <Tekk_> flux1: Yeah, had to tweak my serializer and deserializer a touch but I got it.

22:38 <flux1> I also discovered your post on /r/ocaml and I'm anxious to see if you answer it or delete it.. ;)

22:41 <Tekk_> I'm better than that :D