There can be non-terminal (i.e. non-interactive) sessions
that are *not* a pipe, for example:
ssh user@host ipfs version
In this case, it looks like we should read from stdin.
Parsing stdin is accomplished by deliberately triggering
the parsing loop once.
We didn't previously check whether there is an ArgDef to support
that loop iteration.
This should fix issue #1196 (Can't launch a command line
process from Qt).
The check was bad because it took stdin into account,
but it really shouldn't.
License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
This should fix issue #1141 (ipfs cat "multihash too short"
error when using stdin) and perhaps others.
License: MIT
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
After losing jenkins, it's been difficult to test all commits
manually. This commit adds a Makefile target that makes travis do it.
Unfortunately, this is way too slow. It takes longer than the
allotted 10min.
After asking the travis people what to do, someone suggested making
sure that each commit is pushed to github independently. This makes
travis run CI on every single commit in the PR, and gives us nice
status indicators on each one (so we know which ones did not pass).
This approach means that we need to push a branch to the repo for
each commit in the PR-- otherwise travis may cancel its run if it
detects that the branch is no longer there. We could automate this
with a bot that essentially does:
for each PR:
git fetch the PR branch
push a branch per commit: <branch>-<commit>
for each closed PR:
delete all branches with pattern <branch>-<commit>
We had a very nasty problem: handshakes were serial so incoming
dials would wait for each other to finish handshaking. this was
particularly problematic when handshakes hung-- nodes would not
recover quickly. This led to gateways not bootstrapping peers
fast enough.
The approach taken here is to do what crypto/tls does:
defer the handshake until Read/Write[1]. There are a number of
reasons why this is _the right thing to do_:
- it delays handshaking until it is known to be necessary (doing io)
- it "accepts" before the handshake, getting the handshake out of the
critical path entirely.
- it defers to the user's parallelization of conn handling. users
must implement this in some way already so use that, instead of
picking constants surely to be wrong (how many handshakes to run
in parallel?)
[0] http://golang.org/src/crypto/tls/conn.go#L886
