[Gretl-devel] some new gretl issues

[Allin Cottrell]

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
> manager thing)

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 at 
> de.po before next week. But if needed for release I can promise 
> Tuesday.

Tuesday would be fine; probably the end of the week would be fine.

Allin.