4:14 p.m.
Hi dear devel-ers,
this is a call to run a quick test on the contributed function package
tramolin.gfn, preferably on Windows 10. You can get the package in the
standard way from within gretl. The package requires to have the
external TRAMO program installed and to have the corresponding correct
path setting in gretl's preferences. Furthermore shell commands must be
allowed, also in gretl's settings.
Personally I'm getting errors that I didn't see on another system. I'm
not sure if my configuration on the new system is somehow wrong or
whether there is a deeper issue, possibly some incompatibility with
Windows 10 (of the package itself or of the Tramo program).
thanks
sven
9:32 p.m.
On Wed, 3 Apr 2019, Sven Schreiber wrote:
Hi dear devel-ers,
this is a call to run a quick test on the contributed function package
tramolin.gfn, preferably on Windows 10. You can get the package in the
standard way from within gretl. The package requires to have the
external TRAMO program installed and to have the corresponding correct
path setting in gretl's preferences. Furthermore shell commands must be
allowed, also in gretl's settings.
Personally I'm getting errors that I didn't see on another system. I'm
not sure if my configuration on the new system is somehow wrong or
whether there is a deeper issue, possibly some incompatibility with
Windows 10 (of the package itself or of the Tramo program).
Thanks, as ever, for maintaining a rigorous testing standard! I just
tried the sample script of version 1.11 (2017-01-28) of the tramolin
package on Linux and it ran OK. But I guess that's not very
relevant; I'll have a go on Windows 10 tomorrow.
Allin
9:29 a.m.
Am 03.04.2019 um 23:32 schrieb Allin Cottrell:
On Wed, 3 Apr 2019, Sven Schreiber wrote:
> Personally I'm getting errors that I didn't see on
another system. I'm
> not sure if my configuration on the new system is somehow wrong or
> whether there is a deeper issue, possibly some incompatibility with
> Windows 10 (of the package itself or of the Tramo program).
It cannot be Windows 10 per se, since I have tested on another Win10
system where it works fine.
Thanks, as ever, for maintaining a rigorous testing standard! I just
tried the sample script of version 1.11 (2017-01-28) of the tramolin
package on Linux and it ran OK. But I guess that's not very relevant;
I'll have a go on Windows 10 tomorrow.
Thanks Allin. It's not clear to me what triggers the error on one
machine but not on the other. But I noticed that in both cases an empty
text file 'sername.txt' was produced in the respective current work
directory. From Ignacio's code I didn't really understand why it ended
up in those locations, it looked as if it was intended to go into
$tramodir somewhere. But since on both machines the file is created and
is empty, this doesn't seem to be the (sole) reason.
The only thing that caught my attention was that in the relevant
directory paths on the failing machine there was a hyphen character (-).
I guess this _shouldn't_ cause a problem but who knows.
If the error cannot be resolved with a reasonable amount of effort, I
would simply add a warning to the top of the output of the tramolin
package that some errors have been observed, but because it is useful
for some people and working at least sometimes/most of the time it is
still kept around.
thanks
sven
4:51 p.m.
On Thu, 4 Apr 2019, Sven Schreiber wrote:
Am 03.04.2019 um 23:32 schrieb Allin Cottrell:
> On Wed, 3 Apr 2019, Sven Schreiber wrote:
>> Personally I'm getting errors that I didn't see on another system.
I'm
>> not sure if my configuration on the new system is somehow wrong or
>> whether there is a deeper issue, possibly some incompatibility with
>> Windows 10 (of the package itself or of the Tramo program).
It cannot be Windows 10 per se, since I have tested on another Win10
system where it works fine.
> Thanks, as ever, for maintaining a rigorous testing standard! I just
> tried the sample script of version 1.11 (2017-01-28) of the tramolin
> package on Linux and it ran OK. But I guess that's not very relevant;
> I'll have a go on Windows 10 tomorrow.
I've now tested on Windows 10 and the sample script ran OK.
Thanks Allin. It's not clear to me what triggers the error on
one
machine but not on the other. But I noticed that in both cases an empty
text file 'sername.txt' was produced in the respective current work
directory. From Ignacio's code I didn't really understand why it ended
up in those locations, it looked as if it was intended to go into
$tramodir somewhere. But since on both machines the file is created and
is empty, this doesn't seem to be the (sole) reason.
I see where the empty sername.txt is coming from (it appears on Linux
as well as Windows): it's produced by this (shell command) line in the
tramolin function:
! cat "@tramodir/ausentesf" >> sername.txt
The write location for sername.txt on this line does not carry over
from the previous line, namely,
! cd @seriesdir ; <write stuff to sername.txt in @seriesdir>
since it's a new invocation of the shell. And (at least in the case of
the sample script) the file @tramodir/ausentesf is empty. If
"ausentesf" should really be appended (if not empty), the line that
handles it should read something like:
! cat "@tramodir/ausentesf" >> @seriesdir/sername.txt
I don't know if that's actually wanted. (Note that sername.txt in its
location under the @dotdir/tramo tree is the file that contains the
linearized series to be added to the gretl dataset via the "append"
command.)
The only thing that caught my attention was that in the relevant
directory paths on the failing machine there was a hyphen character (-).
I guess this _shouldn't_ cause a problem but who knows.
Seems unlikely. But in which path(s) does the hyphen appear? Does it
occur in @tramodir?
For troubleshooting, you might try taking a look at
@dotdir/tramo/graph/series/sername.txt
I guess that's the file that's provoking the "Invalid data file"
message -- maybe it's empty or corrupted? (If it were missing
altogether I think you'd get a different message.) Also, does
@dotdir/tramo/graph/series/xlin.t
exist, and if so what does it look like?
Allin
5:07 p.m.
Am 04.04.2019 um 18:51 schrieb Allin Cottrell:
On Thu, 4 Apr 2019, Sven Schreiber wrote:
> $tramodir somewhere. But since on both machines the file is
created and
> is empty, this doesn't seem to be the (sole) reason.
I see where the empty sername.txt is coming from ...
The write location for sername.txt on this line does not carry over from
the previous line, namely,
...
since it's a new invocation of the shell.
...
I don't know if that's actually wanted.
OK, in any case smells like a bug (but not the relevant one for the
current problem)...
Seems unlikely. But in which path(s) does the hyphen appear? Does it
occur in @tramodir?
Yes because (not really a secret) it's part of the user name as in my
boeckler email address, so it's "everywhere".
For troubleshooting, you might try taking a look at
@dotdir/tramo/graph/series/sername.txt
I guess that's the file that's provoking the "Invalid data file"
message
-- maybe it's empty or corrupted?
Indeed on the failing system this file only contains the header
("ser_adj" with these quotes) but no data.
@dotdir/tramo/graph/series/xlin.t
exist, and if so what does it look like?
Appears to be the same on both systems.
Let's not forget we are debugging someone else's package. Aren't the
seasonal adjustment fans using the jDemetra these days?
cheers
sven
5:38 p.m.
On Thu, 4 Apr 2019, Sven Schreiber wrote:
Am 04.04.2019 um 18:51 schrieb Allin Cottrell:
> For troubleshooting, you might try taking a look at
>
> @dotdir/tramo/graph/series/sername.txt
>
> I guess that's the file that's provoking the "Invalid data file"
message
> -- maybe it's empty or corrupted?
Indeed on the failing system this file only contains the header
("ser_adj" with these quotes) but no data.
Noted.
> @dotdir/tramo/graph/series/xlin.t
>
> exist, and if so what does it look like?
Appears to be the same on both systems.
Hmm, xlin.t is supposed to provide most of the content of sername.txt.
You might try executing Ignacio's shell command directly in a console
window:
cd <dotdir>\tramo\graph\series
echo "ser_adj" > sername.txt
if exist xlin.t. (more +6 xlin.t >> sername.txt)
If that fails, I wonder what happens if you try again without the
trailing dot in "exist xlin.t." which is present in the gfn but looks
funny to me (though I'm not a cmd.exe expert).
Allin
8:09 p.m.
Am 04.04.2019 um 19:38 schrieb Allin Cottrell:
Hmm, xlin.t is supposed to provide most of the content of
sername.txt.
You might try executing Ignacio's shell command directly in a console
window:
cd <dotdir>\tramo\graph\series
echo "ser_adj" > sername.txt
if exist xlin.t. (more +6 xlin.t >> sername.txt)
If that fails, I wonder what happens if you try again without the
trailing dot in "exist xlin.t."
Yes it fails (both variants). I narrowed it down to the 'more' command
which gives the error message "too many arguments in command line"
(re-translated).
Looking at the help (more /?) it seems that the /e switch is needed, and
indeed:
more +6 /e xlin.t
seems to work.
I'm still not sure why the failure only happens on one system. But
indeed the Windows Version number (at the beginning of the cmd.exe
output) is lower on the failing system, even though it is a recent setup
(but in a corporate Windows domain setting with group directives or what
they're called).
Maybe there was a bug in the 'more' in Windows 10 which was fixed in
later versions.
Perhaps the /e switch could be added? Don't know whether there are side
effects, though.
cheers
sven
11:46 p.m.
On Thu, 4 Apr 2019, Sven Schreiber wrote:
Am 04.04.2019 um 19:38 schrieb Allin Cottrell:
> Hmm, xlin.t is supposed to provide most of the content of sername.txt.
> You might try executing Ignacio's shell command directly in a console
> window:
>
> cd <dotdir>\tramo\graph\series
> echo "ser_adj" > sername.txt
> if exist xlin.t. (more +6 xlin.t >> sername.txt)
>
> If that fails, I wonder what happens if you try again without the
> trailing dot in "exist xlin.t."
Yes it fails (both variants). I narrowed it down to the 'more' command
which gives the error message "too many arguments in command line"
(re-translated).
Looking at the help (more /?) it seems that the /e switch is needed, and
indeed:
more +6 /e xlin.t
seems to work.
After googling this issue, it seems to me that "more" not working
properly without the "/e" flag is a bug in some (earlier) versions
of Windows 10. See for example
https://superuser.com/questions/1370353/more-command-returns-too-many-arg...
I can check (tomorrow) if appending "/e" causes a problem with a
version of Windows 10 that doesn't have the bug in question.
Allin
4:57 p.m.
Am 05.04.2019 um 01:46 schrieb Allin Cottrell:
After googling this issue, it seems to me that "more" not
working
properly without the "/e" flag is a bug in some (earlier) versions of
Windows 10. See for example
https://superuser.com/questions/1370353/more-command-returns-too-many-arg...
(where also some other potential workarounds are given)
I can check (tomorrow) if appending "/e" causes a problem with a
version of Windows 10 that doesn't have the bug in question.
Please do. Attached is a release candidate version that works for me on
the system where it failed before. Later I can also test on the other one.
thanks
sven
5:32 p.m.
On Fri, 5 Apr 2019, Sven Schreiber wrote:
Am 05.04.2019 um 01:46 schrieb Allin Cottrell:
> After googling this issue, it seems to me that "more" not working
> properly without the "/e" flag is a bug in some (earlier) versions of
> Windows 10. See for example
>
https://superuser.com/questions/1370353/more-command-returns-too-many-arg...
(where also some other potential workarounds are given)
>
> I can check (tomorrow) if appending "/e" causes a problem with a
> version of Windows 10 that doesn't have the bug in question.
>
Please do. Attached is a release candidate version that works for me on
the system where it failed before. Later I can also test on the other one.
I can confirm that the "/e" doesn't hurt anything on my Windows 10
system.
Allin
1851
days inactive
1853
days old
9 comments
2 participants
participants (2)
-
Allin Cottrell -
Sven Schreiber