Re: [Gretl-devel] Ignacio's tramo script
by Ignacio Díaz-Emparanza
I think something is wrong with the last changes.
On wednesday 19 I could run the attached scripts (with gretl for Windows)
without any problem, but on monday I installed the new Windows gretl snapshot
and today I obtained the same error as Sven mentioned: I get the beginning of
the .po file in the script output, and the error: "The systen cannot find the
specified file". I downloaded the current Windows snapshot, and now I do not
obtain the .po file in the script output, but the same error is displayed on
the screen, and the script aborted.
(Unluckily I did not save the gretl_install.exe file of the week before)
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
18 years, 11 months
Re: [Gretl-users] matrix declaration error
by Sven Schreiber
[redirecting to devel]
Riccardo (Jack) Lucchetti schrieb:
>
> ps Sven, Allin and I have been adding quite a few matrix functions
> lately. I have the feeling that at least some of your python programs
> (excellent style, by the way) could be written directly in CVS gretl now.
> Do you feel like giving it a try?
>
Well in terms of matrix functions there wasn't really anything missing IIRC.
But what are those things you guys added?
Apart from that I'm a bit hesitant because porting to gretl script means
abandoning object-orientation. So the structure would be quite
different, and therefore maintenance effort of the parallel python and
gretl programs would be a bit annoying.
I'm open for suggestions though as to how to overcome or reduce this
problem, because in general I also like the idea.
cheers,
sven
18 years, 11 months
Problems compiling Gretl.
by Hélio Guilherme
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi all,
I formatted the disc and installed OpenSuse 10.2.
Even in the previous system I was having error messages when compiling
Gretl. This new fresh installation serves also to test Gretl dependencies.
I installed in this order:
gretl-1.6.0.tar.bz2 - Extracted in home
blas-3_0-2.i386.rpm
lapack-3_0-2.i386.rpm
libgfortran41-4.1.2_20061115-5.i586.rpm
gcc-fortran (using Suse installer)
mpfr (using Suse installer)
gnuplot (using Suse installer)
libplot (dependencies from gnuplot)
With these the configure creates required files (Makefiles, ...), but
reports missing MPFR >= 2.2.0 and LAPACK.
I did solve before the LAPACK test by changing the order of linker
options "-l", and the compilation completes then.
But now I run out of hypothesis, so I ask for your help.
MPFR, config.log part:
...
configure:24396: checking for MPFR - version >= 2.2.0
configure:24479: gcc -o conftest -g -O2 -I/include conftest.c -L/lib
- -lmpfr -lc -lc -lm >&5
conftest.c:56:18: error: mpfr.h: No such file or directory
...
LAPACK, config.log part:
...
configure:24845: checking for LAPACK
configure:24884: gcc -o conftest -I./lib/src -g -O2 conftest.c
- -L/usr/lib -llapack -lblas -lgfor
tran -lc -lc -lm >&5
/usr/lib/liblapack.so: undefined reference to `s_stop'
/usr/lib/liblapack.so: undefined reference to `s_wsfe'
/usr/lib/liblapack.so: undefined reference to `r_lg10'
...
make screen output:
...
mkdir .libs
gcc -o .libs/gretlcli gretlcli.o complete.o
../lib/.libs/libgretl-1.0.so -L/usr/local/lib /usr/lib/libxml2.so -ldl
- -lz -lm -L/opt/gnome/lib /opt/gnome/lib/libglib-2.0.so -lrt
/usr/lib/libgmp.so -lreadline -lncurses
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dspsv_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpptri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpptrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpocon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dsyev_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgeev_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrtri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgelss_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dorgqr_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpotrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpotri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgeqrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgesvd_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrs_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetri_'
collect2: ld returned 1 exit status
make[1]: *** [gretlcli] Error 1
make[1]: Leaving directory `/home/helio/gretl-1.6.0/cli'
make: *** [cli] Error 2
helio@techno:~/gretl-1.6.0>
Thank you,
Hélio Guilherme
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFvnIrHvesJJ5UqvkRAoISAJ4/0oBoF5AdcVV6rylb9axMOAWhmACgzOLn
r5bBD6GznDrYyCwHyrsXZ8w=
=xvfh
-----END PGP SIGNATURE-----
18 years, 11 months
Re: [Gretl-users] vertical matrix concatenation (was matrix declaration error)
by Allin Cottrell
On Tue, 30 Jan 2007, Riccardo (Jack) Lucchetti wrote:
> X = (a ~ b') ~' ( c ~' d)
>
> and
>
> X = (a ~' b') ~' ( c' ~ d)
>
> are not immediate to tell apart.
Yikes, no, I don't like that.
> Hence, my counter-proposal (which, I admit, does have drawbacks,
> but is still preferable IMHO): use "|" for vertical
> concatenation and switch to "&&" and "||" for logical operators.
> It will break existing syntax, but it'd be better in the long
> run.
That does make sense, but I'm a bit reluctant to change the
meaning of logical "&" and "|" right now -- though we could do
that later with fair warning.
How about '#' for now? It's not pretty (or standard), but it
shouldn't collide with anything and is visually distinctive.
Allin
18 years, 11 months
still some function package editing problems
by Sven Schreiber
Hi,
with a cvs build from 2 min ago: when (in a function package) I try to
edit a function, some changes are persistent, others are not.
I can change (in a function argument context) "list restr_exo" to "const
list restr_exo", but not "list restr_exo" to "list restr_exo[null]".
cheers,
sven
18 years, 12 months
i18n fix needed in lib/gmm.c
by Cristian Rigamonti
Hi, I've fixed a typo in lib/gmm.c (just committed), but I noticed a possible
problem with translation in the same lines (1116-8):
pprintf(prn, " %s\n", _("Orthogonality"));
pprintf(prn, " %10s %10s %10s\n\n", _("condition"),
_("mean"), _("std. dev"));
Printing "Orthogonality" above "condition" is correct in English but not in
other languages (the words should be reversed).
Can we work out a way to fix it?
I thought about this, but I guess it's not correct:
pprintf(prn, " %10s %10s %10s\n\n", _("Orthogonality\ncondition"),
_("mean"), _("std. dev"));
Or maybe just make a single string "Orthogonality condition" (but I guess you
had good reasons not to do that in the beginning)?
Or maybe contract "Orth. condition" (but it's not that beautiful)?
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
19 years
another function bug
by Sven Schreiber
Some new bugs I have noticed:
- The most serious: the following example script adds a scalar
"determ_case" to the list of variables, which is completely unintended
and I don't see why it should be so, because it's just an internal
function parameter.
<script>
function vec_decomp (const list endogenous, int ci_rank[1:10:1]), int
determ_case[1:5:3])
list result = null
loop foreach i endogenous
series $i_SWP = i
list result = result $i_SWP
endloop
return list result
end function
## test input:
open denmark
list endo = LRM LRY
list test2 = vec_decomp(endo, 1, 3)
</script>
- The other things are quite trivial: "const", "foreach" and "i" (index
variable) could maybe use some syntax coloring as well, and with "'" as
the transpose notation there are also syntax coloring problems. (It is
interpreted as a string delimiter.)
bye,
sven
19 years
scripting-related
by Sven Schreiber
Hi gretlers,
I just experienced a strange bug that disappeared when I changed all
lines containing just the name of a matrix, say beta_star (to print it,
like on p.70 of the manual), to an explicit 'print beta_star' line.
Before the change, gretl threw an error like "command 'beta_sta' not
known" (note the 8-char truncation).
What was especially strange was that the line 'beta_star' was coming
after an if-check that in this particular case was FALSE, and so the
syntax of the line should have been completely irrelevant. (And gretl
indeed did not execute the other statements in the if-block before the
beta_star line.)
Sorry, but I wasn't able to construct a small self-contained example, so
it seems relatively subtle. However I am pretty confident it is a bug
because as I said, with the explicit 'print xx' variant everything
*seems* to work now.
-- BTW, another unrelated thing: I still see the following in the first
line of a newly fired up gretl-console:
gretl-Konsole: geben Sie 'help' für eine Liste von Befehlen ein
?help
Befehl 'elp' unbekannt
?
And while I'm at it, during function-debugging I often have to close and
restart gretl because it starts reporting nonsense errors (that go away
just by re-loading everything) after the first function error has
occurred. I know that's a pretty vague bug report, but it seems that
gretl may need to clean up its internals a little more after it
encountered a function error...
Anyway, I don't think these things should hold up a new release. Are
there still any other open issues? (Oh, apart from the shell-command
synchronicity thing on Windows... I will test that eventually.)
Cheers,
Sven
19 years
funcerr error
by Sven Schreiber
A new day, a new bug ;-)
I re-built from cvs today, and now I apparently get the beginning of the
.po file in the script output when the function I have called hits a
'funcerr' statement.
(In the example below 'vec_meta' is the function, and a funcerr is
correctly triggered with the given message.)
The bug is clearly not severe because a funcerr stops execution anyway.
Example output:
vec_meta: "This option is not available. Stopping."
Project-Id-Version: gretl-1.6.0
Report-Msgid-Bugs-To:
POT-Creation-Date: 2007-01-12 14:24-0500
PO-Revision-Date: 2007-01-14 22:59+0100
Last-Translator: Sven Schreiber <svetosch gmx.net>
Language-Team: German <gnome-de(a)gnome.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Plural-Forms: nplurals=2; plural=(n != 1)
Fehler bei Skriptausführung: Stopp
-sven
19 years
p.s. (minor issues)
by Sven Schreiber
Sorry, I forgot some trivial things:
In relation to the outfile command: the message 'Closed output file <x>'
seems to be not marked for translation?
And although I have "set messages off" and "set echo off" all over my
functions, I still get unwanted feedback from 'outfile' and 'store'. Am
I missing something or is it a bug?
Good night,
sven
19 years
