> On Oct 16, 2017, at 5:54 PM, Toke Høiland-Jørgensen
> <[email protected]> wrote:
>
> Hmm, I see your point about explicit being better, but again it's
> surprising. A compromise could be to detect it and warn the user
> explicitly (i.e., instead of just printing out the whole help message
> you could go "you specified a unitless duration. did you mean Xs?”).
Sounds good, done (roughly...error message needed to contain stuff from Go to
handle different cases and thus isn’t formatted as I’d like, but I think it’s
good enough).
> This is a trade-off between not accidentally dropping data and not
> having to clean up after a tool that you clearly just interrupted. I
> would definitely say don't output the JSON to STDOUT when interrupted
> (but the stats are fine). Writing to file, hmm, I dunno…
Done (not writing to stdout on interrupt).
I could prompt y/n in the case of a file, then exit on second interrupt
(already exiting on second interrupt fyi, just in case of a hang, which I have
not seen), but for the moment it still writes. Added to my list.
> I haven't tried out the iperf code yet, but from the discussion on the
> list yours has several features that iperf is lacking, most notably the
> handshake (but also way more detailed statistics). So I definitely don't
> think your efforts are wasted :)
Fair enough, will just make it the best I can with what I’ve got… :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tohojo/flent/issues/106#issuecomment-337071377
_______________________________________________
Flent-users mailing list
[email protected]
http://flent.org/mailman/listinfo/flent-users_flent.org
