more function package news
by Allin Cottrell
I said I'd have gretl 1.8.4 out by now, but I found that fixing
problems with the user-function GUI led me further "down the
rabbit hole" than I expected.
I discovered quite a lot of code in lib/src/gretl_func.c, and also
in the associated GUI C files, that was partially duplicated
and/or not readily comprehensible, which may well count for the
"flakiness" that Sven mentioned.
I've therefore done a good deal of clean-up (plus addition of
comments) in those areas. I've also relaxed what I think was the
most awkward limitation in the function-package design up to gretl
1.8.3, namely the fact that a package could only have one public
interface. Now packages can contain as many public (and private)
functions as you like.
This is all good, but as with all new code it needs some testing.
So if anyone can find some time over the next few days to beat on
anything to do with editing or calling function packages, I'd be
very grateful. Then we'll get gretl 1.8.4 out.
Reminder: cleaned-up function packages for use with current CVS
gretl can be found at
http://www.wfu.edu/~cottrell/newgfn/
Two further comments:
* At present you define the list of functions belonging to a
package at the time of initial construction of the package; and
there's no way, in the GUI, to add or remove functions from a
package. I plan to remedy this before long, but probably not for
the 1.8.4 release.
* Now that packages can offer more than one public function
there's a potential ambiguity over the "Help text". I've resolved
this for now by locating the Help at the package level. That is,
suppose you have a package "sfa" that has public functions
"sfa_mod" and "sfa_hetmod" (I'm taking a possible reorganization
of Gordon Hughes's contribution as an example). In that case the
help text that you enter in the GUI package editor should cover
both functions. If the user does "help sfa_mod" or "help
sfa_hetmod", in either case they'll get a redirect to the help
text for the parent package.
Allin.
13 years, 6 months
strings
by Sven Schreiber
Hi,
some untranslated strings I came across in today's (German) cvs (haven't
checked yet whether they appeared in the last couple of days or whether
they are not marked for translation, but before I forget, I'm posting them)
* help text
* public functions
* This function needs time-series data
* please add a sample script for this package
* missing
thanks,
sven
13 years, 7 months
Bug in Gretl or my library?
by Marcin Błażejowski
Hello,
When I've tried to create new empty data set I got (gdb results):
------------
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb6142700 (LWP 11344)]
0xb7cd84d5 in gtk_container_foreach () from /usr/lib/libgtk-x11-2.0.so.0
------------
Current CVS version
Regards,
Marcin
--
Marcin Błażejowski
GG# 203127
13 years, 7 months
Load data in GNU R without row names - feature request
by Robin Gower
All,
Loading data into GNU R fails on my dataset:
*> gretldata <- read.table("/home/robin/gretl/Rdata.tmp", header=TRUE)
Error in read.table("/home/robin/gretl/Rdata.tmp", header = TRUE) :
duplicate 'row.names' are not allowed*
"Row names" are actually the year (which has duplicates as each records
represents a month).
To load the data successfully, I have to do:
*> gretldata <- read.table("/home/robin/gretl/Rdata.tmp", header=TRUE,
row.names=NULL)*
Perhaps gretl could test for this before attempting to load the data into R?
Thanks all for a great program,
Robin
--
Robin Gower
http://infonomics.ltd.uk
0791 255 3187
Recycling by design with Industrial Nutrition:
http://clients.infonomics.ltd.uk/?q=industrial-nutrition
13 years, 7 months
Re: [Gretl-devel] function package news
by Gordon Hughes
I will provide some example scripts for my stochastic frontier functions.
As it happens I have extended the range of models that the functions
are designed to handle, but lack of time caused by a large project
with a tight deadline has limited the amount of time and energy that
I have had to tidy and document the additional
facilities. Fortuitously one major phase of the project has just
come to an end, so that after a few days vacation I can provide
updated function scripts as well as the examples. I should be able
to do this by the end of the first week of September if that is good enough.
However, I do have one question. I prefer to ensure that the
examples make some kind of econometric sense. Further, it makes
sense to design the examples to make use of standard datasets that
accompany Gretl or can easily be added through the data library
functions. However, there is a shortage of panel data that would fit
into a stochastic frontier framework. Is it possible to contribute
one or more datasets based on publicly available data that I could
use to illustrate the estimation of various models with the data. I
have in mind some WHO data that William Greene has used in a variety
of papers. The alternative would be to include code to generate some
artificial data that can be used for estimation, along the lines of
Monte Carlo studies.
Gordon
13 years, 7 months
function package news
by Allin Cottrell
Sorry, this is a bit long, but hopefully it will be of interest to
people writing or using gretl function packages. The question of
how to encourage submission of user-contributed functions was one
thing that occupied a fair amount of our time at the 2009 gretl
conference in Bilbao (for which, many thanks to Ignacio
Diaz-Emparanza and Petr Mariel!) so I think this is important.
I'm very grateful to Sven for pointing out a serious bug in the
GUI for calling user-defined functions, in
http://lists.wfu.edu/pipermail/gretl-devel/2009-August/002053.html
After that came up I undertook a thorough overhaul of the GUI for
calling functions and also the GUI for working with function
packages, and I've now (in CVS and the snapshots for Windows and
OS X) fixed a large number of issues.
Some of the fixes relate to bugs that were introduced since the
function-package GUI was first written, and that have somehow
passed unnoticed, but many of them relate to things that were not
worked out properly when that interface was initially developed,
and that have just "sat there" ever since.
Anyway, I hope that these fixes (which will of course be in gretl
1.8.4, out soon) will make life more agreeable for anyone trying
to work with function packages. And if anyone's working in that
area right now, I'd strongly advise updating to current
CVS/snapshot.
A few things that might not be immediately apparent:
* When you open the window displaying function packages on the
local machine, you should see a directory icon in the toolbar.
If you click on that you can select a directory from which to load
function files. In the past the behavior here has been to load
any _additional_ function files from the chosen directory (not
already found in other places). Now you have the option of
replacing the currently-shown file listing. So if you have a
special directory containing development versions of packages that
you're working on, you can restrict the function-package listing
to just those files.
* You can now do "gretl -p /path/to/gfnfile" on the command line,
to open a specified function package for editing on start-up.
Alternative syntax is "gretl --pkg=/path/to/gfnfile". Give the
full path to the .gfn file.
* If you're updating a package, you can right-click in the package
Date field to get a popup which lets you insert the current date.
As another part of this overhaul I've done something I should have
done a long time ago, namely check carefully all the existing .gfn
package files on the gretl server. I have fixed several of these
and have added sample scripts for most of the cases where these
were missing (but see below). I have also written a test rig
which lets me extract the sample scripts from all packages and
test them for breakage. In some cases my fixes will require gretl
1.8.4, so I won't upload the revised gfn files to the server until
version 1.8.4 is released (as I said, should be soon).
Please note: the Document Type Definition for gfn (gretl function)
packages requires that a sample script be provided. Up till now,
packages that were contributed before this requirement was
introduced have been exempt ("grandfathered", as they say in the
States). But no more. Even with the best intent, documentation
can be a bit obscure, and having a working example to hand is
often the key for a user to get started using a function of
interest; so I think we should enforce this requirement for all
packages.
As I mentioned, I've added sample scripts for the simpler
functions. Naturally, it's the more complex (and interesting)
packages that have given me trouble; I'm less sure of what an
adequate example would look like. I'd be very grateful if Ignacio
could add a sample function for the LLTestim package, and if
Gordon Hughes could add one for the sfa_hetmod package. Feel free
to email me samples and I'll add them to the revised packages for
gretl 1.8.4.
Looking to the future, there are some other things we discussed in
Bilbao that I haven't got to yet, but will start on once gretl
1.8.4 is out. That is, we'd like for gretl function packages to
have these options that are not currently available:
* Include more than one "public interface". (Right now each
package can include only one function that's publicly available.)
* Include properly typeset documentation (i.e. LaTeX -> PDF). (At
present we only support plain text documentation.)
* Include an example dataset, in case no suitable dataset can be
found among those that we distribute with gretl.
* Include more than one example script, if desired.
I have some ideas about how we can add these things without
breaking backward compatibility, but it will take some time to
work those ideas out properly.
Allin.
13 years, 7 months
relative path problems with include on linux
by Sven Schreiber
Hi,
relative paths don't work for me on linux when using 'include' in
scripts, while ironically they seem to work fine on Windows.
Here's the example:
<script1>
# this script 'scriptinlevel2.inp' resides in $HOME/gretlpathtest/level2
include ../scriptingretlpathtest.inp
print "hello"
</script1>
<script2>
# this script 'scriptingretlpathtest.inp' resides in $HOME/gretlpathtest
function pathtest(int yo)
print "inside function"
end function
</script2>
Now when I run the first script on linux, an error window pops up "no
such file or directory".
I noticed this with a more complicated real-world case which I use
cross-platform and which runs fine on Windows, but not linux.
thanks,
sven
13 years, 7 months
question about gretl-1.8.3* download
by tgh
Hi
I can not download gretl-1.8.3* packets for source code and for
windows exe , do you download it success , how to download it,
Thank you
13 years, 7 months
problem with function packages
by Sven Schreiber
Hi,
after a long pause I have been trying to put together a function package
again. Unfortunately, it failed, and it looks like a bug to me. This is
with 1.8.3 both on Windows and Linux.
I'm attaching a trivial example of when the bug happens, named
'toplevel.gfn'. Nevertheless, it could be that it isn't even a minimal
example; I'm using a helper function 'secondlevel' in the package,
haven't tried if that is really necessary to trigger the behavior.
This package returns (or should return) a matrix. And if the functions
are run in a script everything works as expected. But in reality nothing
happens, even if I specify a name in the dialog for the new matrix to be
created from the return value.
thanks,
sven
P.S: I noticed that the function namespace is still quite flaky. For
example after an error happens in a top level calling function due to a
bug there, rerunning the corrected version often leads to a situation
where second level functions that are called aren't being recognized by
gretl anymore, although nothing was changed in the second-level
functions. ('Unknown symbol such_and_such') This really reduced
productivity when developing scripts because gretl needs to be closed
and restarted quite often.
13 years, 7 months
[patch] Respect LDFLAGS variable
by Frederik
The attached patch from Mandriva, makes the gretl build system respect
the LDFLAGS variable set by the user.
--
Frederik Himpe
13 years, 7 months
