10:23 p.m.
Hi,
with 1.7.0 (and before that, too, I think) having an 'include' command
in a script without an open datafile caused an error message along the
lines "you have to open a datafile first".
(Which I assume is based on the fact that 'open' clears the internals of
gretl and thus any user-defined functions would be wiped out, so it
doesn't make too much sense to have 'include' first. On the other hand,
with gretl's scripting capabilities evolving (for example matrix stuff)
it's not clear that you always have a genuine need for a datafile when
you write or run a script. So this "cleaning behavior" of 'open' and the
above error message are becoming more and more awkward it seems --
unless I'm missing something, which is quite probable. But maybe 'open'
should be re-factored into 'clear [workspace]' and 'load [datafile]'
commands? But that is another story...)
Now with the latest snapshot I get a new dialog window popping up saying
"couldn't open file xx.inp". The informative error message is gone, and
it took me a while to figure out what was wrong.
thanks,
sven
11:17 p.m.
On Thu, 13 Dec 2007, Sven Schreiber wrote:
Hi,
with 1.7.0 (and before that, too, I think) having an 'include' command in a
script without an open datafile caused an error message along the lines "you
have to open a datafile first".
Are you sure? The list of commands that is available before a dataset is
open resides in the function ready_for_command(), which is near the end of
the file lib/src/interact.c; thanks to the marvelous piece of software
that cvs is, I was able to establish that the include command has been
legal in that context since May 2005.
By the way, the above list contained a spurious space for the "man"
command. Just fixed in CVS.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
9:49 a.m.
Riccardo (Jack) Lucchetti schrieb:
On Thu, 13 Dec 2007, Sven Schreiber wrote:
> Hi,
>
> with 1.7.0 (and before that, too, I think) having an 'include'
> command in a script without an open datafile caused an error message
> along the lines "you have to open a datafile first".
Are you sure? The list of commands that is available before a dataset
is open resides in the function ready_for_command(), which is near the
end of the file lib/src/interact.c; thanks to the marvelous piece of
software that cvs is, I was able to establish that the include command
has been legal in that context since May 2005.
Yes pretty sure because I switched back from snapshot to 1.7.0 just for
testing it. I said "along the lines" because I was translating back from
German and didn't check the exact wording.
-sven
9:52 a.m.
On Fri, 14 Dec 2007, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
> On Thu, 13 Dec 2007, Sven Schreiber wrote:
>
>> Hi,
>>
>> with 1.7.0 (and before that, too, I think) having an 'include' command in
>> a script without an open datafile caused an error message along the lines
>> "you have to open a datafile first".
>
> Are you sure? The list of commands that is available before a dataset is
> open resides in the function ready_for_command(), which is near the end of
> the file lib/src/interact.c; thanks to the marvelous piece of software that
> cvs is, I was able to establish that the include command has been legal in
> that context since May 2005.
>
>
Yes pretty sure because I switched back from snapshot to 1.7.0 just for
testing it. I said "along the lines" because I was translating back from
German and didn't check the exact wording.
Weird. Could you post an example?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
10:26 a.m.
Riccardo (Jack) Lucchetti schrieb:
Weird. Could you post an example?
Ok the problem is indeed a little different than I first thought,
apparently I was comparing apples and oranges in some sense. On closer
inspection there is no difference between 1.7.0 and the snapshot. Here
are two examples:
1)
gretl-Version 1.7.0
Aktuelle Sitzung: 2007/12/14 11:09
? set messages on
? set echo on
? include IV_ac_wooldridge.inp
<path protected>\IV_ac_wooldridge.inp geöffnet OK
Sie müssen zuerst eine Datendatei öffnen < = you have to open a
datafile first>
Fehler bei Skriptausführung: Stopp
if 2>3 # set to some true expression to activate
Fehler bei Skriptausführung: Stopp
include IV_ac_wooldridge.inp
So it now seems it's not the 'include' but the 'if' which causes
problems, right? That's not a big problem for me, but why is it
necessary to have a datafile open here?
2) Second example; changed the filename to ./IV_ac_wooldridge.inp, and I
get a dialog window saying that it can't be opened. The output says:
gretl-Version 1.7.0
Aktuelle Sitzung: 2007/12/14 11:11
? set messages on
? set echo on
? include ./IV_ac_wooldridge.inp
./IV_ac_wooldridge.inp geöffnet OK
Fehler bei Skriptausführung: Stopp
include ./IV_ac_wooldridge.inp
So here at least the feedback "opened OK" seems weird. Apart from that,
both scripts are in the same directory (which is also set as the user
dir in the prefs), shouldn't ./ work?
thanks,
sven
10:36 a.m.
On Fri, 14 Dec 2007, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
>
> Weird. Could you post an example?
>
Ok the problem is indeed a little different than I first thought, apparently
I was comparing apples and oranges in some sense. On closer inspection there
is no difference between 1.7.0 and the snapshot. Here are two examples:
[...snip...]
I have the feeling that nothing is wrong with "include" per se. If my
suspicion is right, your included file starts with an "if" statement,
which is indeed illegal if no dataset is open (and rightly so). So the
error message you're seeing does not refer to the "include" statement, but
rather to the "if" statement.
If you use the if statement to de-activate a portion of the script
unconditionally (as in "if 2>3"), it seems to me that commenting out the
code is a much better solution.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
12:07 p.m.
Riccardo (Jack) Lucchetti schrieb:
I have the feeling that nothing is wrong with "include" per se.
Yes, except that 'include ./thisfile.inp' doesn't work.
If my suspicion is right, your included file starts with an
"if"
statement, which is indeed illegal if no dataset is open (and rightly
so).
But why "rightly so"? It's not at all obvious to me.
If you use the if statement to de-activate a portion of the script
unconditionally (as in "if 2>3"), it seems to me that commenting out
the code is a much better solution.
Yeah except that AFAIK in gretl's editor it's not possible to do it with
a large chunk in one step. Or is there a hidden (or not so hidden) way?
thanks,
sven
3:34 p.m.
On Fri, 14 Dec 2007, Sven Schreiber wrote:
Riccardo (Jack) Lucchetti schrieb:
>
> I have the feeling that nothing is wrong with "include" per se.
Yes, except that 'include ./thisfile.inp' doesn't work.
Up till now, the "./" notation for filenames has always just used
the actual current working directory, which is not necessarily the
same as "shelldir": the latter was used strictly for shell
commands, and gretl's "open", "include" and so on are not shell
commands. However, this does seem unintuitive so I'm modifying
gretl's path searching: if shelldir is set, it will be checked
first when gretl is asked to open a filename that starts with "./"
or "../".
> If my suspicion is right, your included file starts with an
> "if" statement, which is indeed illegal if no dataset is open
> (and rightly so).
But why "rightly so"? It's not at all obvious to me.
"include" is meant for function files; what you're doing here is
really a "run". But on the substantive point: "if" calls for
evaluation of a condition, which invokes the "genr" apparatus.
That apparatus assumes we have a data set in place, and will fail
in nasty ways if we don't.
One way around this would be to do the equivalent of "open
nulldata 1" automatically on program startup. This is worth
thinking about, but probably not for the 1.7.1 release. I take
your point that we now have quite a lot of things you can
usefully do in gretl without having a dataset open. Doing "open
nulldata" explicitly is not very high-cost, but perhaps it's a bit
clunky.
> If you use the if statement to de-activate a portion of the
> script unconditionally (as in "if 2>3"), it seems to me that
> commenting out the code is a much better solution.
Yeah except that AFAIK in gretl's editor it's not possible to do
it with a large chunk in one step. Or is there a hidden (or not
so hidden) way?
C-style comments "/*" and "*/" make that pretty easy, but it might
be nice to have GUI commands "comment region" and "uncomment
region" in the script editor window.
Allin.
6:22 p.m.
Am 14.12.2007 16:34, Allin Cottrell schrieb:
Up till now, the "./" notation for filenames has always just used
the actual current working directory, which is not necessarily the
same as "shelldir": the latter was used strictly for shell
commands, and gretl's "open", "include" and so on are not shell
commands. However, this does seem unintuitive so I'm modifying
gretl's path searching: if shelldir is set, it will be checked
first when gretl is asked to open a filename that starts with "./"
or "../".
Ah yes I vaguely remember all those directory issues when I was hacking
around with py4gretl. I still find it confusing though; some day when I
find the time I'll try to write down some documentation and possibly
make suggestions for improvement...
"include" is meant for function files; what you're doing here is
really a "run".
'Run' and 'include' also keep confusing me. Is it correct that currently
the differences between 'include' and 'run' are:
* include can also read in a matrix xml file
* run works inside functions, too
I may be missing something, but essentially I still don't understand why
it's necessary --apart from historical reasons-- to have two separate
commands that exist for executing script files. Couldn't they be merged?
One way around this would be to do the equivalent of "open
nulldata 1" automatically on program startup. This is worth
thinking about, but probably not for the 1.7.1 release. I take
your point that we now have quite a lot of things you can
usefully do in gretl without having a dataset open. Doing "open
nulldata" explicitly is not very high-cost, but perhaps it's a bit
clunky.
Thanks for considering it, this is now feature request 1850969.
C-style comments "/*" and "*/" make that pretty easy, but it might
be nice to have GUI commands "comment region" and "uncomment
region" in the script editor window.
No sorry, that was a stupid question/comment of mine, especially since I
have already used "/*" and "*/" in gretl. No need to work on the
editor
in this area IMHO.
thanks,
sven
7:11 p.m.
On Fri, 14 Dec 2007, Sven Schreiber wrote:
> "include" is meant for function files; what you're
doing here is really a
> "run".
'Run' and 'include' also keep confusing me. Is it correct that
currently the differences between 'include' and 'run' are:
* include can also read in a matrix xml file
* run works inside functions, too
Yes, I think that's right.
I may be missing something, but essentially I still don't
understand why it's necessary --apart from historical reasons--
to have two separate commands that exist for executing script
files. Couldn't they be merged?
They are pretty much merged at the code level, but I think it's
worth keeping the two command words for clarity in scripts. "run"
is supposed to indicate that the file in question contains
arbitrary gretl commands, to be executed right away; the basic
purpose of "include" is to include function definitions (with no
commands being executed right away).
We could, I suppose, make an effort to police the content of files
opened with "include", but I'm not sure that's worth it.
Allin.
10:41 p.m.
Am 14.12.2007 19:22, Sven Schreiber schrieb:
Am 14.12.2007 16:34, Allin Cottrell schrieb:
>
> Up till now, the "./" notation for filenames has always just used the
> actual current working directory, which is not necessarily the same
> as "shelldir": the latter was used strictly for shell commands, and
> gretl's "open", "include" and so on are not shell commands.
However,
> this does seem unintuitive so I'm modifying gretl's path searching:
> if shelldir is set, it will be checked first when gretl is asked to
> open a filename that starts with "./" or "../".
>
>
Ah yes I vaguely remember all those directory issues when I was
hacking around with py4gretl. I still find it confusing though; some
day when I find the time I'll try to write down some documentation and
possibly make suggestions for improvement...
Below is an attempt to summarize the situation (corrections are most
welcome), but first let me ask: have I understood correctly that it is
not possible to reference from a script another file which is in the
same directory? (of course unless that directory is also the userdir or
similar, and unless the directory's name is hardcoded into the script)
That would be a bit unfortunate IMHO (but I hope there is a clever way
to achieve this that you will tell me...:-)
The four rules of path references in scripts:
1) plain name or relative path -> location is relative to either the
userdir or the cwd depending on the preference settings for
opening/saving files
2) absolute path -> is honored, may include runtime stuff like @userdir
or strings from getenv("HOME")
3) ./ -> depends on the shelldir setting
4) execution location of shell commands ('!') also depend on shelldir
setting
What commands are affected: include/run -- store -- outfile --
open/append -- ! (shell) -- eqnprint/tabprint -f
And last but not least: the cwd seems to be very fragile, especially on
windows
Is all this correct?
thanks,
sven
10:27 p.m.
On Sat, 15 Dec 2007, Sven Schreiber wrote:
Below is an attempt to summarize the situation...
The four rules of path references in scripts:
1) plain name or relative path -> location is relative to either
the userdir or the cwd depending on the preference settings for
opening/saving files
Sort of.
* For the file read commands (append/open, run/include) we search
as described in the manual, with the addition that if the filename
is of the form "./foo" (or similar; I'll call these dotnames) we
start by checking the shelldir.
* For the file write commands (eqnprint -f, tabprint -f, outfile,
store) we use the userdir unless we're given a dotname, in which
case we use the shelldir.
2) absolute path -> is honored, may include runtime stuff like
@userdir or strings from getenv("HOME")
Yes.
3) ./ -> depends on the shelldir setting
Yes. And the shelldir is initialized to the CWD on program
start-up (though of course its settable thereafter). One other
thing: on read, if "./" doesn't find the file in shelldir, we also
try the actual CWD (which may not equal shelldir, for example if a
shell command involves a "cd").
4) execution location of shell commands ('!') also depend on
shelldir setting
Yes.
And last but not least: the cwd seems to be very fragile,
especially on windows
Could you give an example of what you mean by fragility?
Further question from Sven:
have I understood correctly that it is not possible to reference
from a script another file which is in the same directory? (of
course unless that directory is also the userdir or similar, and
unless the directory's name is hardcoded into the script)
Do you mean, that if a script references another file given as a
plain (non-dot) relative path, gretl will look for the latter in
the same place the script was found? If so, this is the case for
open/append and run/include. For example, if I do
gretlcli -b /some/odd/place/foo.inp
and foo.inp says "open baz.gdt", then we try looking for baz.gdt
in /some/odd/place. There's an internal variable "currdir" which
is set/reset each time a script is opened, and this directory is
prepended to the search path.
Allin.
10:38 p.m.
On Fri, 21 Dec 2007, Allin Cottrell wrote:
* For the file write commands (eqnprint -f, tabprint -f, outfile,
store) we use the userdir unless we're given a dotname, in which
case we use the shelldir.
Sorry, that's incomplete. For these commands: if given a dotfile,
use shelldir; else if USE_CWD is set (e.g. via the gui
proferences), use shelldir; otherwise use userdir.
The function that does this is gretl_maybe_switch_dir() in
gretl_paths.c
Allin.
11:46 p.m.
Am 21.12.2007 23:27, Allin Cottrell schrieb:
On Sat, 15 Dec 2007, Sven Schreiber wrote:
> And last but not least: the cwd seems to be very fragile,
> especially on windows
>
Could you give an example of what you mean by fragility?
Well, you said it yourself some time ago when you were hunting a bug
that I had reported with respect to saved file locations. Apparently
many actions on windows implicitly change the CWD, making it's use in
scripts quite unpredictable.
Further question from Sven:
> have I understood correctly that it is not possible to reference
> from a script another file which is in the same directory? (of
> course unless that directory is also the userdir or similar, and
> unless the directory's name is hardcoded into the script)
>
Do you mean, that if a script references another file given as a
plain (non-dot) relative path, gretl will look for the latter in
the same place the script was found? If so, this is the case for
open/append and run/include. For example, if I do
gretlcli -b /some/odd/place/foo.inp
and foo.inp says "open baz.gdt", then we try looking for baz.gdt
in /some/odd/place. There's an internal variable "currdir" which
is set/reset each time a script is opened, and this directory is
prepended to the search path.
Hm, ok, though my question arises from experiences where I thought that
wouldn't work. I'll report it as a bug eventually when I come across
something reproducible and clearcut.
In general I must say I'm not really happy with gretl's concept of the
user dir. Personally I prefer to arrange my files in terms of projects
I'm working on, not in terms of applications that created those files. I
mean that information is already given by the file extension or other
metadata. So I guess I would like it if gretl had a third preference
option where to open or save files, and that would be in the dir of the
current datafile, or alternatively simply in the last dir which was
used, similar to the "currdir" thing you just mentioned (but which
should be updated not only by handling scripts). Actually until a while
ago I used to think that that was meant by "current working dir" because
to me it sounded very much like it.
(Another loosely related issue about the user dir: when installing
gretl, you are asked for its location. But on windows gretl must be
installed as admin, and presumably that will not be the user account
that executes gretl afterwards. So it doesn't make much sense to ask for
it at install time.)
Thanks for the explanations,
Sven
3:23 a.m.
On Sat, 22 Dec 2007, Sven Schreiber wrote:
Am 21.12.2007 23:27, Allin Cottrell schrieb:
>
> Could you give an example of what you mean by fragility?
Well, you said it yourself some time ago when you were hunting a
bug that I had reported with respect to saved file locations.
Apparently many actions on windows implicitly change the CWD,
making it's use in scripts quite unpredictable.
Yes, some time ago. This shouldn't be the case any longer.
Gretl changes the actual CWD for various operations, on Linux as
much as on Windows, but we always change back to the saved
CWD/shelldir for the file read/write operations that I mentioned.
In general I must say I'm not really happy with gretl's
concept
of the user dir. Personally I prefer to arrange my files in
terms of projects I'm working on, not in terms of applications
that created those files.
I can see your point. The thing is, though, that gretl has reason
to write a fair number of files that the user never sees (graph
files, in-progress session files, auxiliary files in connection
with TRAMO/SEATS and X-12-ARIMA, etc.) We want a reliable, and
preferably constant, location to write those things. However, it
may be worth extending the "currdir" notion as setting the default
for read/write of data files and script files.
(Another loosely related issue about the user dir: when
installing gretl, you are asked for its location. But on windows
gretl must be installed as admin, and presumably that will not
be the user account that executes gretl afterwards.
It's my impression that the great majority of Windows PCs are
single-user machines, on which the "admin" is also the primary
user. I know there are exceptions, and we should probably handle
those exceptions more gracefully. But I can't agree with the
general point.
Allin.
4:45 a.m.
On Fri, 21 Dec 2007, I wrote:
It's my impression that the great majority of Windows PCs are
single-user machines, on which the "admin" is also the primary
user. I know there are exceptions, and we should probably handle
those exceptions more gracefully.
OK, I've started learning about peon vs admin installs, elevation,
UAC prompts, and all that. What fun. This'll take a while to get
right, but perhaps for 1.7.2.
Allin.
3:20 p.m.
Am 22.12.2007 05:45, Allin Cottrell schrieb:
On Fri, 21 Dec 2007, I wrote:
> It's my impression that the great majority of Windows PCs are
> single-user machines, on which the "admin" is also the primary
> user. I know there are exceptions, and we should probably handle
> those exceptions more gracefully.
OK, I've started learning about peon vs admin installs, elevation,
UAC prompts, and all that. What fun. This'll take a while to get
right, but perhaps for 1.7.2.
Allin.
I'd rather say for 2.0, if at all. Sorry for the apparent
misunderstanding, I wasn't asking for non-admin installs, I think it's
not worth the (=your) trouble.
But the recommend way to use even single-user windows machines nowadays
is as for *nix: Use a non-admin account for normal work. IMHO gretl
should support that approach, as it naturally does on Linux. I suggest
to not have a global user dir setting chosen on install, but initialize
it to a reasonable default, say the standard Windows HOME directory
which gretl already can read by getenv("HOME"). Then of course it can be
reset by the user in her/his preferences.
thanks,
sven
10:36 a.m.
On Fri, 21 Dec 2007, Allin Cottrell wrote:
> In general I must say I'm not really happy with gretl's
concept
> of the user dir. Personally I prefer to arrange my files in
> terms of projects I'm working on, not in terms of applications
> that created those files.
I can see your point. The thing is, though, that gretl has reason
to write a fair number of files that the user never sees (graph
files, in-progress session files, auxiliary files in connection
with TRAMO/SEATS and X-12-ARIMA, etc.) We want a reliable, and
preferably constant, location to write those things. However, it
may be worth extending the "currdir" notion as setting the default
for read/write of data files and script files.
IMO both Allin and Sven make valid points. I agree with Sven that the
concept of the userdir is not useful if you prefer, as I do, to organise
your files into nicely separate subtrees. But I've never had a problem
with "./" in my scripts (I don't know what happens with Windows, though).
As for writing temporary stuff: if the user is not meant to see it ever,
then under linux (ad I suspect under other Unices too), they belong in
/tmp/, possibly under a subdir created for the occasion, say
/tmp/gretl-x6b228/. I _think_ there's something similar in windows-land,
something like "C:\Win32\Temp", but I don't know how consistent that is
across the multitude of Windows versions.
How about adding a setting for the default read/write of data & scripts?
Something like
set workdir "/my/very/custom/path/"
which would default to @userdir if unset, or to the directory gretl was
started from if a special keyword was used (like "here", or ".").
Would
this make things any better?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
3 p.m.
On Sat, 22 Dec 2007, Riccardo (Jack) Lucchetti wrote:
IMO both Allin and Sven make valid points. I agree with Sven
that the concept of the userdir is not useful if you prefer, as
I do, to organise your files into nicely separate subtrees. But
I've never had a problem with "./" in my scripts (I don't know
what happens with Windows, though).
I think that CWD and "./" work just fine if you're launching gretl
from, e.g., the bash prompt in an xterm (as I do). You know what
the initial CWD is, and can pre-set it easily by cd'ing to your
project directory. On the other hand, I accept that it's of
questionable usefulness on Windows, where most users won't know
what the CWD is when they launch gretl (and won't even have any
means of finding out, short of typing "set" in the gretl console).
As for writing temporary stuff: if the user is not meant to see
it ever, then under linux (ad I suspect under other Unices too),
they belong in /tmp/, possibly under a subdir created for the
occasion, say /tmp/gretl-x6b228/. I _think_ there's something
similar in windows-land, something like "C:\Win32\Temp"...
I'd really rather not get into that if possible. But here's an
idea (based on what you've suggested):
1. Let's think of what we presently call "userdir" as gretl's
"private" data directory. On Windows, we needn't offer a choice
of this directory on installation; we can just automatically use
USERAPPDATADIR/gretl (the current default). On other platforms we
can continue to default to ~/gretl (perhaps ~/.gretl would be more
appropriate but that has compatibility issues).
2. We add the concept of a user's "working directory" based on the
present value of "currdir". We can save this between sessions
(which we currently don't). We won't write any "internal" files
to this directory, but we'll make it the default for explicit
file open/save, for shell commands, and so on.
3. That leaves the question of what the "working directory" should
default to on first-time installation, i.e. before "currdir" has
been set. Here are some options:
On Windows: the Desktop, MYDOCUMENTS, MYDOCUMENTS/gretl, ??
On Linux: the CWD, HOME, HOME/gretl, ??
We could prompt for this on a first-time Windows install, but I
think that's likely to be confusing since the user probably won't
really know what's being asked at that point.
4. One more loose end: should the working dir be explicitly
settable, or should it always just be set implicitly by data or
script file open operations? Maybe we should offer something like
[] Always start in directory: _____________
That is, a check box plus a directory slot that is enabled if the
box is checked. (Rationale: a user might sometimes want to open a
data file or script from some neutral location such as the
Desktop, without thereby switching the working directory to that
location.)
Allin.
4:10 p.m.
Am 22.12.2007 16:00, Allin Cottrell schrieb:
On Sat, 22 Dec 2007, Riccardo (Jack) Lucchetti wrote:
> IMO both Allin and Sven make valid points. I agree with Sven
> that the concept of the userdir is not useful if you prefer, as
> I do, to organise your files into nicely separate subtrees. But
> I've never had a problem with "./" in my scripts (I don't know
> what happens with Windows, though).
I think that CWD and "./" work just fine if you're launching gretl
from, e.g., the bash prompt in an xterm (as I do). You know what
the initial CWD is, and can pre-set it easily by cd'ing to your
project directory. On the other hand, I accept that it's of
questionable usefulness on Windows, where most users won't know
what the CWD is when they launch gretl (and won't even have any
means of finding out, short of typing "set" in the gretl console).
Exactly. For example, for my current setup it seems to be
"e:\iwonttellyouthepath" but I don't have any idea where that comes from
or how to change the corresponding windows setting. (It's _not_ in the
gretl preferences, and it's _not_ the current setting for "My
Documents"; however, it could be that some months ago it _used to_ to
the setting for "My Documents" -- so maybe some stale registry or ini
setting?)
I'd really rather not get into that if possible. But here's
an
idea (based on what you've suggested):
1. Let's think of what we presently call "userdir" as gretl's
"private" data directory. On Windows, we needn't offer a choice
of this directory on installation; we can just automatically use
USERAPPDATADIR/gretl (the current default). On other platforms we
can continue to default to ~/gretl (perhaps ~/.gretl would be more
appropriate but that has compatibility issues).
Yes, I guess that's more or less what I had in mind with %AppData% in
the email I just sent before I noticed yours.
2. We add the concept of a user's "working directory" based on the
present value of "currdir". We can save this between sessions
(which we currently don't). We won't write any "internal" files
to this directory, but we'll make it the default for explicit
file open/save, for shell commands, and so on.
Sounds great!
3. That leaves the question of what the "working directory" should
default to on first-time installation, i.e. before "currdir" has
been set. Here are some options:
On Windows: the Desktop, MYDOCUMENTS, MYDOCUMENTS/gretl, ??
I don't care much because I would change it right away anyway, but <the
localized/generalized version of> MYDOCUMENTS immediately comes to (my)
mind.
On Linux: the CWD, HOME, HOME/gretl, ??
HOME for the same reason.
We could prompt for this on a first-time Windows install, but I
think that's likely to be confusing since the user probably won't
really know what's being asked at that point.
And as I said, a global setting for all users doesn't make much sense
IMHO. And it's not necessary, since the first open/save operation will
take care of it.
4. One more loose end: should the working dir be explicitly
settable, or should it always just be set implicitly by data or
script file open operations? Maybe we should offer something like
[] Always start in directory: _____________
That is, a check box plus a directory slot that is enabled if the
box is checked. (Rationale: a user might sometimes want to open a
data file or script from some neutral location such as the
Desktop, without thereby switching the working directory to that
location.)
For backwards-compatibility I guess the current concept of userdir
should be preserved if possible. (So maybe even should retain that name,
and what you suggested as the new use of userdir should be called
something else.) So yes, it should be settable IMHO.
Thanks again very much for the open-mindedness to new ideas and criticisms!
cheers,
sven
7:52 p.m.
On Sat, 22 Dec 2007, Sven Schreiber wrote:
> On the other hand, I accept that it's of questionable
> usefulness on Windows, where most users won't know what the
> CWD is when they launch gretl (and won't even have any means
> of finding out, short of typing "set" in the gretl console).
Exactly. For example, for my current setup it seems to be
"e:\iwonttellyouthepath" but I don't have any idea where that
comes from or how to change the corresponding windows setting.
(It's _not_ in the gretl preferences, and it's _not_ the current
setting for "My Documents"
You wouldn't really expect it to be related to either of those
things. You can control it, if you wish, by opening the
properties of the gretl program icon and specifying a start-up
directory.
> 3. That leaves the question of what the "working
directory"
> should default to on first-time installation, i.e. before
> "currdir" has been set. Here are some options:
>
> On Windows: the Desktop, MYDOCUMENTS, MYDOCUMENTS/gretl, ??
I don't care much because I would change it right away anyway,
but <the localized/generalized version of> MYDOCUMENTS
immediately comes to (my) mind.
By "MYDOCUMENTS" I really meant whatever is returned using
CSIDL_MYDOCUMENTS with SHGetFolderPath (win32 API), and similarly
for all uppercase paths.
Allin.
12:39 p.m.
With respect to the thread that has been opened this weekend, about the
directories for open/save data and scripts. I only want to teel you something
about my experience.
I have been living quietly for years saving and opening data to /myhome/gretl
(my userdir) without any problem. I must say that the projects I worked on
were not very "big". On this year I started to work on two "bigger"
new
projects so I felt the need to organise them in subdirectories. I used for
example /myhome/gretl/mybigproject as subdirectory for one of the projects
and I also lived peacefully until the project grow so much that I needed to
include the scripts in a subdirectory and the data in another subdirectory.
I could see that /myhome/gretl/mybigproject/data was not a good place for
this data files, as gretl sometimes (maybe always?) could not find them.
I also had problems with /myhome/gretl/mybigproject/scripts and
/myhome/gretl/mybigproject/db (for the databases). So I studied very
carefully the manual and found a not-very-clear explanation of what was
happening (in section 4.8 Data file collections):
Besides the pre-installed data and scripts that comes with gretl (and specific
known collections as Davidson-MacKinnon, Gujarati, etc) gretl follows a
particular path to look for new collections of data and scripts:
-The program searches in the "system" data directory, the system script
directory, the user directory, and all first-level (and only first-level I
remark) subdirectories of these.
I didn't found this path the most appropiate for me, because I wanted to
mantain each of the new projects as subdirectories of /myhome/gretl, but I
understood why /myhome/gretl/mybigproject/data was not working and I solved
my problem changing this subdirectory to /myhome/gretl/mybigproject-data
and the scripts directory to /myhome/gretl/mybigproject-scripts. Both are
first-level directories from my userdir (/myhome/gretl) so I have no problem
now.
I understand that the new concept of a user's "working directory" that Allin
is proposing, in my case may allow to define as "working
directory" /myhome/gretl/mybigproject/ and so the directory structure I
firstly organised may work.
I think also that I don't find very useful that gretl searches for new data or
script collections in the "system" data dir. or the "system" script
dir.
since normally only the superuser (root) has writting acces to such places.
--
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.et.bs.ehu.es
4:19 p.m.
Am 22.12.2007 11:36, Riccardo (Jack) Lucchetti schrieb:
IMO both Allin and Sven make valid points. I agree with Sven that the
concept of the userdir is not useful if you prefer, as I do, to organise
your files into nicely separate subtrees. But I've never had a problem
with "./" in my scripts (I don't know what happens with Windows, though).
As for writing temporary stuff: if the user is not meant to see it ever,
then under linux (ad I suspect under other Unices too), they belong in
/tmp/, possibly under a subdir created for the occasion, say
/tmp/gretl-x6b228/. I _think_ there's something similar in windows-land,
something like "C:\Win32\Temp", but I don't know how consistent that is
across the multitude of Windows versions.
It seems the standard API function on windows for that is GetTempPath;
apart from that it may be in an environment variable "TEMP" or "TMP",
but hey -- I'm no windows developer, this is just babbling googled stuff.
Apart from that, there is also %AppData%, which (taken from a mozilla
webpage:) "is a shorthand for the Application Data path on Windows
2000/XP/Vista. To use it, click Start > Run... (use the search box on
Vista), enter %AppData% and press Enter. You will be taken to the "real"
folder, which is normally C:\Documents and Settings\[User
Name]\Application Data on Windows XP/2000, C:\users\[User
Name]\AppData\Roaming on Windows Vista."
Both approaches should also work on localized Windows versions I think.
I'm not sure if TEMP is guaranteed to exist or be user-writable, but
%AppData% is always part of the user-specific profile.
How about adding a setting for the default read/write of data & scripts?
Something like
set workdir "/my/very/custom/path/"
which would default to @userdir if unset, or to the directory gretl was
started from if a special keyword was used (like "here", or ".").
Would
this make things any better?
I'm not sure I understand -- how would that be different from the
userdir itself?
-sven
5:57 p.m.
On Sat, 22 Dec 2007, Sven Schreiber wrote:
Apart from [TMP stuff], there is also %AppData%, which (taken
from a mozilla webpage:) "is a shorthand for the Application
Data path on Windows 2000/XP/Vista. To use it, click Start >
Run... (use the search box on Vista), enter %AppData% and press
Enter. You will be taken to the "real" folder, which is normally
C:\Documents and Settings\[User Name]\Application Data on
Windows XP/2000, C:\users\[User Name]\AppData\Roaming on Windows
Vista."
The current default for userdir is in fact %AppData%/gretl.
Allin.
3:23 p.m.
Am 22.12.2007 00:46, Sven Schreiber schrieb:
Am 21.12.2007 23:27, Allin Cottrell schrieb:
> Do you mean, that if a script references another file given as a
plain
> (non-dot) relative path, gretl will look for the latter in the same
> place the script was found? If so, this is the case for open/append
> and run/include. For example, if I do
>
> gretlcli -b /some/odd/place/foo.inp
>
> and foo.inp says "open baz.gdt", then we try looking for baz.gdt in
> /some/odd/place. There's an internal variable "currdir" which is
> set/reset each time a script is opened, and this directory is
> prepended to the search path.
>
Hm, ok, though my question arises from experiences where I thought that
wouldn't work. I'll report it as a bug eventually when I come across
something reproducible and clearcut.
Maybe it was a problem with 1.6.5, my co-author had such a problem
shortly before 1.7.0 was released. But with the current snapshot
everything seems fine in this respect.
-sven
3:23 p.m.
Am 22.12.2007 00:46, Sven Schreiber schrieb:
Am 21.12.2007 23:27, Allin Cottrell schrieb:
> On Sat, 15 Dec 2007, Sven Schreiber wrote:
> Further question from Sven:
>
>
>> have I understood correctly that it is not possible to reference from
>> a script another file which is in the same directory? (of course
>> unless that directory is also the userdir or similar, and unless the
>> directory's name is hardcoded into the script)
>
> Do you mean, that if a script references another file given as a plain
> (non-dot) relative path, gretl will look for the latter in the same
> place the script was found? If so, this is the case for open/append
> and run/include. For example, if I do
>
> gretlcli -b /some/odd/place/foo.inp
>
> and foo.inp says "open baz.gdt", then we try looking for baz.gdt in
> /some/odd/place. There's an internal variable "currdir" which is
> set/reset each time a script is opened, and this directory is
> prepended to the search path.
>
Hm, ok, though my question arises from experiences where I thought that
wouldn't work. I'll report it as a bug eventually when I come across
something reproducible and clearcut.
I think I was just facing such a behavior after installing 1.7.1 on win
xp (thanks for this nice Christmas present BTW!).
As always, I installed as admin, but run as normal user. Before doing
anything else at all with 1.7.1, I opened an existing script file in
S:\my\project\dir. This dir is not specified in the preferences. The
script opens a datafile with the command
open mydata
(relative path pointing to same dir, no file extension), but although it
worked five minutes ago with the previous snapshot that had been running
for some time already, it didn't with the freshly started 1.7.1.
However, after I manually opened the datafile and thereby implicitly
adjusted the current working dir (I presume), it works again (my
preferences are currently set to use the cwd, not the user dir, for
opening files).
So that's what I meant, if I understand correctly this would mean that
the "currdir" was not updated properly when that script was opened.
Thanks,
Sven
4 p.m.
On Fri, 28 Dec 2007, Sven Schreiber wrote:
Before doing anything else at all with 1.7.1, I opened an
existing script file in S:\my\project\dir.
You navigated there using the file open dialog?
This dir is not specified in the preferences. The script opens a
datafile with the command
open mydata
(relative path pointing to same dir, no file extension), but
although it worked five minutes ago with the previous snapshot
that had been running for some time already, it didn't with the
freshly started 1.7.1.
I'll have to try testing on Windows. I just did the equivalent of
what you describe on Linux and it worked OK.
Allin.
4:15 p.m.
Am 28.12.2007 17:00, Allin Cottrell schrieb:
On Fri, 28 Dec 2007, Sven Schreiber wrote:
> Before doing anything else at all with 1.7.1, I opened an
> existing script file in S:\my\project\dir.
You navigated there using the file open dialog?
Actually, I guess I used the submenu for recently opened scripts, maybe
that's the issue... yes, if I manually open the script everything works.
So I guess it's not a cross-platform issue, but perhaps it could be made
to work anyway?
thanks,
sven
4:26 p.m.
On Fri, 28 Dec 2007, Sven Schreiber wrote:
Am 28.12.2007 17:00, Allin Cottrell schrieb:
> On Fri, 28 Dec 2007, Sven Schreiber wrote:
>
> > Before doing anything else at all with 1.7.1, I opened an existing script
> > file in S:\my\project\dir.
>
> You navigated there using the file open dialog?
Actually, I guess I used the submenu for recently opened
scripts, maybe that's the issue... yes, if I manually open the
script everything works. So I guess it's not a cross-platform
issue, but perhaps it could be made to work anyway?
Yes, I can confirm that what you describe doesn't work on Linux
either -- but it ought to.
Allin.
11:07 p.m.
On Fri, 28 Dec 2007, Allin Cottrell wrote:
On Fri, 28 Dec 2007, Sven Schreiber wrote:
> Am 28.12.2007 17:00, Allin Cottrell schrieb:
> > On Fri, 28 Dec 2007, Sven Schreiber wrote:
> >
> > > Before doing anything else at all with 1.7.1, I opened an
> > > existing script file in S:\my\project\dir.
> >
> > You navigated there using the file open dialog?
>
> Actually, I guess I used the submenu for recently opened
> scripts, maybe that's the issue... yes, if I manually open the
> script everything works. So I guess it's not a cross-platform
> issue, but perhaps it could be made to work anyway?
Yes, I can confirm that what you describe doesn't work on Linux
either -- but it ought to.
Now fixed in CVS.
Allin.
6188
days inactive
6203
days old
29 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber