versioning
by Allin Cottrell
Thanks for Artur for putting this back on the agenda.
http://lists.wfu.edu/pipermail/gretl-devel/2015-September/005937.html
I suggest we discuss the issue a bit more fully -- consider the merits
of the proposal and not just the technicalities -- and make a
decision.
The proposal is that we move to a version string of the form
<year><sequential release>, the cleanest variant of this being (IMO)
2015a, 2015b, ...
As I see it it the pros and cons are roughly as follows:
Pro:
* Coming up with a version identifier for each release becomes purely
algorithmic: no need (or scope) for discussion.
* Version identifiers become clearly informative. If someone tells you
they're running gretl YYYYx you know immediately how old it is without
having to look up the change log.
* It reflects the fact that gretl development has been for many years
a more or less continuous process. From time to time the changes
between versions have been relatively major (new "genr"
implementation, new command "tokenizer", introduction of GMM, etc.)
but to date we have never signalled that by a change in the "major"
version number, which is therefore uninformative. We've changed the
"minor" version from time to time, but without any clear principle.
Con:
* We'd be out of line with most free-software projects, which tend
(for whatever historical reason) to the use the M.N.P versioning
idiom.
* We would lose the ability to signal a major, backward-incompatible
change with a major-version bump. (But it's not clear that we'd ever
actually want to do that.)
* It will be a certain amount of bother to make the change, and we'd
probably want to check that it won't be too bothersome for
"downstream" packagers of gretl for Linux, particularly if we go to
<year><letter> (which I prefer) rather than <year>.<number>.
Personally I quite like the proposal, and I'd be prepared to do the
work needed to implement it if we decide that way.
It would obviously be easy to retrospectively label all releases to
date using the proposed scheme (e.g. in the change log, where we
should keep the old version IDs too, for reference). And as Sven has
said, we could easily translate the proposed idiom to a single integer
that preserves order. At present we have
$version = 10000*M + 1000*N + P
so 1.10.2 -> 11002
Just say our next release were "2015d": in that case we could
define
$version = 10*year + alpha_order(letter)
so 2015d -> 20154
(This would get messed up if there were more than 9 releases in a
given year, but I think we can rule that out.)
Allin
9 years, 5 months
varname() / varnames() reloaded
by Sven Schreiber
Hi,
what ever happenend to this thread dangling in the air for a year now?:
http://lists.wfu.edu/pipermail/gretl-devel/2014-September/005264.html
I like Logan's idea. I might also like jack's conversion function idea.
Currently it seems we have a bit of a confusion over the how a set of
names is stored or returned: in some functions it's comma-separated, in
others it's space-separated, and then there are string arrays. IMHO this
could use some consolidation.
In any case I don't regard the introduction of a new function like
"varnames" as evil. Just like in the matrix/matrices distinction, the
plural-s indicates the array nicely I think.
thanks,
sven
9 years, 5 months
Grelt version branding
by Artur Tarassow
Dear all,
I just remembered the discussion we had in Berlin about the upcoming versioning of gretl.
I really, and I think I wasn't alone with this, liked idea to version it using years as e.g. Matlab does (Gretl2015a). This may underline the ongoing development of gretl.
Is this still on the table?
Best,
Artur
9 years, 5 months
Copyright year should be 2000-2015 :)
by Hélio Guilherme
Hi
Just noticed this bug ;)
[helio@localhost gretl]$ grep -R "2000-2014" --include "*.c" .
./gui2/about.c:const gchar *copyright = "Copyright (C) 2000-2014 Allin
Cottrell and "
Thanks!
9 years, 6 months
translations
by Sven Schreiber
Hi,
is there still time to do last-minute translation updates, or is
1.10.2(?) already frozen/closed?
thanks,
sven
9 years, 6 months
Numerical optimization functions
by Allin Cottrell
It just recently struck us that three built-in gretl functions
concerned with numerical optimization -- BFGSmax, NRmax and simann --
are anomalous in their treatment of their first argument.
In each case the first argument is an initial parameter vector, given
in straight "matrix" form, and on exit this matrix holds the optimized
vector. This is something that a user-defined function cannot do:
modify an argument given in straight, non-pointer form in such a way
that the caller ends up with the modified version.
While it's not _necessarily_ the case that built-in functions obey the
same rules as user-defined ones, we reckon it's very desirable that
they do, to avoid potential confusion. So in CVS we have done two
things:
* Modified these three functions so they accept a matrix-pointer
first argument.
* Revised the documentation to specify this form of usage.
For backward compatibility we have not disabled the old form of usage:
calls that give the first argument in straight matrix form will still
work. But we recommend that the new form be used in all newly written
hansl code. We don't have any specific milestone in mind, but it's
possible the old form will be disabled at some future point (with
warning, of course).
Allin
9 years, 6 months
