capture_start() does not immediately return about python-saleae HOT 5 CLOSED

It's a misleading function name, carried over from the Saleae API docs. When your capture finishes, capture_start will return, but this probably isn't the desired behavior in most cases. I have literally one script using this stuff right now, so feel free to change to a more sane API and I'll update my side.

from python-saleae.

Well my bigger concern is the fact that your documentation says that command should return immediately and it doesn't. You also already have the "capture_start_and_wait_for_finished" which does the blocking start.

I found the non-blocking start useful.

My plan is to just add a wait_for_ack parameter to _cmd()

from python-saleae.

Huh. Clearly I thought about that and it doesn't behave as expected. A bit
distracted today, sorry for the misinformation before.

Will saleae eventually send an ack for the capture / will this lead to an
out-of-band ack at some point we have to deal with?

On Wed, Sep 9, 2015 at 4:31 PM Aaron Schulman [email protected]
wrote:

Well my bigger concern is the fact that your documentation says that
command should return immediately and it doesn't. You also already have the
"capture_start_and_wait_for_finished" which does the blocking start.

I found the non-blocking start useful.

My plan is to just add a wait_for_ack parameter to _cmd()

—
Reply to this email directly or view it on GitHub
#3 (comment)
.

from python-saleae.

No, capture never returns an ACK.

"Socket Command: capture
This command starts a capture. It will return NAK if an error occurs. Example:
capture"

from python-saleae.

I decided to add a wait_for_ack parameter to _cmd() with a default of True, and I only modified the capture_start() _cmd() call to not wait for ack.

from python-saleae.