Visualising an Asynchronous Monad
roscidus.com
Visualising an Asynchronous Monad
1–10 of 13 posts
Re: Visualising an Asynchronous Monad
#2nice demos, these feel a bit like playing with an oscilloscope
Re: Visualising an Asynchronous Monad
#3nice demos, these feel a bit like playing with an oscilloscope
Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
Re: Visualising an Asynchronous Monad
#4nice demos, these feel a bit like playing with an oscilloscope
Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
Funny how things are going back to fundamental ways of visualizing systems. Will Haskell be praised by Electric Engineer now ?
Re: Visualising an Asynchronous Monad
#5nice demos, these feel a bit like playing with an oscilloscope
It goes beyond just demos... we can apply this to a vast number of OCaml Mirage libraries and speed things up quite a lot.
One of the nice things about OPAM (the OCaml package manager) is that it can recompile upstream library dependencies if some new optional features gets inserted downstream. In this case, Thomas has put together a "lwt.profiling" library that adds profiling hooks, and then every upstream Mirage library gets systematically recompiled against this new functionality.
This way we can have profiling-free production code, and then just "opam install mirage-profiling" and have a coffee while everything gets instrumented. This is going to be incredible as we hook up more complex distributed unikernel-based systems.
Re: Visualising an Asynchronous Monad
#6nice demos, these feel a bit like playing with an oscilloscope
Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
Directly coding concurrent stuff at all is highly unsafe. Haskellers prefer safety, not debuggers.
Re: Visualising an Asynchronous Monad
#7nice demos, these feel a bit like playing with an oscilloscope
It goes beyond just demos... we can apply this to a vast number of OCaml Mirage libraries and speed things up quite a lot. One of the nice things about OPAM (the OCaml package manager) is that it can recompile upstream library dependencies if some new optional features gets inserted downstream. In this case, Thomas has put together a "lwt.profiling" library that adds profiling hooks, and then every upstream Mirage li…
Very interesting. I've been thinking about a similar feature that involves TAP-based tests. Where can I read more about this and any other similar features that OPAM has?
Re: Visualising an Asynchronous Monad
#8Earlier quoted context omitted.
Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
Directly coding concurrent stuff at all is highly unsafe. Haskellers prefer safety, not debuggers.
Yes, because "typed programs can't go wrong" is not really a promise, but a desperate wish.
Re: Visualising an Asynchronous Monad
#9nice demos, these feel a bit like playing with an oscilloscope
It goes beyond just demos... we can apply this to a vast number of OCaml Mirage libraries and speed things up quite a lot. One of the nice things about OPAM (the OCaml package manager) is that it can recompile upstream library dependencies if some new optional features gets inserted downstream. In this case, Thomas has put together a "lwt.profiling" library that adds profiling hooks, and then every upstream Mirage li…
Interesting, would it make sense to store/convert the trace in the CTF format[0]? Would the viewers from LTTng[1] be useful in analyzing this trace data?
[0] https://www.efficios.com/babeltrace [1] http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwind...
Re: Visualising an Asynchronous Monad
#10Earlier quoted context omitted.
It goes beyond just demos... we can apply this to a vast number of OCaml Mirage libraries and speed things up quite a lot. One of the nice things about OPAM (the OCaml package manager) is that it can recompile upstream library dependencies if some new optional features gets inserted downstream. In this case, Thomas has put together a "lwt.profiling" library that adds profiling hooks, and then every upstream Mirage li…
Interesting, would it make sense to store/convert the trace in the CTF format[0]? Would the viewers from LTTng[1] be useful in analyzing this trace data? [0] https://www.efficios.com/babeltrace [1] http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwind...
Thanks for the links. I haven't used these tools - are they useful? Which features are most helpful? Certainly we'll want to convert to or from some Linux trace format to combine traces that involve Linux and Mirage machines.