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 Tue, 31 May 2011, Ignacio Diaz-Emparanza wrote:
> It seems there is a bug in the function packages editor. I was trying to
> change some lines in an existing package that was formed just by one
> function, but the button "edit function code" does not open the function
> editor. I tried several times with different packages, and there is not
> problem if the package contains two or more functions, but for packages
> with just one function the button does not open the editor.
Thanks for the report, Ignacio. This is now fixed in CVS.
On Thu, 5 May 2011, Riccardo (Jack) Lucchetti wrote:
> On Wed, 4 May 2011, Allin Cottrell wrote:
> > This is a cautionary tale: it can be more difficult that you'd
> > think, converting code from 1-based indexing to 0-based, when you
> > have nested loops to handle!
> As I said in my previous message, I find it quite odd that the problem
> hasn't surfaced in such a long time. Also mysterious is the failure by
> valgrind to detect it. Oh well.
It's odd, yes, but it's not something that valgrind is good at
catching: valgrind does a great job with memory allocated on the
"heap" (malloc) but doesn't help much with stack corruption.
I have some suggestions to replace some of the icons in gretl. As a
source gallery I have looked at www.iconspedia.com/search/gnome/ but I'm
no expert and this has been totally arbitrary. If you know of any more
compatible or cross-platform-friendly icons I'm happy to hear about them
and browse through them.
(Caveat: I don't fully understand how theme-ing affects the displayed
icons in gretl, or where do the icons come from in the Win and Mac
Considerable improvements possible (= where the current situation kind
of irritates me):
- user manual (in the toolbar, and in the help menu):
- why not make identical the command ref icons in the toolbar and in the
- new script (in the toolbar):
http://www.iconspedia.com/icon/gnome-document-new-10-83.html, although I
would prefer to have the icon show a document with lines (as in lines of
- maybe instead of the beta-hat icon use an icon explicitly showing the
letters "OLS", in a fancy font? (and no, not translateable)
- in the tools-> gretl console menu item use the same icon as in the toolbar
- tools -> settings (or is it options):
Only marginal improvements (= where current icons are pretty much ok IMO):
- start calculator (in the toolbar):
I'm aware that a more thorough overhaul of the icon situation would also
seem natural after these suggestions, but I thought I might just start
somewhere. Also I expect that not everybody would like the changes.
On Fri, 20 May 2011, Allin Cottrell wrote:
> Sven and Jack -- thanks for working on this. I have limited
> internet access at the moment. I agree it would be a good idea to
> put something on the gretl website about this.
There's now a note on Ubuntu 11.04 at
On Fri, 20 May 2011, Sven Schreiber wrote:
> Am 20.05.2011 08:00, schrieb Riccardo (Jack) Lucchetti:
> > On Thu, 19 May 2011, Sven Schreiber wrote:
> >> Actually 1.9.5 is already in "testing", it seems. I needed to install
> >> libgmp10 as well (plus libgretl1 and gretl-common of course), but
> >> everything looks good so far. This is on 32bit Ubuntu 11.04 running in
> >> classic mode (gnome, not unity). Tomorrow I can test on 64bit and on
> >> unity as well.
> And it works there, too. Of course the unity interface probably isn't
> very compatible with gretl's UI concept, because the menu bar is at the
> top of the screen, detached from the window. It's very nice if you have
> a maximized window, but not so with multiple windows. (Anybody knows how
> to change that without deactivating unity altogether?)
> > Just so everybody knows: Dirk has just uploaded to sid an updated
> > version with no visible changes to the end user (it just removes an
> > unnecessary dependency). It should enter into testing in 10 days. From a
> > practical point of view, using 1.9.5-1 (currently in testing) or 1.9.5-2
> > (now in unsatable) should make no difference to anyone.
> Apropos: In the changelog for 1.9.5-1 it says: " * debian/rules: Still
> configure with '--disable-sse2'" Does that mean that SSE2 (for RNG
> AFAIK) is not enabled here?
Sven and Jack -- thanks for working on this. I have limited
internet access at the moment. I agree it would be a good idea to
put something on the gretl website about this.
As for SSE2, Dirk and I had some emails back and forth a few weeks
back, and there's (now) no inherent reason for using SSE2 on
I just ran into the problem of not being able to use the default gretl
version in the current Ubuntu 11.04.
I know the problem is fixed in a later gretl version; however, to a
normal user it just looks as if it doesn't work, end of story. And given
the popularity of Ubuntu, I think this is bad for gretl's reputation and
So I would advocate one of two solutions:
- either the package maintainer (who is that for Ubuntu?) backports the fix
- alternatively (or minimally) I think the issue should be mentioned on
the gretl frontpage, and workarounds should be explained
Or am I missing something?
On Wed, 4 May 2011, Sven Schreiber wrote:
> it may seem strange that I'm asking about this after years of gretl
> usage, but here goes: I just noticed that I cannot save the ADF test
> output in Latex format. This is in contrast to model outputs, where it's
> a menu item. I don't know where else Latex output isn't available.
> I think having Latex output there could be just as useful as for models
> (the reason I haven't tried this before with ADF tests is just that I
> have only relatively recently begun to employ gretl's Latex output
> capabilities -- so it's not a sign that it isn't needed there IMHO).
> Could it even be a design goal for gretl to make all tabular output
> available in latex format?
It would be nice, yes. But It's quite tedious getting LaTeX output
just right for gretl constructions. And to an extent I've been
hampered by the self-imposed requirement that if we provide a
LaTeX option we should also provide an RTF option, for people on
Windows who want to paste into Word. Perhaps I should let that go?
On Thu, 5 May 2011, Sven Schreiber wrote:
> Am 05.05.2011 07:32, schrieb Marcin Błażejowski:
> > Hi,
> > simple script:
> > <script>
> > set echo off
> > set messages off
> > function void FOO (matrix mat)
> > printf "%d\n", nelem(mat)
> > end function
> > nulldata 10
> > matrix foo = zeros(2,1)
> > FOO(foo)
> > foo[1,1] = 1
> > FOO(foo)
> > </script>
> > In both situations we get what we excpect: 2
> I'm surprised it works at all, according to the docs nelem() is only for
> lists, not for matrices.
Sven is right: in concept, nelem() is only for lists. For
matrices, use rows() or cols(). However, to facilitate
manipulating lists, it's possible to "cast" from a (suitable)
matrix to a list, where a suitable matrix is a vector containing
nothing but non-negative integers.
What's happening here is that Marcin's matrix looks OK as a
representation of a list, but if it's interpreted that way then in
the second case it references the non-existent series 2.
I think it might be better (to avoid confusing error messages) to
modify "genr" so that the cast from a matrix to a list must be
done explicitly. In that case you'd get a "non-conformable types"
error if you try using nelem() on any object that's not already
defined as a list.