4:24 p.m.
On Tue, 28 May 2013, Sven Schreiber wrote:
for the first time ever I tried to attach a function package to the
menus,
but I couldn't get it to appear. I never got an error, just no effect.
Ah, I introduced a new bug that disabled that effect when I
was fixing the other problems you mentioned. But that in turn
was fixed in CVS and snapshots a few hours ago.
I have noticed that in the dialog where the menu path is
chosen, the "model -> limited dependent" submenu is
expandable, whereas the "model -> time series" submenu
isn't. (There is the 3rd-level submenu cointegration tests
there.)
OK, I suppose in principle it ought to be possible to add an
item to the Cointegration test submenu; I'll look into that.
Allin
12:08 p.m.
Am 28.05.2013 18:24, schrieb Allin Cottrell:
On Tue, 28 May 2013, Sven Schreiber wrote:
> for the first time ever I tried to attach a function package to the menus,
> but I couldn't get it to appear. I never got an error, just no effect.
Ah, I introduced a new bug that disabled that effect when I
was fixing the other problems you mentioned. But that in turn
was fixed in CVS and snapshots a few hours ago.
It's working now, very cool.
> I have noticed that in the dialog where the menu path is
> chosen, the "model -> limited dependent" submenu is
> expandable, whereas the "model -> time series" submenu
> isn't. (There is the 3rd-level submenu cointegration tests
> there.)
OK, I suppose in principle it ought to be possible to add an
item to the Cointegration test submenu; I'll look into that.
Yes that would be the most logical place.
On a related note: I've noticed by trial-and-error that for
"bundle-print" etc. the corresponding defined function must be declared
public instead of helper. (Otherwise the dialog items were greyed out.)
That logic wasn't obvious. And actually, the printing via that function
isn't working for me. Also the bundle that's returned never shows up
anyway -- at least since I have added the package to the menu it's also
not possible anymore to specify a return bundle name/container.
(In my case I'm grabbing a matrix from the result bundle and print the
elements in some way. Nothing happens.)
One further suggestion for the packages: It would be nice if the
bundle-print function (and friends) could get automatic access to the
arguments with which gui-main was called. I know I can stuff all the
arguments inside the bundle and read them out in bundle-print, but that
seems redundant and clunky.
thanks,
sven
3:23 p.m.
On Wed, 29 May 2013, Sven Schreiber wrote:
Am 28.05.2013 18:24, schrieb Allin Cottrell:
> On Tue, 28 May 2013, Sven Schreiber wrote:
>
>> for the first time ever I tried to attach a function package to the menus,
>> but I couldn't get it to appear. I never got an error, just no effect.
>
> Ah, I introduced a new bug that disabled that effect when I
> was fixing the other problems you mentioned. But that in turn
> was fixed in CVS and snapshots a few hours ago.
It's working now, very cool.
>
>> I have noticed that in the dialog where the menu path is
>> chosen, the "model -> limited dependent" submenu is
>> expandable, whereas the "model -> time series" submenu
>> isn't. (There is the 3rd-level submenu cointegration tests
>> there.)
>
> OK, I suppose in principle it ought to be possible to add an
> item to the Cointegration test submenu; I'll look into that.
Yes that would be the most logical place.
In fact, the only place. (I mean, that's the sole submenu
under /Model/Time series; and until further notice packages
cannot themselves add submenus, only items under existing
menus or submenus.)
On a related note: I've noticed by trial-and-error that for
"bundle-print" etc. the corresponding defined function must be declared
public instead of helper. (Otherwise the dialog items were greyed out.)
That logic wasn't obvious.
The thinking here is that "helper" (private) functions are
callable only by public functions in the given package, while
bundle-print and so on have to be callable by third parties,
even if only gretl itself. But this should be documented,
agreed.
And actually, the printing via that function isn't working
for me. Also the bundle that's returned never shows up
anyway -- at least since I have added the package to the
menu it's also not possible anymore to specify a return
bundle name/container.
Another thing that needs to be documented (and I plan to
document it in my paper for GC 2013). If you specify a
"gui-main" function, and this function returns a bundle, then
the handling of the returned bundle is done by gretl. The user
is not given the option of assigning the returned bundle in
advance, because it's assumed that the bundle will be
displayed in a GUI window, from where it can be saved (if the
user wants) in the same sort of way that a gretl model can be
saved.
If your returned bundle is not showing up in a window that
could be a bug in gretl, or possibly in your package (though
in the latter case you should get an error message, and it
would be a gretl bug if you don't). I'll try constructing a
minimal test of this functionality and report back.
One further suggestion for the packages: It would be nice if the
bundle-print function (and friends) could get automatic access to the
arguments with which gui-main was called. I know I can stuff all the
arguments inside the bundle and read them out in bundle-print, but that
seems redundant and clunky.
Not redundant, surely: if the information is to be used
subsequently it has to be stored somewhere. And I can't see a
superior alternative to storing it inside the package's
bundle. From gretl's point of view function arguments are
transient data. And consider the case where the bundle is
stored as part of a saved session file: how else could we save
the argument info other than in the bundle?
Allin
4:09 p.m.
On Wed, 29 May 2013, Allin Cottrell wrote:
Another thing that needs to be documented (and I plan to
document it in my paper for GC 2013). If you specify a
"gui-main" function, and this function returns a bundle,
then the handling of the returned bundle is done by gretl.
The user is not given the option of assigning the returned
bundle in advance, because it's assumed that the bundle will
be displayed in a GUI window, from where it can be saved (if
the user wants) in the same sort of way that a gretl model
can be saved.
If [a] returned bundle is not showing up in a window that
could be a bug in gretl, or possibly in [the associated]
package (though in the latter case you should get an error
message, and it would be a gretl bug if you don't). I'll try
constructing a minimal test of this functionality and report
back.
I've now put a trivial but complete example at
http://users.wfu.edu/cottrell/pkg/
Note that the main function, olsbundle(), calls the
bundle-print function to display its results. This is one way
of doing things. An alternative would be to include in
olsbundle() the special comment
## no-print ##
(see section 6 in
http://gretl.sourceforge.net/papers/addons.pdf ) This signals
to gretl that the function does not print its own results, in
which case gretl will take care of calling the package's
bundle-print function. (We don't want both of these things to
happen.)
Note that if olsbundle() did not print the bundle, and did not
include the special "no-print" comment, then the returned
bundle's window would come up empty (though it would have a
menu enabling saving of the bundle and/or selected contents).
Allin
7:53 p.m.
Am 29.05.2013 17:23, schrieb Allin Cottrell:
On Wed, 29 May 2013, Sven Schreiber wrote:
If your returned bundle is not showing up in a window that
could be a bug in gretl, or possibly in your package (though
in the latter case you should get an error message, and it
would be a gretl bug if you don't). I'll try constructing a
minimal test of this functionality and report back.
I definitely didn't get any error message. There was indeed a mistake in
my bundle-print function (which is not literally called "bundle-print"
BTW), but it was strange that no error was triggered; I had the
following assignment
matrix m = <bundlename>.results
but the bundle member's real name was "mresults" instead. As I said, no
error message made its way through to me.
> One further suggestion for the packages: It would be nice if the
> bundle-print function (and friends) could get automatic access to the
> arguments with which gui-main was called. I know I can stuff all the
> arguments inside the bundle and read them out in bundle-print, but that
> seems redundant and clunky.
Not redundant, surely: if the information is to be used
subsequently it has to be stored somewhere. And I can't see a
superior alternative to storing it inside the package's
bundle. From gretl's point of view function arguments are
transient data. And consider the case where the bundle is
stored as part of a saved session file: how else could we save
the argument info other than in the bundle?
Ok, I guess you're right. I had thought of more "introspection"
capabilities, but it's true that for later use it's probably better to
really store it in the bundle.
thanks,
sven
8:44 p.m.
On Wed, 29 May 2013, Sven Schreiber wrote:
Am 29.05.2013 17:23, schrieb Allin Cottrell:
> On Wed, 29 May 2013, Sven Schreiber wrote:
>
> If your returned bundle is not showing up in a window that
> could be a bug in gretl, or possibly in your package (though
> in the latter case you should get an error message, and it
> would be a gretl bug if you don't). I'll try constructing a
> minimal test of this functionality and report back.
I definitely didn't get any error message. There was indeed a mistake in
my bundle-print function (which is not literally called "bundle-print"
BTW),
No, it couldn't be, since you can't use '-' in a gretl
identifier.
but it was strange that no error was triggered; I had the
following assignment
matrix m = <bundlename>.results
but the bundle member's real name was "mresults" instead. As I said, no
error message made its way through to me.
Can you compare your package with the example I put up today?
[ http://users.wfu.edu/cottrell/pkg/ ] And/or send me your
package code?
I just tried introducing a similar error into the
"bundle-print" function for the "olsbundle" example (i.e.
calling for a non-existent bundle member) and the error
message came across loud and clear.
Allin
9:06 p.m.
On Wed, 29 May 2013, Allin Cottrell wrote:
(see section 6 in http://gretl.sourceforge.net/papers/addons.pdf )
A few comments after a (somewhat casual) re-reading:
* The link
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS is
very cool. Is it linked anywhere?
* You never mention the "hansl" acronym. Is this intentional?
* Formula at page 5 is syntactically wrong (check the parentheses)
* Maybe you could also mention SVAR among the available addons
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
9:55 p.m.
Am 29.05.2013 18:09, schrieb Allin Cottrell:
On Wed, 29 May 2013, Allin Cottrell wrote:
I've now put a trivial but complete example at
http://users.wfu.edu/cottrell/pkg/
('setnote' still is a secret I guess -- although it vaguely rings a
bell, maybe it was discussed somewhere?)
Note that the main function, olsbundle(), calls the
bundle-print function to display its results. This is one way
of doing things. An alternative would be to include in
olsbundle() the special comment
Ok, thanks, I will try that (soon) -- what I don't understand here,
though, is why the bundle needs to be passed in pointer form. In this
example it looks just like a regular call (with a single argument) --
but well, there will be a reason I'm sure.
## no-print ##
(see section 6 in
http://gretl.sourceforge.net/papers/addons.pdf ) This signals
to gretl that the function does not print its own results, in
which case gretl will take care of calling the package's
bundle-print function. (We don't want both of these things to
happen.)
Somehow my feeling is that it would be good to not have this new syntax.
Or maybe it's the "mis-use" of the comment characters. Maybe instead a
specially named argument instead?
(Example:
function bundle olsbundle (series y, list X, bool addon_no_print[1]) )
thanks,
sven
9:59 p.m.
On Wed, 29 May 2013, Riccardo (Jack) Lucchetti wrote:
On Wed, 29 May 2013, Allin Cottrell wrote:
> (see section 6 in http://gretl.sourceforge.net/papers/addons.pdf )
A few comments after a (somewhat casual) re-reading:
* The link
http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS is very
cool. Is it linked anywhere?
I think not, but it probably should be.
* You never mention the "hansl" acronym. Is this
intentional?
Well, the name "hansl" was proposed after this piece was
written, so no, it's not an intentional omission.
* Formula at page 5 is syntactically wrong (check the parentheses)
Oof, yes, sorry. I've now posted a fixed version.
* Maybe you could also mention SVAR among the available addons
In an updated version, yes, of course. IIRC SVAR was at the
alpha stage when I wrote that.
Allin
8:37 a.m.
On Wed, 29 May 2013, Sven Schreiber wrote:
Am 29.05.2013 18:09, schrieb Allin Cottrell:
> On Wed, 29 May 2013, Allin Cottrell wrote:
>
> I've now put a trivial but complete example at
> http://users.wfu.edu/cottrell/pkg/
('setnote' still is a secret I guess -- although it vaguely rings a
bell, maybe it was discussed somewhere?)
It's mentioned in section 12.7 of the User's Guide. I guess
it's time to add it to the function reference.
> Note that the main function, olsbundle(), calls the
> bundle-print function to display its results. This is one way
> of doing things. An alternative would be to include in
> olsbundle() the special comment [...]
Ok, thanks, I will try that (soon) -- what I don't understand here,
though, is why the bundle needs to be passed in pointer form.
It's a matter of efficiency: there's no need to duplicate the
entire bundle when passing it as an argument to
bundle-printing (or bundle-plotting) functions. Using a
pointer just gives access to the bundle as it exists at the
caller level.
> ## no-print ##
>
> (see section 6 in
> http://gretl.sourceforge.net/papers/addons.pdf ) This signals
> to gretl that the function does not print its own results, in
> which case gretl will take care of calling the package's
> bundle-print function. (We don't want both of these things to
> happen.)
Somehow my feeling is that it would be good to not have this new syntax.
Or maybe it's the "mis-use" of the comment characters. Maybe instead a
specially named argument instead?
(Example:
function bundle olsbundle (series y, list X, bool addon_no_print[1]) )
Fair point: the use of a special comment in this context is ad
hoc and potentially fragile. Another possibility would be to
make "no-print" a property of a packaged function that can be
set via the package's .spec file (and preferably also via the
function-packager GUI).
In a "real life" counterpart of olsbundle a standard idiom
would be to include a boolean parameter for printing or not in
the olsbundle() function -- hence giving a choice to the user
calling this function via script -- and to supply a wrapper
function (defined as "gui-main") which calls olsbundle() with
that flag set appropriately (presumably, with printing on). In
that case it would be the wrapper function that wants the
no-print flag.
Allin
8:50 a.m.
>> ## no-print ##
>>
>> (see section 6 in
>> http://gretl.sourceforge.net/papers/addons.pdf ) This signals
>> to gretl that the function does not print its own results, in
>> which case gretl will take care of calling the package's
>> bundle-print function. (We don't want both of these things to
>> happen.)
>
> Somehow my feeling is that it would be good to not have this new syntax.
> Or maybe it's the "mis-use" of the comment characters. Maybe instead a
> specially named argument instead?
> (Example:
> function bundle olsbundle (series y, list X, bool addon_no_print[1]) )
Fair point: the use of a special comment in this context is ad
hoc and potentially fragile. Another possibility would be to
make "no-print" a property of a packaged function that can be
set via the package's .spec file (and preferably also via the
function-packager GUI).
In a "real life" counterpart of olsbundle a standard idiom
would be to include a boolean parameter for printing or not in
the olsbundle() function -- hence giving a choice to the user
calling this function via script -- and to supply a wrapper
function (defined as "gui-main") which calls olsbundle() with
that flag set appropriately (presumably, with printing on). In
that case it would be the wrapper function that wants the
no-print flag.
I have now written at least a dozen of sets of scripts which use the
bundle to store pretty much everything and implement estimators/tests/etc.
In my experience, the best way to proceed (at least in a project which
involves more than a hundred lines of hansl code) is to have 3 separate
functions: one for populating the bundle with the reuslts (estimates etc
-- call it A), one for printing out the results (call it B) and a third
one, which acts as a wrapper, like
function bundle C(..., int verbosity)
bundle mod
...
A(&mod, <whatever>)
if verbosity>1
B(&mod)
endif
return mod
end function
So you have the choice of using the GUI to call function C, or you can
simply call A() if you don't care about viewing the results (like in a
Monte Carlo experiment, or because it's just an intermediate good to what
you want).
This is basically the way the gig and SVAR add-ons work, and quite happy
about it.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
11:46 a.m.
On Thu, 30 May 2013, Allin Cottrell wrote:
On Wed, 29 May 2013, Sven Schreiber wrote:
> Somehow my feeling is that it would be good to not have this new syntax.
[i.e. the special comment, "## no-print ##' ]
> Or maybe it's the "mis-use" of the comment
characters. Maybe instead a
> specially named argument instead?
> (Example:
> function bundle olsbundle (series y, list X, bool addon_no_print[1]) )
Fair point: the use of a special comment in this context is ad hoc and
potentially fragile. Another possibility would be to make "no-print" a
property of a packaged function that can be set via the package's .spec file
(and preferably also via the function-packager GUI).
You can now (CVS) do this via a package's .spec file. The
syntax is
no-print = <funclist>
where <funclist> is a space-separated list of names of
(public) functions that should be given the "no-print"
attribute. You can't yet do this via the GUI.
Allin
11:07 a.m.
Am 29.05.2013 23:59, schrieb Allin Cottrell:
On Wed, 29 May 2013, Riccardo (Jack) Lucchetti wrote:
> On Wed, 29 May 2013, Allin Cottrell wrote:
>
>> (see section 6 in http://gretl.sourceforge.net/papers/addons.pdf )
>
> A few comments after a (somewhat casual) re-reading:
>
> * The link
> http://ricardo.ecn.wfu.edu/gretl/cgi-bin/gretldata.cgi?opt=SHOW_FUNCS is very
> cool. Is it linked anywhere?
I think not, but it probably should be.
It could replace this page:
https://gretlwiki.econ.univpm.it/wiki/index.php/List_of_available_user-co...
But I think it's worth linking from the main site, not "only" from the
wiki -- no offense against the wiki intended, though.
-sven
11:21 a.m.
Am 29.05.2013 22:44, schrieb Allin Cottrell:
On Wed, 29 May 2013, Sven Schreiber wrote:
> but it was strange that no error was triggered; I had the
> following assignment
>
> matrix m = <bundlename>.results
>
> but the bundle member's real name was "mresults" instead. As I said,
no
> error message made its way through to me.
Can you compare your package with the example I put up today?
[ http://users.wfu.edu/cottrell/pkg/ ] And/or send me your
package code?
I just tried introducing a similar error into the
"bundle-print" function for the "olsbundle" example (i.e.
calling for a non-existent bundle member) and the error
message came across loud and clear.
Ok, now I start to understand how these things fit together. There
wasn't any error message because the bundle-print function was never
actually called, since I didn't know how to specify that correctly.
(this) case closed
-- sven
1:13 p.m.
Am 30.05.2013 10:50, schrieb Riccardo (Jack) Lucchetti:
I have now written at least a dozen of sets of scripts which use the
bundle to store pretty much everything and implement
estimators/tests/etc. In my experience, the best way to proceed (at
least in a project which involves more than a hundred lines of hansl
code) is to have 3 separate functions: one for populating the bundle
with the reuslts (estimates etc -- call it A), one for printing out the
results (call it B) and a third one, which acts as a wrapper, like
function bundle C(..., int verbosity)
bundle mod
...
A(&mod, <whatever>)
if verbosity>1
B(&mod)
endif
return mod
end function
So you have the choice of using the GUI to call function C, or you can
simply call A() if you don't care about viewing the results (like in a
Monte Carlo experiment, or because it's just an intermediate good to
what you want).
This is basically the way the gig and SVAR add-ons work, and quite happy
about it.
Yes it is quite natural so I arrived at basically the same structure, too.
This machinery is quite cool indeed, I will upload the package with the
small-sample cointegration rank test soon, it seems to be working well
so far.
Just three things before I forget them:
1) Nothing in the bundle window gives the user a hint that she is
actually dealing with such a bundle. What I mean is: append the menu
entries "save to session as icon" or "save to icon and close" with the
bundle keyword. ("save entire bundle to session as icon" for example)
2) String members of the bundle are nowhere to be found in the GUI.
3) Still pending is the possibility to shove this into the cointegration
test submenu.
thanks,
sven
4:18 p.m.
On Fri, 31 May 2013, Sven Schreiber wrote:
Am 30.05.2013 10:50, schrieb Riccardo (Jack) Lucchetti:
>
> I have now written at least a dozen of sets of scripts which use the
> bundle to store pretty much everything and implement
> estimators/tests/etc. In my experience, the best way to proceed (at
> least in a project which involves more than a hundred lines of hansl
> code) is to have 3 separate functions: one for populating the bundle
> with the reuslts (estimates etc -- call it A), one for printing out the
> results (call it B) and a third one, which acts as a wrapper, like
>
> function bundle C(..., int verbosity)
> bundle mod
> ...
> A(&mod, <whatever>)
> if verbosity>1
> B(&mod)
> endif
> return mod
> end function
>
> So you have the choice of using the GUI to call function C, or you can
> simply call A() if you don't care about viewing the results (like in a
> Monte Carlo experiment, or because it's just an intermediate good to
> what you want).
>
> This is basically the way the gig and SVAR add-ons work, and quite happy
> about it.
>
Yes it is quite natural so I arrived at basically the same structure, too.
This machinery is quite cool indeed, I will upload the package with the
small-sample cointegration rank test soon, it seems to be working well
so far.
Just three things before I forget them:
1) Nothing in the bundle window gives the user a hint that she is
actually dealing with such a bundle. What I mean is: append the menu
entries "save to session as icon" or "save to icon and close" with
the
bundle keyword. ("save entire bundle to session as icon" for example)
OK, that may be worth doing.
2) String members of the bundle are nowhere to be found in the GUI.
That's because there's no GUI representation for string
variables. (And I can't see a use case for that, offhand.)
3) Still pending is the possibility to shove this into the
cointegration
test submenu.
That should now be doable.
Allin
3:10 p.m.
New subject: menu fonts
It seems there is a problem with the gretl menu fonts in Windows (at
least in XP, with the current snapshot). The changes via
"Tools/Preferences/Menu fonts" are not being activated. There is not
such a problem in fixed fonts and in Linux all seems to work well.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
11:47 p.m.
New subject: menu fonts
On Fri, 7 Jun 2013, Ignacio Diaz-Emparanza wrote:
It seems there is a problem with the gretl menu fonts in Windows (at
least in
XP, with the current snapshot). The changes via "Tools/Preferences/Menu
fonts" are not being activated.
I see what you mean, but I think we should probably get rid of that
menu item on Windows rather than trying to "fix" it. Gretl is
supposed to respect the choice of application font set via the
Windows control panel. Is there a particular reason why you want to
override that?
Allin
8 a.m.
New subject: menu fonts
On 08/06/13 01:47, Allin Cottrell wrote:
On Fri, 7 Jun 2013, Ignacio Diaz-Emparanza wrote:
> It seems there is a problem with the gretl menu fonts in Windows (at least in
> XP, with the current snapshot). The changes via "Tools/Preferences/Menu
> fonts" are not being activated.
I see what you mean, but I think we should probably get rid of that
menu item on Windows rather than trying to "fix" it. Gretl is
supposed to respect the choice of application font set via the
Windows control panel. Is there a particular reason why you want to
override that?
Allin
I don't want to override anything. This was a feature of gretl for
Windows until recently (and it is on Linux). It is rather practical when
you are using a proyector for example, for teaching, because this allows
to enlarge the font or put it in bold for better viewing. Some
colleagues here were missing that. I have also used it several times and
would vote for maintaining if not very complicated.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
11:05 a.m.
New subject: menu fonts
On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
On 08/06/13 01:47, Allin Cottrell wrote:
> On Fri, 7 Jun 2013, Ignacio Diaz-Emparanza wrote:
>
>> It seems there is a problem with the gretl menu fonts in Windows (at least
>> in
>> XP, with the current snapshot). The changes via "Tools/Preferences/Menu
>> fonts" are not being activated.
> I see what you mean, but I think we should probably get rid of that
> menu item on Windows rather than trying to "fix" it. Gretl is
> supposed to respect the choice of application font set via the
> Windows control panel. Is there a particular reason why you want to
> override that?
>
> Allin
I don't want to override anything. This was a feature of gretl for Windows
until recently (and it is on Linux). It is rather practical when you are
using a proyector for example, for teaching, because this allows to enlarge
the font or put it in bold for better viewing. Some colleagues here were
missing that. I have also used it several times and would vote for
maintaining if not very complicated.
There are many people (including myself) who like to be able to set gretl
fonts larger than usual when you teach in large rooms and students in the
back can't see the screen well.
Unfortunately, it looks as if somebody at Microsoft assumes that the user
values consistency across applications more than any other thing ("user
experience", they call it), so they simply took away from the programmers
the ability to change menu fonts on a per-application basis. In other
words, I'm afraid there's little we can do about it. I suppose, however,
there is some way to change menu fonts system-wide if absolutely
necessary. I'm not a windows guy, though, so someone else might want to
step in and offer advice.
-------------------------------------------------------
Riccardo (Jack) Lucchetti
Dipartimento di Scienze Economiche e Sociali (DiSES)
Università Politecnica delle Marche
(formerly known as Università di Ancona)
r.lucchetti(a)univpm.it
http://www2.econ.univpm.it/servizi/hpp/lucchetti
-------------------------------------------------------
1:35 p.m.
New subject: error creating a package
I am creating a new function package and I have this error:
"Value "bundle" for attribute type of param is not among the enumerated
set"
what does it mean? I see no problem then with the created package, it
seems to work correctly.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
2:46 p.m.
New subject: error creating a package
On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
I am creating a new function package and I have this error:
"Value "bundle" for attribute type of param is not among the enumerated
set"
what does it mean? I see no problem then with the created package, it seems
to work correctly.
It means you have a function that takes a straight bundle
argument rather than a bundle-pointer argument. That's
allowed, though it's not what you'd usually want to do. The
reason you saw that message is that the document type
definition for gretl packages, gretlfunc.dtd, did not include
the straight bundle type as a recognized parameter type. I've
now fixed that in CVS.
Why is it not what you'd usually want to do? If you use a
straight bundle arguent, the entire bundle is copied for use
by the function, and so no modifications inside the function
persist outside. Illustration:
<hansl>
function void bunfun (bundle b)
b.mat = I(3)
print b
end function
bundle b
bunfun(b)
print b
</hansl>
Of course, on some occasions you may actually want this
behavior, but generally efficiency favors using a
bundle-pointer argument.
Allin
3:59 p.m.
New subject: menu fonts
On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
On 08/06/13 01:47, Allin Cottrell wrote:
> On Fri, 7 Jun 2013, Ignacio Diaz-Emparanza wrote:
>
>> It seems there is a problem with the gretl menu fonts in Windows (at least
>> in
>> XP, with the current snapshot). The changes via "Tools/Preferences/Menu
>> fonts" are not being activated.
> I see what you mean, but I think we should probably get rid of that
> menu item on Windows rather than trying to "fix" it. Gretl is
> supposed to respect the choice of application font set via the
> Windows control panel. Is there a particular reason why you want to
> override that?
I don't want to override anything.
Well, actually you do ;-)
It is rather practical when you are using a proyector for
example, for teaching, because this allows to enlarge the
font or put it in bold for better viewing.
And that's a fair reason for wanting to override the default
Windows font. So I'll try to get that option working again.
Allin
7:33 p.m.
New subject: menu fonts
Ignacio wrote, re. changing the gretl menu font independently
of the system menu font on Windows:
> It is rather practical when you are using a proyector for
example, for
> teaching, because this allows to enlarge the font or put it in bold for
> better viewing.
OK, I have now reinstated the old behavior on Windows. That
is, you get a working selector for the menu font if and only
if you have deselected "Emulate Windows look" under general
preferences.
It may be possible to support menu font selection even when
emulation of the "Windows look" is in force (which looks very
much better on recent Windows), but I haven't yet found a way
of doing that.
Allin
11:32 p.m.
New subject: menu fonts
On Mon, 10 Jun 2013, Riccardo (Jack) Lucchetti wrote:
On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
> On 08/06/13 01:47, Allin Cottrell wrote:
>> On Fri, 7 Jun 2013, Ignacio Diaz-Emparanza wrote:
>>
>>> It seems there is a problem with the gretl menu fonts in Windows (at
>>> least in
>>> XP, with the current snapshot). The changes via "Tools/Preferences/Menu
>>> fonts" are not being activated.
>> I see what you mean, but I think we should probably get rid of that
>> menu item on Windows rather than trying to "fix" it. Gretl is
>> supposed to respect the choice of application font set via the
>> Windows control panel. Is there a particular reason why you want to
>> override that?
>>
>> Allin
>
> I don't want to override anything. This was a feature of gretl for Windows
> until recently (and it is on Linux). It is rather practical when you are
> using a proyector for example, for teaching, because this allows to enlarge
> the font or put it in bold for better viewing. Some colleagues here were
> missing that. I have also used it several times and would vote for
> maintaining if not very complicated.
There are many people (including myself) who like to be able to set gretl
fonts larger than usual when you teach in large rooms and students in the
back can't see the screen well.
Unfortunately, it looks as if somebody at Microsoft assumes that the user
values consistency across applications more than any other thing ("user
experience", they call it), so they simply took away from the programmers the
ability to change menu fonts on a per-application basis.
I'm as ready to slag off Microsoft as the next guy, but actually I
think in this case it's the GTK theming apparatus that's at fault.
For some reason, if (and only if) you invoke the "MS-Windows" GTK
theme it becomes impossible to change the application font. I guess
the problem must lie somewhere in the libwimp code (wimp = "Windows
Impersonator").
Allin
7:41 a.m.
New subject: error creating a package
On 10/06/13 16:46, Allin Cottrell wrote:
On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
> I am creating a new function package and I have this error:
>
> "Value "bundle" for attribute type of param is not among the
enumerated set"
>
> what does it mean? I see no problem then with the created package, it seems
> to work correctly.
It means you have a function that takes a straight bundle
argument rather than a bundle-pointer argument. That's
allowed, though it's not what you'd usually want to do. The
reason you saw that message is that the document type
definition for gretl packages, gretlfunc.dtd, did not include
the straight bundle type as a recognized parameter type. I've
now fixed that in CVS.
Well, I think it was an error in my function which should
have a
bundle-pointer argument.
I did not understand the message.
Thanks.
--
Firma Arista
*Ignacio Díaz-Emparanza*
Zuzendaria/Director
ignacio.diaz-emparanza(a)ehu.es <mailto:ignacio.diaz.emparanza@ehu.es>
94 6013732
*EKONOMIA APLIKATUA III SAILA (EKONOMETRIA ETA ESTATISTIKA)/
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU*
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
*T.: +34 946013740* | *F.: +34 946013754*
*www.ea3.ehu.es* <http://www.ea3.ehu.es>
ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezuak badu bere hartzailea. Okerreko helbidera heldu bada
(helbidea gaizki idatzi, transmisioak huts egin) eman abisu igorleari,
korreo honi erantzunda. Kontuz! Mezua ez bada zuretzat, ez erabili, ez
zabaldu beste inori, ez kopiatu eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial
a la que sólo tiene derecho a acceder el destinatario. Si usted lo
recibe por error le agradeceríamos que no hiciera uso de la información
y que se pusiese en contacto con el remitente.
E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.
12:52 p.m.
New subject: error creating a package
On Tue, 11 Jun 2013, Ignacio Diaz-Emparanza wrote:
On 10/06/13 16:46, Allin Cottrell wrote:
> On Mon, 10 Jun 2013, Ignacio Diaz-Emparanza wrote:
>
>> I am creating a new function package and I have this error:
>>
>> "Value "bundle" for attribute type of param is not among the
enumerated
>> set"
>>
>> what does it mean? I see no problem then with the created package, it
>> seems
>> to work correctly.
> It means you have a function that takes a straight bundle
> argument rather than a bundle-pointer argument. That's
> allowed, though it's not what you'd usually want to do. The
> reason you saw that message is that the document type
> definition for gretl packages, gretlfunc.dtd, did not include
> the straight bundle type as a recognized parameter type. I've
> now fixed that in CVS.
Well, I think it was an error in my function which should have a
bundle-pointer argument.
I did not understand the message.
The message was a bit obscure, agreed. It came from libxml,
not gretl itself.
Allin
4:21 p.m.
New subject: menu fonts
On Mon, 10 Jun 2013, Allin Cottrell wrote:
Ignacio wrote, re. changing the gretl menu font
independently of the system menu font on Windows:
>> It is rather practical when you are using a proyector for
>> example, for teaching, because this allows to enlarge the
>> font or put it in bold for better viewing.
OK, I have now reinstated the old behavior on Windows. That
is, you get a working selector for the menu font if and only
if you have deselected "Emulate Windows look" under general
preferences.
You also now have an option to reset the font to the Windows
default, which may be handly after setting an ad hoc font for
display purposes.
It may be possible to support menu font selection even when
emulation of the "Windows look" is in force (which looks
very much better on recent Windows), but I haven't yet found
a way of doing that.
It turns out that offering a choice of menu font in gretl when
the GTK "MS-Windows" theme is in force (which is the effect of
gretl's "Emulate Windows look" option) is not a practical
possibility. This theme (reasonably enough) hands off control
over fonts to Windows itself so you'd have to use the Windows
control panel in that case.
Allin
3972
days inactive
3989
days old
28 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Riccardo (Jack) Lucchetti -
Sven Schreiber