9:53 a.m.
I think something is wrong with the last changes.
On wednesday 19 I could run the attached scripts (with gretl for Windows)
without any problem, but on monday I installed the new Windows gretl snapshot
and today I obtained the same error as Sven mentioned: I get the beginning of
the .po file in the script output, and the error: "The systen cannot find the
specified file". I downloaded the current Windows snapshot, and now I do not
obtain the .po file in the script output, but the same error is displayed on
the screen, and the script aborted.
(Unluckily I did not save the gretl_install.exe file of the week before)
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
12:35 p.m.
New subject: Ignacio's tramo script
On Wed, 24 Jan 2007, Ignacio Díaz-Emparanza wrote:
On wednesday 19 I could run the attached scripts (with gretl for
Windows) without any problem, but on monday I installed the new
Windows gretl snapshot and today I obtained the same error as
Sven mentioned: I get the beginning of the .po file in the
script output, and the error: "The systen cannot find the
specified file". I downloaded the current Windows snapshot, and
now I do not obtain the .po file in the script output, but the
same error is displayed on the screen, and the script aborted.
At what point in execution does Windows say "The system cannot
find the specified file"?
Allin
3:56 a.m.
New subject: Ignacio's tramo script
El Miércoles, 24 de Enero de 2007 18:35, Allin Cottrell escribió:
On Wed, 24 Jan 2007, Ignacio Díaz-Emparanza wrote:
> On wednesday 19 I could run the attached scripts (with gretl for
> Windows) without any problem, but on monday I installed the new
> Windows gretl snapshot and today I obtained the same error as
> Sven mentioned: I get the beginning of the .po file in the
> script output, and the error: "The systen cannot find the
> specified file". I downloaded the current Windows snapshot, and
> now I do not obtain the .po file in the script output, but the
> same error is displayed on the screen, and the script aborted.
At what point in execution does Windows say "The system cannot
find the specified file"?
I cannot precise because the only output I get is (this time running in
English):
-------------
gretl version 1.6.0
Current session: 2007/01/25 09:52
#open data9-9
#list xlist = nocars pop Y price primert
? list xlist = nocars Y pop
Added list 'xlist'
? include tramolinf.inp
C:\Documents and Settings\Ignacio\Datos de programa\gretl\\tramolinf.inp
opened OK
#list adjlist = tramolin(xlist, year, startp)
? list adjlist = tramolin(xlist, 1976, 1)
Error executing script: halting
list adjlist = tramolin(xlist, 1976, 1)
---------------
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
4:33 a.m.
New subject: Ignacio's tramo script
I was trying to debug my script and I am surprised that even this simple
script gives an error now:
---------
function tramolin(list xlist, scalar year, scalar startp)
genr ser = time
#! cmd /c "del /Q tmp_descript"
# list retlist = null
# scalar nobser = $nobs
end function
open data9-9
list xlist2 = nocars Y pop
list adjlist = tramolin(xlist, 1976, 1)
-------
The results I obtain are:
---------
gretl version 1.6.0
Current session: 2007/01/25 10:20
? function tramolin(list xlist, scalar year, scalar startp)
genr ser = time
#! cmd /c "del /Q tmp_descript"
# list retlist = null
# scalar nobser = $nobs
end function
? open data9-9
Read datafile C:\Archivos de programa\gretl\data\data9-9.gdt
periodicity: 4, maxobs: 60,
observations range: 1976:1-1990:4
Listing 7 variables:
0) const 1) nocars 2) pop 3) Y 4) price
5) primert 6) unemp
? list xlist = nocars Y pop
Added list 'xlist'
? list adjlist = tramolin(xlist, 1976, 1)
Data types not conformable for operation
Error executing script: halting
list adjlist = tramolin(xlist, 1976, 1)
-------
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
8:57 a.m.
New subject: Ignacio's tramo script
On Thu, 25 Jan 2007, Ignacio Díaz-Emparanza wrote:
I was trying to debug my script and I am surprised that even this
simple
script gives an error now:
---------
function tramolin(list xlist, scalar year, scalar startp)
genr ser = time
#! cmd /c "del /Q tmp_descript"
# list retlist = null
# scalar nobser = $nobs
end function
open data9-9
list xlist2 = nocars Y pop
list adjlist = tramolin(xlist, 1976, 1)
? list adjlist = tramolin(xlist, 1976, 1)
Data types not conformable for operation
I take it you actually typed "xlist2" for the first argument to
tramolin (otherwise you would have got a different error
message).
The error message is correct, if not quite as informative as it
might be: you're trying to assign to "adjlist" from a function
that doesn't return anything.
In addition "genr ser = time" won't work. You can say
genr time
genr ser = time
(Perhaps "genr ser = time" ought to work, but it's not claimed to
work.)
Note that for debugging a function, you should do
set echo on
set messages on
inside the function.
Allin.
11:04 a.m.
New subject: Ignacio's tramo script
Allin,
well, you were right in that my "naive" script had two small errors (about
xlist2 and "genr ser = time") this were no important, but the important error
was not to assign a list inside the function. OK, I get now this simple script
corrected, but my initial script (tramo-linearization) that worked perfectly
the previous week does not work now. I have been looking at it and running
line by line and I think the error now is in calling the Windows system
shell. The week before, the command
! cmd /c "..."
was working but not now.
This simple script produces an error in this line, "The system cannot find the
specified file":
--------
function tramolin(list xlist, scalar year, scalar startp)
#! cmd /c "del /Q tmp_descript"
! cmd /c "dir"
return list xlist
end function
open data9-9
list xlist = nocars Y pop
list adjlist = tramolin(xlist, 1976, 1)
--------
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
12:28 p.m.
New subject: Ignacio's tramo script
On Thu, 25 Jan 2007, Ignacio Díaz-Emparanza wrote:
I have been looking at it and running
line by line and I think the error now is in calling the Windows system
shell. The week before, the command
! cmd /c "..."
was working but not now.
That must reflect the change whereby gretl now waits for "!"
commands to complete, which requires using a different Windows API
function as compared with the old "don't wait" default.
I will try some testing on Windows today and see what I can come
up with.
In the meantime if you need to run scripts of that sort, you can
use "launch" instead of "!" and you should get the old behaviour.
Allin.
10:48 p.m.
New subject: shell functionality on Windows
I tried some experiments on Windows today, on the sort of issue
raised by Ignacio. All results were negative (i.e. nothing
I tried worked). I'll have another go tomorrow.
I don't mean to be defensive, but I thought I might briefly
describe what I'm doing here. Usually working on gretl is a
pleasure for me, but when I'm working on issues that are specific
to Windows, and I have to boot Windows to test, I really wish
someone were paying me the big bucks to do it.
Until Ignacio (quite rightly) raised the point about gretl on
Windows not waiting for tramo (started using "!") to finish before
moving on, gretl had been using the relatively simple Windows
function call WinExec() to handle shell commands. Like most
simple Windows functions this is now deprecated by Microsoft.
What you're "supposed to use" -- and what you have to use to make
the caller wait for the command to complete -- is the function
CreateProcess(). This is a typically monstrous Microsoft API: a
function with 10 arguments, two of which are pointers to
structures which between them contain 22 elements.
CreateProcess() is documented in opaque, bureaucratic fashion on
msdn.com. In attempting to understand how to actually use it, one
googles for examples and discussion. This "helpfully" turns up
various cases of Microsoft experts offering authoritative but
mutually contradictory views on the "right" way to use the API --
something that one finds with most such MS APIs.
So that's why it's taking a while to get this right! But I really
don't want to see gretl messing with ad hoc time-waster loops to
work around lack of synchronization, if I can help it.
Allin.
11:16 p.m.
New subject: comment on user-functions and packages
A brief clarification of a recent response to Sven. I'm aware
that some things in the area of function packaging are not right,
but I need probably a couple of days free of distractions to get
things closer to right.
The main issue is this: although packages exist, there is a
completely "flat" namespace for user-defined functions in gretl
right now. This has various undesirable consequences.
* Suppose you load a package "X" which contains an auxiliary
function foo(). Then you load another package "Y" which also has
an auxiliary function foo(). The second foo() will overwrite the
first. If the two instances happen to be identical (or at
least, functionally identical) this might not matter much, but if
the two foo() functions were different, package X will now be
broken!
* (As Sven found, sorry) if you delete a package "Y" which
contains an auxiliary function foo() that is shared with other
packages, watch out: foo() will be gone, deleted along with its
parent, despite the fact that it may be referenced by other
packages.
As I said, this needs fixing. But in the meantime if you are
developing function packages, please follow this rule: Make sure
that in any given package, _all_ functions have unique names that
will not collide with any other functions. Do not rely on
"sharing" code between function packages; it won't work in
general.
Allin.
11:46 a.m.
New subject: comment on user-functions and packages
Allin Cottrell schrieb:
A brief clarification of a recent response to Sven. I'm aware
that some
things in the area of function packaging are not right, but I need
probably a couple of days free of distractions to get things closer to
right.
No problem. It's clear that this new and cool feature must have some
"infant deseases" (as it would be called in German).
The main issue is this: although packages exist, there is a completely
"flat" namespace for user-defined functions in gretl right now. This
has various undesirable consequences.
Couldn't the functions get internally prepended (at packaging time) by a
timestamp string or something like that to make them unique?
As I said, this needs fixing. But in the meantime if you are developing
function packages, please follow this rule: Make sure that in any given
package, _all_ functions have unique names that will not collide with
any other functions. Do not rely on "sharing" code between function
packages; it won't work in general.
That's one of the reasons why I figured that the py4gretl stuff
shouldn't be uploaded on the package server yet.
-sven
5:20 p.m.
New subject: comment on user-functions and packages
On Thu, 25 Jan 2007, Allin Cottrell wrote:
The main issue is this: although packages exist, there is a
completely "flat" namespace for user-defined functions in gretl
right now. This has various undesirable consequences...
I've just commmitted to CVS some fixes for this. Now each
function package is assigned an ID number using (as Sven
suggested) the system time.
Suppose two function packages X and Y contain private functions
with the same name (say, "foo"). Now that should not be a
problem: when the functions are loaded into memory we record the
ID of the package to which they belong. When "foo" is called from
within package X's main function we look up X's foo; if "foo" is
called from within Y we look up Y's foo (and so on recursively if
helper functions call other helper functions).
In a similar way, deleting package Y should result in the deletion
of Y's foo, but not X's.
There's one related issue I'll mention. We want to ensure that
(a) all gretl function _packages_ have unique names, and (b) that
these names correspond to the package's public interface (with
".gfn" appended). To help enforce this I've removed the "Save As"
button from the function package editor -- it seems to me that
button was inviting problems. In addition, if you make a new
package with public interface "somefunc", then go to Save, you'll
be prompted to save as "somefunc.gfn" (with a choice of which
directory to save to). If you overwrite the suggested .gfn name,
so that it no longer matches the public interface, you'll get an
error message.
Also related: when you're editing a function package you can edit
the code of the functions it contains, but you can't change the
names of those functions. In the (I hope) fairly unlikely case
that you want ro redo a function package, renaming the member
functions, you'll have to do something like this:
* Load the original package.
* "Edit" the original package and call up its code
* Copy and paste the code you want to a script window
* Rename the functions in the script, and run the script
* Create a new package that bundles the renamed functions
This is not supposed to be particularly easy, because messing
around with function names in existing packages would create a big
programming headache.
All the new code mentioned above is tested to some degree, but not
very extensively. If people can beat on it that would be very
helpful.
Allin.
6:10 p.m.
New subject: comment on user-functions and packages
Allin Cottrell schrieb:
There's one related issue I'll mention. We want to ensure
that (a) all
gretl function _packages_ have unique names, and (b) that these names
correspond to the package's public interface (with ".gfn" appended). To
help enforce this I've removed the "Save As" button from the function
package editor -- it seems to me that button was inviting problems. In
addition, if you make a new package with public interface "somefunc",
then go to Save, you'll be prompted to save as "somefunc.gfn" (with a
choice of which directory to save to). If you overwrite the suggested
.gfn name, so that it no longer matches the public interface, you'll get
an error message.
Also related: when you're editing a function package you can edit the
code of the functions it contains, but you can't change the names of
those functions. In the (I hope) fairly unlikely case that you want ro
redo a function package, renaming the member functions, you'll have to
do something like this:
* Load the original package.
* "Edit" the original package and call up its code
* Copy and paste the code you want to a script window
* Rename the functions in the script, and run the script
* Create a new package that bundles the renamed functions
This is not supposed to be particularly easy, because messing around
with function names in existing packages would create a big programming
headache.
I completely understand the need for static function names. It seems to
me, however, that your requirement "b" (public function name == function
package name) then makes versioning of packages difficult.
In effect I think I don't quite understand the need for this requirement
b. Or maybe requirement b is really two requirements: First: public
function name == function package name. And second: function package
name == package filename plus ".gfn"?
I have various versions of packages that are easily distinguishible in
the package manager by their version number. But the names of the
functions in them are all the same. I manually save the packages with
version numbers in their filenames. What would be useful IMHO is to
automatically append the version number as a suffix (or interfix, to be
precise) to the package .gfn file, to keep the filename matched to the
actual version of the package.
Ok, it's late, maybe I just mixed something up...
-sven
6:59 p.m.
New subject: comment on user-functions and packages
On Sun, 28 Jan 2007, Sven Schreiber wrote:
I have various versions of packages that are easily
distinguishible in the package manager by their version number.
But the names of the functions in them are all the same. I
manually save the packages with version numbers in their
filenames. What would be useful IMHO is to automatically append
the version number as a suffix (or interfix, to be precise) to
the package .gfn file, to keep the filename matched to the
actual version of the package.
Ok, it's late, maybe I just mixed something up...
No, that makes sense. I'm thinking this out as I go along, and I
hadn't thought of the point you raise.
Allin.
2:29 p.m.
New subject: Ignacio's tramo script
On Thu, 25 Jan 2007, Ignacio Díaz-Emparanza wrote:
The week before, the command
! cmd /c "..."
was working but not now.
I believe this is now fixed in the current Windows snapshot, but
it does involve some change in syntax for "!" on Windows. Here is
the deal:
* Gretl automatically waits for "!" commands to complete.
* The apparatus of "cmd /c" is implicit, you should not
prepend your command with that.
* The shell command as a whole should not be quoted, although
filenames with embedded spaces should be wrapped in quotes.
* There's a new "set" variable, "shelldir", which sets the
working directory for "!" commands (also on Linux).
Thus suppose from inside gretl you want to delete the files *.t in
directory c:\foo\bar. You could do
set shelldir c:\foo\bar
! del /Q *.t
Or (without shelldir)
! cd c:\foo\bar && del /Q *.t
To run tramo in c:\userdata\tramo:
set shelldir c:\userdata\tramo
! tramo -i baz -k serie
This is partly, not fully tested. I can't say for certain that
"shelldir" works on Windows, though it should.
Allin.
11:04 a.m.
New subject: Ignacio's tramo script
Allin Cottrell schrieb:
* There's a new "set" variable, "shelldir",
which sets the
working directory for "!" commands (also on Linux).
I presume the default for this is the dir from which gretl itself was
started? Or something else?
thanks,
sven
1:31 p.m.
New subject: Ignacio's tramo script
On Sat, 27 Jan 2007, Sven Schreiber wrote:
I presume the default for this is the dir from which gretl itself
was
started? Or something else?
The default, right now, is "unset", which means whatever the
current working directory happens to be.
Allin.
10:01 a.m.
New subject: Ignacio's tramo script
El Viernes, 26 de Enero de 2007 20:29, Allin Cottrell escribió:
I believe this is now fixed in the current Windows snapshot, but
it does involve some change in syntax for "!" on Windows. Here is
the deal:
* Gretl automatically waits for "!" commands to complete.
* The apparatus of "cmd /c" is implicit, you should not
prepend your command with that.
* The shell command as a whole should not be quoted, although
filenames with embedded spaces should be wrapped in quotes.
* There's a new "set" variable, "shelldir", which sets the
working directory for "!" commands (also on Linux).
Thus suppose from inside gretl you want to delete the files *.t in
directory c:\foo\bar. You could do
set shelldir c:\foo\bar
! del /Q *.t
Or (without shelldir)
! cd c:\foo\bar && del /Q *.t
To run tramo in c:\userdata\tramo:
set shelldir c:\userdata\tramo
! tramo -i baz -k serie
This is partly, not fully tested. I can't say for certain that
"shelldir" works on Windows, though it should.
Allin.
I have just tested all of this in my script, and all works ok!
Thank you Allin, I think it is a very important improvement of the
Gretl shell command.
I only wonder whether it is convenient that the option /c (in "cmd /c") be
always implicitly run, since in building my script I had to run it several
times with option /k to check the output of the commands executed in the
shell ...
An alternative is to use the "launch" command to debug, as I can see that it
does not include the "cmd /c" option by default.
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
4:24 p.m.
New subject: Ignacio's tramo script
On Mon, 29 Jan 2007, Ignacio Díaz-Emparanza wrote:
El Viernes, 26 de Enero de 2007 20:29, Allin Cottrell escribió:
> I believe this is now fixed in the current Windows snapshot, but
> it does involve some change in syntax for "!" on Windows. Here is
> the deal...
I have just tested all of this in my script, and all works ok!
That's good to hear, thanks!
I only wonder whether it is convenient that the option /c (in
"cmd /c") be always implicitly run, since in building my script
I had to run it several times with option /k to check the output
of the commands executed in the shell ...
In today's snapshot, if the environment variable SHELLDEBUG is
set, then gretl will use "cmd /k" instead of "cmd /c" for
"!"
commands (this is a Windows-only thing).
Something else that might be useful in today's build: extending
the idea of named strings, we now have a few "built-in" string
variables:
@gretldir : gretl installation directory
@userdir : user's gretl directory
@gnuplot : the path to gnuplot, as known by gretl
@tramo: ditto for tramo executable
@x12a : ditto for x-12-arima executable
@tramodir : tramo data directory
@x12adir : x-12-arima data directory
These are not Windows-only. You can use these in scripts, e.g.
printf "The tramo data dir is @tramodir\n"
Allin.
5:17 p.m.
New subject: Ignacio's tramo script
Allin Cottrell schrieb:
Something else that might be useful in today's build: extending the idea
of named strings, we now have a few "built-in" string variables:
@gretldir : gretl installation directory
@userdir : user's gretl directory
@gnuplot : the path to gnuplot, as known by gretl
@tramo: ditto for tramo executable
@x12a : ditto for x-12-arima executable
@tramodir : tramo data directory
@x12adir : x-12-arima data directory
These are not Windows-only. You can use these in scripts, e.g.
printf "The tramo data dir is @tramodir\n"
This is great! I'll check eventually if it also works with store,
outfile etc...
cheers,
sven
2:21 p.m.
New subject: Ignacio's tramo script
El Jueves, 1 de Febrero de 2007 22:24, Allin Cottrell escribió:
Something else that might be useful in today's build: extending
the idea of named strings, we now have a few "built-in" string
variables:
@gretldir : gretl installation directory
@userdir : user's gretl directory
@gnuplot : the path to gnuplot, as known by gretl
@tramo: ditto for tramo executable
@x12a : ditto for x-12-arima executable
@tramodir : tramo data directory
@x12adir : x-12-arima data directory
These are not Windows-only. You can use these in scripts, e.g.
printf "The tramo data dir is @tramodir\n"
Sorry, I see that these work in Linux, but in Windows the result (for all of
them) is "The tramo data dir is C:"
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
2:25 p.m.
New subject: Ignacio's tramo script
On Fri, 9 Feb 2007, Ignacio Diaz-Emparanza wrote:
El Jueves, 1 de Febrero de 2007 22:24, Allin Cottrell escribió:
>
> @gretldir : gretl installation directory
> @userdir : user's gretl directory
> @gnuplot : the path to gnuplot, as known by gretl
> @tramo: ditto for tramo executable
> @x12a : ditto for x-12-arima executable
> @tramodir : tramo data directory
> @x12adir : x-12-arima data directory
>
> printf "The tramo data dir is @tramodir\n"
Sorry, I see that these work in Linux, but in Windows the result
(for all of them) is "The tramo data dir is C:"
Thanks for the warning. I'll have to try testing on Windows.
Allin.
2:35 p.m.
New subject: Ignacio's tramo script
On Fri, 9 Feb 2007, Ignacio Diaz-Emparanza wrote:
> @gretldir : gretl installation directory
> @userdir : user's gretl directory
> @gnuplot : the path to gnuplot, as known by gretl
> @tramo: ditto for tramo executable
> @x12a : ditto for x-12-arima executable
> @tramodir : tramo data directory
> @x12adir : x-12-arima data directory
>
> printf "The tramo data dir is @tramodir\n"
Sorry, I see that these work in Linux, but in Windows the result
(for all of them) is "The tramo data dir is C:"
Ah yes, the jolly old Windows trick of backslashes in pathnames.
This is now fixed in CVS and the current Windows snapshot.
Allin.
6448
days inactive
6467
days old
21 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Ignacio Díaz-Emparanza
-
Sven Schreiber