Run should allow specification of basic workflow joins
Reported by bahuvrihi | April 29th, 2008 @ 11:01 AM | in Tap-1.0.0
The run command syntax might be extended to include workflow joins like:
sequence
# app.sequcence(a,b,c)
% tap run -- a --= b --= c
% tap run -- r1task --+ r2task --= r2sequenced -- r1task --= r1sequenced
fork
# app.fork(src, *targets)
% tap run -- src --[ target -- target -- target --]
merge
# app.merge(target, *sources)
% tap run -- --{ source -- source -- source --} target
Comments and changes to this ticket
-
bahuvrihi May 29th, 2008 @ 12:36 PM
See Basic Control Flow Patterns
These five patterns are what should be included.
-
bahuvrihi July 30th, 2008 @ 08:33 AM
- Tag set to feature, tap
- Milestone changed from Tap 0.10.0 to Tap-1.0.0
-
bahuvrihi August 4th, 2008 @ 04:13 PM
Syntax brainstorm. The exclusive choice may be easy to implement in code but really cannot be done without a block in the command line.
=========== =========== 0. a -- =========== 0. a --:1 1. b -- =========== 0. a --[1,2] 1. b -- 2. c -- =========== 0. a --[1,2] 1. b --{3} 2. c --{3} 3. d =========== 0. a --[1,2,3] 1. b --{4} 2. c --{4} 3. d 4. e =========== 0. a --:1 1. b --[2,3] 2. c --{5} 3. d --{5} 4. e --{5} 5. f -- Numbers indicate which tasks to use. For sequence, no number implies the next task. --: sequence --[] parallell split/fork --() synchronization/sync --x exclusive choice/... (omit) --{} simple merge/merge
-
bahuvrihi August 4th, 2008 @ 04:54 PM
These can get put anywhere, say at the end, or in the middle if desired. First number is assumed to be the last task declared (ex, tasks.length-1). For sequence, the second number is assumbed to be the next task to be declared (ex, tasks.length). In the other cases, numbers must be specified explicitly.
--1:2 sequence 1, 2 --1[2,3] parallel split/fork 1 into 2, 3 --1(2) synchronization/sync 1 into 2 (listed once for each merge) --x exclusive choice/... (omit) --1{2} simple merge/merge 1 into 2 (listed once for each merge)
Variations:
% tap run -- a --:1 b --[2,3] c --{5} d --{5} e --{5} f -- % tap run -- a -- b -- c -- d -- e -- f --0:1 --1[2,3] --2{5} --3{5} --4{5}
-
bahuvrihi August 4th, 2008 @ 05:22 PM
Keep in mind workflow tasks should not take inputs. Do something like:
- parse for tasks, add to array
- collect workflow breaks
- construct workflow from breaks, pulling tasks out of the array as you go. raise error if any of the pulled tasks have inputs
- enque remaining with inputs
Any task can have configurations.
-
bahuvrihi August 25th, 2008 @ 10:47 PM
- State changed from new to resolved
- Assigned user set to bahuvrihi
(from [41521cecf33c34a8b7f82fc04e90b7435ba8c1ee]) Added workflow syntax to run [#25 state:resolved responsible:bahuvrihi] http://github.com/bahuvrihi/tap/...
-
bahuvrihi September 2nd, 2008 @ 11:54 PM
(from [15f36dc701297bc033b7b79857bd210619ab7a3d]) Updated documentation for App. Added sync_merge and switch workflow patterns. [#25 state:resolved responsible:bahuvrihi] http://github.com/bahuvrihi/tap/...
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
A framework for making configurable, file-based tasks and workflows.
People watching this ticket
Referenced by
- 25 Run should allow specification of basic workflow joins (from [41521cecf33c34a8b7f82fc04e90b7435ba8c1ee]) Added w...
- 25 Run should allow specification of basic workflow joins (from [15f36dc701297bc033b7b79857bd210619ab7a3d]) Updated...