12:14 p.m.
Hi,
I am now back to using gretl on Windows (more often at least). So
finally I tested py4gretl on win and of course it fails. Actually I
think it probably also would fail in most desktop ways of using it, even
on *nix.
The reason are the missing write permissions in the current directory
(./), where py4gretl (both gretl and python sides) stores two temp
files. That "current" (at the time of invoking gretl) directory I guess
will often be the installation directory of gretl, where a normal user
cannot write.
So I am thinking of other places to store the temp files. However,
py4gretl needs to pass that information from the gretl side to the
python side, so it's name must somehow be accessible from gretl script.
Hence my question: what type of environment variables can be used in a
script? Or any other ideas on a good place to store temp files (on all
supported platforms)?
Thanks,
Sven
12:59 p.m.
On Thu, 12 Apr 2007, Sven Schreiber wrote:
So I am thinking of other places to store the temp files. However,
py4gretl needs to pass that information from the gretl side to the
python side, so it's name must somehow be accessible from gretl script.
Hence my question: what type of environment variables can be used in a
script? Or any other ideas on a good place to store temp files (on all
supported platforms)?
See chapter 11, section 2 of the User's Guide, sub-head "Built-in
strings". You have "@userdir" which gives the user directory,
which must be writable (or else gretl will fail at startup).
We could maybe add a "getenv" function for strings, so you could
grab variables in the external environment.
Allin.
1:18 p.m.
On Thu, April 12, 2007 14:59, Allin Cottrell wrote:
On Thu, 12 Apr 2007, Sven Schreiber wrote:
> So I am thinking of other places to store the temp files. However,
> py4gretl needs to pass that information from the gretl side to the
> python side, so it's name must somehow be accessible from gretl script.
>
> Hence my question: what type of environment variables can be used in a
> script? Or any other ideas on a good place to store temp files (on all
> supported platforms)?
See chapter 11, section 2 of the User's Guide, sub-head "Built-in
strings". You have "@userdir" which gives the user directory,
which must be writable (or else gretl will fail at startup).
We could maybe add a "getenv" function for strings, so you could
grab variables in the external environment.
That'd be very useful. I am currently working on a paper where I had to
run a number of Monte Carlo experiments. I managed to hack a shell script
with some grep/sed magic to get what I wanted, but getenv() would have
been very useful. sprintf() would also be good.
(Yeah, I know, I could have coded those myself, but I'm too busy atm.
Besides, once I'm done with this paper, I need to find some time to put
fft() in good shape and write some documentation).
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
3:48 p.m.
On Thu, 12 Apr 2007, Riccardo (Jack) Lucchetti wrote:
[getenv would] be very useful. I am currently working on a paper
where I had to run a number of Monte Carlo experiments. I
managed to hack a shell script with some grep/sed magic to get
what I wanted, but getenv() would have been very useful.
I'll see what I can do about that.
sprintf() would also be good.
It's already there:
? sprintf foostr "egg%d", 10
Saved string as 'foostr'
? print "@foostr"
egg10
No, it's not in the manual yet, I'm afraid!
Allin.
2:43 p.m.
Allin Cottrell schrieb:
On Thu, 12 Apr 2007, Sven Schreiber wrote:
>
> Hence my question: what type of environment variables can be used in a
> script? Or any other ideas on a good place to store temp files (on all
> supported platforms)?
See chapter 11, section 2 of the User's Guide, sub-head "Built-in
strings". You have "@userdir" which gives the user directory,
which must be writable (or else gretl will fail at startup).
Again, I should have read the latest manual... That sounds very good!
(Although your last statement above doesn't seem 100% correct at least
on windows, gretl started ok for me with a user dir setting of "/".
Don't know what that would mean on windows, but I couldn't open a gretl
console or a new script until I changed that to something more sensible.)
I also just learned about the named strings. Very nice as well! But --
I can print out "@userdir" alright, but can't assign to a string:
? string jojo = "@userdir"
Syntax error in command line
? string jojo = @userdir
Syntax error in command line
? print "@userdir"
C:\openprogs\gretlwork\
?
Bug or feature?
And BTW, could strings be used as function arguments/parameters? (Not
that I have an urgent need, just checking.)
And finally totally unrelated: could it be that the latest win snapshot
has no syntax coloring support compiled in?
We could maybe add a "getenv" function for strings, so you could
grab variables in the external environment.
I guess a working @userdir would be enough for my needs, but of course
if I'm not opposed to other possibilities...
thanks,
Sven
3:58 p.m.
On Thu, 12 Apr 2007, Sven Schreiber wrote:
Again, I should have read the latest manual... That sounds very
good!
(Although your last statement above doesn't seem 100% correct at least
on windows, gretl started ok for me with a user dir setting of "/".
Oops, then that needs fixing.
I also just learned about the named strings. Very nice as well! But
--
I can print out "@userdir" alright, but can't assign to a string:
? string jojo = "@userdir"
Syntax error in command line
? string jojo = @userdir
Syntax error in command line ...
Bug or feature?
Bug, I'd say.
And BTW, could strings be used as function arguments/parameters?
(Not that I have an urgent need, just checking.)
Functions don't accept string arguments as such. But you could
build a function call using saved strings. Saved strings are
essentially macros: "@foo" is cashed out prior to parsing the
command line.
And finally totally unrelated: could it be that the latest win
snapshot has no syntax coloring support compiled in?
I suppose it could be. Not sure why that would be. I'll have to
try it myself.
Allin.
4:13 p.m.
On Thu, 12 Apr 2007, Allin Cottrell wrote:
> ? string jojo = "@userdir"
> Syntax error in command line
> ? string jojo = @userdir
> Syntax error in command line ...
> Bug or feature?
Bug, I'd say.
To be more precise, only the first of the above is expected to
work, since a string literal needs quotes around it. The odd
thing is that here it _does_work:
? string jojo = "@userdir"
Saved string as 'jojo'
? print "@jojo"
/home/cottrell/gretl/
Allin.
5:20 p.m.
Allin Cottrell schrieb:
On Thu, 12 Apr 2007, Allin Cottrell wrote:
>> ? string jojo = "@userdir"
>> Syntax error in command line
>> ? string jojo = @userdir
>> Syntax error in command line ...
>> Bug or feature?
> Bug, I'd say.
To be more precise, only the first of the above is expected to
work, since a string literal needs quotes around it. The odd
thing is that here it _does_work:
? string jojo = "@userdir"
Saved string as 'jojo'
? print "@jojo"
/home/cottrell/gretl/
I guess it has to do with the backslashes on windows, especially the
'\"' that comes out in the end (this time in German, but still evident):
? print "@userdir"
C:\openprogs\gretlwork\
? string jojo = "@userdir "
Saved string as 'jojo'
? string jojo = "@userdir"
Syntax-Fehler in Befehlszeile
?
But I'm afraid the trailing space cannot be used as a workaround in many
cases. Actually AFAIK Windows can also digest forward slashes internally
as path separators, so maybe that would be the way to go instead of
fixing the complicated parsing? Or double backslashes?
In general I must say I don't quite understand the need to have both the
@-escape *and* enclosing double quotes for a string variable. Well I
understand it after you've given the macro explanation, but it certainly
feels strange and in this particular case will cause you headaches...
-sven
5:56 p.m.
On Thu, 12 Apr 2007, Sven Schreiber wrote:
I guess it has to do with the backslashes on windows, especially the
'\"' that comes out in the end (this time in German, but still evident):
? print "@userdir"
C:\openprogs\gretlwork\
? string jojo = "@userdir "
Saved string as 'jojo'
? string jojo = "@userdir"
Syntax-Fehler in Befehlszeile
But I'm afraid the trailing space cannot be used as a workaround
in many cases. Actually AFAIK Windows can also digest forward
slashes internally as path separators...
Internally, yes, but I don't think command.com can handle them.
Maybe the solution is, when parsing a string definition, to treat
a trailing \" as if it were \\" (\" could never be a valid
ending for a string literal).
Allin.
8:01 p.m.
Allin Cottrell schrieb:
Maybe the solution is, when parsing a string definition, to treat
a trailing \" as if it were \\" (\" could never be a valid
ending for a string literal).
At least I cannot think of anything better, whatever that means...
BTW, I noticed already earlier that the print command is quite liberal
in that respect, I think it doesn't even require the closing second
quote char.
Let's see how far I get with the current state of the @userdir affair...
Thanks,
Sven
3:54 p.m.
Sven Schreiber schrieb:
Let's see how far I get with the current state of the @userdir affair...
Oh I'm so stupid... My earlier py4gretl problem on windows had nothing
to do with write permissions at all (I think;-), but was just due to the
fact that python was not in the PATH for my new system setup.
Another stupidity: My comment about syntax coloring was bogus, too,
because I attributed it to the console (instead of a script, where it
works fine).
Nevertheless I'm rounding off this message with some remarks about
perceived minor glitches on Windows:
- could not open the pdf user guide, error says application not found --
which application is gretl trying to find?
- Admin privileges are needed to install, which is understandable. But
it is a bit strange that the installer wants the _one_ location where
"personal data files" are stored. It seems that that's the directory
which then is written to the preferences as the gretl user directory,
but for _every_ user? IMHO a better solution would be to *not* ask for
it at installation time, but just use a reasonable default, and let
individual users adjust their respective preferences.
- (not windows-specific:) It seems impossible to load packaged function
files (.gfn) into gretl from somewhere on the harddisk. This is a bit
awkward (if I'm not missing something).
Thanks,
SVen
7:57 p.m.
On Fri, 13 Apr 2007, Sven Schreiber wrote:
- could not open the pdf user guide, error says application not
found -- which application is gretl trying to find?
On Windows, gretl just tells the OS to open the PDF file. So
whatever is the default PDF viewer.
ShellExecute(NULL, "open", fname, NULL, NULL, SW_SHOW);
where "fname" is the name of the PDF file.
- Admin privileges are needed to install, which is
understandable. But it is a bit strange that the installer wants
the _one_ location where "personal data files" are stored. It
seems that that's the directory which then is written to the
preferences as the gretl user directory, but for _every_ user?
You mean you can have more than one user on Windows? ;-) I'll
have to look into that.
- (not windows-specific:) It seems impossible to load packaged
function files (.gfn) into gretl from somewhere on the harddisk.
This is a bit awkward (if I'm not missing something).
No, I don't think you're missing anything there. We could add a
"free range" file open box for .gfn files.
Allin.
3:55 p.m.
Allin Cottrell schrieb:
On Thu, 12 Apr 2007, Sven Schreiber wrote:
>
> But I'm afraid the trailing space cannot be used as a workaround
> in many cases. Actually AFAIK Windows can also digest forward
> slashes internally as path separators...
Internally, yes, but I don't think command.com can handle them.
Hm, I'm no expert on this, but this is taken from
http://gnuwin32.sourceforge.net/install.html:
<quote>
Path separators
The MS-Windows command interpreters, command.com and cmd.exe, understand
both the backward slash '\' (which is the default) and the forward slash
'/' (such as on Unix) in filenames. In general, it is best to use
forward slashes, since some programs internally use the filename, e.g.
to derive a directory name, and in doing this rely on the forward slash
as path separator.
</quote>
So maybe still worth a try?
-sven
4:25 p.m.
On Thu, 12 Apr 2007, Sven Schreiber wrote:
In general I must say I don't quite understand the need to have
both the @-escape *and* enclosing double quotes for a string
variable. Well I understand it after you've given the macro
explanation, but it certainly feels strange and in this
particular case will cause you headaches...
OK, I agree with you. On reflection, this is lame. (I have to
admit that the string variable code was thrown together too
hastily.)
I'm committing to CVS a change, whereby @foo-type string variables
are treated as proper variables in the relevant contexts, namely,
* when used as arguments to printf or sprintf, and
* when they appear on the right-hand side of
string sname = ...
This means that from now on you should _not_ enclose the names of
such variables in quotes in those contexts. Examples:
? printf "user dir is %s\n", @userdir
user dir is /home/allin/gretl
? string foo = @gretldir
Saved string as 'foo'
? print "@foo"
/opt/esl/share/gretl
? printf "%s\n", @foo
/opt/esl/share/gretl
? printf "%s\n", "@foo"
@foo
Allin.
3:46 p.m.
New subject: not working in Kubuntu
This is only to report that building gretl in kubuntu
with the current cvs version of gretl, I have two problems:
1- In running "make" the program asked for a new program "fftw3" and I
could
not get gretl built until I installed it and "fftw3-dev".
2-Installing this two packages I got no error in "make" and "make
install",
but when I try to run gretl (in a console) I get the error:
etpdihei@ataul:~$ gretl
/opt/gretl/bin/gretl_x11: error while loading shared libraries:
libgretl-1.0.so.0: cannot open shared object file: No such file or directory
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
3:58 p.m.
New subject: not working in Kubuntu
On Mon, April 16, 2007 17:46, Ignacio Diaz-Emparanza wrote:
This is only to report that building gretl in kubuntu
with the current cvs version of gretl, I have two problems:
1- In running "make" the program asked for a new program "fftw3" and
I
could
not get gretl built until I installed it and "fftw3-dev".
2-Installing this two packages I got no error in "make" and "make
install",
but when I try to run gretl (in a console) I get the error:
etpdihei@ataul:~$ gretl
/opt/gretl/bin/gretl_x11: error while loading shared libraries:
libgretl-1.0.so.0: cannot open shared object file: No such file or
directory
My fault.
I added the fast Fourier transform to our matrix repertoire via the fftw3
library and practically forced Allin to swallow it.
All I can say is that on my debian boxes everything works ok after
installing the 2 packages you mention. Perhaps Ubuntu has an earlier
version? I'd find it surprising, since fftw3 is a needed package for
octave too. Besides, I only used very simple functions, so a bleeding
edge version of fftw3 should be unnecessary.
Did you run ./configure before make?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
4:25 p.m.
New subject: not working in Kubuntu
El Lunes, 16 de Abril de 2007 17:58, Riccardo (Jack) Lucchetti escribió:
> but when I try to run gretl (in a console) I get the error:
>
> etpdihei@ataul:~$ gretl
> /opt/gretl/bin/gretl_x11: error while loading shared libraries:
> libgretl-1.0.so.0: cannot open shared object file: No such file or
> directory
My fault.
I added the fast Fourier transform to our matrix repertoire via the fftw3
library and practically forced Allin to swallow it.
All I can say is that on my debian boxes everything works ok after
installing the 2 packages you mention. Perhaps Ubuntu has an earlier
version? I'd find it surprising, since fftw3 is a needed package for
octave too. Besides, I only used very simple functions, so a bleeding
edge version of fftw3 should be unnecessary.
Did you run ./configure before make?
Yes I usually build gretl from a script that executes
./configure --prefix=/opt/gretl --without-gnome --enable-build-doc
make
make check
sudo make install
I don't think the problem is with the fftw3 version, since ./configure
shows "FFTW3 support: yes" in the output.
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
9:10 p.m.
New subject: not working in Kubuntu
On Mon, 16 Apr 2007, Ignacio Diaz-Emparanza wrote:
El Lunes, 16 de Abril de 2007 17:58, Riccardo (Jack) Lucchetti
escribió:
> > but when I try to run gretl (in a console) I get the error:
> >
> > etpdihei@ataul:~$ gretl
> > /opt/gretl/bin/gretl_x11: error while loading shared libraries:
> > libgretl-1.0.so.0: cannot open shared object file: No such file or
> > directory
>
> [snip]
>
> Did you run ./configure before make?
Yes I usually build gretl from a script that executes
./configure --prefix=/opt/gretl --without-gnome --enable-build-doc
make
make check
sudo make install
I don't think the problem is with the fftw3 version, since ./configure
shows "FFTW3 support: yes" in the output.
Ignacio, could you try doing "make clean" followed by
make 2>errs
and see what's in the "errs" file? Thanks.
Allin.
1:35 p.m.
New subject: not working in Kubuntu
El Lunes, 16 de Abril de 2007 23:10, Allin Cottrell escribió:
Ignacio, could you try doing "make clean" followed by
make 2>errs
and see what's in the "errs" file? Thanks.
I finally solved the problem executing "ldconfig" as root.
I usually do not need to do so when I update gretl from CVS, so
I don't know why this time I needed it, .... but it is because I really don't
understand well how "ldconfig" and the file ld.so.conf work.
(The "errs" file didn't show any error, only some warnings)
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
4:01 p.m.
New subject: not working in Kubuntu
On Tue, 17 Apr 2007, Ignacio Diaz-Emparanza wrote:
El Lunes, 16 de Abril de 2007 23:10, Allin Cottrell escribió:
>
> Ignacio, could you try doing "make clean" followed by
>
> make 2>errs
>
> and see what's in the "errs" file? Thanks.
I finally solved the problem executing "ldconfig" as root.
I usually do not need to do so when I update gretl from CVS, so
I don't know why this time I needed it, ....
Funny: "make install" ends by running ldconfig. I wonder if it
was the fftw library that was not registered in ld.so.cache until
you ran ldconfig manually?
Allin.
4:29 p.m.
New subject: not working in Kubuntu
On Tue, April 17, 2007 18:01, Allin Cottrell wrote:
On Tue, 17 Apr 2007, Ignacio Diaz-Emparanza wrote:
>
> I finally solved the problem executing "ldconfig" as root.
>
> I usually do not need to do so when I update gretl from CVS, so
> I don't know why this time I needed it, ....
Funny: "make install" ends by running ldconfig. I wonder if it
was the fftw library that was not registered in ld.so.cache until
you ran ldconfig manually?
The debian package for fftw3 does run ldconfig (actually, it's the only
thing that runs after installation, as part of the "configure" chore). I
would expect the ubuntu .deb file to do the same.
If you install fftw3 via
apt-get install fftw3 fftw3-dev
or any menu-driven equivalent (aptitude, synaptic, dselect, whatever) you
should be ok.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
10:59 a.m.
New subject: Some small bugs
(gretl from current cvs in kubuntu Linux with spanish language)
1-In a gretl console, writing "help command" (for example "help ols")
I obtain
an error box with the text "g_locale_to_utf8 failed for charset
'UTF-8'", I
click on "close" and gretl exits. If I execute gretl from a console, in this
situation an error is reported:
console text did not validate as utf8
Segmentation fault
2- I cannot run gretl in english, "gretl --english" is not working for me. May
be a problem with my kubuntu installation?
3- I tried to build a dummy using the command in the "gretl command reference"
page 16:
(for example with data9-9)
genr d = (obs>1982:1)
but I obtained an error:
? genr dd=(obs>1982:1)
genr dd=(obs>1982:1
Se esperaba ')' pero se encontró
':'
(gretl was waiting for a ')' but found ':')
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
12:15 p.m.
New subject: Some small bugs
On Thu, 19 Apr 2007, Ignacio Diaz-Emparanza wrote:
(gretl from current cvs in kubuntu Linux with spanish language)
1-In a gretl console, writing "help command" (for example "help ols")
I obtain
an error box with the text "g_locale_to_utf8 failed for charset
'UTF-8'", I
click on "close" and gretl exits. If I execute gretl from a console, in this
situation an error is reported:
console text did not validate as utf8
Segmentation fault
Thanks for the report. I'll investigate these things tonight on
my home Ubuntu machine.
2- I cannot run gretl in english, "gretl --english" is not working for me. May
be a problem with my kubuntu installation?
3- I tried to build a dummy using the command in the "gretl command reference"
page 16:
(for example with data9-9)
genr d = (obs>1982:1)
but I obtained an error:
? genr dd=(obs>1982:1)
> genr dd=(obs>1982:1
Se esperaba ')' pero se encontró ':'
(gretl was waiting for a ')' but found ':')
I need to update the manual on that. If the reference observation
is given by date it has to be quoted:
genr dd=(obs>"1982:1")
Allin.
3:58 a.m.
New subject: Some small bugs
On Thu, 19 Apr 2007, Ignacio Diaz-Emparanza wrote:
1-In a gretl console, writing "help command" (for example
"help
ols") I obtain an error box with the text "g_locale_to_utf8
failed for charset 'UTF-8'", I click on "close" and gretl exits.
I've checked this now and I see what you mean. That gretl crashed
on the encoding error was a simple bug, now fixed in CVS. The
encoding error itself is a bit more complex. I'll explain what's
going on and maybe we can out what's the best fix.
When you call for help in the gretl console, the help file that
gets read is the same one used by gretlcli. Traditionally this
has been encoded in ISO-8859-N, because that has been the most
common encoding in Linux terminals (though that is changing now).
But GTK requires UTF-8, so when we display a chunk of the help
file we need to ensure it's in UTF-8, recoding if necessary. In
general, when we're about to display stuff in the console we (a)
check if it's valid UTF-8, and if not then (b) call for recoding.
But recoding from what character set? The assumption up till now
has been: the character set that glib says is in use on the local
system. But on Ubuntu the local system encoding is UTF-8, so
gretl is thoroughly confused: it ends up trying to recode from
UTF-8 to UTF-8, but the help file text is not actually UTF-8 at
all!
One workaround (i.e., should solve your problem right now) would
be to use the "recode" utility to turn gretlcli.hlp.es into UTF-8.
In fact, I think we should probably produce and distribute all
gretl help files in UTF-8, and recode to the local encoding at the
terminal as and when needed (that is, not at all on current
Ubuntu and similar modern Linux systems).
Allin.
4:05 a.m.
New subject: Some small bugs
On Thu, 19 Apr 2007, Allin Cottrell wrote:
One workaround (i.e., should solve your problem right now) would
be to use the "recode" utility to turn gretlcli.hlp.es into UTF-8.
Just checked and, yes, that works fine:
recode iso8859-1..utf8 gretlcli.hlp.es
Allin
7:23 a.m.
New subject: Some small bugs
El Viernes, 20 de Abril de 2007 05:58, Allin Cottrell escribió:
One workaround (i.e., should solve your problem right now) would
be to use the "recode" utility to turn gretlcli.hlp.es into UTF-8.
In fact, I think we should probably produce and distribute all
gretl help files in UTF-8, and recode to the local encoding at the
terminal as and when needed (that is, not at all on current
Ubuntu and similar modern Linux systems).
Allin.
I recoded the gretlcli.hlp.es file,
and the help is working now.
Thank you, Allin.
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
5:52 p.m.
On Thu, 12 Apr 2007, Sven Schreiber wrote:
And finally totally unrelated: could it be that the latest win
snapshot
has no syntax coloring support compiled in?
Hmm, it "works for me". Well, actually I tried today's Windows
snapshot, but I'm pretty sure I haven't changed anything relevant
to syntax highlighing.
Allin.
6209
days inactive
6217
days old
26 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber