[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preparing for a new release
From: |
Ricardo Wurmus |
Subject: |
Re: Preparing for a new release |
Date: |
Mon, 10 Feb 2020 22:28:11 +0100 |
User-agent: |
mu4e 1.2.0; emacs 26.3 |
zimoun <address@hidden> writes:
> On Mon, 10 Feb 2020 at 07:31, Ricardo Wurmus <address@hidden> wrote:
>> zimoun <address@hidden> writes:
>
>
>> >> * It’s not possible to select more than one tagged item
>> >>
>> >> In my test workflow I’m generating a bunch of inputs by mapping over
>> >> an argument list. Now the problem is that I can’t select all of these
>> >> inputs easily in a code snippet. With the syntax we have I can only
>> >> select the first item following a tag.
>> >>
>> >> To address this I’ve extended the accessor syntax, so this works now:
>> >>
>> >> --8<---------------cut here---------------start------------->8---
>> >> process frobnicate
>> >> packages "frobnicator"
>> >> inputs
>> >> . genome: "hg19.fa"
>> >> . samples: "a" "b" "c"
>> >> outputs
>> >> . "result"
>> >> # {
>> >> frobnicate -g {{inputs:genome}} --files {{inputs::samples}} >
>> >> {{outputs}}
>> >> }
>> >> --8<---------------cut here---------------end--------------->8---
>> >>
>> >> Note how {{inputs::samples}} is substituted with “a b c”. With just a
>> >> single colon it would be just “a”. Single colon = single item; double
>> >> colon = more than one item.
>> >
>> > I am confused by the syntax.
>> > Well how to select the second element "b"?
>> >
>> > Naively, I would tempt to write {{inputs:samples:2}} or
>> > {{inputs::samples:2}}.
>>
>> There’s no syntax for that because you can use good ol’ list processing
>> (let’s call it “Listp”, or perhaps “Lisp”…) to work on this outside of
>> the code snippet.
>
> If I understand correctly, for such cases, 3 solutions:
>
> 1. manually split
>
> inputs
> . sample-1: "a"
> . sample-2: "b"
> . sample-3: "c"
>
> or 2. split elsewhere 'samples' using piece of Lisp
>
> or 3. use Lisp features
>
> inputs
> . sample-1: `(list-ref ,samples 1)
> . sample-2: `(list-ref ,samples 2)
> . sample-3: `(list-ref ,samples 3)
>
>
> Right?
That’s correct, but to directly access values in the “inputs” field,
though, you’d have to use a let binding around the definition of the
code snippet, which would be uglier.
So ugly in fact that I decided to write this little procedure:
--8<---------------cut here---------------start------------->8---
;; Simplify access to tagged items in lists.
(define pick
(case-lambda
;; First item.
((key collection)
(and=> (memq key collection) cadr))
;; Nth item
((n key collection)
(let ((sub
(and=> (memq key collection)
(lambda (sublist)
(break keyword? (cdr sublist))))))
(cond
((number? n)
(and (> (length sub) n)
(list-ref sub n)))
;; All items
((and (procedure? n)
(eq? (procedure-name n) '*))
sub)
;; SRFI-1 accessors like "first"
((procedure? n)
(n sub))
(else (error "pick: Selector not supported.")))))))
--8<---------------cut here---------------end--------------->8---
Then I noticed that it’s really inconvenient to use let bindings inside
of fields, so I changed the “make-process” macro to allow for
definitions inside of the fields of a process.
So you can do this now:
--8<---------------cut here---------------start------------->8---
process foo
inputs
. "something"
. samples: "a" "b" "c"
procedure
define second-sample
pick second samples: inputs
. # { echo {{second-sample}} }
--8<---------------cut here---------------end--------------->8---
Unfortunately, the leading dot sticks out like a wart here. We could
only drop it if I manage to rewrite the code-snippet value so that it
really is a procedure that will return itself when applied to zero
arguments… It might be possible with some tinkering.
(Note that you do need the “procedure” field name here; it can be left
off only when the last value is a code-snippet.)
--
Ricardo
- Preparing for a new release, Ricardo Wurmus, 2020/02/08
- Re: Preparing for a new release, Kyle Meyer, 2020/02/08
- Re: Preparing for a new release, Ricardo Wurmus, 2020/02/08
- Re: Preparing for a new release, Ricardo Wurmus, 2020/02/10
- Re: Preparing for a new release, zimoun, 2020/02/10
- Re: Preparing for a new release,
Ricardo Wurmus <=
- Re: Preparing for a new release, zimoun, 2020/02/10
- Re: Preparing for a new release, Ricardo Wurmus, 2020/02/11
- Re: Preparing for a new release, Ricardo Wurmus, 2020/02/11
- Re: Preparing for a new release, zimoun, 2020/02/11