The bpm-sw-cli repository is a client application
and a set of scripts for talking to the bpm-sw
server. It does not make sense to have it as a
submodule, even though it has the libclient
dependency. The repository is avaialble at
https://github.com/lnls-dig/bpm-sw-cli

This client application is provided by bpm-sw-cli repository,
available at https://github.com/lnls-dig/bpm-sw-cli

This is a temporary fix to github issue #94

This was necessary as CZMQ 3.0.0 zrex engine has changed
and the pattern {1,3} is not supported anymore.

This commit, up to 02e6830e, fix #82 github issue.

This is necessary to get the correct acq_chan header file
depending on the specified board. The libbpmclient should
not depend on this. To be fixed soon!

This fixes #92 github issue.

This is unnecessary, as even if we force the user to input
a valid range, nothing guarantees that the specified board
will be plugged in the crate.

These macros were probably copied over without checking,
resulting in this set of duplicate MACROS.

This was done as devio_loop () is more semantic and widespread.

Our actors/pipes were not terminating properly due to asynchronous
behaviour of actors/pipes. Now, a proper handshake accurs between
DEVIO and actor/pipes SMIOs and they terminate gracefully.

Our actors/pipes were not terminating properly due to asynchronous
behaviour of actors/pipes. Now, a proper handshake accurs between
DEVIO and actor/pipes SMIOs and they terminate gracefully.

There was a mismatch between the enum declaration and the
error description structure, causing the error to print
an unexpected message.

With the previous tcp//*:9999, clients could not
connect to the broker. Needs further investigation.

We were treating mlm_client_t * as an zactor_t * or sock_t *,
which is clearly wrong. Now, we first get the actor reference
from mlm_client_t * and then resolve the actor to the libzmq
socket.

The regular PIPE socket (pipe_mgmt) created on zactor_new () will be used
for string commands and the pipe_msg wil be used for general messages.

With the new CZMQ 3.0.0 we no longer store a libzmq
socket type (void *), but a zactor_t polymorphic type.
Now, in order to get access to the libzmq socket reference
we need to call zsock_resolve ().

With the new CZMQ 3.0.0 we no longer store a libzmq
socket type (void *), but a zactor_t polymorphic type.
Now, in order to get access to the libzmq socket reference
we need to call zsock_resolve ().

This is not needed anymore as the log directory must be
mounted before our software initializes

This uses makeself script available at "https://github.com/megastep/makeself"