Make the tracing version more available.

[Drup]

trafficstars

cc @talex5

The current way, which is to pin the dev version, is not optimal. Would it be possible to release tracing version for lwt version in opam, something like lwt.2.5.0-tracing ? How much of a burden would that be for you ?

If I'm not mistaken, opam should prioritize the regular lwt (@AltGr, can you confirm ?)

Down the road, we should probably find a way to integrate it better.

Edit: For people not aware of it: https://github.com/mirage/lwt/tree/tracing http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/

[talex5]

Having it in opam sounds risky (could easily get the wrong version).

Ideally:

• Lwt would build with tracing if an OASIS flag was set
• Lwt would accept a label argument for most constructors, which would be ignored when compiled without tracing. This would replace the wrappers in MProf.Trace, allowing libraries to support tracing without any extra dependency.
• There would be some opam mechanism to enable tracing. Possibly a flag, or the presence of some other package that was a depopt of Lwt (e.g. lwt-tracing).
• lwt.ml could do with a little refactoring to make adding tracing easier. Currently, much logic is duplicated (for performance?).

The main problem I see is that lwt.ml will become messier, with lots of conditional compilation for tracing vs non-tracing versions.

[Drup]

Having it in opam sounds risky (could easily get the wrong version).

Is that really a problem ? We have the same kind of things for camlp4 at the moment and it's working-ish.

For the "messy lwt" problem ... maybe we can just have two (subpart of) lwt.ml and choose one at compile time.

[AltGr]

There is no real way to prioritize the standard version in opam and have a tracing version available. Opam will always prioritize what is latest according to its version ordering, so what you could do is have a lower number for the tracing version (but then, unless you pin, it will get removed on opam upgrade). lwt.2.5.0~tracing would be below lwt.2.5.0 for that purpose (see http://opam.ocaml.org/doc/Manual.html#version-ordering for details).

Using a virtual package as an optional dependency could indeed be a way to provide a toggle for lwt. Feels like a workaround but I think that would work perfectly. @dbuenzli's "input variables" (https://github.com/ocaml/opam/issues/2247) would be a nicer solution to the problem, but they aren't available yet.

[Drup]

I'm not very fond of the fact that installing a package that is not lwt, would change lwt's core behavior completely. You wouldn't be able to see if you have this behavior just by "opam show lwt", in particular.

I personally think having to pin a specific version of lwt for tracing is fine. It's not something you do often.

[foretspaisibles]

ocamlfind has the nice feature of supporting selection of object files based on predicates. Following the common practice of shipping libraries with and without debugging symbols seems natural to me and one could install the two versions of the library and use ocamlfind predicates to select the library we want to link in.

[mseri]

Is there still any plan to make the tracing part of the main lwt?

[aantron]

@talex5 What do you think about building tracing into Lwt unconditionally, to be toggled on/off at runtime?

[talex5]

Sure, if you can find a way to do that without an unacceptable runtime penalty. You need to store a unique integer for each thread.

(and sadly, I don't have any time to work on this)

[aantron]

Also, @talex5, is tracing being used these days at Mirage (or elsewhere)?

[talex5]

It never got updated to Lwt 3, so probably not. Would be nice to have it back, though!

[talex5]

(actually, I think Takayuki Imada has been using it to profile Mirage networking recently)