[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gwl-devel] merging “processes” and “restrictions”
From: |
zimoun |
Subject: |
Re: [gwl-devel] merging “processes” and “restrictions” |
Date: |
Mon, 21 Jan 2019 19:45:13 +0100 |
Hi Ricardo,
I have just updated the repo.
Wouawou !!
For example, I run:
guix gc
GUILE_AUTO_COMPILE=0 GUIX_WORKFLOW_PATH=./doc/examples/ \
./pre-inst-env guix workflow -r simple
and all the dance with the store shows up. Beautiful! :-)
Is it possible to turn off the test (make check) when building hello ?
Cosmetic comment. :-)
About the `A -> B' which means A depends on B.
To me, the arrow is counterintuitive, notationally speaking. :-)
Because the data flow is going from B to A.
Even if this notation is usual when speaking of dependencies and graph.
> >> Or like this assuming that all of the processes declare inputs and
> >> outputs *somehow*:
> >>
> >> (workflow
> >> (name "simple")
> >> (processes
> >> (eat "fruit") (eat "veges") greet sleep bye))
> >
> > With this, I do not see how the graph could be deduced; without
> > specifying the inputs-outputs relationship and without specifying the
> > processes relationship.
>
> This will only work if these processes declare inputs and outputs and
> they can be matched up. Otherwise all of these processes would be
> deemed independent.
>
> I still wonder how processes should declare inputs. The easiest and
> possibly least useful way I can think of is to have them declare
> abstract symbols.
>
> --8<---------------cut here---------------start------------->8---
> (process: 'bake
> (data-inputs '(flour eggs))
> (procedure '(display "baking"))
> (outputs '(cake)))
>
> (process: fry
> (data-inputs '(flour eggs))
> (procedure '(display "frying"))
> (outputs '(pancake)))
>
> (process: (take thing)
> (procedure '(format #t "taking ~a." thing))
> (outputs (list thing)))
>
> (workflow: dinner
> (processes
> (list (take 'flour) (take 'eggs) fry bake)))
> --8<---------------cut here---------------end--------------->8---
>
[...]
> Given this information we can deduce the adjacency list:
>
> (graph
> (fry -> (take 'flour) (take 'eggs))
> (bake -> (take 'flour) (take 'eggs)))
>
[...]
> I’m not sure how useful this is as a *generic* mechanism, though. One
> could also use this as a very specific mechanism, for example to have a
> process declare that it outputs a certain file, and another that it
> takes this very same file as an input.
>From a simple user perspective, I find more readable the current
version with `graph'. Because I am able to see the flow even if I do
not know about the processes fry, bake and take.
With:
(graph
(fry -> (take 'flour) (take 'eggs))
(bake -> (take 'flour) (take 'cheese)))
the dependency graph is clear even if I have no idea about all the processes.
With:
(list (take 'flour) (take 'eggs) fry bake)))
I need to know how the process `fry' is built to deduce what this
workflow will do.
>From my point of view, the `let' part fixes the entry point or some
specific location of outputs (for debugging purpose?).
(define (eat input output)
(process
(name "Eat")
(data-inputs input)
(outputs output)))
(define (cook input output)
(process
(name "Cook")
(data-inputs input)
(outputs output)))
(define (take input output)
(process
(name "Take")
(data-inputs input)
(outputs output)))
(workflow
(processes
(let ((take-choc (inputs take "/path/to/chocolate"))
(take-cake (outputs take "/path/to/store/cake"))
(miam (outputs eat "/path/to/my/mouth")))
(graph
(cook -> take-choc)
(take-cake -> cook)
(miam -> take-cake)))
If the inputs/outputs are not specified in the `let' part, then they
are automatically stored somewhere in /tmp/ or elsewhere and then
(optionally) removed when all the workflow is done.
I imagine `inputs'/`outputs' returning a curryfied process, somehow.
And similarly about options, e.g,
(define* (cook input output #:optional temp-woven)
blah)
Does it make sense ?
> (I don’t know how this would relate to the content addressable data
> store. Maybe it doesn’t at all.)
I do not know neither. :-)
All the best,
simon
- [gwl-devel] merging “processes” and “restrictions”, Ricardo Wurmus, 2019/01/19
- Re: [gwl-devel] merging “processes” and “restrictions”, Ricardo Wurmus, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, zimoun, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, Ricardo Wurmus, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, zimoun, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, Ricardo Wurmus, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, zimoun, 2019/01/21
- Re: [gwl-devel] merging “processes” and “restrictions”, Ricardo Wurmus, 2019/01/26