[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pending instrument-control release
From: |
Olaf Till |
Subject: |
Re: pending instrument-control release |
Date: |
Thu, 10 Aug 2017 10:30:31 +0200 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
On Wed, Aug 09, 2017 at 03:50:06PM -0400, JohnD wrote:
> 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
> >
> > <snip>
> >
> > 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.
I've pushed a minor correction.
> > <snip>
> >
> > 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?
This should be better. But still, as long as separate oct-files are
used, the static flag variables in the methods are not seen across
oct-files and ...::register_type() will be called more than once for a
type.
> > <snip>
> >
> > 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?
I'm not prepared to dig into Octaves concept of operator definition
now... But however it's done, if the compiler complains about 'defined
but not used', I think this part of code can't be useful in any way.
Let's put this off until later.
> <snip>
>
> > 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.
So I'll do it after the release.
I understand that we can put off all unresolved items until later, so
I'll push the release. You don't need to regenerate the tarballs,
since the root Makefile works fine.
Olaf
--
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net
signature.asc
Description: Digital signature