octave-maintainers
[Top][All Lists]
Advanced

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

RE: pending instrument-control release


From: JohnD
Subject: RE: pending instrument-control release
Date: Wed, 9 Aug 2017 15:50:06 -0400

My comments below

> -----Original Message-----
> From: Olaf Till [mailto:address@hidden
> Sent: Wednesday, August 09, 2017 3:13 PM
> To: Octave Maintainers
> Cc: JohnD; Stefan Mahr
> Subject: pending instrument-control release
> 
> 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?


You are right - no close - I will remove it.

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

I don't see anything different on it compared to the other entries - I do
see that resolvehost is off by a space so will fix that. Let me know if I am
missing something obvious.

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

The instructions in the makefile suggest tagging it, so will remove that
line as well.

> 
> 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.
> 

I see in the database package that you register the type in the new octave
value type - is that an acceptable solution we can use?

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

I don't believe the coding style matches octave anywhere except by accident
:) Will try getting in order for a futures release, not now.

> 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.
> 

I havent done anything with the operators before , so don't know - are they
there and will be used by calls from octave itself rather than from in the
oct file code?

Ie:

A = serial()
B = A

If A == B
  display " the same object"
endif

> 
> 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?
> 

I saw the warnings in dev octave, but, like you was reluctant to do any
changes before the official octave release unless it was stopping it from
building.

If it is something easy for you, and you have the time I am ok with you
making the change now, if you have other stuff to do, then after the release
is also fine - let me know.

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





reply via email to

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