Hello, gretl developers.
I'm trying to start a translation of help files into russian on
launchpad.net as it seems to be the most suitable tool to participate
for all familiars with econometrics but not with gettext, linux. cvs,
The problem is that there is already a project for gretl on launchpad
and it is strongly prohibited to start more than one project for a
single program. I cannot contact with Constantine Tsardounis for about
a month, so I think it is time to re-assign that project to someone
else. On the irc-channel of launchpad I was told that
Our admins can re-assign the project to new owners but we'd prefer to
hear from the upstream owners. can you get one of them to submit a
But if nobody from main developers wants to register and do something
at launchpad it is possible to assign this function to me and in that
case a letter in this list will probably be enough.
I have prepared a .po-file for genr_funcs.xml and gretl_commands.xml
with the help of po4a utility and got 1511 strings for translation
(strings a rather big).
Good luck, Ivan Sopov.
P.S. My previous letter about using launchpad for translation is
As some of you know, we're currently experimenting with openmp in
gretl. When building from CVS, use of openmp is the default (if
openmp is supported on the host) unless you pass the option
--disable-openmp to the configure script. In addition the current
snapshots for Windows and OS X are built with openmp support
(using gcc 4.4.3 and gcc 4.2.4 respectively).
This note is just to inform you about the state of play, and to
invite submission of test results if people would like to do that.
Right now, we use openmp only for gretl's native matrix
multiplication. So it'll get used (assuming you have at least two
cores) if you do matrix multiplication in a script, or call a
function that does matrix multiplication (such as qform), or use a
built-in command that happens to call matrix multiplication. If we
decide it's a good idea, we could use openmp directives in other
gretl code (but as along as we rely on lapack for much of our
number-crunching, and as long as lapack is not available in a
parallelized form, the scope for threading will remain somewhat
In a typical current use situation, with gretl running on a
dual-core machine where there's little other demand being placed
on the processors, the asymptotic speed-up from openmp should be
close to a factor of two. However, it takes a big calculation to
get close to the asymptote, and we've found that with small to
moderate sized matrices the overhead from starting and stopping
threads dominates, producing a slowdown relative to serial code.
This is similar to what we found with regard to the ATLAS
optimized blas; see
Anyway, in case anyone would like to test I'm attaching a matrix
multiplication script that Jack wrote. Right now this is mostly
useful for people building gretl from source, since you want to
run timings both with and without MP, which requires rebuilding.
But if you're currently using a snapshot from before yesterday
(build date 2010-03-21 or earlier) you could run the script, then
download a current snapshot and run it again.
On Mon, 28 Feb 2011, Marcin B�^Bażejowski wrote:
> the latest windows builds generate such warning message on win2000: "The
> procedure entry point getaddrinfo could not be located in the dynamic
> link library WS2_32.dll".
> Is it mean that win2k is no longer support?
Ah, that's right, the updated version of the GLib dll does not
Perhaps we should put out a version of gretl 1.9.4 with support
for old systems (Windows 2000 and non-SSE2 processors), once we've
figured out exactly what has to be done to make that work.
the latest windows builds generate such warning message on win2000: "The
procedure entry point getaddrinfo could not be located in the dynamic
link library WS2_32.dll".
Is it mean that win2k is no longer support?
On Thu, 24 Feb 2011, Sven Schreiber wrote:
> I got a similar error, but I don't think it has to do with the commit
> per se.
> What surprises me, though, is that you are checking in a new revision of
There's something weird (though I believe harmless) about CVS and
the up-to-dateness of .po files.
Every now and then I run "make update-po" to sync the .po files
with a revised gretl.pot, then do a commit. Fine, all the .po
files get updated. Then later, at home, I do a CVS update and I
get the new .po files OK. Then maybe I edit some non-po file and
do a commit (still at home); and I notice that the "modified"
files committed include 2 or 3 of the .po files, which I have not
explicitly touched. Puzzling. I should probably use "cvs diff" to
see what's happening here. But I'm pretty sure nothing substantive
is being changed in these "ghost commits".
On Thu, 24 Feb 2011, Talha Yalta wrote:
> I have just comitted the TR translation updates but I also received
> the below error(s). Do you think it went through? Do I have to do
> File "/usr/lib64/python2.4/smtplib.py", line 306, in connect
> raise socket.error, msg
> socket.error: (111, 'Connection refused')
That is breakage in the mechanism that used to work for
auto-emailing notifications of CVS commits in the translations
area. I suppose this is fallout from the changes made following
the hacking of Sourceforge. But although it looks messy it's
harmless, the commits go through OK. (I filed a support ticket
about this, maybe 10 days ago, but I haven't heard anything back.)
I have just comitted the TR translation updates but I also received
the below error(s). Do you think it went through? Do I have to do
Checking in de.po;
/cvsroot/gretl/gretl/po/de.po,v <-- de.po
new revision: 1.240; previous revision: 1.239
Checking in tr.po;
/cvsroot/gretl/gretl/po/tr.po,v <-- tr.po
new revision: 1.220; previous revision: 1.219
Generating notification message...
Generating notification message... done.
Generating notification message...
Traceback (most recent call last):
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 433, in ?
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 426, in main
contextlines, fromhost, replyto)
File "/cvsroot/sitedocs/CVSROOT/cvstools/syncmail", line 223, in blast_mail
File "/usr/lib64/python2.4/smtplib.py", line 306, in connect
raise socket.error, msg
socket.error: (111, 'Connection refused')
“An expert is a person who has made all the mistakes that can be made
in a very narrow field.” - Niels Bohr (1885-1962)
Hi, I finally understood how to program a script and how to create a package (thanks, mostly, to the script sent to me be Allin Cottrell, but also to the GRETL's user guide). I must confess that the process is very simple. I made several tests in order to be sure that the new GRETL version and the original matlab version provide the same results (and they do) so I think that the package works fine. I only have a small last question: suppose I find a bug in my package (or something like that). If I upload to the server an improved version under the same name, the latter will automatically replace the old version or the old version must be erased "by hand"? Thanks
From: Daniel Ventosa S. <dventosa(a)yahoo.com>
To: GRETL list <gretl-devel(a)lists.wfu.edu>
Sent: Tuesday, February 8, 2011 8:46 AM
Subject: Many thanks (a small econometric proposal)
Many thanks for the help. I tried to package the function following the manual's instruction. That's when I realized that I am too ignorant of GRETL's architecture. I was absolute incompetent in doing so. I think I'll have to read more carefully the manual (and from the first page). Anyway, thanks a lot,
On Mon, 14 Feb 2011, Ignacio Diaz-Emparanza wrote:
> Another question I see is not well resolved, IMHO, is when you want to
> prepare a package function that produces a list of series. In this case,
> the dialog box of the f. package that appears to the user has a field
> "Assign return value(optional):
> Selection or new variable... "
> and a box field to select an already defined list or to define a new
> name. (See for example the function package Brown in the server).
> Recently I saw (newbie) users very confused about this field...
Returning a list is fine for command-line use, but I think the
best way of constructing a user-friendly GUI function call is via
bundles. Jack and I have been working on this and we'll get it
documented for 1.9.4. In the meantime you might like to play with
the attached: it's a re-write of your Brown package to use
bundles. Inside the tarball is all you need to build and install
the revised package ("make", "make install" should do it). You'll
need current CVS for everything to work right.
Basic idea: the user does not specify a return assignment, but
he/she can get everything the package provides via the GUI, using
menus in the window that the GUI function creates. In this case
the user should be able to save the linear and/or quadratic trend
(and also see a plot of the results).
I should mention, my version of Brown uses a function that's not
yet documented (though it has been in CVS for a while), namely
"setnote". This adds a descriptive note to an item within a
Allin (and friends),
Another question I see is not well resolved, IMHO, is when you want to
prepare a package function that produces a list of series. In this case,
the dialog box of the f. package that appears to the user has a field
"Assign return value(optional):
Selection or new variable... "
and a box field to select an already defined list or to define a new
name. (See for example the function package Brown in the server).
Recently I saw (newbie) users very confused about this field. As this
field was optional they only selected the other params, cliked on accept
and got nothing. I had to tell them to put a new name into that field
for the package to work (and then I modified the function so that now at
least the output is displayed in a text window).
I think it could be solved if the function programmer could put a
default value for the (new) defined list.
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754