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 Fri, 29 Apr 2011, Ignacio Diaz-Emparanza wrote:
> This is only to report that this construction does not work:
> loop j=5..9
> list xreg$j = varA$j varB$j varC$j
> list lreg$j = null
> loop foreach i xreg$j
> series l$i = log($i + 1)
> list lreg0$j += l$i
> end loop
> end loop
It should now work OK in CVS. (Apart, that is, from the little bug
in the script itself: "lreg$j" versus "lreg0$j".)
On Sun, 24 Apr 2011, Henrique Andrade wrote:
> Em 11 de abril Henrique escreveu:
> Dear Allin,
> > I'd found a string that I think are not marked for translation:
> > Q-stat (in the correlogram window)
That one was already marked.
> I've found another unmarked strings:
> (1) Garch variants (on main menu);
> (2) including (on Johansen integration test results window);
> (3) Corrected for sample size (df = ) (on Johansen integration test results
Those are now added.
I'd found a string that I think are not marked for translation:
Q-stat (in the correlogram window)
*Henrique C. de Andrade*
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
On Fri, 15 Apr 2011, Allin Cottrell wrote:
> On Fri, 15 Apr 2011, Sven Schreiber wrote:
> > the following script throws an error and halts:
> > <script>
> > open greene14_1
> > catch smpl (Q<0) --restrict
> > </script>
> Ah, it continues OK in gretlcli, but stops in the GUI. I'll look
> into that.
OK "catch" now governs the smpl command in GUI script execution,
On Fri, 15 Apr 2011, Sven Schreiber wrote:
> the following script throws an error and halts:
> open greene14_1
> catch smpl (Q<0) --restrict
Ah, it continues OK in gretlcli, but stops in the GUI. I'll look
the following script throws an error and halts:
catch smpl (Q<0) --restrict
? open greene14_1 # balanced panel w/o missings
Lese Datendatei /usr/local/share/gretl/data/greene/greene14_1.gdt
Periodizität: 15, max. Beob.: 90
Liste 7 Variablen auf:
0) const 1) unit 2) year 3) C 4) Q
5) PF 6) LF
? catch smpl (Q<0) --restrict
Keine Beobachtung würde ausgelassen!
Fehler bei Skriptausführung: Stopp
> catch smpl (Q<0) --restrict
IMHO it would be in the spirit of 'catch' to let this script continue, no?
(BTW, never mind the misleading message "Keine Beobachtung würde
ausgelassen!" which is a translation bug, probably long-standing and
AFAIR not introduced by me. I will correct that soon.)
On Fri, 15 Apr 2011, Hélio Guilherme wrote:
> Maybe if we used "Observed" instead of "Actual" would make things easier.
In English both "actual" and "observed" are OK, but it would work
fine to translate "actual" as (the equivalent of) "observed".
> On Fri, Apr 15, 2011 at 2:28 PM, Ignacio Diaz-Emparanza <
> ignacio.diaz-emparanza(a)ehu.es> wrote:
> > El 15/04/11 14:53, Allin Cottrell escribió:
> > > On Fri, 15 Apr 2011, Ignacio Diaz-Emparanza wrote:
> > >
> > >> gretl from yesterday's CVS on Ubuntu Linux 10.04
> > >>
> > >> Cross-section data. I estimate an ols model, in the model window I
> > >> select /Graphs/fitted, actual plot/Actual vs fitted
> > >>
> > >> there is an error in the key:
> > >> it shows something like
> > >> actual=fitted (and a line)
> > >
> > > That's actually correct: the line is labeled "actual = predicted"
> > > because in this Theil-type plot it's the "45-degree" line, on
> > > which perfect predictions would lie.
> > >
> > Umm, .. I see. Then it is not correctly translated. "Actual" is one of
> > these tricky words that exist in Spanish as well but not exactly with
> > the same meaning (current).
> > In any case, don't you think it should be clearer to label it "45-degree
> > line"?
> > --
> > Ignacio Diaz-Emparanza
> > 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
> > www.ea3.ehu.es
> > _______________________________________________
> > Gretl-devel mailing list
> > Gretl-devel(a)lists.wfu.edu
> > http://lists.wfu.edu/mailman/listinfo/gretl-devel
Department of Economics
Wake Forest University
On Fri, 15 Apr 2011, Ignacio Diaz-Emparanza wrote:
> gretl from yesterday's CVS on Ubuntu Linux 10.04
> Cross-section data. I estimate an ols model, in the model window I
> select /Graphs/fitted, actual plot/Actual vs fitted
> there is an error in the key:
> it shows something like
> actual=fitted (and a line)
That's actually correct: the line is labeled "actual = predicted"
because in this Theil-type plot it's the "45-degree" line, on
which perfect predictions would lie.