From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1gleZr-0004jC-Ja for mharc-gwl-devel@gnu.org; Mon, 21 Jan 2019 13:45:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gleZo-0004ge-I0 for gwl-devel@gnu.org; Mon, 21 Jan 2019 13:45:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gleZn-00080p-Gb for gwl-devel@gnu.org; Mon, 21 Jan 2019 13:45:40 -0500 Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]:44053) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gleZl-0007tZ-Hw for gwl-devel@gnu.org; Mon, 21 Jan 2019 13:45:37 -0500 Received: by mail-qk1-x72f.google.com with SMTP id o8so12793187qkk.11 for ; Mon, 21 Jan 2019 10:45:26 -0800 (PST) MIME-Version: 1.0 References: <87bm4df2ld.fsf@elephly.net> <878szgg9bi.fsf@elephly.net> <871s58fk0z.fsf@elephly.net> In-Reply-To: <871s58fk0z.fsf@elephly.net> From: zimoun Date: Mon, 21 Jan 2019 19:45:13 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: =?UTF-8?B?UmU6IG1lcmdpbmcg4oCccHJvY2Vzc2Vz4oCdIGFuZCDigJxyZXN0?= =?UTF-8?B?cmljdGlvbnPigJ0=?= List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ricardo Wurmus Cc: gwl-devel@gnu.org Hi Ricardo, I have just updated the repo. Wouawou !! For example, I run: guix gc GUILE_AUTO_COMPILE=3D0 GUIX_WORKFLOW_PATH=3D./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=E2=80=99m 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 processe= s. 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=E2=80=99t know how this would relate to the content addressable da= ta > store. Maybe it doesn=E2=80=99t at all.) I do not know neither. :-) All the best, simon