Re: [Gretl-devel] remaining feature to-do list

Three things that I would love to see in 2.0 (or possibly 3.0): 1. A loop structure like the parfor in Matlab, i. e. a parrell processed loop. 2. A special series data type that can hold text. This would be useful for labeling a discreet variable, and could be used for making nice labes on factorized plots. 3. More integration of LaTeX. Maybe a LaTeX function like gnuplot(). Cheers, Logan -------- Original message -------- From: Sven Schreiber <svetosch(a)gmx.net&gt; Date: 11/27/2013 11:41 AM (GMT-06:00) To: Gretl development <gretl-devel(a)lists.wfu.edu&gt; Subject: [Gretl-devel] remaining feature to-do list Hi, out of curiosity: what is still on the general to-do list for gretl 2.0? I'm not talking about a wishlist for incremental features which will always contain some items and will be added in point releases, but the big picture -- I've heard there's ongoing work about multiprocessing support, but apart from that I cannot think of anything fundamental that is really missing, or is there? Or actually maybe I do have a suggestion for further "modular extension" interfaces. Namely: make user-defined functions callable by custom command options. Example: say somebody writes a function to do a new diagnostic test after a model is estimated. Say the function is called 'modtest_mynewdiagtest' and the corresponding .inp file has been saved in a standard (to be defined) place. Then I want the following hansl code to work: <hansl-proposed> ols y 0 x modtest --mynewdiagtest </hansl-proposed> The signature of the user-defined function would be: 'function void modtest_mynewdiagtest (bundle *modelbundle)' So if gretl encounters an unknown command option, it would check whether a user-supplied corresponding function definition/file exists, and it would call that function with the argument of the standard bundle that the previous estimation command created (if I understand correctly the way it works now; the internal bundle may have to be exposed to hansl for that, I don't know). Then the user-supplied function would presumably print out some results, and/or add new items to the input bundle which could be used afterwards. That way gretl could be extended without touching the C source, but from the point of view of users with the same syntax as the built-in options. (I guess this would be a bit like do-files in Stata, but I'm not sure.) Thanks, I wasn't planning to write such a long email.... Sven _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel