Re: [Gretl-devel] 'include' w/o 'open' -- new behavior
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