directory structure in CVS
by Allin Cottrell
I've taken a first step in modifying the gretl directory
structure, in CVS and the current Windows snapshot, following the
discussions here a few days back.
I've split the old "userdir", which served both as the repository
for automatically generated files and as the default location for
explicit file input/output on the user's part, into two:
(a) "dotdir": this holds the automatic files. It is not
user-selectable (directories of this sort are rarely if ever
user-configurable). On unix-type systems it is HOME/.gretl, and
on MS Windows it is APPDATA\gretl, where "APPDATA" is a standard
Windows API thing, localized and user-ized. It may expand to
something like
"C:\Documents and Settings\cottrell\Application data"
(b) "workdir": the default path for explicit user file I/O. This
defaults to HOME/gretl on unix, and to PERSONAL\gretl on Windows.
"PERSONAL" is again localized and user-ized. It may expand to
something like
"C:\Documents and Settings\cottrell\My Documents"
Unlike dotdir, this is user-configurable. For previous gretl
installations, it inherits the old "userdir" setting; for new
installs it can be changed under Tools/Preferences, as before.
I considered using just HOME (unix) or PERSONAL (Windows) for the
default workdir (without appending "/gretl"). But gretl writes
some files to this directory without explicit GUI filename
selection (e.g. the eqnprint and tabprint commands, the gnuplot
command in batch mode), and it seemed like bad form to dump stuff
into HOME or PERSONAL directly. If you don't want to use
{HOME,PERSONAL}/gretl for this purpose, change the preference and
blow the unneeded directory away.
A couple of other changes:
(1) The Windows installer no longer prompts for, or creates, a
per-user working directory. This is handled at run-time: the
appropriate "dotdir" and default "workdir" are created for the
current user, if they don't already exist (and if the default
workdir is not contradicted by an existing registry setting).
(2) Since the CWD (current working directory) is pretty much
inscrutable on Windows, we no longer use this as the default
for the "shelldir" variable: this now defaults to the "workdir".
(You can launch GUI program from a Windows console, but I don't
think anyone but me ever does that!)
Since (a) OS X is very much GUI-oriented and (b) gretl from the OS
X dmg starts up inside Gretl.app, which is definitely not a
sensible location for writing anything, I've also arranged for
shelldir to default to workdir on OS X.
On unix, the shelldir still defaults to whatever is the CWD on
startup. This could perhaps be user-configurable (CWD vs.
workdir), but it would be a somewhat arcane item.
As I say, this is a first step. I have not yet done anything
about automatically changing workdir based on the last directory
visited via the file open/save dialog. I'm not sure that's a good
idea, though it's open for discussion.
Allin.
16 years, 12 months
'include' w/o 'open' -- new behavior
by Sven Schreiber
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
16 years, 12 months
shell stuff
by Allin Cottrell
There's an extension of gretl's shell capabilities in the works.
Sorry, not available for Windows just yet, but on *nix you can now
(current CVS) capture output from shell commands in a string
variable, using "$(command)", and you also have a subset of C's
sscanf to process such strings.
Here are a few examples:
<script>
nulldata 10
string fnum = $(ls | wc -l)
scalar n
sscanf @fnum, "%d", &n
printf "There are %d files in this directory\n", n
string bessel = $(echo "j(3,10)" | bc -l)
scalar j
sscanf @bessel, "%lf", &j
printf "Bessel function, order 3, of 10 = %.15g\n", j
! echo "1 2 3 4" > mat.txt
! echo "5 6 7 8" >> mat.txt
string mat = $(cat mat.txt)
printf "mat (string form) = \n%s\n", @mat
matrix m
sscanf @mat, "%m", &m
print m
</script>
The allowable sscanf conversions are "d" (int), "lf" (double),
"s" or "[stuff]" (string) and "m" (matrix). With matrix
conversion we proceed along the input string so long as we're able
to read doubles, with space or tab counting as column separator
and CR-LF, LF or CR counting as row separators.
Allin
17 years
Installation on Windows
by Allin Cottrell
Thoughts based on some quick research.
When the gretl installer is being run on Windows there are three
main cases to consider:
1. gretl is being installed by someone who has admin (or at least
"power user") rights, and this person will also be using gretl.
I believe that's the most likely case, at least in the American
academic sphere, and in this case what we do currently is fine.
2. gretl is being installed by an admin user, on behalf of someone
else who doesn't have admin rights but who will actually use the
progam. In this case the install should go OK, though as Sven
points out it will redundantly create a gretl userdir tree for
the admin user. When the ordinary user runs the program there may
be some permissions issues on saving settings. This should be
fixable without too much difficulty.
3. An unprivileged user is trying to install gretl on their own
account. This will fail at present. It's possible we could set
things up so that it'll work: don't install gretl into
PROGRAMFILES but into a per-user directory; don't attempt to write
registry keys under "Local Machine", only "Current User".
MSDN says:
"During setup your application should check to see whether the
application is being installed by a user account having the
privileges to write to HKEY_LOCAL_MACHINE. If your setup is not
run by a user with write permissions to HKEY_LOCAL_MACHINE, the
application should notify the user with a message such as, "You
are not allowed to install this application for all users on this
machine; do you want to install this application for personal
use?" All users should be able to install an application for their
own use."
Conversely, if the user does have admin status we could ask: "You
are installing gretl as an administrator; will you be using the
program yourself?" -- and create a userdir tree only if the answer
to that is Yes.
I'm not sure yet how much of this can be done with the current
version of Inno Setup, but I'm trying to figure that out.
Allin.
17 years
Re: Re: [Gretl-devel] Extend quantile function to matrices
by andreas.rosenblad＠ltv.se
r.lucchetti(a)univpm.it @ INTERNET skrev 2007-12-21 15:06:07 :
> On Fri, 21 Dec 2007, andreas.rosenblad(a)ltv.se wrote:
>
> >
> > Please extend the quantile() function so that it can be used with
matrices
> > too, working on columns in the same way as e.g. meanc() and sumc().
>
> Nice idea. I suppose that what you have in mind is something like
>
> a = quantile(X, 0.9)
>
> where X is (nxm) and a is (1xm), right?
Yes, exactly.
> Could you file a feature request on the Sourceforge database, please?
Done.
Andreas
17 years
Extend quantile function to matrices
by andreas.rosenblad＠ltv.se
Please extend the quantile() function so that it can be used with matrices
too, working on columns in the same way as e.g. meanc() and sumc().
Best regards
Andreas
17 years
Please extend the resample command
by andreas.rosenblad＠ltv.se
Please extend the resample() command so that it can be used with an mxn
matrix A too. Then B = resample(A) should construct a matrix where B
contains resampled rows from A.
This would be very useful when bootstrapping a regression model using the
paired bootstrap method (see e.g.
http://www.stanford.edu/~zhenwei/papers/bootstrap.pdf).
Secondly, add a second argument to the resample() command where one can
choose the number of resamplings that should be drawn. E.g., if the
variable has n observations, sometimes one may want to draw m>n
resamplings. This should be possible by writing e.g. x = resample(y,m),
with the default value m=n, so that x = resample(y) draws n resamples, but
one could use x = resample(y,m) with m not equal to n.
Best regards and thanks for a great software,
Andreas
17 years
Documentation for the "set" command
by Riccardo (Jack) Lucchetti
Hi everyone,
I just committed an update of the documentation for the "set" command,
which was quite outdated. Unfortunatly, this will require some extra work
for the translators, because I also changed a few strings in
lib/src/libset.c.
Moreover:
1) the "force_decpoint" settings seems to be used nowhere. I
peronally don't remember anything about it. Allin, what do
you think we should do?
2) the "BFGSmax" function is undocumented in the "genr" command section,
although it receives fairly extensive treatment in the User's Guide.
However, documenting "genr" like any other command is maybe a bit
difficult nowadays. Maybe we should add a chapter in the User's Guide
documenting all the genr functions in alphabetical order. Note that this
could be a collaborative effort: the User's guide is in LaTeX, so it's
easy to edit for everybody, and the full list of genr functions can be
easily retrieved from the source. Opinions?
3) the options that the "restrict" commands accepts are, surprisingly, not
listed in commands.xml. This is a harder task than it may seem, since
internally "restrict" behaves quite differently depending on what
estimation method was last used, and therefore accepts different options.
IMHO, none of the above items should be considered release blockers, but
it'd be nice if they could be addressed.
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
17 years
