01:19 <companion_cube> TIL: `Float.min_max_num`

08:15 <d_bot> <darrenldl> astronavt: I've added an introduction to date time and stuff to the top of timere api doc, if you happen to have time to take a look: https://daypack-dev.github.io/timere/timere/Timere/index.html

09:11 <d_bot> <darrenldl> (anyone interested in timere/date time handling please feel free to chime in as well)

09:15 <d_bot> <Cyclomatic Complexity> Hey, anyone got any idea why `dune build @doc` with `odoc` might yield `Unbound Module` errors where `dune build .` and `dune runtest` don't?

10:56 <d_bot> <antron> @Drup @dinosaure the crappy syntax errors seem to be caused by ppxlib, reported already by @kit_ty_kate <https://github.com/ocaml-ppx/ppxlib/issues/221>. i tried with pre-ppxlib lwt_ppx, and it reports normal, useful syntax errors. i'll do some bisects to figure out if there is a ppxlib version that isn't broken

16:45 <d_bot> <Bryan.Bennett> I've got a small program that I am building with Dune that bundles BAP. I've recently updated it to opium 0.2.0. In the process, I reworked the two executables I have to use a shared library (one provides the opium web-frontend and the other provides the same functionality as a CLI entrypoint)

16:45 <d_bot> <Bryan.Bennett>

16:45 <d_bot> <Bryan.Bennett> After building, BAP fails to initialize with the following:

16:45 <d_bot> <Bryan.Bennett>

16:45 <d_bot> <Bryan.Bennett> ```

16:47 <d_bot> <Bryan.Bennett> I've got a small program that I am building with Dune that bundles BAP. I've recently updated it to opium 0.2.0. In the process, I reworked the two executables I have to use a shared library (one provides the opium web-frontend and the other provides the same functionality as a CLI entrypoint)

16:47 <d_bot> <Bryan.Bennett>

16:47 <d_bot> <Bryan.Bennett> After building, BAP fails to initialize with the following:

16:47 <d_bot> <Bryan.Bennett>

16:47 <d_bot> <Bryan.Bennett> ```

16:47 <d_bot> <Bryan.Bennett> Failed to load plugin "x86": Failed to load x86_plugin: error loading shared library: Dynlink.Error (Dynlink.Cannot_open_dll "(Failure\n \"/tmp/x86_pluginf71cfc.cmxs: undefined symbol: camlStr__string_match_1006\")")

16:47 <d_bot> <Bryan.Bennett> ```

16:47 <d_bot> <Bryan.Bennett>

16:47 <d_bot> <Bryan.Bennett> This seems like the standard library is missing? (`Str.string_match`?)

16:47 <d_bot> <Bryan.Bennett>

16:47 <d_bot> <Bryan.Bennett> Has anyone seen anything like this? Can anyone point me at how I might've screwed up?

16:50 <d_bot> <Bryan.Bennett> the standard dynlink dune building stuff applies. I depend on `findlib.dynload`. I have tried adding `-linkall` to `library_flags`...

17:33 <d_bot> <roddy> @Bryan.Bennett I don't know what the exact problem is, but fyi `Str` isn't actually part of the standard library; it's distributed with OCaml but not automatically linked (https://ocaml.org/manual/libstr.html)

17:34 <d_bot> <Bryan.Bennett> Yes - I'm aware of the distinction, but I would've assumed that dune knows that too and would link that in.

17:34 <d_bot> <Bryan.Bennett> But that's a useful distinction to make. I appreciate the reminder. Maybe I can figure out if that's an issue.

17:41 <companion_cube> (also, Str sucks)

17:42 <d_bot> <Bryan.Bennett> I didn't write the code causing that exception. I agree that it (mostly) sucks, but I'm not making "first-party" use of it :/

17:42 <companion_cube> oh ouch.