-
Notifications
You must be signed in to change notification settings - Fork 173
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make the tracing version more available. #180
Comments
Having it in opam sounds risky (could easily get the wrong version). Ideally:
The main problem I see is that |
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. |
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 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" (ocaml/opam#2247) would be a nicer solution to the problem, but they aren't available yet. |
I'm not very fond of the fact that installing a package that is not lwt, would change lwt's core behavior completely. I personally think having to pin a specific version of lwt for tracing is fine. It's not something you do often. |
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. |
Is there still any plan to make the tracing part of the main lwt? |
@talex5 What do you think about building tracing into Lwt unconditionally, to be toggled on/off at runtime? |
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) |
Also, @talex5, is tracing being used these days at Mirage (or elsewhere)? |
It never got updated to Lwt 3, so probably not. Would be nice to have it back, though! |
(actually, I think Takayuki Imada has been using it to profile Mirage networking recently) |
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/
The text was updated successfully, but these errors were encountered: