[Gretl-devel] GSOC (was: Several things)

On Mon, 9 Feb 2009, Talha Yalta wrote: You know, Talha, people happen to have lives :-) I'm going back to your 7/2 proposal: 1)- C library for various file filters 2)- Enhancing the gretl database server 3)- Adding more statistical distributions 4)- Improving the NIST test suite function 5)- Adding confidence bands plots and I could add 6)- Improving function packages management (more on this later) On (1) to (5), I'm with Allin. While (1) and (2) are doable, (3) is IMO not worth attempting, at least for now: for statistical distributions we rely ATM mostly on netlib. The R guys have their own code, and GSL is yet another independent implementation. I don't see huge advantages in standardising on one, plus it would be boring and complicated at the same time. I don't find (4) and (5) particularly exciting, so of course I'm not against them but it's not something I'm eager to spend any time on. (6) is probably something feasible and IMO worth doing. At the moment, we manage function packages from within gretl, which is a neat solution when packages are few and little. However, the present solution is not IMHO well suited for more complex contributions. What I'd like to see is something similar to R's library mechanism. Outline: a) we set up a sourceforge project called gretl-packages or so b) function writers upload to sourceforge tar.gz or zip archives, whose internal structure is well defined. I'd abandon our custom-made xml structure in favour of an ordinary archive which contains subdirectories. c) we introduce a gretl command (which could well be modelled after R's install.library() command) which takes care of connecting to sourceforge, downloading the bundle and uncompressing it in the proper place. Of course, a GUI interface could be added as well. For example: suppose that I wrote a package implementing (say) multivariate GARCH models. I'd produce an archive mgarch.tar.gz containing the following subdirs: src/ (with the actual functions) examples/ (with a few example scripts and datasets) doc/ (with pdf or tex documentations files) guihook/ (with xml descriptions of the GUI-callable functions) Then, I'd upload the tarball to sourceforge. The user would a) open gretl b) issue the command (say) "library mgarch --install". This would download the package from sourceforge and unpack it into a suitable subdirectory of his local tree (say, /usr/local/share/gretl_packages/mgarch/). Of course, there would be a GUI equivalent. c) issue the command (say) "library mgarch". This would "include" all the files in /usr/local/share/gretl_packages/mgarch/src/ and create an "mgarch" entry somewhere in gretl's GUI menu. d) use the functions and complain about the bugs :-) This seems doable, in a reasonable timespan, by someone with little prior knowledge of gretl's internals and would be IMO a nice improvement in the way 'outsiders' could contribute. Riccardo (Jack) Lucchetti Dipartimento di Economia Università Politecnica delle Marche r.lucchetti(a)univpm.it http://www.econ.univpm.it/lucchetti