msplitby subtlety
by Sven Schreiber
Hi, in the context of a problem in the SVAR addon I've stumbled over
what might be a bug in msplitby:
Consider this:
<hansl>
clear
matrix M = {1,2}
matrices MM = msplitby(M, {2}) # gives invalid argument error
print MM
</hansl>
According to the doc, I would have instead expected a result equivalent to:
matrices MM = defarray(null, {1,2})
An example with a "taller" matrix works as expected:
<hansl>
clear
matrix M = {1,2; 3,4}
matrices MM = msplitby(M, {2,3}) # gives defarray(null, {1,2}, {3,4}), fine
print MM
</hansl>
So it looks to me as if the special case of a 1-element vector (matrix)
as the second argument to msplitby() isn't properly handled. Gretl seems
to treat it as a scalar then, and as per the documented behavior of
msplitby(), the meaning and desired result then changes.
In the real-world code that's affected, the length of the second matrix
argument can be 1 or more. Of course we can intercept the special case
of a single element and work around the problem; but shouldn't
msplitby() honor the user's input type also in the special 1-element case?
thanks
sven
1 year, 11 months
subtle list in bundle in function problem
by Sven Schreiber
Hi,
the following is something I noticed when I tried to solve another problem:
<hansl>
function bundle bL(void)
list L = 0
return _(L)
end function
open denmark # just to have a dataset in place
eval typename(bL.L) # gives "null"
</hansl>
I can understand why that happens since a list in a bundle is tricky.
The list L refers just to the constant term with index 0, but the when
it is stuffed inside the bundle and returned to the outer scope it
apparently is evaluated by its index number content, and the number 0
means "null" according to the typename() doc. Nevertheless, I doubt that
that's the desired or supported result, or is it?
thanks
sven
1 year, 12 months
ui-maker and spaces (and TRUE/FALSE aliases)
by Sven Schreiber
Hi,
it seems to me that for the new ui-maker functionality (see the function
package guide) spaces are not supported. So one has to write the string
for the 'depends' field as "x==0" instead of "x == 0". I think the
latter should also be supported, just strip out whitespace in the code.
Furthermore, using the FALSE alias also isn't recognized, apparently.
I'd like to write "x == FALSE" for better readability, since for some
time now this is valid syntax in gretl.
Of course, it's not a showstopper since right now "x==0" works and can
be used.
thanks
sven
2 years
revision of build process for gretl addons
by Cottrell, Allin
Here's a heads-up for those building gretl from source: in git master
there's a change in the build setup for the "addons" function
packages.
The need-to-know message is just this: To ensure a correct build with
current git you should delete the "addons" subdirectory under your
build tree (NOT the source tree!), rerun gretl's configure script,
then build as usual. (Blowing away build/addons is a one-time thing:
no need to repeat it unless there's a comparable change in future.)
For anyone who wants to know more: with gretl 2024a we set up tight
integration of the addons into gretl releases. That involved scrapping
the old, individual version numbers of the addons and substituting the
current gretl version for all of them. To automate this we renamed the
".spec" file for each of the addons (which specifies the package
version among other things) as <addon>.spec.in and arranged for the
configure script to read this source file and write out <addon>.spec
in the build tree, substituting the current gretl version for the
dummy string "@VERSION@" in the spec.in file.
This worked OK up to a point, but a downside became apparent. Any
changes to the source file <addon>.spec.in would propagate to
<addon>.spec, and thence to the addon itself, ONLY if the configure
script is rerun. And that's confusing, since one generally expects
that revisions to a source file (as opposed to the addition of new
source files) will propagate directly via "make", without it being
necessary to reconfigure.
So the new change in git renames <addon>.spec.in as <addon>.spec, and
instead of relying on configure to cash out "@VERSION@" with the
current gretl version, the "makepkg" command takes care of that job.
The reason why you should delete build/addons, one time, is that this
tree will contain what are now stale generated <addon>.spec files.
Under the new scheme there's no generated .spec file in the build
tree, just a symlink to <addon>.spec in the source tree.
Allin
2 years
Faster compilation of gretl
by Riccardo (Jack) Lucchetti
OK, I just found out about this tool and called "ccache" I wanted to
share my enthusiasm with somebody. Basically, it keeps a cache of
previous invocations of gcc and makes re-compilation INSANELY faster.
What I did on my Debian work box is
<bash>
configure CC='ccache gcc' --enable-quiet-build --enable-build-addons \
--with-odbc --enable-build-editor --disable-xdg
time make -j6
make clean
time make -j6
</bash>
First make:
real 0m42.887s
user 3m46.995s
sys 0m27.083s
Second make:
real 0m9.971s
user 0m48.332s
sys 0m10.464s
I found out about ccache on a stackoverflow page. Guess who the tip is
from? Our friend Dirk Eddelbuettel 🙂
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
2 years
printf and line break in the console
by Sven Schreiber
Hi,
just a minor thing: when you use 'printf' in the console and don't add
an \n explicitly, the following prompt "?" does not appear on a new
line. Perhaps it should?
cheers
sven
2 years
undated data and change dataset frequency
by Sven Schreiber
Hi again,
shouldn't the menu entries for the data frequency change be greyed out
for undated datasets? They're not (always), apparently.
thanks
sven
2 years