12:30 p.m.
Dear all,
Below is a script illustrating the problem
# creates list of all global series
function list fun1(void)
list retlist = seq(1,$nvars-1)
return retlist
end function
# identity list function
function list fun2(list a_list)
return a_list
end function
# checking function
function void fu(string name)
catch eval @name
err = $error
if err
printf "Variable %s is not defined\n", name
endif
end function
#contaminating function
function void spoil(void)
list list1 = fun1()
list list2 = fun2(list1)
end function
###### example
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil()
# after
fu("x1")
On the first run fu("x1") does not know
global series 'x1' but after running spoil()
fu("x1") knows and evaluates x1
Oleh
1:49 p.m.
Am 13.10.2018 um 14:30 schrieb oleg_komashko(a)ukr.net:
On the first run fu("x1") does not know
global series 'x1' but after running spoil()
fu("x1") knows and evaluates x1
Hi Oleh, good to hear from you again -- could you please explicit what
kind of behavior you are expecting instead? I _think_ I might know what
your problem is, but I don't want to speculate too much.
thanks,
sven
2:13 p.m.
Dear Sven,
The behavior I expect is always
output "Variable x1 is not defined"
The problem with spoil()
is after running it x1 is visible
from inside any user-specified
function, e.g.
append to the previous script and run
function void fun4(void)
matrix x1 = 1
eval sin(x1)
end function
fun4()
After running spoil() output will be
? fun4()
The variable x1 is of type series, not acceptable in context
*** error in function fun4, line 1
matrix x1 = 1
Error executing script: halting
fun4()
Oleh
13 жовтня 2018, 16:49:35, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 13.10.2018 um 14:30 schrieb oleg_komashko(a)ukr.net:
>
>
> On the first run fu("x1") does not know
> global series 'x1' but after running spoil()
> fu("x1") knows and evaluates x1
>
> it what kind of behavior you are expecting instead? I _think_ I might know what your
problem is, but I don't want to speculate too much.
>
> thanks,
> sven
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
7:18 a.m.
Dear Sven,
The ultimate cause of the problem
is in
list retlist = seq(1,$nvars-1)
But it does not shows before
running some list functions
inside another function
The problem was found in my a_eff
but it is very long
and I spent much time before
invented this minimal example
Oleh
13 жовтня 2018, 22:08:00, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 13.10.2018 um 16:13 schrieb oleg_komashko(a)ukr.net:
> Dear Sven,
> The behavior I expect is always
> output "Variable x1 is not defined"
> The problem with spoil()
> is after running it x1 is visible
> from inside any user-specified
> function, e.g.
> ______________
> _________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
11:08 a.m.
New subject: global series ... further examples
Dear all,
spoil1() and spoil3() functions are
somewhat more simple than spoil()
spoil2() and spoil4() differ from
spoil1() and spoil3() respectfully
by calling fun20() which does nothing!
<hansl
# creates list of all global series
function list fun1(void)
list retlist = seq(1,$nvars-1)
return retlist
end function
# identity list function
function list fun2(list a_list)
return a_list
end function
function void fun20(list a_list)
print ""
end function
# checking function
function void fu(string name)
catch eval @name
err = $error
if err
printf "Variable %s is not defined\n", name
endif
end function
function void fun4(void)
matrix x1 = 1
eval sin(x1)
end function
#(non)contaminating functions
function void spoil(void)
list list1 = fun1()
list list2 = fun2(list1)
end function
function void spoil1(void)
list list1 = fun1()
fun20(list1)
end function
function void spoil2(void)
list list1 = fun1()
end function
function void spoil3(void)
list a_list = seq(1,$nvars-1)
fun20(a_list)
end function
function void spoil4(void)
list a_list = seq(1,$nvars-1)
end function
###### examples
# contamination
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil()
# after
fu("x1")
fun4()
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil1()
# after
fu("x1")
# non-contamination
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil2()
# after
fu("x1")
/*
function void fun20(list a_list)
print ""
end function
function void spoil1(void)
list list1 = fun1()
fun20(list1)
end function
function void spoil2(void)
list list1 = fun1()
end function
*/
# So spoil1() causes contamination,
# but spoil2() does not!
# the only difference betwwen them
# is
# calling fun20(list1) but
# fun20() actually does nothing!
# contamination
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil3()
# after
fu("x1")
# non-contamination
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil4()
# after
fu("x1")
/*
function void fun20(list a_list)
print ""
end function
function void spoil3(void)
list a_list = seq(1,$nvars-1)
fun20(a_list)
end function
function void spoil4(void)
list a_list = seq(1,$nvars-1)
end function
*/
# So spoil3() causes contamination,
# but spoil4() does not!
# Again, the only difference betwwen them
# is
# calling fun20(list1) but
# fun20() actually does nothing!
hansl>
Oleh
7:46 p.m.
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear all,
Below is a script illustrating the problem
# creates list of all global series
function list fun1(void)
list retlist = seq(1,$nvars-1)
return retlist
end function
# identity list function
function list fun2(list a_list)
return a_list
end function
# checking function
function void fu(string name)
catch eval @name
err = $error
if err
printf "Variable %s is not defined\n", name
endif
end function
#contaminating function
function void spoil(void)
list list1 = fun1()
list list2 = fun2(list1)
end function
###### example
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil()
# after
fu("x1")
On the first run fu("x1") does not know
global series 'x1' but after running spoil()
fu("x1") knows and evaluates x1
Thanks, Oleh. I see what the problem is here and I have an idea of how
to fix it, but I can't work on it until tomorrow.
Allin
8:05 p.m.
It's very nice.
a_eff is both my favorite
and the largest package.
Without fixing it I
would have to use a roundabout
with a sizable worsening
of syntax
Oleh
14 жовтня 2018, 22:47:01, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Dear all,
> Below is a script illustrating the problem
>
>
> # creates list of all global series
> function list fun1(void)
> list retlist = seq(1,$nvars-1)
> return retlist
> end function
> # identity list function
> function list fun2(list a_list)
> return a_list
> end function
> # checking function
> function void fu(string name)
> catch eval @name
> err = $error
> if err
> printf "Variable %s is not defined\n", name
> endif
>
> end function
>
> #contaminating function
>
> function void spoil(void)
> list list1 = fun1()
> list list2 = fun2(list1)
> end function
>
> ###### example
>
> nulldata 20
> set seed 13
> x1 = normal()
> # before
> fu("x1")
> # looking at x1
> print x1
>
> # spoiling
> spoil()
> # after
> fu("x1")
>
>
> On the first run fu("x1") does not know
> global series 'x1' but after running spoil()
> fu("x1") knows and evaluates x1
Thanks, Oleh. I see what the problem is here and I have an idea of how
to fix it, but I can't work on it until tomorrow.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
10:04 a.m.
On Sun, 14 Oct 2018, oleg_komashko(a)ukr.net wrote:
It's very nice.
a_eff is both my favorite
and the largest package.
Without fixing it I
would have to use a roundabout
with a sizable worsening
of syntax
Oleh: I reckon that you may want to take a new look at some parts of your
a_eff package and use a feature that (if all goes well) will be part of
the next release, that is the "feval()" function. This is going to be one
of the most fragile functions we have in Hansl, and debugging will never
be enough; but once it's sorted out properly, it'll be very handy to have
IMO.
Example (needs current git):
<hansl>
f = "log"
eval feval(f, seq(1,3))
<hansl>
yields
<output>
? eval feval(f, seq(1,3))
0.0000 0.69315 1.0986
</output>
PS: we're all delighted to have you back!
-------------------------------------------------------
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:29 a.m.
I'll look at it somewhat later
Now I want to know what will be the
solution of "penetration" problem,
since right now the package causes
"penetrating": should I make
some roundabouts or all would be ok
as is
Anyway, I have included heckit so
I want to update the package as soon as
"penetrating" problem will be solved
I use @ frequently but have not detected
any problems insofar
The ultimate cause of "penetrating"
is in using list a_list = seq(1,$nvars - 1)
More clear examples are under
"Re: [Gretl-devel] global series ... further examples"
Oleh
15 жовтня 2018, 13:05:03, від "Riccardo (Jack) Lucchetti"
<r.lucchetti(a)univpm.it>:
On Sun, 14 Oct 2018, oleg_komashko(a)ukr.net wrote:
> It's very nice.
> a_eff is both my favorite
> and the largest package.
> Without fixing it I
> would have to use a roundabout
> with a sizable worsening
> of syntax
Oleh: I reckon that you may want to take a new look at some parts of your
a_eff package and use a feature that (if all goes well) will be part of
the next release, that is the "feval()" function. This is going to be one
of the most fragile functions we have in Hansl, and debugging will never
be enough; but once it's sorted out properly, it'll be very handy to have
IMO.
Example (needs current git):
<hansl>
f = "log"
eval feval(f, seq(1,3))
<hansl>
yields
<output>
? eval feval(f, seq(1,3))
0.0000 0.69315 1.0986
</output>
PS: we're all delighted to have you back!
-------------------------------------------------------
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
-------------------------------------------------------
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
12:36 p.m.
On Mon, 15 Oct 2018, oleg_komashko(a)ukr.net wrote:
I'll look at it somewhat later
OK. By the way: there's a function in a_eff that can be re-implemented a
little more efficiently as follows:
<hansl>
function string repchar(string char, int n)
fmt = sprintf("%%%ds", n)
return strsub(sprintf(fmt, " "), " ", char[1])
end function
</hansl>
Perhaps we could include it in the "extra" package. What do you think,
Sven?
-------------------------------------------------------
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:25 p.m.
On Mon, 15 Oct 2018, oleg_komashko(a)ukr.net wrote:
Now I want to know what will be the
solution of "penetration" problem,
since right now the package causes
"penetrating" [...]
The problem is now solved, without totally banning access, within a
function, to series other than those provided to the function via
arguments. Such access is not at all encouraged but it is tolerated,
and its potentially bad consequences for the global namespace are
guarded against.
At least I think that's the case. If you're able to come up with an
example that causes trouble in current git, please let us know!
Allin
9:43 p.m.
Happy coincidence!
I send an example before reading
your message
Oleh
19 жовтня 2018, 00:25:32, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Mon, 15 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Now I want to know what will be the
> solution of "penetration" problem,
> since right now the package causes
> "penetrating" [...]
The problem is now solved, without totally banning access, within a
function, to series other than those provided to the function via
arguments. Such access is not at all encouraged but it is tolerated,
and its potentially bad consequences for the global namespace are
guarded against.
At least I think that's the case. If you're able to come up with an
example that causes trouble in current git, please let us know!
Allin
10:04 p.m.
On Fri, 19 Oct 2018, oleg_komashko(a)ukr.net wrote:
Happy coincidence!
I send an example before reading
your message
Indeed!
But the "minor problem" remaining (per your example) is actually not
a problem.
As you say, the series "ser", created within a function, "has
penetrated into global data set" -- but it has penetrated in a
legitimate manner since it's a member of a list returned by the
function spoil300 and accepted by the caller via assignment.
If the caller did not assign the return value from that function,
"ser" would be destroyed on exit and would not feature in the global
data set.
Allin
5:01 a.m.
I see,
Oleh
P.S. I think updating a_eff
and lagreg should go with 2018d
as minimal version, despite
the both home versions sample
scripts works on 2018c
What is your opinion
19 жовтня 2018, 01:04:31, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Fri, 19 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Happy coincidence!
> I send an example before reading
> your message
Indeed!
But the "minor problem" remaining (per your example) is actually not
a problem.
As you say, the series "ser", created within a function, "has
penetrated into global data set" -- but it has penetrated in a
legitimate manner since it's a member of a list returned by the
function spoil300 and accepted by the caller via assignment.
If the caller did not assign the return value from that function,
"ser" would be destroyed on exit and would not feature in the global
data set.
Allin
6:59 a.m.
Am 19.10.2018 um 07:01 schrieb oleg_komashko(a)ukr.net:
P.S. I think updating a_eff
and lagreg should go with 2018d
as minimal version, despite
the both home versions sample
scripts works on 2018c
What is your opinion
Can you give an example of what does not work with 2018c?
thanks,
sven
9:05 a.m.
> the both home versions sample
> scripts WORKS on 2018c
The difference between 2018c
and today's git and snapshot
is :
git: a_eff and lagreg work and cause no problems
2018c : they work but cause "penetration"
Oleh
19 жовтня 2018, 09:59:17, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 19.10.2018 um 07:01 schrieb oleg_komashko(a)ukr.net:
>
> P.S. I think updating a_eff
> and lagreg should go with 2018d
> as minimal version, despite
> the both home versions sample
> scripts works on 2018c
> What is your opinion
>
> r/>
> _______________________________________________
> Gretl-devel mailing list
> Gretl-devel(a)lists.wfu.edu
> http://lists.wfu.edu/mailman/listinfo/gretl-devel
>
9:18 a.m.
Am 19.10.2018 um 11:05 schrieb oleg_komashko(a)ukr.net:
>> the both home versions sample
>> scripts WORKS on 2018c
The difference between 2018c
and today's git and snapshot
is :
git: a_eff and lagreg work and cause no problems
2018c : they work but cause "penetration"
In this case I would tend to leave the requirement at something <=
2018c. Depending on how serious you think this spillover into the global
scope is (what you called "penetration"), you could issue a clear
warning to the users, for example in the help text and/or in the printout.
For the printout, you could check the gretl version like this:
if $version < 20183 # earlier than 2018d
print "watch it!" # the warning (not this one!)
endif
thanks,
sven
9:30 a.m.
Dear Sven,
Absolutely agree
I have came to very similar idea
I'll insert if by $version
with a warning and an additional note
into help files for 2018c
Anyway the current server versions lead
to "penetration" and have additional
things which are corrected and/or improved
I think I'll be ready to upload on Sunday
or Saturday
Oleh
19 жовтня 2018, 12:18:42, від "Sven Schreiber" <svetosch(a)gmx.net>:
Am 19.10.2018 um 11:05 schrieb oleg_komashko(a)ukr.net:
> > > the both home versions sample
> > > scripts WORKS on 2018c
> > > lockquote>
> > > The difference between 2018c
> > > and today's git and snapshot
> > > is :
> > > git: a_eff and lagreg work and cause no problems
> > > 2018c : they work but cause "penetration"
> > > ent at something <= 2018c. Depending on how serious you think this
spillover into the global scope is (what you called "penetration"), you could
issue a clear warning to the users, for example in the help text and/or in the printout.
> > >
> > > For the printout, you could check the gretl version like this:
> > > if $version < 20183 # earlier than 2018d
> > > print "watch it!" # the warning (not this one!)
> > > endif
> > >
> > > thanks,
> > > sven
> > >
> > > _______________________________________________
> > > Gretl-devel mailing list
> > > Gretl-devel(a)lists.wfu.edu
> > > http://lists.wfu.edu/mailman/listinfo/gretl-devel
> > >
9:07 a.m.
New subject: global series penetrating... missing "series ID N is out of bounds" diagnostics
nulldata 100
x = normal()
y = normal()
function void crash(void)
list z = seq(1,4)
end function
# list from vector: series ID 4 is out of bounds
# as should be
list z = seq(1,100)
# crach
crash()
Oleh
19 жовтня 2018, 01:04:31, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Fri, 19 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Happy coincidence!
> I send an example before reading
> your message
Indeed!
But the "minor problem" remaining (per your example) is actually not
a problem.
As you say, the series "ser", created within a function, "has
penetrated into global data set" -- but it has penetrated in a
legitimate manner since it's a member of a list returned by the
function spoil300 and accepted by the caller via assignment.
If the caller did not assign the return value from that function,
"ser" would be destroyed on exit and would not feature in the global
data set.
Allin
1:16 p.m.
New subject: global series penetrating... missing "series ID N is out of bounds" diagnostics
On Fri, 19 Oct 2018, oleg_komashko(a)ukr.net wrote:
nulldata 100
x = normal()
y = normal()
function void crash(void)
list z = seq(1,4)
end function
# list from vector: series ID 4 is out of bounds
# as should be
list z = seq(1,100)
# crach
crash()
Thanks. That was a newly introduced bug, now fixed in git.
Allin
9:26 p.m.
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear all,
Below is a script illustrating the problem
# creates list of all global series
function list fun1(void)
list retlist = seq(1,$nvars-1)
return retlist
end function
# identity list function
function list fun2(list a_list)
return a_list
end function
# checking function
function void fu(string name)
catch eval @name
err = $error
if err
printf "Variable %s is not defined\n", name
endif
end function
#contaminating function
function void spoil(void)
list list1 = fun1()
list list2 = fun2(list1)
end function
###### example
nulldata 20
set seed 13
x1 = normal()
# before
fu("x1")
# looking at x1
print x1
# spoiling
spoil()
# after
fu("x1")
On the first run fu("x1") does not know
global series 'x1' but after running spoil()
fu("x1") knows and evaluates x1
Thanks for the report. The primary source of mischief here is the
ability, within a function, to create a list that includes series
that were not given as arguments in any shape or form (neither as
"pointer"-form series arguments nor as members of a list argument),
by the simple expedient of referring to the series by their ID
numbers -- with the $nvars accessor providing a handy upper bound!
I've been aware of this possibility for a while but I didn't think
it was a high priority for fixing, since it seemed excessively
"tricksy" and unlikely to arise in practice.
Now it has if fact arisen, the loophole is closed in git. You can
now put into a list by ID number only series that satisfy one of
these criteria:
1. the series was given to the function via a "pointer-to-series"
argument,
2. the series was given to the function as a member of a list
argument, or
3. the series was newly defined after the function began executing.
This means that the statement in fun1() above,
list retlist = seq(1,$nvars-1)
will fail right away (since fun1 is not passed any arguments, let
alone references to series), and therefore the mischief will not get
started.
Allin
10:58 p.m.
Dear Allin,
This is the way I was afraid of the most.
Is it possible to have some substitute?
Say, getvalues(int ID) similar to getinfo()?
Oleh
16 жовтня 2018, 00:26:56, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Dear all,
> Below is a script illustrating the problem
>
> # creates list of all global series
> function list fun1(void)
> list retlist = seq(1,$nvars-1)
> return retlist
> end function
> # identity list function
> function list fun2(list a_list)
> return a_list
> end function
> # checking function
> function void fu(string name)
> catch eval @name
> err = $error
> if err
> printf "Variable %s is not defined\n", name
> endif
> end function
>
> #contaminating function
>
> function void spoil(void)
> list list1 = fun1()
> list list2 = fun2(list1)
> end function
>
> ###### example
>
> nulldata 20
> set seed 13
> x1 = normal()
> # before
> fu("x1")
> # looking at x1
> print x1
>
> # spoiling
> spoil()
> # after
> fu("x1")
>
>
> On the first run fu("x1") does not know
> global series 'x1' but after running spoil()
> fu("x1") knows and evaluates x1
Thanks for the report. The primary source of mischief here is the
ability, within a function, to create a list that includes series
that were not given as arguments in any shape or form (neither as
"pointer"-form series arguments nor as members of a list argument),
by the simple expedient of referring to the series by their ID
numbers -- with the $nvars accessor providing a handy upper bound!
I've been aware of this possibility for a while but I didn't think
it was a high priority for fixing, since it seemed excessively
"tricksy" and unlikely to arise in practice.
Now it has if fact arisen, the loophole is closed in git. You can
now put into a list by ID number only series that satisfy one of
these criteria:
1. the series was given to the function via a "pointer-to-series"
argument,
2. the series was given to the function as a member of a list
argument, or
3. the series was newly defined after the function began executing.
This means that the statement in fun1() above,
list retlist = seq(1,$nvars-1)
will fail right away (since fun1 is not passed any arguments, let
alone references to series), and therefore the mischief will not get
started.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2:03 p.m.
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
Dear Allin,
This is the way I was afraid of the most.
Is it possible to have some substitute?
Say, getvalues(int ID) similar to getinfo()?
Context: Oleh pointed out that it's possible, within a function, to
reference series that were not "given to" the function via any
argument (by using numeric series IDs). This breaks the encapsulation
or modularity that hansl functions are supposed to exhibit, and under
certain conditions can thoroughly muddle the "main" and function
namespaces such that (for example) it becomes impossible to define a
matrix "x" within a function if there already exists a series "x" at
the main level of a script.
My first thought for fixing this (now in git) was to limit access to
series IDs within functions: the function gets to "see" only the IDs
of series that were passed via a series-pointer argument or as members
of a list argument. I messed this up at first, forgetting to allow
universal access to series 0 ("const"), but after Oleh's reminder
that's now fixed in git.
Now Oleh implies that this change will break some of his functions.
I'm willing to consider an alternative fix but I think we need to be
clear on the rationale for allowing access to series not given to a
function via arguments. (I take it that is what Oleh wants.)
Allin
2:34 p.m.
Am 16.10.2018 um 16:03 schrieb Allin Cottrell:
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Dear Allin,
> This is the way I was afraid of the most.
> Is it possible to have some substitute?
> Say, getvalues(int ID) similar to getinfo()?
My first thought for fixing this (now in git) was to limit access to
series IDs within functions: the function gets to "see" only the IDs
of series that were passed via a series-pointer argument or as members
of a list argument.
I think this was the correct fix, because the other trick was against
the rules.
Now Oleh implies that this change will break some of his functions.
I'm willing to consider an alternative fix but I think we need to be
clear on the rationale for allowing access to series not given to a
function via arguments. (I take it that is what Oleh wants.)
I agree, in the sense that I think such a rationale must be very strong
if the important principle of function encapsulation were to be weakened.
Also it seems to me that the relatively recent possibility to add lists
to bundles makes it easier to have quasi-global availability of a list
(and its series members): just pass the bundle around to the "children"
functions. Another possibility might be to copy the contents (values,
numbers) to a matrix and pass the matrix around.
So, maybe we can help with coming up with alternative solutions for the
need to have "global" access.
cheers,
sven
3:04 p.m.
On Tue, 16 Oct 2018, Sven Schreiber wrote:
Am 16.10.2018 um 16:03 schrieb Allin Cottrell:
> On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
>
>> Dear Allin,
>> This is the way I was afraid of the most.
>> Is it possible to have some substitute?
>> Say, getvalues(int ID) similar to getinfo()?
>
> My first thought for fixing this (now in git) was to limit access to series
> IDs within functions: the function gets to "see" only the IDs of series
> that were passed via a series-pointer argument or as members of a list
> argument.
I think this was the correct fix, because the other trick was against the
rules.
> Now Oleh implies that this change will break some of his functions. I'm
> willing to consider an alternative fix but I think we need to be clear on
> the rationale for allowing access to series not given to a function via
> arguments. (I take it that is what Oleh wants.)
I agree, in the sense that I think such a rationale must be very strong if
the important principle of function encapsulation were to be weakened.
I agree with Sven 100%.
The policy of function encapsulation must be kept at all costs (ok, with
the obvious exception of "const" and "time", that are generated on the
fly (actually, the same would hold for seasonal dummies as well, but we
doi have the seasonals() function for that).
If enforcing the principle with consistency breaks a package, I'm sorry,
but it's the lesser of two evils. A package can always be updated with
little difficulty.
-------------------------------------------------------
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
-------------------------------------------------------
7:12 p.m.
On Tue, 16 Oct 2018, Riccardo (Jack) Lucchetti wrote:
On Tue, 16 Oct 2018, Sven Schreiber wrote:
> Am 16.10.2018 um 16:03 schrieb Allin Cottrell:
>> On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
>>
>>> Dear Allin,
>>> This is the way I was afraid of the most.
>>> Is it possible to have some substitute?
>>> Say, getvalues(int ID) similar to getinfo()?
>
>>
>> My first thought for fixing this (now in git) was to limit access to
>> series IDs within functions: the function gets to "see" only the IDs of
>> series that were passed via a series-pointer argument or as members of a
>> list argument.
>
> I think this was the correct fix, because the other trick was against the
> rules.
>
>> Now Oleh implies that this change will break some of his functions. I'm
>> willing to consider an alternative fix but I think we need to be clear on
>> the rationale for allowing access to series not given to a function via
>> arguments. (I take it that is what Oleh wants.)
>
> I agree, in the sense that I think such a rationale must be very strong if
> the important principle of function encapsulation were to be weakened.
I agree with Sven 100%.
The policy of function encapsulation must be kept at all costs (ok, with the
obvious exception of "const" and "time", that are generated on the
fly
(actually, the same would hold for seasonal dummies as well, but we doi have
the seasonals() function for that).
If enforcing the principle with consistency breaks a package, I'm sorry, but
it's the lesser of two evils. A package can always be updated with little
difficulty.
I agree too, but we'll need a transitional period.
Here's one reason why (perhaps it's the only reason). My recent
restriction on access to series within functions was too restrictive
in that it did not give access to series that are members of a list
passed as a bundle-member (as Oleh pointed out).
Now I'm not 100% sure what is "right" in that context but it's clear
that (a) we can't just close down such access (that would break 14
function packages) and (b) it won't be a trivial matter to get the
handling of bundle-member lists sorted out properly. So I think I have
to back off on the new restriction until the bundle-member case is
fully worked out and well tested.
Fortunately, I've seen a way to avoid the worst fall-out from
"penetration" in the meantime. As I pointed out in
http://lists.wfu.edu/pipermail/gretl-devel/2018-October/009108.html
the real trouble occurs when series that belong in main get stuck with
a "stack level" > 0 when function-execution terminates. So here's a
suitable hack: whenever we exit back to main, run a little loop that
puts all series back to level 0.
The point is that any "surviving" series (i.e., not local to any
function, and therefore destroyed on exit) that have level > 0 can
only have got into that state via the mess-up Oleh identified; they
must really belong in main.
Allin
9:18 a.m.
I have noticed that only user-specified
functions have this effect:
function scalar mynelem (list alist)
return nelem(alist)
end function
function void spoil100(bundle *b)
s = nelem(b.xlist)
end function
function void spoil200(bundle *b)
s = mynelem(b.xlist)
end function
function void fu(string name)
catch eval @name
end function
nulldata 20
set seed 13
y = normal()
x1 = normal()
x2 = normal()
bundle bu
list bu.xlist = x1 x2
fu("x1")
fu("x2")
fu("y")
# no effect
spoil100(&bu)
fu("x1")
fu("x2")bewtween
fu("y")
# "penetrating" the only difference
# between spoil100 and spoil200 is in
# using user-specified mynelem and
# the native nelem; with mynelem
# being just wrapper over nelem
spoil200(&bu)
fu("x1")
fu("x2")
fu("y")
Oleh
11:25 p.m.
It seems the prohibition should not include const:
open greene5_1.gdt -q
function void fun20(list ylist, list xlist)
list zlist = const xlist
ols ylist const zlist
end function
fun20(realcons, realgdp)
Oleh
16 жовтня 2018, 00:26:56, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Dear all,
> Below is a script illustrating the problem
>
> # creates list of all global series
> function list fun1(void)
> list retlist = seq(1,$nvars-1)
> return retlist
> end function
> # identity list function
> function list fun2(list a_list)
> return a_list
> end function
> # checking function
> function void fu(string name)
> catch eval @name
> err = $error
> if err
> printf "Variable %s is not defined\n", name
> endif
> end function
>
> #contaminating function
>
> function void spoil(void)
> list list1 = fun1()
> list list2 = fun2(list1)
> end function
>
> ###### example
>
> nulldata 20
> set seed 13
> x1 = normal()
> # before
> fu("x1")
> # looking at x1
> print x1
>
> # spoiling
> spoil()
> # after
> fu("x1")
>
>
> On the first run fu("x1") does not know
> global series 'x1' but after running spoil()
> fu("x1") knows and evaluates x1
Thanks for the report. The primary source of mischief here is the
ability, within a function, to create a list that includes series
that were not given as arguments in any shape or form (neither as
"pointer"-form series arguments nor as members of a list argument),
by the simple expedient of referring to the series by their ID
numbers -- with the $nvars accessor providing a handy upper bound!
I've been aware of this possibility for a while but I didn't think
it was a high priority for fixing, since it seemed excessively
"tricksy" and unlikely to arise in practice.
Now it has if fact arisen, the loophole is closed in git. You can
now put into a list by ID number only series that satisfy one of
these criteria:
1. the series was given to the function via a "pointer-to-series"
argument,
2. the series was given to the function as a member of a list
argument, or
3. the series was newly defined after the function began executing.
This means that the statement in fun1() above,
list retlist = seq(1,$nvars-1)
will fail right away (since fun1 is not passed any arguments, let
alone references to series), and therefore the mischief will not get
started.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
12:04 a.m.
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
It seems the prohibition should not include const:
open greene5_1.gdt -q
function void fun20(list ylist, list xlist)
list zlist = const xlist
ols ylist const zlist
end function
fun20(realcons, realgdp)
Yes, you're right; that's now fixed in git.
Allin
2:40 a.m.
List components of bundles are non-usable:
nulldata 20
y = normal()
x = normal()
ols y 0 x
mod = $model
function void fun7(bundle *b)
list xx = b.xlist
end function
fun7(&mod)
This did not caused "penetration"
before "prohibition"
Oleh
16 жовтня 2018, 03:04:55, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
> It seems the prohibition should not include const:
>
> open greene5_1.gdt -q
> function void fun20(list ylist, list xlist)
> list zlist = const xlist
> ols ylist const zlist
> end function
> fun20(realcons, realgdp)
Yes, you're right; that's now fixed in git.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2:08 p.m.
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
List components of bundles are non-usable:
nulldata 20
y = normal()
x = normal()
ols y 0 x
mod = $model
function void fun7(bundle *b)
list xx = b.xlist
end function
fun7(&mod)
This did not caused "penetration"
before "prohibition"
OK, I see what you mean. That needs to be fixed.
Allin
4:01 p.m.
On Tue, 16 Oct 2018, oleg_komashko(a)ukr.net wrote:
List components of bundles are non-usable:
nulldata 20
y = normal()
x = normal()
ols y 0 x
mod = $model
function void fun7(bundle *b)
list xx = b.xlist
end function
fun7(&mod)
This did not caused "penetration"
before "prohibition"
Actually it did support penetration, you just had to pass the bundled
list on to another function. Here's an example:
<hansl>
function void F2 (list L)
print "Trouble in store!"
end function
function void F1 (bundle *b)
matrix x = I(3)
F2(b.xlist)
end function
nulldata 20
y = normal()
x = normal()
ols y 0 x
mod = $model
F1(&mod) # OK, or so it seems
F1(&mod) # broken on second call
</hansl>
(Note: this won't run on current git without reverting the new guard
against ID theft.)
Here's what's happening. When you pass a list to a function, the
member series have their "stack level" temporarily incremented so
they're accessible within the function. Then on exit from the function
the stack level is decremented so the series "go back to where they
really belong."
Suppose function F1 "steals" a reference to some series at main level
rather than coming by it honestly via an argument. F1 passes a stolen
list on to F2: the stack level of the members becomes 2. Then we
return to F1, and their stack level goes to 1. But it never goes back
to 0, as it should, because of course there's no record of F1 having
obtained a reference to the series from main.
In the case of a bundled list, it seems we'll have to treat that in
the same way as a plain list argument, which we have not been doing so
far: we need to create a record of origin of the member series.
Allin
11:42 p.m.
Even this!
function void fun30(list ylist, list xlist)
list zlist = ylist xlist
end function
list z = const realgdp
fun30(realcons, z)
? fun30(realcons, z)
Series 0 is not accessible
*** error in function fun30, line 1
list zlist = ylist xlist
Error executing script: halting
fun30(realcons, z)
Oleh
16 жовтня 2018, 00:26:56, від "Allin Cottrell" <cottrell(a)wfu.edu>:
On Sat, 13 Oct 2018, oleg_komashko(a)ukr.net wrote:
> Dear all,
> Below is a script illustrating the problem
>
> # creates list of all global series
> function list fun1(void)
> list retlist = seq(1,$nvars-1)
> return retlist
> end function
> # identity list function
> function list fun2(list a_list)
> return a_list
> end function
> # checking function
> function void fu(string name)
> catch eval @name
> err = $error
> if err
> printf "Variable %s is not defined\n", name
> endif
> end function
>
> #contaminating function
>
> function void spoil(void)
> list list1 = fun1()
> list list2 = fun2(list1)
> end function
>
> ###### example
>
> nulldata 20
> set seed 13
> x1 = normal()
> # before
> fu("x1")
> # looking at x1
> print x1
>
> # spoiling
> spoil()
> # after
> fu("x1")
>
>
> On the first run fu("x1") does not know
> global series 'x1' but after running spoil()
> fu("x1") knows and evaluates x1
Thanks for the report. The primary source of mischief here is the
ability, within a function, to create a list that includes series
that were not given as arguments in any shape or form (neither as
"pointer"-form series arguments nor as members of a list argument),
by the simple expedient of referring to the series by their ID
numbers -- with the $nvars accessor providing a handy upper bound!
I've been aware of this possibility for a while but I didn't think
it was a high priority for fixing, since it seemed excessively
"tricksy" and unlikely to arise in practice.
Now it has if fact arisen, the loophole is closed in git. You can
now put into a list by ID number only series that satisfy one of
these criteria:
1. the series was given to the function via a "pointer-to-series"
argument,
2. the series was given to the function as a member of a list
argument, or
3. the series was newly defined after the function began executing.
This means that the statement in fun1() above,
list retlist = seq(1,$nvars-1)
will fail right away (since fun1 is not passed any arguments, let
alone references to series), and therefore the mischief will not get
started.
Allin
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
2257
days inactive
2263
days old
33 comments
4 participants
participants (4)
-
Allin Cottrell -
oleg_komashko＠ukr.net -
Riccardo (Jack) Lucchetti -
Sven Schreiber