1:57 p.m.
Hi,
I'm noticing that with the Oct 4th snapshot in the (local) function
package list window a (preliminary) package appears that lives in a
non-standard path.
This is new I think, because it used to be that one could switch to a
user-specified path, and then only those packages from there was shown.
If one reverted to the standard listing, the non-standard paths would be
forgotten again.
Is this a bug or a feature?
thanks,
sven
9:37 p.m.
On Sat, 6 Oct 2018, Sven Schreiber wrote:
I'm noticing that with the Oct 4th snapshot in the (local)
function package list window a (preliminary) package appears that
lives in a non-standard path.
This is new I think, because it used to be that one could switch
to a user-specified path, and then only those packages from there
was shown. If one reverted to the standard listing, the
non-standard paths would be forgotten again.
Is this a bug or a feature?
Sorry it has taken a while, but anyway... I don't think this has
changed lately. When gretl is asked to show function packages "on
the local machine" we search in the following locations:
* the "system" functions directory, which will be under /usr on
Linux (possibly /usr/local if self-compiled), /Program files/gretl
on Windows;
* the "functions" subdirectory of the user's "dotdir" (which is
where packages will go on "install" if the user doesn't have write
permission on the "system" directory); and
* the user's current working directory.
Allin
11:02 p.m.
On Thu, 11 Oct 2018, Allin Cottrell wrote:
On Sat, 6 Oct 2018, Sven Schreiber wrote:
> I'm noticing that with the Oct 4th snapshot in the (local)
> function package list window a (preliminary) package appears that
> lives in a non-standard path.
>
> This is new I think, because it used to be that one could switch
> to a user-specified path, and then only those packages from there
> was shown. If one reverted to the standard listing, the
> non-standard paths would be forgotten again.
>
> Is this a bug or a feature?
Sorry it has taken a while, but anyway... I don't think this has
changed lately. When gretl is asked to show function packages "on
the local machine" we search in the following locations:
* the "system" functions directory, which will be under /usr on
Linux (possibly /usr/local if self-compiled), /Program files/gretl
on Windows;
* the "functions" subdirectory of the user's "dotdir" (which is
where packages will go on "install" if the user doesn't have write
permission on the "system" directory); and
* the user's current working directory.
Another thought, in response to Sven's "bug or feature" question.
The inclusion of the user's working directory in the package search
path is a feature in the sense of being deliberately designed in,
but maybe it's a mis-feature (aka bug). Since you probably spend
more time working with function-package files than anyone else,
Sven, I'd value your opinion on whether including the working
directory by default is a help or a hazard. It would be easy enough
to exclude it.
Allin
6:33 a.m.
Am 12.10.2018 um 01:02 schrieb Allin Cottrell:
On Thu, 11 Oct 2018, Allin Cottrell wrote:
> On Sat, 6 Oct 2018, Sven Schreiber wrote:
>
>> I'm noticing that with the Oct 4th snapshot in the (local) function
>> package list window a (preliminary) package appears that lives in a
>> non-standard path.
>>
>> This is new I think, because it used to be that one could switch to
>> a user-specified path, and then only those packages from there was
>> shown. If one reverted to the standard listing, the non-standard
>> paths would be forgotten again.
>>
>> Is this a bug or a feature?
> * the user's current working directory.
Ah right, this must be it, my CWD is very likely currently set to that
location.
Another thought, in response to Sven's "bug or feature" question.
The inclusion of the user's working directory in the package search
path is a feature in the sense of being deliberately designed in, but
maybe it's a mis-feature (aka bug). Since you probably spend more time
working with function-package files than anyone else, Sven, I'd value
your opinion on whether including the working directory by default is
a help or a hazard. It would be easy enough to exclude it.
Good question. For me as a package developer it was actually useful,
because when I debug and recreate the package it is then (in the CWD)
automatically updated within gretl.
Also this makes it easier to distribute non-public or non-official
packages to colleagues, and also for backing them up along with other
files. They just have to put it in the same place as their project.
I was just not actively aware of it, but I don't think it's a hazard
because shoving a package file actively in those non-standard places
will be for some reason, not by accident. Also it's good that gretl
shows the path where it found the package in its info window. It might
be also useful to show that path in the package registry, but the space
there is also limited.
So probably just leave as is.
What's more of an issue for me is the perennial path-searching problem
when including .inp files. My observation (or just feeling?) is that
when I want to include <pathprefix>/helper.inp from
<pathprefix>/main.inp I either have to set the CWD to <pathprefix> or I
have to give absolute, not relative paths. The first is a nuisance
because I often switch projects and/or paths, the second is also not
very elegant I think.
I think I had questions like this already years ago which led to the
CWD being more easily settable. The recent display of the CWD in the
main window also helps because it is clickable and brings up the setting
dialog. But some unix-y suggestions like 'include ./helper.inp" or
similar don't work on Windows (do they actually work on Linux, cannot
test right now?). It would seem very natural that you could just
"include" a file sitting next to you.
thanks,
sven
3:05 p.m.
On Fri, 12 Oct 2018, Sven Schreiber wrote:
Am 12.10.2018 um 01:02 schrieb Allin Cottrell:
> On Thu, 11 Oct 2018, Allin Cottrell wrote:
>
>> On Sat, 6 Oct 2018, Sven Schreiber wrote:
>>
>>> I'm noticing that with the Oct 4th snapshot in the (local) function
>>> package list window a (preliminary) package appears that lives in a
>>> non-standard path.
>>>
>>> This is new I think, because it used to be that one could switch to a
>>> user-specified path, and then only those packages from there was shown.
>>> If one reverted to the standard listing, the non-standard paths would be
>>> forgotten again.
>>>
>>> Is this a bug or a feature?
>> * the user's current working directory.
Ah right, this must be it, my CWD is very likely currently set to that
location.
>
> Another thought, in response to Sven's "bug or feature" question.
>
> The inclusion of the user's working directory in the package
> search path is a feature in the sense of being deliberately
> designed in, but maybe it's a mis-feature (aka bug). Since you
> probably spend more time working with function-package files than
> anyone else, Sven, I'd value your opinion on whether including
> the working directory by default is a help or a hazard. It would
> be easy enough to exclude it.
Good question. For me as a package developer it was actually
useful, because when I debug and recreate the package it is then
(in the CWD) automatically updated within gretl. [...]
OK, then we'll retain that feature.
What's more of an issue for me is the perennial path-searching
problem when including .inp files. My observation (or just
feeling?) is that when I want to include <pathprefix>/helper.inp
from <pathprefix>/main.inp I either have to set the CWD to
<pathprefix> or I have to give absolute, not relative paths. The
first is a nuisance because I often switch projects and/or paths,
the second is also not very elegant I think.
I think I need a full test case to expose the problem you're talking
about, because I'm not seeing it myself (but maybe I'm doing
something different). The design idea is that if you run a script
that sits in some specified directory D (doesn't have to be your
working directory), then any uses of "open" or "include" (for inp
files) within that script will by default look for the requested
file in D. (Other possibilities will be considered if that doesn't
work.)
To be explicit, here's a test case I just ran:
* There's a directory ~/stats/myhre on my system; it contains among
other things the scripts myhre_test.inp and findme.inp, and the
datafile myhre.asc. This directory is not my working directory,
neither is it the current working directory so far as the shell is
concerned. myhre_test.inp includes the lines
open myhre.asc
include findme.inp
(no paths given, just plain basenames).
* via gretlcli: from my home directory I execute
gretlcli -b ~/stats/myhre/myhre_test.inp
and everything is found.
* via gretl (1): from my home directory I execute
gretl ~/stats/myhre/myhre_test.inp
and then run the script from the script editor: again, everything is
found.
* via gretl (2): I start gretl from a desktop menu, use the file
dialog under /Files/Script files to open myhre_test.inp, then run
the script via the Run button. Once again: everything found.
Allin
3:20 p.m.
On Fri, 12 Oct 2018, Allin Cottrell wrote:
To be explicit, here's a test case I just ran:
* There's a directory ~/stats/myhre on my system; it contains
among other things the scripts myhre_test.inp and findme.inp, and
the datafile myhre.asc. This directory is not my working
directory, neither is it the current working directory so far as
the shell is concerned. myhre_test.inp includes the lines
open myhre.asc
include findme.inp
(no paths given, just plain basenames).
I just tried a variant test -- I wasn't certain it would work, but
it does. Exactly as described in my previous post, except that I
moved findme.inp into a subdirectory of ~/stats/myhre named "subdir"
and amended the include line to read
include subdir/findme.inp
It was found OK.
Allin
3:45 p.m.
On Fri, 12 Oct 2018, Allin Cottrell wrote:
I just tried a variant test -- I wasn't certain it would work,
but
it does. Exactly as described in my previous post, except that I
moved findme.inp into a subdirectory of ~/stats/myhre named
"subdir" and amended the include line to read
include subdir/findme.inp
It was found OK.
Ah but... maybe I've now found the case you're talking about. If I
execute the top-level script via
run ~/stats/myhre/myhre_test.inp
in the gretl console window, then ~/stats/myhre is not searched and
the other input files are not found. The same applies if I run a
one-line "meta-script" with the above "run" content from the script
window.
I don't think of either of these methods as "idiomatic" use of
gretl: to me, the "natural" way to run a script in the GUI is via
the Run button or Ctrl-R in the window containing the script in
question. Nonetheless, the fact that the script's directory is not
automatically searched in these cases should perhaps be considered a
bug.
(I'm not sure it's a bug when "run" is executed from within a
script, as in my second case above. Then it would displace the
primary script's location as the automatic search path, which is
probably not what's wanted.)
Allin
4:29 p.m.
Am 12.10.2018 um 17:20 schrieb Allin Cottrell:
On Fri, 12 Oct 2018, Allin Cottrell wrote:
> To be explicit, here's a test case I just ran:
>
> * There's a directory ~/stats/myhre on my system; it contains among
> other things the scripts myhre_test.inp and findme.inp, and the
> datafile myhre.asc. This directory is not my working directory,
> neither is it the current working directory so far as the shell is
> concerned. myhre_test.inp includes the lines
Well, my test case is quite simple. This is with yesterday's snapshot on
Win 7.
Under C:\Benutzer\sven-schreiber\Dokumente I created a new directory
"gtest".
(Equivalently in the Windows cmd.exe shell it shows as the non-localized
variant C:\users\sven-schreiber\Documents\gtest. Perhaps the language
issue on Windows plays a role, I don't know.)
Because it's a new directory, gretl's CWD is something quite different.
In that dir I save a file gmain.inp which contains just "include
helper.inp". That file helper.inp is also in there next to gmain.inp,
and it contains the line 'print "helper!"'.
When I click the run (cogwheel) button in the script editor for the
gmain.inp file I get the error "Error reading helper.inp" (in German
translation).
Then I set the CWD to the gtest directory, and I get as an echo the path
of helper.inp, and the printout: helper!
In other words, then it works.
thanks,
sven
4:56 p.m.
Am 12.10.2018 um 18:29 schrieb Sven Schreiber:
Well, my test case is quite simple. This is with yesterday's snapshot
on Win 7.
Under C:\Benutzer\sven-schreiber\Dokumente I created a new directory
"gtest".
(Equivalently in the Windows cmd.exe shell it shows as the
non-localized variant C:\users\sven-schreiber\Documents\gtest. Perhaps
the language issue on Windows plays a role, I don't know.)
Because it's a new directory, gretl's CWD is something quite different.
In that dir I save a file gmain.inp which contains just "include
helper.inp". That file helper.inp is also in there next to gmain.inp,
and it contains the line 'print "helper!"'.
When I click the run (cogwheel) button in the script editor for the
gmain.inp file I get the error "Error reading helper.inp" (in German
translation).
Then I set the CWD to the gtest directory, and I get as an echo the
path of helper.inp, and the printout: helper!
In other words, then it works.
Should I put it on the tracker?
thanks,
sven
6:09 p.m.
On Wed, 17 Oct 2018, Sven Schreiber wrote:
Am 12.10.2018 um 18:29 schrieb Sven Schreiber:
>
> Well, my test case is quite simple. This is with yesterday's snapshot on
> Win 7.
>
> Under C:\Benutzer\sven-schreiber\Dokumente I created a new directory
> "gtest".
> (Equivalently in the Windows cmd.exe shell it shows as the non-localized
> variant C:\users\sven-schreiber\Documents\gtest. Perhaps the language issue
> on Windows plays a role, I don't know.)
> Because it's a new directory, gretl's CWD is something quite different.
>
> In that dir I save a file gmain.inp which contains just "include
> helper.inp". That file helper.inp is also in there next to gmain.inp, and
> it contains the line 'print "helper!"'.
> When I click the run (cogwheel) button in the script editor for the
> gmain.inp file I get the error "Error reading helper.inp" (in German
> translation).
>
> Then I set the CWD to the gtest directory, and I get as an echo the path of
> helper.inp, and the printout: helper!
> In other words, then it works.
Should I put it on the tracker?
No, not yet please. Can you try the current Windows snapshot first?
Allin
1:12 p.m.
Am 17.10.2018 um 20:09 schrieb Allin Cottrell:
On Wed, 17 Oct 2018, Sven Schreiber wrote:
> Am 12.10.2018 um 18:29 schrieb Sven Schreiber:
>>
>> Well, my test case is quite simple. This is with yesterday's
>> snapshot on Win 7.
>>
>> Under C:\Benutzer\sven-schreiber\Dokumente I created a new directory
>> "gtest".
>> (Equivalently in the Windows cmd.exe shell it shows as the
>> non-localized variant C:\users\sven-schreiber\Documents\gtest.
>> Perhaps the language issue on Windows plays a role, I don't know.)
>> Because it's a new directory, gretl's CWD is something quite different.
>>
>> In that dir I save a file gmain.inp which contains just "include
>> helper.inp". That file helper.inp is also in there next to
>> gmain.inp, and it contains the line 'print "helper!"'.
>> When I click the run (cogwheel) button in the script editor for the
>> gmain.inp file I get the error "Error reading helper.inp" (in German
>> translation).
>>
>> Then I set the CWD to the gtest directory, and I get as an echo the
>> path of helper.inp, and the printout: helper!
>> In other words, then it works.
>
> Should I put it on the tracker?
No, not yet please. Can you try the current Windows snapshot first?
It seems to work now! Hope I did everything as before.
Thanks,
sven
6:34 p.m.
On Thu, 18 Oct 2018, Sven Schreiber wrote:
Am 17.10.2018 um 20:09 schrieb Allin Cottrell:
> On Wed, 17 Oct 2018, Sven Schreiber wrote:
>
>> Am 12.10.2018 um 18:29 schrieb Sven Schreiber:
>>>
>>> Well, my test case is quite simple. This is with yesterday's snapshot on
>>> Win 7.
>>>
>>> Under C:\Benutzer\sven-schreiber\Dokumente I created a new directory
>>> "gtest".
>>> (Equivalently in the Windows cmd.exe shell it shows as the non-localized
>>> variant C:\users\sven-schreiber\Documents\gtest. Perhaps the language
>>> issue on Windows plays a role, I don't know.)
>>> Because it's a new directory, gretl's CWD is something quite
different.
>>>
>>> In that dir I save a file gmain.inp which contains just "include
>>> helper.inp". That file helper.inp is also in there next to gmain.inp,
and
>>> it contains the line 'print "helper!"'.
>>> When I click the run (cogwheel) button in the script editor for the
>>> gmain.inp file I get the error "Error reading helper.inp" (in
German
>>> translation).
>>>
>>> Then I set the CWD to the gtest directory, and I get as an echo the path
>>> of helper.inp, and the printout: helper!
>>> In other words, then it works.
>>
>> Should I put it on the tracker?
>
> No, not yet please. Can you try the current Windows snapshot first?
It seems to work now! Hope I did everything as before.
Good, it was supposed to work now!
Allin
9:34 p.m.
On Thu, 18 Oct 2018, Sven Schreiber wrote:
Am 18.10.2018 um 20:34 schrieb Allin Cottrell:
> On Thu, 18 Oct 2018, Sven Schreiber wrote:
>>
>> It seems to work now! Hope I did everything as before.
>
> Good, it was supposed to work now!
So was it the local-language path?
Actually no, but the placement of the call that sets the directory
to be searched for inputs on behalf of a given script was not quite
right, so it could miss under some conditions.
Allin
2035
days inactive
2047
days old
13 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber