IRC channel logs


back to list of 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.
<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_>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
<rekado_>zimoun: basilisk on Bioconductor
<rekado_>civodul: sounds good!
<rekado_>zimoun: I’m important Bioconductor packages again.
<zimoun>ouch! well, I boycot such package. ;-)
<rekado_>tried using 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>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