7:02 p.m.
Hi,
I'm trying (for a shiny new function package) to add a graph to the icon view/window
within a function context.
Example (with denmark.gdt):
function void myfunc(list mylist)
testgraph <- gnuplot mylist
end function
list mylist = LRM LRY
myfunc(mylist)
But this isn't working, it's only saving the gnuplot commands to a .plt file, as
if the "testgraph <-" part weren't there.
I understand that the inner scope of a function isn't supposed to affect the outer
scope; however, I think the functionality would be useful. But I admit it's probably
difficult to get this right conceptually, or isn't it?
thanks,
sven
12:03 a.m.
On Wed, 18 Nov 2009, Sven Schreiber wrote:
I'm trying (for a shiny new function package) to add a graph to
the icon view/window within a function context.
Example (with denmark.gdt):
function void myfunc(list mylist)
testgraph <- gnuplot mylist
end function
list mylist = LRM LRY
myfunc(mylist)
But this isn't working, it's only saving the gnuplot commands to
a .plt file, as if the "testgraph <-" part weren't there.
I understand that the inner scope of a function isn't supposed
to affect the outer scope; however, I think the functionality
would be useful. But I admit it's probably difficult to get this
right conceptually, or isn't it?
I'll have a think about it. But to push the question back: Do we
want functions to be able to do this sort of thing? (That is,
create named objects in the user's personal namespace without
getting the user's explicit consent in the form of assigning a
return value.) The question is not mean to be rhetorical; I'm not
sure what's right here.
Allin.
9:01 a.m.
>
> But this isn't working, it's only saving the gnuplot commands to
> a .plt file, as if the "testgraph <-" part weren't there.
>
> I understand that the inner scope of a function isn't supposed
> to affect the outer scope; however, I think the functionality
> would be useful. But I admit it's probably difficult to get this
> right conceptually, or isn't it?
I'll have a think about it. But to push the question back: Do we
want functions to be able to do this sort of thing? (That is,
create named objects in the user's personal namespace without
getting the user's explicit consent in the form of assigning a
return value.) The question is not mean to be rhetorical; I'm not
sure what's right here.
I agree, it's not clear at all. In a normal function context I'd say it's not
necessary, because you can run a script and in the top-level scope of your script do these
"<-" assignments easily (gnuplot or model table). The problem arises within
the package context, where everything is hidden from the user and should happen
automatically.
Maybe this is stretching the package thing too far; OTOH let me add some thoughts:
* Currently the function is doing *something* beyond its scope, namely writing a .plt file
to disk. And I don't think that's bad, because the automatically chosen name makes
reasonably sure it's not interfering with anything (I hope). Would it be so different
if the function adds something to the icon view, maybe using the same name scheme?
* The main reason I think the functionality is useful is because just having the .plt file
is not nearly as good as having the icon. If I (or a package user) could somehow import
the .plt file easily into gretl to get an icon with the associated possibility of GUI
tweaking the graph, then I would probably rest the case.
thanks for listening,
cheers,
sven
2:19 p.m.
On Thu, 19 Nov 2009, Sven Schreiber wrote:
> I'll have a think about it. But to push the question back:
Do we
> want functions to be able to do this sort of thing? (That is,
> create named objects in the user's personal namespace without
> getting the user's explicit consent in the form of assigning a
> return value.) The question is not mean to be rhetorical; I'm not
> sure what's right here.
>
I agree, it's not clear at all. In a normal function context I'd
say it's not necessary, because you can run a script and in the
top-level scope of your script do these "<-" assignments easily
(gnuplot or model table). The problem arises within the package
context, where everything is hidden from the user and should
happen automatically...
* The main reason I think the functionality is useful is because
just having the .plt file is not nearly as good as having the
icon. If I (or a package user) could somehow import the .plt
file easily into gretl to get an icon with the associated
possibility of GUI tweaking the graph, then I would probably
rest the case.
What about the possibility of supplying an optional string
argument? If the user gives a name for the graph, the function
saves it as an icon under that name, otherwise the graph is
skipped?
This still requires activating the "objectname <-" mechanism
inside functions, but that should be possible.
Allin
3:12 p.m.
-------- Original-Nachricht --------
Datum: Thu, 19 Nov 2009 09:19:38 -0500 (EST)
Von: Allin Cottrell <cottrell(a)wfu.edu>
An: Gretl development <gretl-devel(a)lists.wfu.edu>
Betreff: Re: [Gretl-devel] saving graphs to icons within functions
On Thu, 19 Nov 2009, Sven Schreiber wrote:
> > I'll have a think about it. But to push the question back: Do we
> > want functions to be able to do this sort of thing? (That is,
> > create named objects in the user's personal namespace without
> > getting the user's explicit consent in the form of assigning a
> > return value.) The question is not mean to be rhetorical; I'm not
> > sure what's right here.
> >
>
> I agree, it's not clear at all. In a normal function context I'd
> say it's not necessary, because you can run a script and in the
> top-level scope of your script do these "<-" assignments easily
> (gnuplot or model table). The problem arises within the package
> context, where everything is hidden from the user and should
> happen automatically...
>
> * The main reason I think the functionality is useful is because
> just having the .plt file is not nearly as good as having the
> icon. If I (or a package user) could somehow import the .plt
> file easily into gretl to get an icon with the associated
> possibility of GUI tweaking the graph, then I would probably
> rest the case.
What about the possibility of supplying an optional string
argument? If the user gives a name for the graph, the function
saves it as an icon under that name, otherwise the graph is
skipped?
This still requires activating the "objectname <-" mechanism
inside functions, but that should be possible.
Allin
You mean like
function void myfunc(string plotname)
plotname <- gnuplot <whatever>
end function
string ploticonname = "great plot"
myfunc(ploticonname)
?
That would be fine I guess, although of course it's abusing the string a little.
It's quite intransparent to the caller that it is actually granting access to the icon
view.
In principle (without saying that I'm suggesting this, just thinking out loud) a new
parameter type would be needed; matrices that are returned from functions are shoved into
the icon view, so are scalars and strings (?). Returned series (or lists of series) are
shoved into the workspace as well. What's missing is the possibility to
"return" a gnuplot plot from a function so that it get's added to the icon
view. Similar for models in the model table.
Let me get back one more time to the other idea: Wouldn't it be nice to be able to
load a .plt file into gretl's icon session view? Maybe then the
adding-to-icon-view-within-functions thing wouldn't be necessary. (Although strictly
speaking they are two different issues.)
thanks,
sven
5494
days inactive
5495
days old
4 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber