Fixed travis badge link

tested nifty graphs

…ng for clarity.

…f 'declname' tag

… there.

…o EAGLE types

… to Doxygen for PyFuncApp

…cognise additional parameter types basedon default value

…arsing of parameters. Skip components whose methods begin with an underscore.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

We have been getting away with this code, but in reality we have always
been guilty of not taking the GIL in the "pythonic" dynlibs (i.e., those
offering a "init2" method rather than an "init" one). Until 3.8 no
errors have showed up, but in 3.9 segfaults start to happen when calling
PyLong_FromLong (and possibly other methods).

To solve this I've updated our example code to take the GIL as
appropriate. This is verbose, but it's the simples solution. A different
approach would have been to load the dynlib with ctypes's PyDLL rather
than CDLL, but that forces all C function calls to hold the GIL even if
not required, which is less performant. Nobody (except Kevin, if he
still does?) is using this anyway, and if so they would have run into
the same error as we did here, so there's no issue in clarifying that
the GIL must be taken by the dynlib code rather than by daliuge.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

This was found while stabilising the unit tests running against python
3.9, which in turn I was doing to have a stable basis to work against
for YAN-968.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

Now that the problems with 3.9 have been solved we should be able to
test against it without problems.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

This was found while working on YAN-968.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

When creating drops from a graph specification we used to use only the
top-level key-values to build the keyword map passed down to
applications, which then inspected it to obtain their user-provided
arguments. For some time now LGs (and their translation into PGs) have
separated how arguments are provided to applications though, grouping
them together inside an applicationArgs map instead of placing them at
the top-level of each drop specification. This means that applications
cannot access these values directly, and that the mechanism to declare
arguments at the class level (using dlg_string_param and friends)
doesn't pick them up.

This commit merges the information contained in applicationArgs into the
set of arguments passed down to drops via kwargs. This is enough for the
dlg_*_param declarations to pick these up.

This is part of YAN-968.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

This is part of YAN-968.

Signed-off-by: Rodrigo Tobar <rtobar@icrar.org>

This seems to be what is in the code when I checked out the branch, so I'm confused why the code in the PR was different.