8 ms·

Visualising an Asynchronous Monad

80 points by astrada 12y ago

poseid 12y ago
nice demos, these feel a bit like playing with an oscilloscope
- seanmcdirmid 12y ago
  Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
  - agumonkey 12y ago
    Funny how things are going back to fundamental ways of visualizing systems. Will Haskell be praised by Electric Engineer now ?
  - Vektorweg 12y ago
    Directly coding concurrent stuff at all is highly unsafe. Haskellers prefer safety, not debuggers.
    - seanmcdirmid 12y ago
      Yes, because "typed programs can't go wrong" is not really a promise, but a desperate wish.
- avsm 12y ago
  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.
  - malandrew 12y ago
    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?
    - avsm 12y ago
      The homepage is at https://opam.ocaml.org https://opam.ocaml.org, and the repository of packages at https://github.com/ocaml/opam-repository https://github.com/ocaml/opam-repository. Mailing list is opam-devel@lists.ocaml.org.
  - edwintorok 12y ago
    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 https://www.efficios.com/babeltrace [1] http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwindow http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwind...
    - talex5 12y ago
      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.
      - edwintorok 12y ago
        I've tried LTTng once, but it was quite complicated to set up, and required patching the kernel. It seems they improved that, it only needs a kernel module so I might give it another try. I also used 'perf timechart'[0] in the past, or rather I tried to, but the traces on any realistic workload generated SVG files so large that it was too slow to open in firefox/inkscape etc. Your approach seems to be more scalable as it doesn't generate one huge image/SVG but rather generates that zoomable view via Javascript on-the-fly, right? [0] http://web.archive.org/web/20130729151516/http://blog.fenrus.org/?p=5 http://web.archive.org/web/20130729151516/http://blog.fenrus...

80 points by astrada 12y ago

poseid 12y ago

nice demos, these feel a bit like playing with an oscilloscope

seanmcdirmid 12y ago
Oscilloscopes are actually the best way to debug data flow (since the 50s), this looks like the future of Haskell debugging to me.
- agumonkey 12y ago
  Funny how things are going back to fundamental ways of visualizing systems. Will Haskell be praised by Electric Engineer now ?
- Vektorweg 12y ago
  Directly coding concurrent stuff at all is highly unsafe. Haskellers prefer safety, not debuggers.
  - seanmcdirmid 12y ago
    Yes, because "typed programs can't go wrong" is not really a promise, but a desperate wish.
avsm 12y ago
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.
- malandrew 12y ago
  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?
  - avsm 12y ago
    The homepage is at https://opam.ocaml.org https://opam.ocaml.org, and the repository of packages at https://github.com/ocaml/opam-repository https://github.com/ocaml/opam-repository. Mailing list is opam-devel@lists.ocaml.org.
- edwintorok 12y ago
  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 https://www.efficios.com/babeltrace [1] http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwindow http://lttng.org/files/lttv-doc/user_guide/c42.html#mainwind...
  - talex5 12y ago
    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.
    - edwintorok 12y ago
      I've tried LTTng once, but it was quite complicated to set up, and required patching the kernel. It seems they improved that, it only needs a kernel module so I might give it another try. I also used 'perf timechart'[0] in the past, or rather I tried to, but the traces on any realistic workload generated SVG files so large that it was too slow to open in firefox/inkscape etc. Your approach seems to be more scalable as it doesn't generate one huge image/SVG but rather generates that zoomable view via Javascript on-the-fly, right? [0] http://web.archive.org/web/20130729151516/http://blog.fenrus.org/?p=5 http://web.archive.org/web/20130729151516/http://blog.fenrus...