The source file enum.hpp was not found when not building in the source
tree. Also, extraction of the brief description did not work correctly
when there was additional XML markup inside the <para> element.
std::default_delete<> is originally defined as struct, not class.
This does not really make much of a difference, but some compilers
complain when the struct/class tag is not consistent across all
declarations of the type.
Make the Python and Java bindings use the same set of preprocessor
macros for the SWIG parsing stage, taken from a make variable. Add
G_GNUC_{BEGIN,END}_IGNORE_DEPRECATIONS to that set.
Writing to an object through a pointer of incompatible type is
really evil. Even when the data size matches, it is still a
violation of strict aliasing rules.
Replace all instances by direct casts of the value, without the
unnecessary and dangerous indirection.
The Java bindings currently have some weird problem with function
arguments passed by const reference. Not all types are affected,
but the collection types that involve custom typemaps are.
For now, revert back to pass-by-value for the problematic types.
Looks like SWIG silently ignores default arguments specified via
aggregate initialization. This is rather unfortunate, especially
if the argument types are complex.
Replace custom Deleter classes with std::default_delete<>, declared
as friend so it can invoke the private destructor. Inexplicably,
std::shared_ptr<> does not use default_delete<> by default, so it
is still necessary to explicitly specify the deleter when creating
shared_ptr instances.
With this, unique_ptr and shared_ptr instances now use the same
default delete mechanism.
Make use of std::unique_ptr<> to manage the lifetime of members
or container elements, so that manual invocations of delete can
be avoided. This also provides for exception safety.
Since std::unique_ptr<> is only movable but not copyable, adapt
the code to avoid copies and assignments of these pointers.
Reduce needless over-generalization. There is no design need
for the ParentOwned and UserOwned classes to contain the C base
struct pointer. Instead, just make the _structure pointer a
private member of each class that needs one.
Apparently this problem has been fixed in SWIG 3.0.6. However,
until we can require that version, define "private" as "protected"
when running the SWIG parser.
Declare accessor methods that return value members const. For now,
skip all cases where constness would have to be applied transitively
to shared objects.
Context::package_version() and Context::lib_version() do not access
context state and should be static. However, leave the logging
related methods alone for now, as making them static would entail
making the callback data a global static, since the C API lacks
destroy notification callbacks.
If one of these functions does throw an exception, std::terminate()
will be called. Without this, the behavior is undefined since the C
stack is not prepared to deal with exceptions.
The SWIG 2.0.12 on my system bails out with a syntax error on the
"noexcept" keyword in C++11 code. Define "noexcept" to nothing (for
the SWIG parser only) to work around this problem.
Make use of std::move() to transfer arguments passed in by value.
Take complex container arguments by const reference, as passing
those by value is rather unorthodox even for C++11 style code.
Using the attribute mechanism results in badly named wrappers like
getLog_level(), as well as incompletely applied typemaps for templated
container types. If we just avoid this mechanism entirely, we get the
same foo() and set_foo() accessors as we have in the C++ API.
If we're going to %extend these methods, we need to firstly ignore the
originals, and secondly implement all possible argument combinations.
This fixes the rest of bug #417.
Without this we get:
/usr/include/python2.7/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning
"Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API
NPY_1_7_API_VERSION" [-Wcpp]
As far as I'm aware we're not using any deprecated NumPy C API features.
This fixes part of bug #417.
Completely remove the old session save code that has been
superseded by the srzip output module. Also refactor a bit,
plug a number of leaks and tighten the error checking.
The GNU libstdc++ headers use isascii(), which is not part of any
POSIX standard. On BSD, this breaks the build. It is however part
of XOPEN, which on Linux is apparently enabled implicitly for C++.
This should fix#649.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
The confusingly named sr_log_logdomain_set() simply set a global
string prefixed to the log message by the default log callback.
This is pretty much useless, misleadingly named, and not used by
either sigrok-cli or PulseView.
SWIG_init() returns void for Python 2.x and 'PyObject *' for Python 3.
Use an #if to handle both cases properly, otherwise the Python bindings
for either Python 2 or 3 will fail to build.
Python 3.x failure:
sigrok/core/classes_wrap.cpp: In function ‘PyObject* PyInit__classes()’:
sigrok/core/classes_wrap.cpp:59002:5: error: return-statement with no
value, in function returning ‘PyObject* {aka _object*}’ [-fpermissive]
return;
^
Python 2.x failure:
In file included from /usr/include/dirent.h:244:0,
from /usr/include/glib-2.0/glib/gdir.h:32,
from /usr/include/glib-2.0/glib.h:45,
from /usr/include/pygobject-3.0/pygobject.h:7,
from sigrok/core/classes_wrap.cpp:3179:
sigrok/core/classes_wrap.cpp: In function ‘void init_classes()’:
sigrok/core/classes_wrap.cpp:59002:12: error: return-statement with a
value, in function returning 'void' [-fpermissive]
return NULL;
^
Extend setup.py to allow environment variables to be set on the
command line. Use that functionality to replace the pkg-config
invocations with flags passed on from make. Suppress the annoying
-Wstrict-prototypes warning by overriding the OPT variable.
Also move the "cd bindings/python" from Makefile.am to setup.py
to side-step problems with "cd" in make rules.
This also fixes bug #628.
The tables defined with this struct can now be used for information
on items other than config keys.
Functions to access these tables have been renamed sr_key_info_[name_]get.
These take an extra argument, keytype, which should be set to SR_KEY_CONFIG
to get the config key tables. Other key types will be added.
This fixes a build problem due to the reduced include search paths
introduced by my recent changes. Also fix a couple of other
includes to use angle brackets.
When the import of gi.repository.GLib failed, we would get a NULL
pointer that we passed along without any checking. In this situation,
the entire program would crash with a segmentation fault, and no
message to indicate the problem.
When the import fails, abort the SWIG init and print a message. The
Python interpreter then prints out a backtrace, which can be useful
in tracking down the problem.
This requires sr_hw_cleanup_all() and sanity_check_all_drivers()
to also take a context.
The (runtime) generation of the driver list now happens in sr_init()
and sr_driver_list() always returns that pre-generated list. This fixes
a segfault when (correctly) invoking multiple sr_init() and sr_exit()
calls with different contexts (caught by the unit tests).
This fixes bug #565.
Fix "undefined reference to `sigrok::EnumValue<sigrok::LogLevel,
sr_loglevel>::_values'", which happens at least when using clang(++),
e.g. on Linux, Mac OS X, or FreeBSD.
This fixes bug #534.
Thanks to Uffe Jakobsen and Martin Ling for reporting and investigating!
As per upstream docs "#include <glibmm.h>" is the correct usage,
the "glibmm-2.4" directory is handled correctly via pkg-config:
$ pkg-config --cflags glibmm-2.4
-I/usr/include/glibmm-2.4 [...]
libsigrokcxx.pc has a "Requires" field listing "libsigrok" which
will cause libsigrok's "Requires.private" entries to be used/inherited
when 'pkg-config --libs --static libsigrokcxx' is used.
Silence some warnings when building the Python bindings:
sigrok/core/classes_wrap.cpp: In function ‘PyObject* _wrap_new_OutputFormatMap(PyObject*, PyObject*)’:
sigrok/core/classes_wrap.cpp:5232:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
^
sigrok/core/classes_wrap.cpp:14383:13: note: ‘argv[0]’ was declared here
PyObject *argv[2];
^
sigrok/core/classes_wrap.cpp: In function ‘PyObject* _wrap_new_ChannelGroupMap(PyObject*, PyObject*)’:
sigrok/core/classes_wrap.cpp:5232:4: warning: ‘argv[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
res = SWIG_ConvertPtr(obj,(void**)&p,swig::type_info<map_type>(),0);
^
sigrok/core/classes_wrap.cpp:23356:13: note: ‘argv[0]’ was declared here
PyObject *argv[2];
^
We add -Wno-uninitialized since the warnings are harmless and we really
don't care about them in the generated classes_wrap.cpp.
This fixes parts of #417.