IRC channel logs

<zimoun>civodul: yes, it’s a followup to the original paper.

<rekado_>I’m halfway through the paper; struggling to translate it to actionable work in the GWL.

<rekado_>the way I see it we’re potentially doing too much work because we compute hash chains.

<zimoun>rekado_: oh! Neat! How do you implement the “constraint” monadic stuff (such as Applicative, Monad, etc.)?

<rekado_>I don’t see a good use case for dynamic dependencies yet.

<zimoun>BTW, I put in my TODO list to write a “blog entry” (for personal use at least) in order to explain such paper backed with “Scheme“. From my POV, it would help to rewrite the daemon, for instance.

<rekado_>one thing I took away from the paper is the possibility of using a suspending scheduler instead of topo-sorting the tasks in advance.

<zimoun>Ok. Are you trying to translate to GWL? Or only with Guix?

<rekado_>I think it’s not an urgent thing to change at this point. But it’s something I like to keep in mind for later.

<rekado_>with a suspending scheduler I could have dynamic dependencies, but I don’t know if that’s useful for GWL (I’m missing a good example), and I don’t know how it would fit in with the simple GWL abstractions.

<civodul>we have dynamic dependencies for grafts

<civodul>but in general, it's best to avoid them

<rekado_>right

<rekado_>while working on the PiGx wastewater pipeline I found that the strict Make-like file-based graph construction that snakemake uses can be a limitation

<zimoun>and for some cross-compilation, isn’t it?

<rekado_>sometimes we want to cut out part of the graph based on an intermediate result

<rekado_>I’m not sure we can do that with the GWL, because graph construction happens before any work is done.

<rekado_>but we can construct the graph more directly, not only by matching inputs with outputs

<rekado_>supporting this use case is more important to me than a generic solution to dynamic dependencies

<rekado_>ugh: ‘This package installs a self-contained Conda instance that is managed by

<rekado_>the R/Bioconductor installation machinery. This aims to provide a consistent

<rekado_>Python environment that can be used reliably by Bioconductor packages.’

<zimoun>rekado_: ahah! From where?

<civodul>speaking of which, i plan to try and implement "early cutoff": if a build result is unchanged modulo self, use grafting for dependents instead of buildilng them

<civodul>*building

<rekado_>zimoun: basilisk on Bioconductor

<rekado_>civodul: sounds good!

<rekado_>zimoun: I’m important Bioconductor packages again.

<rekado_>*importing

<zimoun>ouch! well, I boycot such package. ;-)

<rekado_>tried using https://github.com/google/ruy/blob/master/cmake/bazel_to_cmake.py for tensorflow

<rekado_>doesn’t work

<rekado_>even with a bunch of changes I’m stuck at missing features that have no translation

<civodul>we should make friends with the folks who write bazel-to-cmake converters

<civodul>(who would have thought i'd find myself in a situation where my preference goes to cmake?)

<rekado_>I’m going back and forth between bazel-to-cmake conversion and attempting to package bazel.

<rekado_>each of these options always seems much worse than when I last tried.

<civodul>heh

<civodul>the converter above looks rather basic

<civodul>i wonder what it would take to implement the missing Bazel features that something like Tensorflow uses

<civodul>i must be naive though :-)

<rekado_>I added more and more substitutions to get past the initial errors (relating to keyword arguments to ‘load’), but then hit the unimplemented repository_rule, which is a datatype combining a configuration procedure taking a context, and a dictionary to augment the context.

<rekado_>I don’t know nearly enough about cmake or bazel to work around this

IRC channel logs

2021-09-07.log