2:28 p.m.
Hello translators: I think most of you are now using direct access
to gretl CVS, but I have just sent an updated gretl.pot file to IRO
in preparation for the gretl 1.5.1 release.
I won't add or change any more translatable strings at this point.
But we're still taking bug reports. I'll try to track down the
issue Jack mentioned, with gretlcli.exe crashing in the win32
console.
Any test results for the model table, using the latest Windows
snapshot?
--
Allin Cottrell
Department of Economics
Wake Forest University, NC
2:45 p.m.
On Tue, March 7, 2006 15:28, Allin Cottrell wrote:
But we're still taking bug reports. I'll try to track down
the
issue Jack mentioned, with gretlcli.exe crashing in the win32
console.
Any test results for the model table, using the latest Windows
snapshot?
The two things may be related IMO. I saw the crash reported in my other post
while investigating the model table crash (which I HAVE seen in my qemu
session -- it happens both right- and double-clicking the Model Table Icon).
But again, they may be independent of one another and there is the possibility
that it's just qemu fault (although that seems a bit odd).
The reason why I was launching gretl from the command line is that I wanted to
have a look at stderr --- how do you do that in windows?
--
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
2:57 p.m.
On Tue, 7 Mar 2006, Riccardo Jack Lucchetti wrote:
> But we're still taking bug reports. I'll try to track
down the
> issue Jack mentioned, with gretlcli.exe crashing in the win32
> console.
>
> Any test results for the model table, using the latest Windows
> snapshot?
The two things may be related IMO...
Actually, I think this was a matter of two independent bugs, each a
side-effect of a "fix" for a separate issue.
The reason why I was launching gretl from the command line is that
I wanted to have a look at stderr --- how do you do that in
windows?
I'd be interested in the answer to that too. I have the impression
that Windows just doesn't know about stderr.
Allin.
4:56 p.m.
Allin Cottrell schrieb:
> The reason why I was launching gretl from the command line is that I
> wanted to have a look at stderr --- how do you do that in windows?
I'd be interested in the answer to that too. I have the impression that
Windows just doesn't know about stderr.
I'm definitely the wrong person to ask, so I don't know how much the
following helps, but windows at least seems to know something about stderr:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/...
-sven
2:56 p.m.
On 3/7/06, Allin Cottrell <cottrell(a)wfu.edu> wrote:
But we're still taking bug reports. I'll try to track down
the
issue Jack mentioned, with gretlcli.exe crashing in the win32
console.
I can confirm this issue with Gretl 1.5.0 (03/05/2006) on a "native" Win XP.
Any test results for the model table, using the latest Windows
snapshot?
This works now fine for me on the above mentioned configuration.
Best wishes,
jean
3:07 p.m.
jean ries schrieb:
On 3/7/06, Allin Cottrell <cottrell(a)wfu.edu> wrote:
> But we're still taking bug reports. I'll try to track down the
> issue Jack mentioned, with gretlcli.exe crashing in the win32
> console.
I can confirm this issue with Gretl 1.5.0 (03/05/2006) on a "native" Win XP.
> Any test results for the model table, using the latest Windows
> snapshot?
This works now fine for me on the above mentioned configuration.
Same for me on both accounts.
With respect to the cli-crash: If I don't just <enter> at the output
prompt, but type in something (here: "hallo"), I get the following gretl
error message before the crash:
type a filename to store output (enter to quit): hallo
Schreibe Sitzungsausgabe nach C:\userdata\gretl\user\hallo
Die Syntax für den Dateinamen, Verzeichnisnamen oder die
Datenträgerbezeichnung
ist falsch.
"c:\userdata\gretl\\gretlcli" -b "C:\userdata\gretl\user\session.inp"
>
"C:\user
data\gretl\user\hallo"
Note the double backslash in the first quoted path, is that ok?
-sven
3:30 p.m.
Any test results for the model table, using the latest Windows
snapshot?
I tried with the current snapshot. The model table seems to work well, but
gretl crashes if I try to save a session that contains an estimated model. If
the session does not contains a model I can save it.
I also have problems saving the session in the gretlcli console.
--
Ignacio Díaz-Emparanza
Dpto. de Economía Aplicada III (Econometría y Estadística)
UPV-EHU
5:14 p.m.
On Tue, 7 Mar 2006, Ignacio Díaz-Emparanza wrote:
I tried with the current snapshot. The model table seems to work
well, but gretl crashes if I try to save a session that contains
an estimated model. If the session does not contains a model I can
save it.
I need to go over the whole of gui2/session.c more carefully. I
redefined a "session model" in what I think is an improved way, but
now any functions that have not been brought up to date with that
change are broken. It looks as if saving a session model is in that
category. I'll fix it up.
Allin.
5:32 p.m.
On Tue, March 7, 2006 18:14, Allin Cottrell wrote:
On Tue, 7 Mar 2006, Ignacio Díaz-Emparanza wrote:
> I tried with the current snapshot. The model table seems to work
> well, but gretl crashes if I try to save a session that contains
> an estimated model. If the session does not contains a model I can
> save it.
I need to go over the whole of gui2/session.c more carefully. I
redefined a "session model" in what I think is an improved way, but
now any functions that have not been brought up to date with that
change are broken. It looks as if saving a session model is in that
category. I'll fix it up.
While you're at it, the crash I reported with gretlcli on win appears to hit
the linux version too :-(
I'm sorry I won't be able to give more details until tomorrow.
--
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
5:37 p.m.
On Tue, March 7, 2006 18:32, Riccardo Jack Lucchetti"" wrote:
While you're at it, the crash I reported with gretlcli on win appears to hit
the linux version too :-(
I'm sorry I won't be able to give more details until tomorrow.
To be more precise:
jack@ec-4:~$ gretlcli
gretl version 1.5.0
Copyright Ramu Ramanathan and Allin Cottrell
This is free software with ABSOLUTELY NO WARRANTY
Current session: 2006/03/07 18:35
"help" gives a list of commands
Type "open filename" to open a data set
? open djclose
open djclose
Read datafile /usr/local/share/gretl/data/misc/djclose.gdt
periodicity: 5, maxobs: 2528,
observations range: 1980/01/02-1989/12/29
Listing 2 variables:
0) const 1) djclose
? q
commands saved as /home/jack/gretl/session.inp
type a filename to store output (enter to quit):
Segmentation fault
jack@ec-4:~$
-----------------------------
Riccardo "Jack" Lucchetti
Dipartimento di Economia
Facoltà di Economia "G. Fuà"
Ancona
11:19 p.m.
Allin Cottrell schrieb:
Hello translators: I think most of you are now using direct access
to
gretl CVS, but I have just sent an updated gretl.pot file to IRO in
preparation for the gretl 1.5.1 release.
I won't add or change any more translatable strings at this point.
While I was working on de.po (sort of offline), the cvs-version changed,
and when I updated my local tree, the cvs-client indicated a conflict.
Should I have committed before trying another update? And what do I do
now to resolve the conflict and merge my changes?
thanks for your help,
sven
10:12 a.m.
On Wed, Mar 08, 2006 at 12:19:06AM +0100, Sven Schreiber wrote:
While I was working on de.po (sort of offline), the cvs-version changed,
and when I updated my local tree, the cvs-client indicated a conflict.
Should I have committed before trying another update?
Yes, to avoid conflicts it's best practice to commit changes as soon as they are
finalized.
And what do I do now to resolve the conflict and merge my changes?
In principle you could dig into the file and manually examine all the sections
marked with
<<<<<
...
=====
...
>>>>
as it's explained in
http://cvsbook.red-bean.com/cvsbook.html#Detecting%20And%20Resolving%20Co...
But in the case of .po files that's not convenient, because typically you'll
have to deal with LOTS of changes (and most changes have to do with comments).
So I suggest to use the "merge" feature of your favourite po editor (e.g.
poedit, kbabel...) to automatically transfer the new translated strings from
your old working copy (the cvs client should have saved a copy as
".#de.po.revision") to the newer cvs revision.
If you are using a simple text editor to edit po files, you can use the
"msgmerge" command line utility (from the "gettext" package), like
this:
msgmerge your_original_working_copy.po cvs_copy.po > output.po
output.po will have the same structure of the newer cvs po file and will include
the translations you had in your original working copy (and perhaps some new
and fuzzy strings to translate).
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
1:10 p.m.
Cristian Rigamonti schrieb:
On Wed, Mar 08, 2006 at 12:19:06AM +0100, Sven Schreiber wrote:
> While I was working on de.po (sort of offline), the cvs-version changed,
> and when I updated my local tree, the cvs-client indicated a conflict.
> Should I have committed before trying another update?
Yes, to avoid conflicts it's best practice to commit changes as soon as they are
finalized.
Thanks for your help; just for clarification, do you mean "don't wait
too long" or do you mean "commit first, not checking for updates before
that"?
> And what do I do now to resolve the conflict and merge my changes?
So I suggest to use the "merge" feature of your favourite
po editor (e.g.
poedit, kbabel...) to automatically transfer the new translated strings from
your old working copy (the cvs client should have saved a copy as
".#de.po.revision") to the newer cvs revision.
I will do that tonight, I'm using poedit on win (basically the only
choice...). Could there arise any further problems if yet another de.po
update appears in the meantime, before I can merge the changes?
Cheers,
Sven
2:31 p.m.
On Wed, 8 Mar 2006, Sven Schreiber wrote:
Cristian Rigamonti schrieb:
> On Wed, Mar 08, 2006 at 12:19:06AM +0100, Sven Schreiber wrote:
>> While I was working on de.po (sort of offline), the cvs-version changed,
>> and when I updated my local tree, the cvs-client indicated a conflict.
>> Should I have committed before trying another update?
>
> Yes, to avoid conflicts it's best practice to commit changes as soon as they are
> finalized.
Thanks for your help; just for clarification, do you mean "don't wait
too long" or do you mean "commit first, not checking for updates before
that"?
No, you have to update first. If you try to commit when you're not
up to date with the Repository you'll just get an error message from
CVS.
I will do that tonight, I'm using poedit on win (basically the
only choice...). Could there arise any further problems if yet
another de.po update appears in the meantime, before I can merge
the changes?
Sorry for the inconvenience, but this shouldn't happen very often.
The de.po file will change -- independently of the changes you are
making -- only when I do "make update-po" in the gretl source tree.
And I do that only when we've accumulated a fair number of changes
to the gretl.pot file. (If I don't do that, the new strings will
never make it into the .po files.)
Since I think we now have all the active translators on the
gretl-users list, perhaps I should get into the habit of posting a
warning to this list when I'm doing an "update-po".
Allin.
2:46 p.m.
On Wed, Mar 08, 2006 at 02:10:07PM +0100, Sven Schreiber wrote:
Thanks for your help; just for clarification, do you mean "don't wait
too long"
Yes.
or do you mean "commit first, not checking for updates before
that"?
The safest procedure with respect to the risk of conflicts is:
- cvs update
- make your local changes
- cvs commit
minimizing the time elapsed between the steps.
I will do that tonight, I'm using poedit on win (basically the
only
choice...).
If you are using poedit, all you have to do is to open your "old" de.po file
(the
one not modified by the latest cvs update operation, a copy of which should have
been saved by your cvs client as ".#de.po.REVISION") and then select
"Catalog ->
Update from POT file" in poedit's menu, and select the latest revision of
"gretl.pot" as the POT file.
This way, you'll merge the new strings coming from the latest POT file into your
old working copy (preserving your old not-yet-committed translations).
Then you can fix the fuzzy and new strings, update the catalog version ("Catalog
-> Settings") to 1.5.1, save the result as de.po and commit it.
Could there arise any further problems if yet another de.po
update appears in the meantime, before I can merge the changes?
In principle that could happen, and you'd just have to do a cvs update before
doing the things I mentioned above (the key point is to keep a copy of your
"old" not-yet-committed po file); in practice, Allin said that there won't
be
any string changes until the release of 1.5.1, so don't worry! :-)
Cri
--
GPG/PGP Key-Id 0x943A5F0E - http://www.linux.it/~cri/cri.asc
Free software, free society - http://www.fsfeurope.org
1:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
Allin Cottrell wrote:
> Hello translators: I think most of you are now using direct
access to
> gretl CVS, but I have just sent an updated gretl.pot file to IRO in
> preparation for the gretl 1.5.1 release.
>
> I won't add or change any more translatable strings at this point.
Me and Raquel are working on the Portuguese translation. But this is a
new one. I have already some work done, but there are many differences
from the gretl.pot. I don't even know how to merge the template on kbabel.
Should Allin copy gretl.pot to pt_PT.po and pt_BR.po on the CVS tree,
and then we have a fresh start from them?
(Raquel will work more on this, since I got a job as Technical Writer
and I'm too busy at the moment.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEENZ6HvesJJ5UqvkRAgfsAJ98SBfNCNUYYmeC86xtNVyFRPK3ogCeLBsS
DZVsDUbbKssbicIoxEh7yYY=
=wqk/
-----END PGP SIGNATURE-----
10:24 a.m.
El Viernes, 10 de Marzo de 2006 02:29, HelioSoft de Hélio Guilherme escribió:
...
Me and Raquel are working on the Portuguese translation. But this is a
new one. I have already some work done, but there are many differences
from the gretl.pot. I don't even know how to merge the template on kbabel.
I use Kbabel as well. You can open the gretl.pot file and then go to
"tools/quick translation" (sorry, my kbabel is in Spanish and I am
translating this strings to English, they may be not very exact) at the
right-bottom you may "configure" a catalog for translations. Selecting
"database" and "explore a PO file" you may select your previous
translated po
file and clicking on "accept" and "start" (at the right-above) the
entries of
the pot file will be filled with the strings on your old po file. The problem
I see is that you may do all of them be marked as fuzzy or none of them. And
it is not optimal.
As you use Kbabel I suppose you are using Linux, and probably you have
installed the "gettext" package. This includes a utility called
"msgmerge"
that provides a better way to do waht you want. You may use "msgmerge" in a
similar way as indicated by Cri last week:
msgmerge gretl.previous.po.pt gretl.pot > gretl.new.po.pt
gretl.new.po.pt will have the same structure of the newer gretl.pot file and
will include the translations you had in your original .po, but will have
marked as fuzzy only the entries that msmerge "guess" and so perhaps they are
not exact translations.
--
Ignacio Díaz-Emparanza
Spanish translator of gretl
6867
days inactive
6870
days old
17 comments
7 participants
participants (7)
-
Allin Cottrell -
Cristian Rigamonti -
HelioSoft de Hélio Guilherme -
Ignacio Díaz-Emparanza -
jean ries -
Riccardo Jack Lucchetti -
Sven Schreiber