Hi fellow gretl users (and also developers),
not terribly important, but I'm wondering about the (size of the) close
button in many gretl windows, for example in script, script output, and
console windows. It takes the entire width of the window, at the bottom.
Is that really necessary? It happens to me relatively often that I hit
it by accident, when I aim for the scrollbar or something like that. So
it's a bit annoying. Actually all these windows seem to also have a
small close button in the toolbar at the top (a cross), not even
mentioning the close-window-button of the OS-level window manager.
So could the largest of these three close buttons maybe be abolished?
Just thinking out loud...
Here's a follow-up to my last message:
To clue everyone in, I'm appending the message I recently received
from Benno Schulenberg.
Perhaps we should discuss this. Benno's point, which seems fair
enough, is that if we're using the Translation Project (TP) at
all, we should use it consistently.
But is the TP the best way of promoting and coordinating the
translation of gretl? Presumably, we have the alternative of
withdrawing from the TP and going over to using CVS exclusively.
I'm not advocating that, just setting out options. It doesn't
make a lot of difference to me, but perhaps it makes a bigger
difference to you?
---------- Forwarded message ----------
Date: Thu, 13 Sep 2007 21:25:22 +0200
From: Benno Schulenberg <coordinator(a)translationproject.org>
To: Allin Cottrell <cottrell(a)wfu.edu>
Subject: when TP handles translations, it expects to handle all
Today I noticed there is a newer version of gretl available that
seemingly was never announced to the Translation Project. Looking
at the contents of the tarball, gretl-1.6.5.tar.bz2, it appears
that it contains four PO files that are not present at the TP:
de.po, eu.po, pt.po and pt_BR.po. This is not good.
When a package maintainer asks the Translation Project to handle the
translations for his package, the TP assumes it is handling _all_
the translations for that package, and expects the maintainer to
point any new translators to the TP, and not accept any PO files
directly. If some translator does not want to use the TP and the
maintainer accepts the PO file directly, the TP should know about
this, so it can mark the language as 'external' for that package --
otherwise some other translator at the TP, not knowing the package
has already been translated, might do the same work again.
Anyway, for now I've imported the above four PO files into the TP,
after correcting some mistakes in the headers. I haven't marked
them as external, so please direct anyone who has updates for any
of the translations to the TP. If some translator refuses, then
please let the TP know.
Allin Cottrell a écrit :
On Fri, 1 Jun 2007, Hélio Guilherme wrote:
But we really need some more
gretlers who are in a position to make the gretl wish list
_shrink_! (That is, by implementing some of the items on the
If you know of any graduate students with programming expertise
who might be interested in contributing to gretl, please try to
encourage them to do so!
I have no grasp on C programming but I used to program in Visual Basic a (rudimenatry) econometric software that I went proud of. I gave up when I knew about Gretl! Anyway, could you or anyone else recommand me any good book on C/C++ programming (in english, french or italian) or any other web resources, it should be a pleasure to invest my spare time (and much more than that) to be of any help in contributing to Gretl! It really deserves it!
Thanks once again, for having offered us a useful and great softawre!
Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de mail !
If this is the case, the error may be triggered during the computation of
> Local Whittle estimate of d. Javier, do you still get the error if you
> compute the raw periodogram (ie, without smoothing)?
Duh. Hate to reply to myself, but I've got it the other way around. I
meant WITH smoothing. In this case, the computation of the 2 estimates we
give of the long-memory parameter d is skipped, so if the problem is with
the Fourier routine you should be ok.
I don't understand very well what do you want to tell me. Do you refer to
calculate the estimated espectral function with the Bartlett's lag window?
If I do that I don't get the error
In order to fix the problem it is necessary to replicate it. Have you been
using the snapshot version all along? If you install earlier versions of
gretl and/or gnuplot, does the problem persist?
Yes, I have been using the snapshot version and the problem appears with
1.6.5 version, but when I install earlier version of Gretl (1.6.0,
specifically) the problem dissapears
Does it happen only with
the particular series you sent in an earlier message, or does it happen
all the time?
It happens with the serie I sent and with other series, but not with the
most of series
If you open the
gretl console and do
do you get the error? Or is it only when you select the
periodogram option from the menus?
Yes, I get the same error when I do in the console or with the menu
Are you running gretl in Spanish or in English?
I'm running Gretl in Spanish
Do you also get an error if you call for the correlogram of the
variable, from the menu?
No, if I call for the periodogram I don't get any error