Belated response to Sven on function packages
by Allin Cottrell
Before I try responding to the list of small bugs that has
appeared on gretl-users, I'd like to come back on some points that
Sven raised earlier, regarding function packages.
First of all, py4gretl is very cool! Thanks for making this
available. One request: I think it would be very helpful if you
could put up a few examples of use of the py4gretl functions. (I
have this is mind, though it's not yet implemented: allow for a
.gfn file to contain a complete, runnable sample script.)
Now, on a few design issues.
* Should we have a standard File Open dialog that allows you to
open .gfn files from anywhere in the filesystem? On reflection,
No, that would likely be confusing for most users. Unlike regular
.inp files, .gfn files are supposed to be special. There are two
authorized locations for such files: @gretldir/functions and
@userdir/functions. If you want to be able to open such a file,
then put it, copy it, or symlink it into one of those locations.
* Version numbers embedded in gfn filenames. I started along the
road of trying to accommodate this, but I now think that was a
mistake.
One symptom is the issue Sven mentioned, that if you upload a new
version of a package to the server, the old one will still hang
around, if it has a different filename, and you can't delete the
old one. What's supposed to happen is that when you post an
update the old file is automatically overwritten, which will
happen if they have the same name.
Also, version numbers in the filename are redundant from a user's
point of view (the version is recorded inside the file), and they
take up space unneccessarily in the function package dialog
window. [To make the redundancy point more persuasive, I've now
modified the dialog so that it shows the version number beside the
name.]
I can see that from the point of view of a function package
developer, it's convenient to have versioned filenames. My
suggestion would be: keep the files with the versioned names in a
separate directory, and symlink the one you want to use currently
into @userdir/functions
@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn
If this sounds reasonable, I can rename the py4gretl files on the
server accordingly.
* Which functions appear as available for packaging in gretl? I
haven't had time to check this fully, but here's what's _supposed_
to happen when you load function package P:
- P's public interface (which should have the same name as the
package) will _not_ appear as packageable. That's intentional:
it's already packaged and shouldn't appear as the public interface
of any other package.
- If there's at least one "free" function available for packaging,
then any helper functions inside P should be available: helper
function are supposed to be reusable.
- How do you make "free" functions available? For example, put
them into an .inp file and run it.
- If you really want to "cannibalize" a package -- that is, steal
its public interface and use it to make another package, then
you'll have to do some copying and pasting. Copy the code out of
the code-editing window in the function packager and paste it into
an .inp file. Re-start gretl; load and run the .inp file.
Allin.
17 years
latest snapshot, serious problems
by Sven Schreiber
I updated to the latest (=today's) Windows snapshot to see if that fixes
some of the little remaining issues with function packages, but things
are much worse suddenly (BTW, I like that snapshots get version numbers
different from releases!):
When trying to delete function package from machine:
empty confirmation dialog, and then: "g_locale_from_utf8 failed for
charset 'CP1252'" error
gretl crashes when executing newly created package from the function
package manager
and after restarting gretl cannot open existing packages
I will go back to 1.6.2 for the moment, good luck with the bug-squashing!
-sven
17 years
moving averages
by Marco Marini
Hi,
I was looking for a way to apply moving average filters to a time series.
To my understanding there isn't a built-in function in gretl, so I would
like
to know whether some user has already developed it.
If not, I think I will write a user function (I need it to show its
properties to my students).
In this case, I would like to know whether is available the convolution
function in gretl,
which is very helpful to combine filters. Any suggestion is obviously
welcome!
Thanks a lot.
Marco
17 years
environment variables in gretl script
by Sven Schreiber
Hi,
I am now back to using gretl on Windows (more often at least). So
finally I tested py4gretl on win and of course it fails. Actually I
think it probably also would fail in most desktop ways of using it, even
on *nix.
The reason are the missing write permissions in the current directory
(./), where py4gretl (both gretl and python sides) stores two temp
files. That "current" (at the time of invoking gretl) directory I guess
will often be the installation directory of gretl, where a normal user
cannot write.
So I am thinking of other places to store the temp files. However,
py4gretl needs to pass that information from the gretl side to the
python side, so it's name must somehow be accessible from gretl script.
Hence my question: what type of environment variables can be used in a
script? Or any other ideas on a good place to store temp files (on all
supported platforms)?
Thanks,
Sven
17 years
double vs. single quotes
by Sven Schreiber
"Uff" (expression of exhaustion...), I think I've just found the subtle
cause of a remaining bug in my py4gretl functions, leading to temp files
not being deleted on windows.
The following python call (shell command) fails:
! python -c 'import os; os.remove("testhome.txt")'
while swapping the single/double quotes works:
! python -c "import os; os.remove('testhome.txt')"
I guess this is actually a windows shell thing (because the functions
worked ok on Linux IIRC), does anybody know something about that stuff?
Or does gretl parsing play a role, too?
Thanks,
Sven
17 years
