pwr22 / go-zoom Goto Github PK
View Code? Open in Web Editor NEWParallel command executor with a focus on simplicity and good cross-platform behaviour
License: MIT License
Parallel command executor with a focus on simplicity and good cross-platform behaviour
License: MIT License
This can occur if the commands from the initial batch are sent into the channel before the main goroutine starts. So basically if an error occurs in a command before all the initial commands are started then zoom
will not stop all commands and exit early as expected
Just the basics here: any occurrences of {}
will be replaced with the job arguments and this will disable the auto-concatenation
Make commands output always come in the order they are given
The standard go flag
stuff violates the principle of least surprise and is less feature rich as well. E.g. no "for free" shortened forms
The ID could be the ordinal number of the jobs 1..n
. This will be particularly useful if the output is interleaved.
We might pull them out into separate packages at some point but for now just keep them all in zoom.
Device on what it is and stub out the arguments with a not implemented yet response.
--extensionless-placeholder
--file-placeholder
--directory-placeholder
--extentionless-file-placeholder
.--job-placeholder
--runner-placeholder
WIP
It's like a giant single function now - it can be split up
Since GOMAXPROCS
is set to the number of logical CPU cores since Go 1.5 this seems sensible to me
In the event that a command fails then zoom
should exit with that itself
IMO the Rust Parallel semantics make more sense but GNU Parallel is the popular implementation everyone will be using
I think the answer to this probably boils down to "Are we mostly compatible with GNU Parallel?" and if the answer is yes then adopt those semantics, otherwise not. If supporting GNU Parallel compatibility behind a flag then we can potentially have both semantics available
This will have no meaningful effect right now because the process is going to exit pretty much right after
However, when the runner is itself a separate project then I still don't think it would be a problem because the only goroutine that would ever listen on that channel is gone but it's still worth doing to keep everything clean
This is to match GNU Parallel, make, gcc and other usual things
Best practice these days.
Better to keep the readme short and sweet
This will make the code tidier and setting options easier
And the Windows equivalent (%COMSPEC%
?)
This will make the code more testable and move all the os.Exit()
usage to one place (probably main)
Like in GNU Parallel
The file should be passed as the only argument on the command line
Details can be found by running go test -race ./...
Signals to handle
And any others that are appropriate
This is to avoid confusion with things like the zoom messenger or presentation library.
This will make testing easier as we'll be able to easily capture the output to check it or to send it to a black hole if we don't care about it
Atm we allocate a slice of length n
for n
commands to run - two of them actually
Moving to a map should work just fine and reduce memory usage
We don't update lastJobPrinted
so it sits with value -1
and we'll only ever do one scan through of pending outputs when job number 0 finishes
Thanks to @jes for spotting this
In the current implementation this will generate an empty list of commands so it's pointless to allow it
In parallel it will do a permutation of the first line with every other line but it does allow it. I consider this more of a bug than a feature since I can't find it documented anywhere
Would be good to have a few different scenarios and compare cpu, memory and runtime to GNU parallel, MIT Parallel and rush.
I'm not sure how to do with with pflag
or even if it's possible. Right now it shows the flags which is great but there needs to be a lot more documentation of the other arguments that can be passed and what the tool actually does!
Right now if one command fails we try to stop every other command and then wait for them all to finish. This is so things always end gracefully and we always get all output (zoom was designed for some tools that are a bit flakey at flushing their output).
Other failure modes we should support:
SIGKILL
to commands after some timeout.A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.