On Fri, 26 Oct 2007, Sven Schreiber wrote:
I want to support the idea of a more formal bug collection &
management approach that came up recently. Among other reasons,
I think one gets a nice feeling of job satisfaction when looking
at resolved bugs...
If you want I could do the maintenance of the bug list/database at least
initially. I mean not on my computer at home or by setting up a server,
but just by verifying, classifying, and hopefully closing bug reports
that are stored in some sourceforge/bugzilla/trac/whatever instance.
Somebody said the sourceforge tool is not good, but I'd say we can
always switch to something better later. (Provided that at least the sf
tool has some usable export feature?)
Thanks very much for the offer. I tend to agree that using SF
might be acceptable, at least for now. Personally, I don't have
time to set up something better. Other thoughts?
Ok, here's the list (on gretl windows snapshot from 9/19, so not
the most recent I'm afraid):
1) the VAR model window doesn't have a close box (apart from the window
That's an oversight -- it should have a File/Close item like the
regular model window. I'll fix that.
2) with T = 235 and 2 equ with about 20 coeffs each, gretl says it
doesn't have enough dofs for autocorrelation test of order 4 (or
even 1!) -- sometimes it even does that just for estimation! (maybe
triggered by repeatedly checking/un-checking the robust cov option,
which I did?)
I'll take a look. But if you could provide an explicit spec that
provokes the problem that would be helpful.
3) a big wishlist item or question: how to modify an existing
model instead of starting always from scratch???
Hmm. The model spec is (mostly) remembered from one opening of
the model dialog to another, and you also have the add/omit test
entries in the model window. Could you be a bit more explicit on
what you'd like to see?
4) bug recipe (not 100% sure which part is the bug though):
a) create new dataset
b) save dataset as "test1.gdt"
c) save as session "my1session.gretl"
d) close dataset
e) open above session file, and get the data named "data.gdt" (
instead of "test1.gdt")
Ah well, that's supposed to be a feature. When you save a
session, a snapshot of the data used in that session is stored as
data.gdt, inside the session zipfile. Think about what might
happen if a session were not self-contained in that way, but
referenced an external data file. The user could delete or modify
the datafile between saving and re-opening the session, in which
case the re-opened session would be badly broken.
5) also observed that saving a subset of variables to a new
datafile doesn't update the variable list/view, but does change
the datafile name above the variable listing. Not sure which
part of this behavior is intended and which is a bug.
That seems inconsistent. We probably need to pop up the "Do you
want to switch to the reduced dataset?" dialog.
Oh BTW, I'm sorry but I won't have time to take another look
de.po before next week. But if needed for release I can promise
Tuesday would be fine; probably the end of the week would be fine.