2016-04-22

<hcarty> I'm not sure if that would work though
<hcarty> companion_cube: That's what I need to figure out :-) And now talking to you... maybe GenM?
<companion_cube> hcarty: what other options are you considering?
<hcarty> Drup: Fair enough, on to other options
<hcarty> Drup: There was a discussion somewhat recently about concurrent consumers from a feed in Lwt. What is the recommended way to handle N consumers for one Lwt_stream.t?
<hcarty> For OCaml records you could create a set of bigarrays, one per field, if all the fields fit into the available bigarray types
<hcarty> twobitsp1ite: Are these OCaml record types or C structs?
<hcarty> twobitsp1ite: No, not really
<g4143> hcarty: I was thinking about that too but I but I'm wondering what else I would break if I installed Python2.
<hcarty> orbitz: It should, yes
<hcarty> g4143: There should be a python2 package (not sure what the name is) available to install as a work-around
<orbitz> hcarty: I am thinking of using polymorphic variants and I could just ahve `None in each variant, that should work, right?
<g4143> hcarty: Ubuntu 16.04 has Python 3 instead of Python 2 and apparently merlin/vim does not play with Python3.
<hcarty> orbitz: If the addition of a My_none case doesn't make things ambiguous then it seems like an reasonable thing to do
<hcarty> g4143: What's the problem? Haven't tried that combination yet.
<hcarty> There are also bindings to PCRE
<hcarty> sgronblo_: That one's pure OCaml
<hcarty> sgronblo_: re
<hcarty> And :MerlinYankLatestType if I need the text of the type
<hcarty> :MerlinTypeOf
<hcarty> apache2: I use merlin for that
<apache2> hcarty: that only gives you types for "public" things, not the instantiation of a functor 100 lines down from the main function
<sgronblo_> hcarty: ok fantastic, thanks
<hcarty> sgronblo_: 'open Core.Std'
<hcarty> vim personally
<hcarty> sgronblo_: (neo)vim, emacs, atom, sublime text all seem to have reasonable support
<hcarty> apache2: merlin, ocamlc -i foo.ml, utop
<hcarty> apache2: It's a limitation of labeled arguments that (2 |> a) won't work
<hcarty> apache2: ~foo:2 on its own is not valid OCaml syntax as far as I know

2016-04-21

<jtmcf> hcarty: yeah definitely, i have a friedn or two who would join too, let me know when this is starting up
<hcarty> Hopefully there's enough interest in the area to do something regularly
<hcarty> jtmcf: There will be :-)
<jtmcf> hcarty: there's ocaml meetups in Clarendon?
<hcarty> jtmcf: Clarendon
<hcarty> jtmcf: Just saw your question from a couple days ago... Arlington VA

2016-04-20

<hcarty> gasche: Thanks!
<gasche> hcarty: I created an issue to keep track of the need for Mantis documentation, thanks: http://caml.inria.fr/mantis/view.php?id=7236
<hcarty> Navigating/figuring out mantis can be a blocker on its own for more casual contributors
<hcarty> gasche: Having that information available would be good. Even better would be that information + a direct link to an appropriate mantis URL with filters applied

2016-04-19

<jtmcf> hcarty: outside of DC?
<hcarty> Algebr: Will do, thanks!
<Algebr> hcarty: email me maybe? edgar.factorial@gmail.com
<Algebr> hcarty: the other meetup was this one: http://www.meetup.com/OpenLate/events/229628135/ the speaker dropped out at last moment and I volunteered with an OCaml spiel, naturally.

2016-04-13

<hcarty> That should work with the protobuf extension too
<hcarty> t4nk822: For example [@yojson.key "foo"]
<hcarty> t4nk822: You can add a prefix to 'key'
<hcarty> Would be nice to catch that before the official release
<hcarty> aantron: If you can create a small reproducible case that seems like something worth putting on mantis sooner rather than later

2016-04-11

<hcarty> companion_cube: I suspect the flambda folks would be very interested in a benchmark which slows down that much

2016-04-08

<hcarty> leyyin: It doesn't exist yet, unfortunately

2016-04-07

<hcarty> Never mind... there are instructions right in the README for the opam-cross-windows repository
<hcarty> Can you make opam ignore a .install file in a package? I'm trying to add some of dbuenzli's packages to whitequark's opam-cross-windows repository and opam-installer doesn't play well with the cross compiler directory structure.

2016-04-06

<struktured> hcarty: ah ok, tx
<hcarty> struktured: It's been out for a while, with (I think) a backwards compatibility layer for ounit 1.x
<hcarty> scrabcakes: Can you show an example? pastebin/gist if it's more than a line or two

2016-04-05

<hcarty> (this may also be a faulty memory)
<hcarty> I remember seeing that version number in one of the pre-packaged opam versions floating around
<hcarty> companion_cube: I think 1.2.1~rc2 may be == 1.2.2

2016-04-01

<seangrove> hcarty: Just manually added a list of files to rm in the make target... not thrilled about it, but whatever for now.
<hcarty> seangrove: Something like a/m.ml and b/m.ml?
<seangrove> hcarty: hrm, that seems a bit bizarre. I have a few build targets, and I'd like for them not to clash. Right now ocamlbuild complains because of the top level cm* files, and then creates a _build/sanitize.sh script
<hcarty> seangrove: I don't know if there currently is a way to do that
<hcarty> mrvn: I hadn't thought of that, but it seems like an excellent idea.
<mrvn> hcarty: so when you compile something for the 4th time and still get the same error the compile would add an angry emoji?
<hcarty> pierpa: We already have opam using emoji. Adding them to the compiler seems like a logical step.

2016-03-31

<companion_cube> hcarty: if only...
<hcarty> companion_cube: The Gen approach seems nice :-)
<hcarty> companion_cube: Indeed
<hcarty> While the stdlib/core/batteries/containers/extlib/custom-personal-lib split is unfortunate, the Async/Lwt split is a bigger problem since it ties users' hands when libraries pick one to support instead of the other.
<Algebr`> hcarty: thanks!
<hcarty> Algebr`: Passing it around at work for comments
<hcarty> flux: Indeed. I've spent more time on it than I can afford to right now, but I plan/hope to figure it out later.
<flux> hcarty, :(
<hcarty> s/any/much/
<hcarty> Otherwise I'm not sure it will make any sense outside of folks already involved in the community
<hcarty> Algebr`: A nice addition would be some more details around each point on the list. What exists, why that doesn't meet the need.
<hcarty> flux: My tracing adventure yesterday ended in me throwing up my hands and running an otherwise blocking operation with Lwt_preemptive.detach
<hcarty> I haven't seen evidence of (7) either - it's unfortunate and worrisome if it's widespread
<hcarty> Algebr`: I don't think cohttp.unix exists yet, sadly
<hcarty> Algebr`: That would take care of the "10 lines + monads" issue
<hcarty> Algebr`: It would be nice to have concurrency-less cohttp working, for example. There were patches for this I think, but I'm not sure what their current state is.
<hcarty> Algebr`: As Drup said, it's your opinion piece. I'd need to think about it more.
<Algebr`> hcarty: would you like to add it? otherwise I'll add it
<hcarty> Drup: :-)
<hcarty> Algebr`: For 1: having [@@deriving pg_insert, pg_select] or similar would be nifty. For 2,4: opium?; For 5: No opinion; For 7: I think the attitude is friendly
<hcarty> ^ Exactly, opium makes getting a simple service up VERY easy
<hcarty> Algebr`: Because I think the web portion is quite nice in OCaml from a services perspective. And there is a lot of effort being put into the browser side too.
<Algebr`> hcarty: would you like to add anything?
<hcarty> Algebr`: I agree with 3, 6, 8, 9, 10, 11; not sure about 1, 2, 4, 5, 7
<hcarty> I agree that the separation is useful. For simple cases you don't need to worry about the Re.t form if you use Re_(pcre|glob|etc)
<hcarty> else ignore (Unix.go_back_in_time (abs_float s))
<hcarty> freehck: I think that's correct
<hcarty> freehck: Then Unix.select is the way to go
<freehck> hcarty: no way to use it, I have 4.01.0
<hcarty> freehck: I think there's something coming in 4.03.0... Unix.sleepf

2016-03-30

<doomy> hcarty: oh, nice. Thank you !
<hcarty> doomy: You can 'include' the modules in everything.ml and everything.mli if you want all your values, types, etc to live in Everything
<hcarty> companion_cube: It's worth reporting, at least to get an "official" opinion. Maybe for |> too?
<flux> hcarty, good luck, you're going to need it.. :)
<hcarty> flux: I've never used a tracing tool for something like this before - seems like a good time to start, thanks!
<hcarty> flux: cpp-driver (the C Cassandra interface) uses libuv internally. There's not direct tie to Lwt, which is still using libev
<flux> hcarty, it seems feasible to me that if there somehow were two event loops involved, one of them might still be stuck waiting for a signal (ie. suspension) to make them carry on..
<flux> hcarty, or do you run it in its own thread?
<flux> hcarty, how do you bind libuv to the lwt main loop?
<flux> hcarty, it should show that the program ends up in a select that waits for some file descriptor..
<flux> hcarty, have you tried tracing tools?
<hcarty> The bindings are using the C interface to Cassandra which uses libuv internally. Maybe there's an issue there, a conflict between libev in Lwt and libuv in the driver...
<hcarty> To make it weirder, if I open it in lldb (currently trying this on a Mac) and I suspend then resume the process it exits properly
<hcarty> toolslive: No, no threads are canceled in the code
<toolslive> hcarty: do you cancel the threads at the end of your application ?
<hcarty> What could cause Lwt_main.run to never return? A colleague and I are working on some Cassandra bindings (to hopefully release some time soon). The Lwt version works except that Lwt_main.run seems to never return.

2016-03-29

<hcarty> Followed by a normal 'opam upgrade''
<hcarty> 'opam upgrade --fixup' seems to be the answer
<Algebr``> hcarty: I also got that
<hcarty> I'll wait for that I guess, as that will require effectively everything to rebuild
<hcarty> I was looking at the opam.ocaml.org website rather than Lwt's opam file
<hcarty> Ah, ok thank you!
<ygrek> hcarty, "camlp4" {= "4.02+7"} (* lacks "camlp4.quotations.o" *)
<hcarty> There doesn't seem to be any reason why these two would be in conflict
<hcarty> Any idea why I would get this error from opam? "camlp4.4.02+7 is in conflict with lwt.2.5.1"
<hcarty> ohCamel: It wraps the command you provide in syntax which should be OS-appropriate
<hcarty> ohCamel: Lwt_process.shell doesn't run the application

2016-03-01

<seangrove> hcarty: Will do
<hcarty> seangrove: It looks like that information is missing from the manual (https://github.com/gasche/manual-ocamlbuild) so it's probably worth adding a bug report/feature request.
<hcarty> companion_cube: ... would be nice. I think there was a request to that effect, maybe with a PR?
<hcarty> I got ocp-build to build but I'm not sure how safe my changes are.
<hcarty> rks`: Ah, good point. Thanks!
<rks`> hcarty: just use your 4.02 built ocp-indent with your 4.03 code
<hcarty> ocp-build has several breakages on 4.03, which unfortunately prevents ocp-indent from being usable on 4.03.
<hcarty> Are there any OCamlPro folks about? With information on plans for tool compatibility with 4.03.
<hcarty> companion_cube: It's worth adding https://github.com/def-lkb/ocp-indent-vim if you're going to try ocp-indent again

2016-02-29

<aantron> hcarty: thank you :)
<hcarty> aantron: Your ocamlbuild namespaces plugin looks quite nice!

2016-02-23

<hcarty> ggole: And FWIW it looks like ocaml-stdint is the modern/supported incarnation of ocaml-uint
<hcarty> ggole: I suspect you're correct
<lokien> hcarty: oh, I'm fine with that then
<hcarty> toolslive: read 4 bytes as an Int32.t, you could end up with a negative value
<ggole> hcarty: I suppose use ocaml-uint then
<hcarty> Blue, like infinity
<hcarty> lokien: It's not actual magic, just feels like it
<hcarty> The sign does in the lookup case
<hcarty> s/uses/be used/
<hcarty> ggole, toolslive: A bag of bits which need to compare correctly and, in some cases, uses as an offset in a separate file
<toolslive> @hcarty what are you doing with the unsigned ints ?
<ggole> hcarty: do you need unsigned operators or just a bag of a certain number of bits?
<hcarty> This is specifically for reading values from disk in some arbitrary raw format.
<hcarty> At this point, what is the best/proper way to use unsigned integers in OCaml? The uint library? ctype's uint support? Pretend that Int32.t and Int64.t aren't signed when I want an unsigned integer?
<hcarty> lazy%foo[@foo]

2016-02-22

<hcarty> toolslive: A stale setup.data maybe?

2016-02-17

<wirrbel> thank hcarty
<hcarty> wirrbel: #mod_use "myothermode.ml";;
<insane_person> hcarty: I want fancier bar! with combo counter and explosions!
<hcarty> Use it wisely
<hcarty> insane_person: utop gives you that power
<hcarty> pflanze: Unless I misunderstood what you're asking... if you mean cpp-style location hints then I'm not sure.
<hcarty> pflanze: __LINE__ and several others
<lokien> hcarty: oh, sure. it works now! I couldn't wrap my mind around these errors, thanks
<hcarty> lokien: Or swap the position of xs and the function
<hcarty> lokien: You probably need to add a ~f label to the function. Core changes the signature of a lot of functions vs the stdlib
<hcarty> lokien: ? ggole's response should do what you want, minus whatever changes are required to match Core's API
<lokien> hcarty: so.. 134217728 GB? sweet!
<yawnt> hcarty: a restart fixed it
<hcarty> yawnt: The package may not be installed. Or the findlib package name may not match the module name, depending on the library.
<hcarty> lokien: It's in bytes

2016-02-16

<elfring> Kakadu, hcarty, octachron, aantron: Are there any more attempts to express open issues (like the parallelism aspect) in the available documentation besides the wording "Lightweight threads"?
<elfring> Kakadu, hcarty: May I expect support for parallel execution on several processors from the wording "Lightweight threads for Posix 1003.1c and Win32" in the document "http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.html"?
<hcarty> "real" threads are used internally. As of 4.02.3 OCaml only runs one of those threads at a time.
<hcarty> What do you mean by "too promising"?
<elfring> Kakadu, hcarty: Is the wording "Lightweight threads for Posix 1003.1c and Win32" too promising in the document ""http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.html?
<hcarty> elfring: If you want parallelism in OCaml code then you'll need to use multi-processing with a library such as the ones flux mentioned
<hcarty> elfring: OCaml's threads are not executed in parallel, with the exception of IO and some calls to C libraries.

2016-02-12

<hcarty> Updating a ref in general would be atomic, regardless of its content. It's the creation of the new value that goes into the ref which may not be.
<icicled> awesome, that's really good to know - thanks hcarty
<hcarty> If the expression on the right hand side of := allocates, though, then it's not
<hcarty> icicled: "my_bool_ref := false" should be safe without a wrapper

2016-02-10

<pgiarrusso> hcarty: feels like https://xkcd.com/927/ (XKCD “Standards”)
<pgiarrusso> hcarty: ROTFL
<hcarty> oasis/topkg/jenga/omake/OCamlMakefile/ocamlbuild/obuild/make is clearly the best choice
<hcarty> We almost got custom indexing operators in 4.03 but the type-disambiguation approach came up and conflicted enough that a decision was made to wait for 4.04
<hcarty> s/customer/custom/
<hcarty> There is work to add both customer indexing operators and potentially type-dismbiguated indexing
<hcarty> Are there specific things you are looking for? If the content is missing from ocaml.org it would be good to know so the site can be updated.
<hcarty> There may be something in OCaml From the Very Beginning - http://ocaml-book.com/
<hcarty> ergo: Some basic style guidelines are here: https://ocaml.org/learn/tutorials/guidelines.html
<hcarty> Drup: https://github.com/hcarty/ppx_defer -- thank you again for your help!
<hcarty> Drup: Either way, thank you so much for your help. This is a new area for me and I appreciate the guidance.
<hcarty> Drup: If I use that as a reference do you mind if I release ppx_defer under MIT? It's a small amount of code, so once I figure this out I'd like to write it up and put it on opam in case it's useful for others.
<hcarty> And I'll take a look
<hcarty> Drup: Updated with @metaloc and setting loc_ghost after creating the [%expr ...]
<hcarty> I'm not sure how to get around the identifier issue. How do I reorder expressions without using a temporary named value?
<hcarty> Oh nice, thanks
<hcarty> Drup: ghost?
<hcarty> Drup: Thanks... I hadn't used that variation. I thought I somehow needed to attach the [@metaloc ...] attributes to the now and later inside of [%expr ...]
<hcarty> Drup: Slight improvement to location reporting - still not correct or precise enough: https://gist.github.com/hcarty/2e817c5541b5f2758686

2016-02-09

<hcarty> Ah, I see... "_none_" - interesting
<hcarty> I can never remember how to interpret the character ranges in OCaml errors
<hcarty> It gives me the right line, with one too many characters I think?
<Drup> hcarty: yeah, as I said
<Drup> hcarty: really ? that's very surprising
<hcarty> Drup: The ("" : int) case seems to work properly, with OCaml pointing out the correct error at the correct location
<hcarty> Drup: Any pointers to how to avoid having "__ppx_defer_actual_result" accessible inside of <later>?
<hcarty> Drup: Thanks! I'll keep playing with it.
<hcarty> This code was mostly the result of trial and error... ppx_tools.metaquot is magic
<hcarty> s/looks/is/
<hcarty> Am I using ppx_tools correctly? The code seems simple and the result looks correct... I'm worried that it all looks too simple
<hcarty> For a Go-ish (let ic = open_in_bin "foo" in [%defer close_in ic]; do_stuff_with_ic)
<hcarty> It (is supposed to) rewrite ([%defer expr_later]; expr_now) into (let result = expr_now in expr_later; result)
<hcarty> A first attempt at a ppx extension: https://gist.github.com/hcarty/2e817c5541b5f2758686

2016-02-01

<caml_hump> hcarty: Thank you.
<hcarty> caml_hump: I don't think that there is for source files. #load_rec will try once they're compiled.

2016-01-31

<hcarty> seangrove: See also https://github.com/janestreet/ppx_sexp_conv for sexpressions
<hcarty> I haven't used the Jane St camlp4 extensions so I'm not sure what they need in order to work
<hcarty> SomeDamnBody: You're welcome. For extra fun, "ocamlbuild src/bar.inferred.mli" will put the automatically inferred interface for src/bar.ml into _build/src/bar.inferred.mli
<SomeDamnBody> hcarty, ^
<hcarty> seangrove: You can use ppx_deriving_yojson to get easy (de)serialization functions
<hcarty> SomeDamnBody: ocamlbuild src/foo.native (or ocamlbuild src/bar.cma)

2016-01-29

<seangrove> hcarty: Perfect, thank you!
<hcarty> seangrove: type person = { fav_colors : string list }
<hcarty> On the plus side, it sounds like 4.04 will come relatively quickly after 4.03
<octachron> hcarty, I like to have exotic list types from time to time, but having them appears unqualified by a module is a little too nasty; even for my taste
<octachron> hcarty, the local open in pattern one
<hcarty> octachron: Which PR is required, out of curiosity?
<hcarty> companion_cube: Agreed, that does look quite nice. A very light alternative to NFS/Riak/etc

2016-01-27

<hcarty> Or, more accurately, examples
<hcarty> That's good. I thought I had tested all of those plugins...
<hcarty> companion_cube: Not sure. It's enough that it complains if anything is missing, but I haven't used it in a while.
<companion_cube> hcarty: I'm not sure it's enough, is it?
<Leonidas> hcarty: thanks! But when I try it, I get an error because it suddenly can't find -lc -lm and -ldl
<hcarty> And from ocamlbuild you can use something like: https://github.com/hcarty/ocamlbuild-plugins/blob/master/mystatic.ml
<hcarty> Leonidas: -cclib -static
<hcarty> That could help reduce the clutter significantly if it happens
<hcarty> There is/was a request to allow all ocamlbuild configuration to be set in myocamlbuild.ml

2016-01-26

<hcarty> Yeah, they're keeping the camlp4 versions (not sure if they'll be actively maintained?) and there's an opam repository PR in place to rename the existing packages to have camlp4-specific names
<xificurC> hcarty: ah ok, it's separate
<xificurC> hcarty: maybe you're right
<hcarty> I dunno, opam provides a nice base to work from
<hcarty> My award for saddest loss from 4.03 goes to the loss of https://github.com/ocaml/ocaml/pull/69
<hcarty> I saw early February for creating a format 4.03 branch, release sometime after that
<hcarty> haesbaert: Yes
<hcarty> A lot of material was pushed to post-4.03
<haesbaert> 15:28 < hcarty> xificurC: Last I heard a test release is planned post-4.03. It won't be in 4.03.
<hcarty> xificurC: https://github.com/ocaml/ocaml/blob/trunk/Changes does a good job of covering what's happened
<hcarty> xificurC: Last I heard a test release is planned post-4.03. It won't be in 4.03.
<hcarty> xificurC: It's in the process of being merged in for the 4.03.0 release

2016-01-25

<_berke_> hcarty: interesting, thanks.
<hcarty> _berke_: I played around with the gadt bigarray change a bit here - https://github.com/hcarty/extbigarray/blob/master/src/extbigarray.ml

2016-01-22

<hcarty> Or, rather, it seems reasonable that 'a COULD be ('b, 'c) result
<hcarty> From an 'a Lwt.state perspective, it seems reasonable for 'a to be ('b, 'c) result, with exceptions still handled in the Fail case
<hcarty> I think the same issue is there for any type with a parameter
<smondet> hcarty: I've been thinking of Pervasives.result, it should be easy to make 85% of the code compatible, then every time one hacks around with Lwt.(.... return (`Ok blabla)) there'll be type errors to guide the changes
<hcarty> smondet: With a Pervasives.result type incoming I've been looking at what it would take to switch over
<hcarty> smondet: I've seen it and used it a lot - thanks for releasing the code!
<smondet> hcarty: I've been using http://seb.mondet.org/software/pvem_lwt_unix/index.html everywhere (which the functor here http://seb.mondet.org/software/pvem/index.html applied to Lwt + Lwt_unix wrapped functions)
<hcarty> How would you mix result-using code with Lwt in that case?
<hcarty> True :-)
<hcarty> Is there a better way to handle this in Lwt?
<hcarty> I've been using one internally (http://vpaste.net/fxqHc for the interface) but am wondering if something else exists already
<hcarty> Drup: (or other Lwt-interested folks) Is there an Lwt-ready result type module?

2015-12-30

<Algebr> hcarty: will Lwt seg fault or will I just get inconsistent data structures if i don't use the mutex when I should have been using it
<hcarty> Algebr: Only if you call a blocking ('a Lwt.t returning) function as part of the mutation

2015-12-23

<hcarty> You can also perform the conversion in multiple steps - a more or less direct/vanilla conversion to a temporary value, then perform the conversion to your final type in another step.
<hcarty> It's comparable to atdgen in my experience, but I suspect atdgen covers more edge cases since it's been around longer and been fairly heavily used
<MercurialAlchemi> hcarty: I don't think it does very well when the ocaml structure is very different from the original
<hcarty> MercurialAlchemi: You could use ppx_deriving_yojson for your JSON conversion needs

2015-11-30

<hcarty> Leonidas: This FFI tutorial also has some nice descriptions and examples

2015-11-24

<Drup> hcarty: possible, I don't remember
<hcarty> I may have that mixed up with something else...
<hcarty> Weren't there some other tweaks like if%lwt?
<Drup> hcarty: I think that's the only improvement
<hcarty> Drup: Thanks for the already-done fix :-) Do you think a release would be possible with all of the ppx improvements which have happened post-2.5.0? Or a separate opam package for lwt.ppx.
<hcarty> Thanks
<hcarty> Drup: Sure, I'll file it now
<hcarty> This is OCaml 4.02.3, Lwt 2.5.0 from opam
<hcarty> Removing the 'exception' case gets rid of the warning.
<hcarty> For example: http://vpaste.net/xuwG9
<hcarty> Does the Lwt PPX extension support match%lwt ... with | exception e -> ...? When I try I get an unused match case error.

2015-10-22

<hcarty> s/something //
<hcarty> Or another module which provides something similar functionality
<hcarty> Is there a way to inspect the contents of a Lwt_mvar.t without affecting its state? An equivalent to val is_empty : 'a Lwt_mvar.t -> unit
<hcarty> mfp: Thanks
<mfp> hcarty: you mean in terms of scalability? none
<hcarty> Potentially with a few thousand threads
<hcarty> Aside from managing the threads themselves, is there any issue with pushing aside Lwt threads with Lwt.async?

2015-10-13

<hcarty> def`: Very handy
<hcarty> Algebr: And more recently you can do some custom printf stuff via ppx. I don't know the details of how that works though.
<hcarty> Algebr: There is %a
<hcarty> They seem to be implicitly associated with the currently active thread, but that's more of a guess based on the interface than a real understanding of how they work
<hcarty> I'd like something very similar to a key but associated with the thread externally rather than internally
<hcarty> def`: Can you access keys from outside of the thread?
<def`> hcarty: keys ?
<hcarty> A way to associate an arbitrary identifying value with a specific thread, for example
<hcarty> Does Lwt provide a way to associate a value (or multiple values) with a thread from outside of the thread?