Hi Allin or whoever has permissions on the function package server,
I have just uploaded new versions of py4gretl packages. And since I
changed 'vecrestrict' to 'vecmrestrict', the new version of that package
didn't replace the old one. Could someone please remove the
'vecrestrict' (w/o the m).
a week ago I mentioned that gretl was sometimes deleting variables from
my dataset. Well it happened again, and it seems to have to do with the
* using a function package like py4gretl_vecm
* creating a named list of variables (via GUI) for use in there
* on execution (via GUI) the package fails/dies with "unspecified error"
because there are missing values in the dataset which py4gretl can't
handle (and so far also doesn't check for)
* the variables that were in the named list are gone!
Another effect is that the function failure seems to confuse gretl very
much, often I cannot simply run the package again but have to restart gretl.
I don't have time right now for more detailed investigation, but the
loss of the variables is for real, maybe the description already helps.
Loosely related: it would be really helpful to have the named lists in
the session view like the matrices.
shortly after a stable release is the best time for trivial changes,
IMHO there are too many menu separator lines especially in the File and
Model (first and last) menu. Groups don't make much sense if they tend
to consist of only one member...
What do others think?
It seems to me that gretl doesn't recover properly from a funcerr
statement in a function package.
I noticed this with py4gretl_vecm version 0.9.4 which I have uploaded a
minute ago. It now checks for missing data in the sample and thus the
* open a (timeseries) dataset with some missing data e.g. at the beginning
* execute py4gretl_vecm 0.9.4, it should trigger a meaningful error
dialog "missing values can't be handled"; click ok
* adjust the sample
* execute py4gretl_vecm again, and I get an unspecified error
But when I restart gretl and execute py4gretl_vecm with the same
parameters (including adjusted sample) everything is fine.
(BTW, this kind of things is what I meant with stabilizing gretl a little.)
the following short script (with a recent windows snapshot):
list mylist = null
loop foreach i mylist
... produces the following error output ("not enough memory" ?!):
Aktuelle Sitzung: 2007/05/23 12:35
? open denmark
Lese Datendatei C:\Programme\gretl\data\misc\denmark.gdt
Frequenz: 4, max-Beob.: 55,
Liste 5 Variablen auf:
0) const 1) LRM 2) LRY 3) IBO 4) IDE
? list mylist = null
Fügte Liste 'mylist' hinzu
? loop foreach i mylist
Zu wenig Speicher - Fehler
Fehler bei Skriptausführung: Stopp
> loop foreach i mylist
During the last couple of days I have worked with gnumeric for the first
time. I noticed that it has some statistical tests built in, like
testing equality of means. Remembering our discussion about the
appropriate formulae and handling of these (especially in small
samples), what exactly do they do? And do gretl and gnumeric differ for
the same data/setups? Would that be good or bad?
-----BEGIN PGP SIGNED MESSAGE-----
There are still some missing strings in POT.
- --In Bootstrap the "Coefficient:" appears in English although there is a
translated string in .po. Please note the ":" at the end, the existent
word in POT does not have it.
- -- In Help->Check for Updates, th reporting of no gretl's updates in
server is not translated.
- -- Isn't it supposed to be Gretl version 1.6.5? ;)
Not errors but suggestions:
I do not recall to ever seen the Windows installer in Portuguese. I
think that there are translations for it. Do you know something about this?
In both non parametric tests the report mentions Wilcoxon Rank (signed
or not) test. I think that the Wilcoxon test(s) are best known by that
name instead of just Rank.
I am starting to translate to Portuguese the commands online help, and
did some tests on the PDF (with a horrible substitute font).
The help never shows in my LANG setting. Do I only need to translate
files in doc/chapters_pt (which I created and adjusted makefiles)?. The
cmdlist.xml is the only that is partially translated.
Also my PDF is never shown (only for testing). Could we have some
special debug flag for me to test it? For example DOCPTDEBUG, to pass to
compiler and then the right help would be shown.
Thanks and keep doing this great work,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
helio.guilherme(a)bluebottle.com @ INTERNET skrev 2007-05-16 02:22:27 :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi all,
> Not errors but suggestions:
> In both non parametric tests the report mentions Wilcoxon Rank (signed
> or not) test. I think that the Wilcoxon test(s) are best known by that
> name instead of just Rank.
I do agree.
Med vänliga hälsningar / Best regards
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
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
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
@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn
If this sounds reasonable, I can rename the py4gretl files on the
* 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.
The error messages has disappeared in the new build.
Med vänliga hälsningar / Best regards
cottrell(a)wfu.edu @ INTERNET skrev 2007-05-10 03:10:34 :
> On Wed, 9 May 2007, Allin Cottrell wrote:
> > On Wed, 9 May 2007, Sven Schreiber wrote:
> > > > in the win snapshot I downloaded two minutes ago I get error >
> > messages at startup, complaining about some obsolete help files >
> > in c:\userdata\....
> > > OK, testing on Windows I see the same thing. This is a weird
> one, > but I'll track it down before releasing 1.6.3.
> Fixed, I believe, in tonight's snapshot. If anyone can test the new
> build, I'd be grateful.
> Gretl-devel mailing list