Sugestion: new function called varnames
by Logan Kelly
Hello,
Quick suggestion. Could a function called varnames() be added that is like varname() except it returns an array with the names of variables in a list. For example:
<hansl>
function strings varnames(list in)
#Returns an array of strings containing the names of each variable in a list
catch strings ret = strsplit(strsub(varname(in),","," "))
if $error != 0
strings ret
string errormesage = errmsg($error)
print errormesage
endif
return ret
end function
</hansl>
Just a thought.
Logan
10 years
devel news II
by Allin Cottrell
OK, maybe I should give some idea of what to expect from the new
parser, when it comes on line.
1) It will be a lot easier to maintain (admittedly, not something
users will see directly).
2) It will check the syntax of hansl commands much more rigorously.
This is a benefit which might hurt a little at first ;-) Here are
some examples:
* The old parser sloppily accepted some quoted strings where the
quotation was never actually closed, as in
print "This is a string
Not any more!
* While the old parser mostly checked for _absence_ of required
elements on the command line, it wasn't properly equipped to check
for the _presence_ of syntactical "junk". E.g.
print "This is a string")
The extraneous ')' here will now cause an error. For another
example, consider
end mle @foo
at the end of an mle block. The idea is clear enough, "@foo" is
being used for string substitution, perhaps to add the --verbose
option or not depending on how the string named foo is defined. But
suppose there is in fact no string named foo in scope. The old
parser would happily ignore the undigested "@foo" at the end of the
line; the new one will not.
(The above examples are based on real-world cases from contributed
function packages.)
3) The main benefit that should eventually be visible to users is
the potential for substantial speed-up of big scripts. I say
"potential" here: in the first instance I don't expect much impact
on speed -- some scripts may go faster, some may go a little slower.
But the way the new parser works, it will create the possibility for
pre-parsing an entire hansl script, including both loops and any
functions called, and I expect a major speed-up for complex scripts
from that, when we get to it.
Allin
10 years
devel news
by Allin Cottrell
Some of you may have noticed that the rate of CVS commits and
production of new gretl snapshots has been low over the last few
weeks. Contrary to what you might infer, that doesn't mean that
gretl devel activity has been minimal.
I've been working quite intensively on replacing gretl's old command
parser with a new, streamlined version. This is something we've been
thinking about for a few years, but I finally decided it was now or
never to do the job. Since the command parser is at the heart of the
program, this is major surgery, with lots of inevitable
complications. So I took the development out of CVS to avoid
excessive breakage.
I'm thinking that I can probably merge my changes back into CVS in
the coming week. I'll report back then.
Allin
10 years
The "append" command
by Allin Cottrell
This is a follow-up to the discussion at
http://lists.wfu.edu/pipermail/gretl-devel/2014-August/005253.html
By default, the "append" command now strictly appends data (news series
and/or additional observations). The old behavior included the "updating"
of any observations that were in common between the existing in-memory
dataset and the file specified with "append". This behavior can be called
for by use of the new --update-overlap option.
Allin
10 years, 1 month
Data messed up after 'append' with panel data
by Sven Schreiber
Hi,
this problem turned out to be easy to demonstrate, after it was
recognized and diagnosed:
First consider the workfile 'importcheck'. It is a 5 units by 5 periods
panel dataset, structured by the index variables 'ix' and 'tx'; the
existing values of 'ix' are 25, 27, 30, 35, 40. The only real variable
is called 'somedata' and has mostly missings.
The second file 'tobeimported' also has panel data identified by ix and
tx, but there is an additional ix=33 in there, so it's 6 units by 5 periods.
When you append the second file to the first, gretl says 'appended ok',
but in fact it does not honor the ix/tx-structure, such that the values
of the existing variable 'somedata' are moved around to different
observations. This is pretty bad, especially if you do not notice it
right away!
This is with today's snapshot on Windows, but must have existed before
the latest release.
thanks,
sven
10 years, 1 month
Need help to build gretl in CentOS 6.5
by Hélio Guilherme
Hi,
For sometime I did not update gretl files from CVS, and now I not able to
build.
I believe it was by changes regarding date/time functions.
Here is the output:
CC prescr.lo
CC seive.lo
LD libgretl-1.0.la
make[1]: Leaving directory `/home/helio/gretl/lib'
make -C cli
make[1]: Entering directory `/home/helio/gretl/cli'
CC gretlcli.o
CC complete.o
LD gretlcli
../lib/.libs/libgretl-1.0.so: undefined reference to `g_get_monotonic_time'
collect2: ld returned 1 exit status
make[1]: *** [gretlcli] Error 1
make[1]: Leaving directory `/home/helio/gretl/cli'
make: *** [cli] Error 2
---
Searching in Internet for g_get_monotonic_time, I see that it belongs in
GTK+, but even in GTK 2, is there.
Well, there is now a CentOS 7 released, maybe if I upgrade, this gets
solved.
Hélio
10 years, 1 month
