5:51 p.m.
Before I try responding to the list of small bugs that has
appeared on gretl-users, I'd like to come back on some points that
Sven raised earlier, regarding function packages.
First of all, py4gretl is very cool! Thanks for making this
available. One request: I think it would be very helpful if you
could put up a few examples of use of the py4gretl functions. (I
have this is mind, though it's not yet implemented: allow for a
.gfn file to contain a complete, runnable sample script.)
Now, on a few design issues.
* Should we have a standard File Open dialog that allows you to
open .gfn files from anywhere in the filesystem? On reflection,
No, that would likely be confusing for most users. Unlike regular
.inp files, .gfn files are supposed to be special. There are two
authorized locations for such files: @gretldir/functions and
@userdir/functions. If you want to be able to open such a file,
then put it, copy it, or symlink it into one of those locations.
* Version numbers embedded in gfn filenames. I started along the
road of trying to accommodate this, but I now think that was a
mistake.
One symptom is the issue Sven mentioned, that if you upload a new
version of a package to the server, the old one will still hang
around, if it has a different filename, and you can't delete the
old one. What's supposed to happen is that when you post an
update the old file is automatically overwritten, which will
happen if they have the same name.
Also, version numbers in the filename are redundant from a user's
point of view (the version is recorded inside the file), and they
take up space unneccessarily in the function package dialog
window. [To make the redundancy point more persuasive, I've now
modified the dialog so that it shows the version number beside the
name.]
I can see that from the point of view of a function package
developer, it's convenient to have versioned filenames. My
suggestion would be: keep the files with the versioned names in a
separate directory, and symlink the one you want to use currently
into @userdir/functions
@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn
If this sounds reasonable, I can rename the py4gretl files on the
server accordingly.
* Which functions appear as available for packaging in gretl? I
haven't had time to check this fully, but here's what's _supposed_
to happen when you load function package P:
- P's public interface (which should have the same name as the
package) will _not_ appear as packageable. That's intentional:
it's already packaged and shouldn't appear as the public interface
of any other package.
- If there's at least one "free" function available for packaging,
then any helper functions inside P should be available: helper
function are supposed to be reusable.
- How do you make "free" functions available? For example, put
them into an .inp file and run it.
- If you really want to "cannibalize" a package -- that is, steal
its public interface and use it to make another package, then
you'll have to do some copying and pasting. Copy the code out of
the code-editing window in the function packager and paste it into
an .inp file. Re-start gretl; load and run the .inp file.
Allin.
7:33 p.m.
Allin Cottrell schrieb:
First of all, py4gretl is very cool! Thanks for making this
available. One request: I think it would be very helpful if you
could put up a few examples of use of the py4gretl functions. (I
have this is mind, though it's not yet implemented: allow for a
.gfn file to contain a complete, runnable sample script.)
I'm planning to do that after py4gretl has become reasonably stable.
Since I'm using it myself at least from time to time, that shouldn't
take too long.
Actually, I don't think extending the capabilities of .gfn files in the
way you describe is worth your effort. People can play around with the
function packages, and documentation can be in the help texts or
elsewhere online.
Now, on a few design issues.
* Should we have a standard File Open dialog that allows you to
open .gfn files from anywhere in the filesystem? On reflection,
No, that would likely be confusing for most users. Unlike regular
.inp files, .gfn files are supposed to be special. There are two
authorized locations for such files: @gretldir/functions and
@userdir/functions. If you want to be able to open such a file,
then put it, copy it, or symlink it into one of those locations.
Ok with me! It just seemed to me that gretl could only execute packages
that were packaged by itself or that it downloaded from the server. But
since that is not the case, all is well.
* Version numbers embedded in gfn filenames. I started along the
road of trying to accommodate this, but I now think that was a
mistake.
I'm still not entirely convinced that that's true, but I think the best
way to proceed is to do what causes you the least amount of work.
One symptom is the issue Sven mentioned, that if you upload a new
version of a package to the server, the old one will still hang
around, if it has a different filename, and you can't delete the
old one. What's supposed to happen is that when you post an
update the old file is automatically overwritten, which will
happen if they have the same name.
Yes; however, I do think that the old versions should be archived
somewhere. Imagine somebody relies on a package for serious work. Now
the author accidentally uploads a new version which breaks everything.
In a worst-case scenario, even the author herself does not have a backup
of the old working version. All users of that package would be doomed,
and some of them will blame gretl for it... So maybe the function
package files on the server could somehow be automatically inserted into
the CVS repository as well?
Also, version numbers in the filename are redundant from a user's
point of view (the version is recorded inside the file), and they
take up space unneccessarily in the function package dialog
window. [To make the redundancy point more persuasive, I've now
modified the dialog so that it shows the version number beside the
name.]
Well, by that logic it's also redundant to name the gretl installer
gretl-1.6.2.exe... But your solution is nice (haven't seen it yet). Does
it also apply to the dialog showing the packages on the server (IMHO it
should)?
I can see that from the point of view of a function package
developer, it's convenient to have versioned filenames. My
suggestion would be: keep the files with the versioned names in a
separate directory, and symlink the one you want to use currently
into @userdir/functions
@userdir/functions/foo.gfn -> /other/place/foo-1.28.3a.gfn
If this sounds reasonable, I can rename the py4gretl files on the
server accordingly.
Yes I can live with that easily. (But please wait until I have uploaded
versions 0.9.2 of the py4gretl files.)
* Which functions appear as available for packaging in gretl? I
haven't had time to check this fully, but here's what's _supposed_
to happen when you load function package P:
- P's public interface (which should have the same name as the
package) will _not_ appear as packageable. That's intentional:
it's already packaged and shouldn't appear as the public interface
of any other package.
Can you remind me again why the names should match? Couldn't the name of
the public interface function be completely invisible to the package
user, and then it wouldn't matter what it would be called?
thanks,
sven
8:04 p.m.
On Thu, 26 Apr 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
>
> First of all, py4gretl is very cool! Thanks for making this
> available. One request: I think it would be very helpful if you
> could put up a few examples of use of the py4gretl functions. (I
> have this is mind, though it's not yet implemented: allow for a
> .gfn file to contain a complete, runnable sample script.)
I'm planning to do that after py4gretl has become reasonably stable.
Since I'm using it myself at least from time to time, that shouldn't
take too long.
OK, great.
Actually, I don't think extending the capabilities of .gfn files
in the
way you describe is worth your effort. People can play around with the
function packages, and documentation can be in the help texts or
elsewhere online.
Yes, but... If the interface is complex it can be difficult even
to start playing around without an example to refer to. Full
documentation is nice, but does not always get written ;-) A
sample is quite easy to produce, and people can use it as a
template for customizing.
> * Should we have a standard File Open dialog that allows you to
> open .gfn files from anywhere in the filesystem? On reflection,
> No, that would likely be confusing for most users. Unlike regular
> .inp files, .gfn files are supposed to be special. There are two
> authorized locations for such files: @gretldir/functions and
> @userdir/functions. If you want to be able to open such a file,
> then put it, copy it, or symlink it into one of those locations.
Ok with me! It just seemed to me that gretl could only execute packages
that were packaged by itself or that it downloaded from the server. But
since that is not the case, all is well.
Fine.
> * Version numbers embedded in gfn filenames. I started along
the
> road of trying to accommodate this, but I now think that was a
> mistake.
I'm still not entirely convinced that that's true, but I think the best
way to proceed is to do what causes you the least amount of work.
Least work definitely means not attempting to provide full support
for versioned filenames!
> One symptom is the issue Sven mentioned, that if you upload a
new
> version of a package to the server, the old one will still hang
> around, if it has a different filename, and you can't delete the
> old one. What's supposed to happen is that when you post an
> update the old file is automatically overwritten, which will
> happen if they have the same name.
Yes; however, I do think that the old versions should be archived
somewhere.
Yes, I agree; that should be quite easy to arrange.
> Also, version numbers in the filename are redundant from a
user's
> point of view (the version is recorded inside the file), and they
> take up space unneccessarily in the function package dialog
> window. [To make the redundancy point more persuasive, I've now
> modified the dialog so that it shows the version number beside the
> name.]
Well, by that logic it's also redundant to name the gretl installer
gretl-1.6.2.exe...
Yes, it is redundant. The only reason I do that is so the
previous installers get archived on sourceforge, in case anyone
wants to backdate.
But your solution is nice (haven't seen it yet). Does
it also apply to the dialog showing the packages on the server (IMHO it
should)?
Yes, it does apply to packages on the server.
Yes I can live with that easily. (But please wait until I have
uploaded
versions 0.9.2 of the py4gretl files.)
Fine, no hurry.
> * Which functions appear as available for packaging in gretl? I
> haven't had time to check this fully, but here's what's _supposed_
> to happen when you load function package P:
>
> - P's public interface (which should have the same name as the
> package) will _not_ appear as packageable. That's intentional:
> it's already packaged and shouldn't appear as the public interface
> of any other package.
Can you remind me again why the names should match?
Urgh, I have to remind myself first!
Couldn't the name of the public interface function be completely
invisible to the package user...
Then you'd only be able to call them from the GUI, not from
scripts. I don't think we want that.
Allin.
8:21 a.m.
Allin Cottrell schrieb:
On Thu, 26 Apr 2007, Sven Schreiber wrote:
>> - P's public interface (which should have the same name
as the
>> package) will _not_ appear as packageable. That's intentional:
>> it's already packaged and shouldn't appear as the public interface
>> of any other package.
> Can you remind me again why the names should match?
Urgh, I have to remind myself first!
> Couldn't the name of the public interface function be completely
> invisible to the package user...
Then you'd only be able to call them from the GUI, not from
scripts. I don't think we want that.
Ah okay, I hadn't thought of that...
-sven
1:38 p.m.
Allin Cottrell schrieb:
On Thu, 26 Apr 2007, Sven Schreiber wrote:
> Yes I can live with that easily. (But please wait until I have uploaded
> versions 0.9.2 of the py4gretl files.)
Fine, no hurry.
The versions 0.9.2 of two of the three files are on the server now, no
more version numbers in the filenames. They should fail less often now.
The one that is missing is py4gretl_vecdecomp, because I found out that
gretl seems to have a 4KB line length limit (regarding script files
invoked with the "run" command) -- which is understandable, but
sometimes breaks the (admittedly) clumsy way how py4gretl_vecdecomp
passes the calculated time series from Numpy back to gretl in a
temporary text file. Would that limitation be easy to lift, or should I
think of a way to work around that?
There are still issues when creating new packages, this area still seems
a little fragile. Often I need to restart gretl, otherwise gretl isn't
showing me the necessary helper functions to package (although I have
run them of course).
Or sometimes gretl uses a helper function of a previously executed
package instead of a newer version helper function that was run
afterwards. I think if you really want to make the helper functions of
existing packages available easily (i.e., w/o copy & paste), the
namespaces (or what you want to call it) should be separated:
So if f1() is a helper function in a loaded package called
"superpackage", and a (possibly different) function f1() has been run by
the user, the function chooser for packaging should label them for
example as "f1 (superpackage)" and "f1". Or just don't make the
helper
functions of packages public, interested people can still copy&paste and
run them quite easily. All IMHO of course.
Some other misc. stuff I came across (all on Windows, pretty recent
snapshot):
* why is "#" in a matrix definition line invalid?
* closing function package call window by window close cross
doesn't work
* with py4gretl_vecrestrict, I again get some internal
function matrices in the session window (alpha_pattern and beta_pattern)
* IIRC some snapshots ago saving files with a script
into "./" would save them into "c:\Dokumente und
Einstellungen\<loginname>"
and now it seems to be "c:\Dokumente und
Einstellungen\<loginname>\Eigene Dateien".
Has that changed or am I mixing things up?
* out of curiosity: has the behavior of printf in combination with a
matrix changed? Earlier I believe it would print out all elements, now
only the first one.
Have a good weekend,
sven
6:44 p.m.
On Sat, 28 Apr 2007, Sven Schreiber wrote:
(Sorry, I can't answer all of these points right now, but I'll try
some.)
The versions 0.9.2 of two of the three files are on the server now,
no
more version numbers in the filenames. They should fail less often now.
Thanks, I'll archive the old ones and get them out of the way.
The one that is missing is py4gretl_vecdecomp, because I found out
that
gretl seems to have a 4KB line length limit (regarding script files
invoked with the "run" command) -- which is understandable, but
sometimes breaks the (admittedly) clumsy way how py4gretl_vecdecomp
passes the calculated time series from Numpy back to gretl in a
temporary text file. Would that limitation be easy to lift, or should I
think of a way to work around that?
Don't know offhand; I'll take a look.
There are still issues when creating new packages... sometimes
gretl uses a helper function of a previously executed package
instead of a newer version helper function that was run
afterwards.
That's expected. Helper functions don't have to have unique
names. If you load package A that has helper function foo, then
package B that also has a helper function foo, both helpers are
held in memory, indexed by their respective packages. Otherwise
loading B could break A. If A's public function calls "foo", it
gets A's version; if B's public function calls "foo" it gets B's
version. If "foo" is called from outside any package, you get the
first available definition.
I think if you really want to make the helper functions of
existing packages available easily (i.e., w/o copy & paste), the
namespaces (or what you want to call it) should be separated: So
if f1() is a helper function in a loaded package called
"superpackage", and a (possibly different) function f1() has
been run by the user, the function chooser for packaging should
label them for example as "f1 (superpackage)" and "f1".
Yes, that sounds like a good idea.
Some other misc. stuff I came across (all on Windows, pretty recent
snapshot):
* why is "#" in a matrix definition line invalid?
Where would you expect it to be valid? I would expect it to work
as a comment, and here it does:
? matrix M = I(3) # identity matrix
matrix M = I(3)
Generated matrix M
? M
M
M (3 x 3)
1.0000 0.0000 0.0000
0.0000 1.0000 0.0000
0.0000 0.0000 1.0000
* closing function package call window by window close cross
doesn't work
Will check that.
* IIRC some snapshots ago saving files with a script
into "./" would save them into "c:\Dokumente und
Einstellungen\<loginname>"
and now it seems to be "c:\Dokumente und
Einstellungen\<loginname>\Eigene Dateien".
Has that changed or am I mixing things up?
I don't think that has changed.
* out of curiosity: has the behavior of printf in combination
with a matrix changed? Earlier I believe it would print out all
elements, now only the first one.
I'm surprised it works at all -- that it prints out the first
element is some sort of strange freebie. So far as I'm aware it
never printed the whole matrix.
Allin.
7:48 p.m.
Allin Cottrell schrieb:
On Sat, 28 Apr 2007, Sven Schreiber wrote:
> The one that is missing is py4gretl_vecdecomp, because I found
out that
> gretl seems to have a 4KB line length limit (regarding script files
> invoked with the "run" command) -- which is understandable, but
> sometimes breaks the (admittedly) clumsy way how py4gretl_vecdecomp
> passes the calculated time series from Numpy back to gretl in a
> temporary text file. Would that limitation be easy to lift, or should I
> think of a way to work around that?
Don't know offhand; I'll take a look.
Actually, I think it would only make sense to change gretl for that if
it turns out to be possible to (more or less) abolish the restriction
entirely. (For example, such that everything up to 1MB per line would be
okay.) Otherwise py4gretl_vecdecomp would still fail for large datasets
(say, financial high-frequency data), and that would not be a nice
solution. If that's possible to achieve, I have no idea. Note that
changing the way how py4gretl gets new series back into gretl would be
definitely possible, but of course would cause some work as well.
> * why is "#" in a matrix definition line invalid?
Where would you expect it to be valid? I would expect it to work
as a comment, and here it does:
? matrix M = I(3) # identity matrix
matrix M = I(3)
Generated matrix M
Well that seems to depend on a blank before the '#':
? matrix M = I(3)# identity matrix
matrix M = I(3)#
Ungültiges Zeichen '#'
^^^^^^^^^^^
(= "invalid character '#'")
> * out of curiosity: has the behavior of printf in combination
> with a matrix changed? Earlier I believe it would print out all
> elements, now only the first one.
I'm surprised it works at all -- that it prints out the first
element is some sort of strange freebie. So far as I'm aware it
never printed the whole matrix.
Well I now rely on the fact that at least it's capable to print out a
single matrix element (equivalent to a scalar in that respect I guess),
looping over all rows and columns. Please don't change that in the
future :-)
cheers,
Sven
4:02 p.m.
On Sat, 28 Apr 2007, Sven Schreiber wrote:
The one that is missing is py4gretl_vecdecomp, because I found
out that gretl seems to have a 4KB line length limit (regarding
script files invoked with the "run" command) -- which is
understandable, but sometimes breaks the (admittedly) clumsy way
how py4gretl_vecdecomp passes the calculated time series from
Numpy back to gretl in a temporary text file. Would that
limitation be easy to lift, or should I think of a way to work
around that?
In the context of saving a "session", if there are any saved
matrices gretl writes out a file called matrices.xml, which is
then re-loaded when the session is reopened.
I've now added this: you can load such a matrix file,
independently of the session mechanism, using the "include"
command. So, if I'm understanding the issue correctly, you should
be able to get the relevant data into gretl without super-long
command lines: get python to write out a matrices file then ask
gretl to "include" it. Here's an example of the format for such a
file:
<?xml version="1.0" encoding="UTF-8"?>
<gretl-matrices count="2">
<gretl-matrix name="A" rows="3" cols="3">
1 0 0
0 1 0
0 0 1
</gretl-matrix>
<gretl-matrix name="B" rows="2" cols="4">
1 2 3 4
4 3 2 1
</gretl-matrix>
</gretl-matrices>
Allin.
8:10 a.m.
Allin Cottrell schrieb:
I've now added this: you can load such a matrix file,
independently of the session mechanism, using the "include"
command. So, if I'm understanding the issue correctly, you should
be able to get the relevant data into gretl without super-long
command lines: get python to write out a matrices file then ask
gretl to "include" it. Here's an example of the format for such a
file:
That's a good idea, and in the longer run should probably be the way to
go for all py4gretl parts. For now I would restrict that approach to
py4gretl_vecdecomp which would be broken otherwise, because the feature
of course would require gretl 1.6.3.
Two questions though:
Wasn't the "include" command disabled in scripts? (Remember the
discussion we had that led to "run" being enabled.)
And does the latest Win snapshot have this? (If not, that's also fine,
my computer is now a dual-boot machine, so I can also work with gretl
cvs on linux for these kind of things.)
Thanks,
Sven
8:34 p.m.
On Mon, 30 Apr 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> I've now added this: you can load such a matrix file,
> independently of the session mechanism, using the "include"
> command. So, if I'm understanding the issue correctly, you should
> be able to get the relevant data into gretl without super-long
> command lines: get python to write out a matrices file then ask
> gretl to "include" it. Here's an example of the format for such a
> file:
>
That's a good idea, and in the longer run should probably be the
way to go for all py4gretl parts. For now I would restrict that
approach to py4gretl_vecdecomp which would be broken otherwise,
because the feature of course would require gretl 1.6.3.
Two questions though:
Wasn't the "include" command disabled in scripts? (Remember the
discussion we had that led to "run" being enabled.)
Good point. I've now enabled "include" in scripts, at this point
for matrix files only.
And does the latest Win snapshot have this? (If not, that's also
fine, my computer is now a dual-boot machine, so I can also work
with gretl cvs on linux for these kind of things.)
The Windows snapshot now has this.
Allin.
8:05 p.m.
Allin Cottrell schrieb:
On Mon, 30 Apr 2007, Sven Schreiber wrote:
> Allin Cottrell schrieb:
>
>> I've now added this: you can load such a matrix file,
>> independently of the session mechanism, using the "include"
>> command. So, if I'm understanding the issue correctly, you should
>> be able to get the relevant data into gretl without super-long
>> command lines: get python to write out a matrices file then ask
>> gretl to "include" it. Here's an example of the format for such a
>> file:
>>
Ok, I have implemented this new matrix transfer mechanism for
py4gretl_vecdecomp and it seems to work well (with the latest win
snapshot). Thanks Allin! I will delay the upload until gretl 1.6.3,
because it won't work with current versions.
Re-adressing one other thing: Do you remember I was asking about whether
directory meanings for "./" had changed? Well I have observed some
weirdness and now decided to tackle it systematically, because it was
driving me made while testing scripts. Here's what I found, regarding
the question as to where does the command "outfile ./test.txt --write"
save the file to (when gretl is started via the start menu on windows)?
(a) The default current dir for gretl on windows is "c:\Dokumente und
Einstellungen\<loginname>", which is fine.
(b) However, "./" then seems to behave like a kind of global variable
which is changed by every file saving action (for an example session see
below). IMHO that's bad, because it makes things unpredictable.
I would prefer if ./ always stays at the value it has at gretl startup
time. As a second-best solution, I could imagine that ./ is interpreted
relative to the location of the containing script.
What do you think?
cheers,
sven
=================
Example experimentation from which I inferred the current "rules":
(1) Directly from the console as the first thing that is done:
in c:\Dokumente und Einstellungen\<loginname>
(2) Unsaved script, directly after step 1: in the same dir as in step 1
(3) Same script as in 2, but saved: in the same dir where the script was
saved
(4) Unsaved script, same contents as in 2, but now after step 3: in the
same dir as in step 3!!!
(5) From the console again, but after steps 1-4: in the same dir as in
steps 3&4 again!!!
----- restart gretl -----
(6) After having wrapped the command in a simple function package,
execute the package: in the same dir as in step 1
(7) Save another unrelated script or function package to dir <foo>, and
then execute the function package from step 6 again: in dir <foo>!
12:19 a.m.
On Tue, 1 May 2007, Sven Schreiber wrote:
Re-adressing one other thing: Do you remember I was asking about
whether
directory meanings for "./" had changed? Well I have observed some
weirdness and now decided to tackle it systematically, because it was
driving me made while testing scripts. Here's what I found, regarding
the question as to where does the command "outfile ./test.txt --write"
save the file to (when gretl is started via the start menu on windows)?
Thanks for the detailed report. Brief experimentation on Linux
gave me what I expected, but I'll test on Windows tomorrow and
give a proper response on this point.
Allin.
12:48 a.m.
New subject: dotdir (was Belated response to Sven on function packages)
On Tue, 1 May 2007, Sven Schreiber wrote:
Re-adressing one other thing: Do you remember I was asking about
whether directory meanings for "./" had changed? Well I have
observed some weirdness and now decided to tackle it
systematically, because it was driving me made while testing
scripts. Here's what I found, regarding the question as to where
does the command "outfile ./test.txt --write" save the file to
(when gretl is started via the start menu on windows)? ...
OK, I've now done some more experimentation. On Linux I didn't at
first notice the effect you mentioned, though I now see it's
there.
The basic point is this: at present the "./" notation does
literally what it says; that is, it references the current working
directory (CWD). This starts off as whatever directory (the OS
deems) gretl was started from, but the CWD is changed by various
gretl file operations -- apparently, more so on Windows than on
Linux, probably due to how the Windows file selector works.
As you say, this means that the effect of using "./" in filenames
in a script (or in the console) is unpredictable.
I can think of at least 3 contexts where "./" might be used:
(1) for the filename given to "store"
(2) for the filename given out "outfile"
(3) in a shell command line ("!" or "launch")
The effect in case (3) can be controlled by
set shelldir /some/path
but at present the user has no real control in cases (1) and (2).
It would not be difficult to plug "store" and "outfile" into the
shelldir mechanism, so that for example
set shelldir /some/path
outfile "./some.txt" --write
would open /some/path/some.txt.
Aother possibility (which could be combined with the above) would
be to record the CWD at startup and write that in as the default
value for shelldir. (Right now it's an empty string until set by
the user.)
That still leaves a few tricky issues.
* In the console/script context, should we pay any attention to
the GUI configuration choice of using the @userdir or the CWD as
the default for saving files? In the GUI context, this determines
the location in the filesystem at which the File, Save dialog
points initially. This could be read over into the console/script
situation, or not.
* Related to the above, should we make a distinction between the
filenames "foo" and "./foo" for opening a file for writing in the
console/script setting? The shell itself makes no such
distinction (well, it does in the case of calling executables, but
that's not what we're talking about here).
* As for setting shelldir as CWD on startup, what about (most?)
GUI users who don't even know what that directory is? From their
point of view we'd be better to let shelldir default to @userdir
-- or should we just assume that such users will never have
occasion to write such files anyway, so we can ignore them?
One point seems clear: packaged functions should never use "./"
filenames (or relative paths at all) unless they're very sure
what's implied (i.e. unless they have set shelldir or the
equivalent). Packages should not assume that the startup CWD
means anything, or is writable by the user.
Thoughts?
Allin
3:06 a.m.
New subject: dotdir
Having presented various options and problems, here's a
specific proposal. I'm open to counter-suggestions.
1. When gretl starts, we record the initial CWD and set shelldir
to this value.
2. When we come across a filename in a store or outfile (or
similar gretl) command we do the following:
(a) If it's an absolute path, respect it (of course).
(b) If it's a plain filename with no explicit path element,
we take it that @userdir is implied.
(c) If it's a "./" filename we use shelldir.
(d) Shelldir can be changed by the user via the set command,
and this will be respected in context (c).
In the context of actual "!" shell calls, you can of course do as
you like, giving absolute paths, using the @userdir variable,
setting shelldir, using "cd", or whatever. I don't propose trying
to push output into @userdir in that context.
I guess I can see a possible argument for using shelldir when
faced with a plain filename (case b), if shelldir has been
explicitly set by the user. But I'm not sure if that is more or
less confusing than always defaulting to @userdir.
Thus the notion is
store foo.gdt # gretl, write the file where you think is best
store ./foo.gdt # write the file HERE!
Allin.
2:19 p.m.
New subject: dotdir
Allin Cottrell schrieb:
1. When gretl starts, we record the initial CWD and set shelldir
to this value.
I actually thought this was already the case, so I'm all for it. (It
seems that the built-in cleverness of Python's path searching spared me
any problems related to this.)
2. When we come across a filename in a store or outfile (or
similar gretl) command we do the following:
(a) If it's an absolute path, respect it (of course).
Yes.
(b) If it's a plain filename with no explicit path element,
we take it that @userdir is implied.
No I think gretl should rather respect the user preference setting
(userdir or CWD) in this case. (Or else get rid of this preference
option in gretl and leave that stuff to the desktop environment.)
(c) If it's a "./" filename we use shelldir.
(d) Shelldir can be changed by the user via the set command,
and this will be respected in context (c).
For (c) I repeat that I would prefer to leave "./" untouched after
startup. What's the advantage for a user of being able to change ./? If
the user has a certain directory in mind, she can always provide the
(absolute or relative) path as part of the store/outfile command.
(Repeating also my second-best suggestion: make ./ the dir of the
containing script.)
Now ad (d): I like the idea very much that the context directory for "!"
can be set by a script. (I hope that's what it means.)
In the context of actual "!" shell calls, you can of course do as
you like, giving absolute paths, using the @userdir variable,
setting shelldir, using "cd", or whatever. I don't propose trying
to push output into @userdir in that context.
Now I don't quite understand this; I thought everything in a "!" line
after the ! would be just passed literally to the OS's shell. That means
I can type in absolute paths, or previously doing a "set shelldir" etc.,
but how can I use variables? For example, this does not work (I never
thought it would):
? ! python -c "f=open('(a)userdir\test.txt', 'w'); f.close()"
And wrapping with double quotes is even more problematic, because they
are needed for so many other things (paths with spaces, for example).
Thus of course the following also doesn't work:
? ! python -c "f=open('"(a)userdir"\test.txt', 'w');
f.close()"
That's why I find the "set shelldir" feature so interesting, because it
seems like the best way to achieve these things.
I guess I can see a possible argument for using shelldir when
faced with a plain filename (case b), if shelldir has been
explicitly set by the user. But I'm not sure if that is more or
less confusing than always defaulting to @userdir.
No I still think is to leave shelldir for "!" only, and for (b) see my
comment above.
So altogether my suggestions would imply:
1) If a script author wants to use the gretl user directory or some
relative path based on that (ignoring the user's preferences), she must
use the @userdir variable for store/outfile and shelldir.
2) If a script author wants to honor the user's preferences, she must
simply use a relative path to end up either in the gretl user dir or in
the CWD.
3) If a script author wants to enforce the CWD, use "./"
What's not possible by gretl's design is to use $HOME (or whatever it's
called), or did you already implement Jack's getenv suggestion?
oK, so much for that...
-sven
4 p.m.
New subject: dotdir
On Thu, 3 May 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> 1. When gretl starts, we record the initial CWD and set shelldir
> to this value.
I actually thought this was already the case, so I'm all for it.
Yes, it makes a lot of sense and I should have thought of it
before.
> 2. When we come across a filename in a store or outfile (or
> similar gretl) command we do the following:
>
> (a) If it's an absolute path, respect it (of course).
Yes.
> (b) If it's a plain filename with no explicit path element,
> we take it that @userdir is implied.
No I think gretl should rather respect the user preference setting
(userdir or CWD) in this case. (Or else get rid of this preference
option in gretl and leave that stuff to the desktop environment.)
OK, I can go with that.
> (c) If it's a "./" filename we use shelldir.
> (d) Shelldir can be changed by the user via the set command,
> and this will be respected in context (c).
For (c) I repeat that I would prefer to leave "./" untouched
after startup. What's the advantage for a user of being able to
change ./?
Well, basically the same as being able to do "cd" in the shell
itself. You can then do things without having to type (possibly
long and possibly "have-to-be-wrapped-in-quotes" filenames).
Now ad (d): I like the idea very much that the context directory
for "!" can be set by a script. (I hope that's what it means.)
Yes, that's the primary intent behind "set shelldir".
> In the context of actual "!" shell calls, you can of
course do as
> you like, giving absolute paths, using the @userdir variable,
> setting shelldir, using "cd", or whatever. I don't propose trying
> to push output into @userdir in that context.
Now I don't quite understand this; I thought everything in a "!" line
after the ! would be just passed literally to the OS's shell. That means
I can type in absolute paths, or previously doing a "set shelldir" etc.,
but how can I use variables?
For example, this does not work (I never thought it would):
? ! python -c "f=open('(a)userdir\test.txt', 'w'); f.close()"
This must be one of those wretched backslash things; it works fine
on Linux
? ! touch @userdir/test.file
? ! touch '(a)userdir/test.file'
Both are OK. I'll try some testing on Windows.
So altogether my suggestions would imply:
1) If a script author wants to use the gretl user directory or some
relative path based on that (ignoring the user's preferences), she must
use the @userdir variable for store/outfile and shelldir.
Yes, fine.
2) If a script author wants to honor the user's preferences, she
must
simply use a relative path to end up either in the gretl user dir or in
the CWD.
Ditto.
3) If a script author wants to enforce the CWD, use "./"
Again, OK.
What's not possible by gretl's design is to use $HOME (or
whatever it's called), or did you already implement Jack's
getenv suggestion?
Not yet; maybe later today.
I think the only point on which we're not quite agreed is whether
it makes sense to have "set shelldir" work as a sort of "cd" which
affects the default path for outfile and so on. But I don't have
very strong feelings about that, and I can see that it might be
cleaner to let shelldir affect only shell commands.
Allin.
4:34 p.m.
New subject: dotdir
On Thu, 3 May 2007, Allin Cottrell wrote:
> What's not possible by gretl's design is to use $HOME
(or
> whatever it's called), or did you already implement Jack's
> getenv suggestion?
Not yet; maybe later today.
Now in CVS:
nulldata 10
string foo = getenv("HOME")
print "@foo"
You get an empty string "" if the variable is not defined.
Allin.
5:02 p.m.
New subject: dotdir
Allin Cottrell schrieb:
On Thu, 3 May 2007, Sven Schreiber wrote:
> For example, this does not work (I never thought it would):
>
> ? ! python -c "f=open('(a)userdir\test.txt', 'w');
f.close()"
This must be one of those wretched backslash things; it works fine
on Linux
whoops, my mistake, with a forward slash it works fine here, too!
So I am amazed...
-sven
5:26 p.m.
New subject: dotdir
On Thu, 3 May 2007, Sven Schreiber wrote:
Allin Cottrell schrieb:
> On Thu, 3 May 2007, Sven Schreiber wrote:
>
>
>> For example, this does not work (I never thought it would):
>>
>> ? ! python -c "f=open('(a)userdir\test.txt', 'w');
f.close()"
>
> This must be one of those wretched backslash things; it works fine
> on Linux
>
whoops, my mistake, with a forward slash it works fine here, too!
So I am amazed...
Ah, that's good.
I just tested the new -g or --debug flag on XP and that seems to
work nicely. You get a console with 500 lines of scrollback.
In running on XP, I noticed that the CWD was
c:\Program Files\gretl
("set" in the gretl console shows you the value of shelldir).
I think this sort of confirms my notion that banking on a
user-writable initial CWD may not be a good idea.
Allin.
6:22 a.m.
New subject: dotdir
Allin Cottrell schrieb:
In running on XP, I noticed that the CWD was
c:\Program Files\gretl
("set" in the gretl console shows you the value of shelldir).
I think this sort of confirms my notion that banking on a
user-writable initial CWD may not be a good idea.
If it is essentially equal to @gretldir in many cases, then yes.
So this will break the existing py4gretl setup, but that's ok, I will
prepare new versions which should use @userdir for the temp files
always, now that I know how it's done.
IIRC the usage of @userdir was changed after 1.6.2 (the double-quote
wrapping issue, at my request actually -- or was it before 1.6.2?). So
I'm wondering, is there a way to use @userdir (maybe in combination with
set shelldir) such that it will be backwards compatible with old-style
usage as well?
thanks,
sven
2:08 p.m.
New subject: decimal point
It seems in the last CVS versions something is wrong
because if I select "Use locale settings for decimal point" and reinitialize
gretl, I see decimal points instead of decimal commas (but the format of the
ols output is different than unselecting this tickmark).
Apart from this I confirm that "gretl --english" (or gretl -e) is not working,
I always obtain gretl running in Spanish.
(Remember: gretl on Kubuntu Linux 7.04)
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
2:17 p.m.
New subject: decimal point
On Fri, 4 May 2007, Ignacio Diaz-Emparanza wrote:
It seems in the last CVS versions something is wrong because if
I select "Use locale settings for decimal point" and
reinitialize gretl, I see decimal points instead of decimal
commas (but the format of the ols output is different than
unselecting this tickmark).
Apart from this I confirm that "gretl --english" (or gretl -e)
is not working, I always obtain gretl running in Spanish.
(Remember: gretl on Kubuntu Linux 7.04)
Anyone have any idea what's happening here? On my own system, if
I do
LANG=es_ES gretl
I get gretl in Spanish (with decimal commas), and if I do
LANG=es_ES gretl -e
I get gretl in English.
I have now installed Ubuntu 7.04 at home, so I'll check there this
evening -- but this is puzzling.
Allin.
3 a.m.
New subject: decimal point (2)
On Fri, 4 May 2007, Ignacio Diaz-Emparanza wrote:
It seems in the last CVS versions something is wrong because if
I select "Use locale settings for decimal point" and
reinitialize gretl, I see decimal points instead of decimal
commas (but the format of the ols output is different than
unselecting this tickmark).
Apart from this I confirm that "gretl --english" (or gretl -e)
is not working, I always obtain gretl running in Spanish.
I've now experimented on Ubuntu 7.04, and I have to say I do not
understand how Ubuntu handles languages. Here's what I get,
typing the following commands in an xterm (with the locale decimal
character selected in gretl):
LANGUAGE=spanish gretl
-- I get the Spanish translation, but not the decimal comma.
LANG=spanish gretl
-- English strings plus decimal comma
LANGUAGE=spanish LANG=spanish
-- (expected by now) Spanish strings plus decimal comma.
LANGUAGE=spanish LC_ALL=spanish
-- same as above.
LANGUAGE=spanish LC_NUMERIC=spanish gretl
-- Spanish strings, no decimal comma (this seems to me to be
broken).
For comparison, on my own (non-Ubuntu, originally derived from
Slackware) Linux system I get Spanish strings and also the
decimal comma using
LANG=es_ES gretl
As for the -e or --english option, I can't replicate the problem.
In all cases where I get gretl to come up in Spanish, I can
prevent that by appending -e to the command line.
Can anyone else shed any light on this -- maybe try some
experiments and report the results?
Allin.
3:05 a.m.
New subject: decimal point (2)
One other thing occurs to me: Could you do "env" in an xterm and
report any language-related settings that appear?
Here, on Ubuntu 7.04, I'm getting
LANG=en_US.UTF-8
LANGUAGE=en_US:en
(before messing with any settings).
Allin.
3:30 a.m.
New subject: decimal point (3)
On Fri, 4 May 2007, Allin Cottrell wrote:
One other thing occurs to me: Could you do "env" in an
xterm and
report any language-related settings that appear?...
Here are some smarter experiments to try in a terminal:
locale
locale -a
LANGUAGE=english gretl
Allin.
1:31 p.m.
New subject: decimal point (2)
On Saturday 05 May 2007 05:00:11 Allin Cottrell wrote:
I've now experimented on Ubuntu 7.04, and I have to say I do not
understand how Ubuntu handles languages. Here's what I get,
typing the following commands in an xterm (with the locale decimal
character selected in gretl):
I repeated your steps, and run the suggested commands, obtaining the
following:
LANGUAGE=spanish gretl
-- I get the Spanish translation, but not the decimal comma.
The same as you.
LANG=spanish gretl
-- English strings plus decimal comma
I obtain the error:
(gretl_x11:7453): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
and gretl appears in english.
LANGUAGE=spanish LANG=spanish
-- (expected by now) Spanish strings plus decimal comma.
The same error:
LANGUAGE=spanish LANG=spanish gretl
(gretl_x11:7466): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
and gretl working in english.
LANGUAGE=spanish LC_ALL=spanish
-- same as above.
And again:
LANGUAGE=spanish LC_ALL=spanish gretl
(gretl_x11:7478): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
and gretl appears in english as well.
LANGUAGE=spanish LC_NUMERIC=spanish gretl
-- Spanish strings, no decimal comma (this seems to me to be
broken).
Now the same error is displayed, but gretl appears IN SPANISH:
LANGUAGE=spanish LC_NUMERIC=spanish gretl
(gretl_x11:7487): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
For comparison, on my own (non-Ubuntu, originally derived from
Slackware) Linux system I get Spanish strings and also the
decimal comma using
LANG=es_ES gretl
LANG=es_ES gretl
(gretl_x11:7500): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
And now gretl appears in English.
As for the -e or --english option, I can't replicate the problem.
In all cases where I get gretl to come up in Spanish, I can
prevent that by appending -e to the command line.
I can see no error when executing "gretl --english" (or gretl -e) but gretl
appears in Spanish.
On Saturday 05 May 2007 05:05:35 Allin Cottrell wrote:
One other thing occurs to me: Could you do "env" in an
xterm and
report any language-related settings that appear?
etpdihei@ataul:~$ env
KDE_MULTIHEAD=false
SSH_AGENT_PID=5827
DM_CONTROL=/var/run/xdmctl
TERM=xterm
SHELL=/bin/bash
XDM_MANAGED=/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,rsvd,method=classic
GTK2_RC_FILES=/home/etpdihei/.gtkrc-2.0-kde:/home/etpdihei/.kde/share/config/gtkrc-2.0
GTK_RC_FILES=/etc/gtk/gtkrc:/home/etpdihei/.gtkrc:/home/etpdihei/.kde/share/config/gtkrc
GS_LIB=/home/etpdihei/.fonts
WINDOWID=50331655
KDE_FULL_SESSION=true
USER=etpdihei
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35:
SSH_AUTH_SOCK=/tmp/ssh-lKPOpq5788/agent.5788
SESSION_MANAGER=local/ataul:/tmp/.ICE-unix/5882
KONSOLE_DCOP=DCOPRef(konsole-6298,konsole)
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/gretl/bin
DESKTOP_SESSION=default
KONSOLE_DCOP_SESSION=DCOPRef(konsole-6298,session-1)
PWD=/home/etpdihei
LANG=es_ES.UTF-8
HISTCONTROL=ignoreboth
HOME=/home/etpdihei
SHLVL=1
XCURSOR_THEME=kubuntu
LOGNAME=etpdihei
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-VHlGrh68ye,guid=699f601a192cb1fedf381e00463ed1a1
LESSOPEN=| /usr/bin/lesspipe %s
DISPLAY=:0.0
LESSCLOSE=/usr/bin/lesspipe %s %s
COLORTERM=
_=/usr/bin/env
On Saturday 05 May 2007 05:30:30 Allin Cottrell wrote:
On Fri, 4 May 2007, Allin Cottrell wrote:
> One other thing occurs to me: Could you do "env" in an xterm and
> report any language-related settings that appear?...
Here are some smarter experiments to try in a terminal:
locale
locale -a
LANGUAGE=english gretl
etpdihei@ataul:~$ locale
LANG=es_ES.UTF-8
LC_CTYPE="es_ES.UTF-8"
LC_NUMERIC="es_ES.UTF-8"
LC_TIME="es_ES.UTF-8"
LC_COLLATE="es_ES.UTF-8"
LC_MONETARY="es_ES.UTF-8"
LC_MESSAGES="es_ES.UTF-8"
LC_PAPER="es_ES.UTF-8"
LC_NAME="es_ES.UTF-8"
LC_ADDRESS="es_ES.UTF-8"
LC_TELEPHONE="es_ES.UTF-8"
LC_MEASUREMENT="es_ES.UTF-8"
LC_IDENTIFICATION="es_ES.UTF-8"
LC_ALL=
etpdihei@ataul:~$ locale -a
C
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
es_AR.utf8
es_BO.utf8
es_CL.utf8
es_CO.utf8
es_CR.utf8
es_DO.utf8
es_EC.utf8
es_ES.utf8
es_GT.utf8
es_HN.utf8
es_MX.utf8
es_NI.utf8
es_PA.utf8
es_PE.utf8
es_PR.utf8
es_PY.utf8
es_SV.utf8
es_US.utf8
es_UY.utf8
es_VE.utf8
POSIX
LANGUAGE=english gretl
It works. There is no error, and gretl appears in English.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
4:47 p.m.
New subject: decimal point (2)
On Mon, 7 May 2007, Ignacio Diaz-Emparanza wrote:
On Saturday 05 May 2007 05:00:11 Allin Cottrell wrote:
> I've now experimented on Ubuntu 7.04, and I have to say I do not
> understand how Ubuntu handles languages. Here's what I get,
> typing the following commands in an xterm (with the locale decimal
> character selected in gretl):
I repeated your steps, and run the suggested commands, obtaining the
following...
Thanks Ignacio. I should be able to figure out what's going on
from this.
Allin.
8:43 p.m.
New subject: decimal point (2)
On Mon, 7 May 2007, Ignacio Diaz-Emparanza wrote:
I repeated your steps, and run the suggested commands, obtaining the
following...
I have made a few changes in CVS after studying the output you
sent.
I'm still sowewhat baffled by Ubuntu's handling of locales, but
maybe the changes will help.
Allin.
7:14 a.m.
New subject: decimal point (2)
Allin Cottrell schrieb:
On Mon, 7 May 2007, Ignacio Diaz-Emparanza wrote:
> I repeated your steps, and run the suggested commands, obtaining the
> following...
I have made a few changes in CVS after studying the output you
sent.
I'm still sowewhat baffled by Ubuntu's handling of locales, but
maybe the changes will help.
My only credentials in this area are that I also had a problem with
locales on Ubuntu once, and I don't really know what your problem is,
but here are some possibly related comments:
* Are you guys sure that the "spanish" alias refers to Spanish in Spain
in all cases? AFAIK in Latin America the decimal separator may well be
the dot.
* Are the locales really present, maybe they need to be regenerated
(recent upgrade to Feisty?), which IIRC is a bit complicated.
good luck,
sven
2:59 p.m.
New subject: decimal point (2)
On Tuesday 08 May 2007 22:43:32 Allin Cottrell wrote:
On Mon, 7 May 2007, Ignacio Diaz-Emparanza wrote:
> I repeated your steps, and run the suggested commands, obtaining the
> following...
I have made a few changes in CVS after studying the output you
sent.
I'm still sowewhat baffled by Ubuntu's handling of locales, but
maybe the changes will help.
Allin.
_______________________________________________
Allin, I reinstalled Gretl from the CVS and repeated again the steps you
mentioned in your message some days ago, and run the suggested commands.
I obtained the following:
> LANGUAGE=spanish gretl
>
> -- I get the Spanish translation, but not the decimal comma.
The same.
> LANG=spanish gretl
>
> -- English strings plus decimal comma
I obtain the error:
(gretl_x11:6261): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
and gretl appears in english.
> LANGUAGE=spanish LANG=spanish
>
> -- (expected by now) Spanish strings plus decimal comma.
The same error:
(gretl_x11:6270): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
and gretl working in english.
> LANGUAGE=spanish LC_ALL=spanish
This changed from what happened some days before, now I obtain gretl running
in Spanish, but the decimals are not commas.
> LANGUAGE=spanish LC_NUMERIC=spanish gretl
>
> -- Spanish strings, no decimal comma (this seems to me to be
> broken).
Now the same error is displayed, but gretl appears IN SPANISH:
(gretl_x11:6292): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Gretl working in english
> For comparison, on my own (non-Ubuntu, originally derived from
> Slackware) Linux system I get Spanish strings and also the
> decimal comma using
>
> LANG=es_ES gretl
LANG=es_ES gretl
(gretl_x11:6301): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
And gretl appears in English.
> As for the -e or --english option, I can't replicate the problem.
> In all cases where I get gretl to come up in Spanish, I can
> prevent that by appending -e to the command line.
I can see no error when executing "gretl --english" (or gretl -e) but gretl
appears in Spanish.
Thi is corrected now, the command "gretl --english" (or gretl -e) produces
Gretl running in English, and no error message.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
8:44 p.m.
New subject: decimal point (2)
On Thu, 10 May 2007, Ignacio Diaz-Emparanza wrote:
On Tuesday 08 May 2007 22:43:32 Allin Cottrell wrote:
> On Mon, 7 May 2007, Ignacio Diaz-Emparanza wrote:
> > I repeated your steps, and run the suggested commands, obtaining the
> > following...
>
> I have made a few changes in CVS after studying the output you
> sent.
>
> I'm still sowewhat baffled by Ubuntu's handling of locales, but
> maybe the changes will help.
Allin, I reinstalled Gretl from the CVS and repeated again the steps you
mentioned in your message some days ago, and run the suggested commands.
I obtained the following...
Thanks.
In an earlier message you reported that your LANG setting was
es_ES.UTF-8. In current CVS gretl, when the "locale decimal
separator" is selected, at the startup of the program you should
see (on stderr, e.g. when started from a terminal), something like
setlocale(LC_NUMERIC, "es_ES.UTF-8") returned es_ES.UTF-8
That is, gretl reads the LANG setting from the environment and
issues the instruction to set LC_NUMERIC to the same value.
If you see this, but are not getting the decimal comma, then I
think it is a broken locale setting on Kubuntu to blame. In which
case you could try
sudo localedef -i es_ES -f UTF-8 es_ES.UTF-8
Allin.
8:33 a.m.
New subject: decimal point (2)
On Thursday 10 May 2007 22:44:34 Allin Cottrell wrote:
In an earlier message you reported that your LANG setting was
es_ES.UTF-8. In current CVS gretl, when the "locale decimal
separator" is selected, at the startup of the program you should
see (on stderr, e.g. when started from a terminal), something like
setlocale(LC_NUMERIC, "es_ES.UTF-8") returned es_ES.UTF-8
That is, gretl reads the LANG setting from the environment and
issues the instruction to set LC_NUMERIC to the same value.
If you see this, but are not getting the decimal comma, then I
think it is a broken locale setting on Kubuntu to blame. In which
case you could try
sudo localedef -i es_ES -f UTF-8 es_ES.UTF-8
Allin.
_______________________________________________
Well, I see
setlocale(LC_NUMERIC, "es_ES.UTF-8") returned es_ES.UTF-8
but don't get the decimal comma.
I tried to use the command "localedef" as you suggested but all is the same.
In other applications as openoffice-calc or kcalc I am getting the decimal
comma without any problem.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
2:31 p.m.
New subject: decimal point (2)
On Fri, 11 May 2007, Ignacio Diaz-Emparanza wrote:
Well, I see
setlocale(LC_NUMERIC, "es_ES.UTF-8") returned es_ES.UTF-8
but don't get the decimal comma.
Could you try compiling and running this little program?
/* start program */
#include <stdio.h>
#include <stdlib.h>
#include <locale.h>
int main (int argc, char **argv)
{
char *ret;
if (argc != 2) {
fprintf(stderr, "Please give a language specifier\n");
exit(EXIT_FAILURE);
}
ret = setlocale(LC_NUMERIC, NULL);
printf("Default: LC_NUMERIC=%s\n", ret);
printf("one-point-five: %g\n", 1.5);
ret = setlocale(LC_NUMERIC, argv[1]);
printf("After setlocale: LC_NUMERIC=%s\n", ret);
printf("one-point-five: %g\n", 1.5);
return 0;
}
/* end program */
Try saving the above as point.c, and do
gcc -Wall -o point point.c
Then
./point es_ES.UTF-8
Here I get:
waverley:~$ gcc -Wall -o point point.c
waverley:~$ ./point es_ES.UTF-8
Default: LC_NUMERIC=C
one-point-five: 1.5
After setlocale: LC_NUMERIC=es_ES.UTF-8
one-point-five: 1,5
If you get the same then there is a problem somewhere in gretl.
Allin.
9:02 p.m.
New subject: dotdir
On Fri, 4 May 2007, Sven Schreiber wrote:
IIRC the usage of @userdir was changed after 1.6.2 (the double-quote
wrapping issue, at my request actually -- or was it before 1.6.2?).
I think it was after 1.6.2.
So I'm wondering, is there a way to use @userdir (maybe in
combination with set shelldir) such that it will be backwards
compatible with old-style usage as well?
Yes, I think that should work, e.g. I just tested
set shelldir "@userdir/foo bar"
and that ought to work in 1.6.2.
Allin.
2:07 p.m.
New subject: dotdir (was Belated response to Sven on function packages)
[More answers to your concrete proposal in another email right after
this one.]
Allin Cottrell schrieb:
(3) in a shell command line ("!" or "launch")
The effect in case (3) can be controlled by
set shelldir /some/path
This "set shelldir" thing is very interesting, but it seems
undocumented!? I will think about whether it can be used to solve the
temp file location issue for py4gretl.
* In the console/script context, should we pay any attention to
the GUI configuration choice of using the @userdir or the CWD as
the default for saving files? In the GUI context, this determines
the location in the filesystem at which the File, Save dialog
points initially. This could be read over into the console/script
situation, or not.
Yes I think that would be useful and intuitive, just like the other
settings there are also honored by console/script gretl.
* Related to the above, should we make a distinction between the
filenames "foo" and "./foo" for opening a file for writing in the
console/script setting?
Yes, please. I think we actually discussed part of this issue some time
ago when I requested a change of the store/outfile behavior and you were
so kind to do it. The "only" remaining issue is the rule for "./".
The shell itself makes no such
distinction (well, it does in the case of calling executables, but
that's not what we're talking about here).
I don't understand this, can you explain?
* As for setting shelldir as CWD on startup, what about (most?)
GUI users who don't even know what that directory is? From their
point of view we'd be better to let shelldir default to @userdir
-- or should we just assume that such users will never have
occasion to write such files anyway, so we can ignore them?
Yes I think we can, I don't see how anybody would be affected by
changing shelldir from an empty string to something else.
One point seems clear: packaged functions should never use "./"
filenames (or relative paths at all) unless they're very sure
what's implied (i.e. unless they have set shelldir or the
equivalent). Packages should not assume that the startup CWD
means anything, or is writable by the user.
Well py4gretl uses "./"! :-) Not because it's clean, but because
otherwise one would have to tell the user how to set her preferences for
file saving locations. At least that's what I thought, I realize there
are still things I don't know about gretl scripting. Maybe the shelldir
thing in combination with the @userdir variable makes it unnecessary, I
will think about it.
Thanks for reading,
-sven
3:40 p.m.
New subject: dotdir (was Belated response to Sven on function packages)
On Thu, 3 May 2007, Sven Schreiber wrote:
> set shelldir /some/path
This "set shelldir" thing is very interesting, but it seems
undocumented!? I will think about whether it can be used to solve the
temp file location issue for py4gretl.
I'll make sure it's documented for 1.6.3. It came up in
discussion about scripting with Ignacio (I can't remember now on
which gretl list but it's in the archive somewhere).
> * In the console/script context, should we pay any attention to
> the GUI configuration choice of using the @userdir or the CWD as
> the default for saving files? In the GUI context, this determines
> the location in the filesystem at which the File, Save dialog
> points initially. This could be read over into the console/script
> situation, or not.
Yes I think that would be useful and intuitive, just like the other
settings there are also honored by console/script gretl.
OK, that sounds reasonable.
> * Related to the above, should we make a distinction between the
> filenames "foo" and "./foo" for opening a file for writing in
the
> console/script setting?
Yes, please. I think we actually discussed part of this issue some time
ago when I requested a change of the store/outfile behavior and you were
so kind to do it. The "only" remaining issue is the rule for "./".
The shell itself makes no such
> distinction (well, it does in the case of calling executables, but
> that's not what we're talking about here).
I don't understand this, can you explain?
I'll try! In the shell, it usually makes no difference if you do
touch foo OR touch ./foo
rm foo OR rm ./foo
Either way the operation takes place in the CWD: the second form
makes that explicit, but it's implicit in the first. On the other
hand, "test" versus "./test" (execution) may well make a
difference, depending on the path and the CWD.
So, now, consider
outfile foo --write
vs
outfile ./foo --write
I think maybe we're converging on this (?): (a) if your preference
is set to use @userdir by default, the first variant writes foo to
@userdir but (b) if your preference is to use the CWD, it writes
to the CWD. The second variant, by contrast, always writes to the
CWD.
> One point seems clear: packaged functions should never use
"./"
> filenames (or relative paths at all) unless they're very sure
> what's implied (i.e. unless they have set shelldir or the
> equivalent). Packages should not assume that the startup CWD
> means anything, or is writable by the user.
Well py4gretl uses "./"! :-) Not because it's clean, but because
otherwise one would have to tell the user how to set her preferences for
file saving locations. At least that's what I thought, I realize there
are still things I don't know about gretl scripting. Maybe the shelldir
thing in combination with the @userdir variable makes it unnecessary, I
will think about it.
OK, this is complex. If it's just a matter of writing temporary
files, then I suppose "./" may be OK. (Though it's not guaranteed
that "./" is writable by the user.) I was thinking more of files
that are intended to be findable by the user, and my point was
just that the user may have no idea where "./" is.
More in reply to your second message!
Allin.
6443
days inactive
6458
days old
35 comments
3 participants
participants (3)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Sven Schreiber