octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

pending instrument-control release


From: Olaf Till
Subject: pending instrument-control release
Date: Wed, 9 Aug 2017 21:13:29 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

John and Stefan,

in the proposed instrument-control-0.3.0 NEWS advertises and UDP
overloaded function "close", which is not in INDEX. Where is that
function defined?

A minor issue is that the indentation in NEWS is wrong for this item.

Note that releases of community packages should only be tagged after
the release is ready (typically I'm doing this).


Next issues probably are not release-critical, but maybe one of you
wants to have them dealt with before the release. If so, please tell
me.


As you probably know, symbols defined in an oct-file are not "seen" by
other oct-files (and by Octave), due to the way oct-files are loaded
by Octave. This is reasonable, but must be considered. You have dealt
with this by defining the global variable type_loaded (which is
supposed to indicate if ...::register_type() has already been called)
in several oct-files. This causes ...::register_type() of a new type
to be called once for each loaded oct-file which uses this type. This
will work, as long as Octave tolerates calling register_type() several
times for the same new type. But it's certainly not very clean. And if
this part of instrument-control should ever be incorporated into core
Octave, there may be problems due to multiple declarartions of the
same global variable.

The solution is to link all files containing DEFUN_DLD for a certain
new type together into single type-specific oct-files, and to
introduce PKG_ADD commands containing autoload(...). And, the global
variable type_loaded should be replaced by static variables within
member functions of the respective types.

There may be similar issues elsewhere.


In the future, the coding style should be adapted to that of Octave
everywhere. It deviates from it at some places.

The latter point also means that explicite 'this->...' should only be
used if necessary.


If compiled with -Wall, there are several warnings of 'defined but not
used', in particular in the context of operator definition, so the
latter is probably not successfully implemented.


With development versions of Octave, there are many deprecation
warnings. They don't need to be dealt with now, but doing so could
make the release longer usable... Since I have a standard frame for
this, do you want me to apply it? If yes, before or after the release?

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]