Re: some csv feedback
On Tuesday 10 July 2007 00:53, Derek Atkins wrote:
Christian Stimming [EMAIL PROTECTED] writes:
Then, I have a conceptual addition with dates. Do you already have plans
for different date separators? In the struct date_format_internal there
is only '/'. Eventually, the code needs to take several different date
separators into account. I know of 2007/06/05 and 2007-06-05 and
05.06.2007, i.e. the separator is one of [/-.], but there might be
others. Maybe
http://en.wikipedia.org/wiki/Date_and_time_notation_by_country tells of
some, but maybe that page is just a prime example of the wiki principle
failing gloriously. Heh :-)
The QIF code has a decent date parser, although it's in scheme
right now. The regex looks like:
^ *([0-9]+) *[-/.'] *([0-9]+) *[-/.'] *([0-9]+).*$|^
*([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]).*$
In other words the seperators are a dash (-), slash (/), period (.),
and single quote ('). Also note that there's no requirement that you
use the same separator both times. E.g. you could use 7/1'07 and this
is a perfectly valid date.
That's true, but 7/1'07 has a different meaning than 7/1/07 esp. if bot
versions are used in the same file. This is important if you try to import
ancient data from the last century. Also, there is no consitant usage of the
apostrophe version among the various products even if they come from the same
manufacturer (Quicken in this case).
--
Regards
Thomas Baumgart
GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA
-
Windows are like... windows. Shiny, fragile, expensive.
-
pgpna4ZU1MeJe.pgp
Description: signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-fr] Special Translations for Windows menu items, anyone?
Quoting Nikos Charonitakis [EMAIL PROTECTED]: http://svn.gnucash.org/trac/browser/gnucash/trunk/packaging/win32/gnucash.iss.in?format=raw Unfortunately the file contains characters by at least two different encodings by now: iso-8859-1 for the German umlauts, and iso-8859-7 for the Greek text. I hope this works out fine. hm, this is windows world... utf8 not supported? No, utf8 is not supported. In this particular case it's the fault of our Setup generator Inno Setup in that it supports only 8bit character encoding and it has to switch the codepages appropriately. There are some FAQs on Inno Setup's pages talking about either Unicode or Utf8, but there is no doubt this is currently not supported in Inno. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some csv feedback
Thanks for all of your comments!
Christian and I already discussed some of his email in #gnucash, but
I'll summarize that discussion here, and respond to the rest of his
comments as well as those from Derek and Thomas about the date
parsing.
On 7/8/07, Christian Stimming [EMAIL PROTECTED] wrote:
(I have to admit I haven't been able to compile your branch due to goffice
issues in lib/stf, but I'm quite sure I'll figure these out soon.)
I just committed some changes that should make the lib/stf code
compile with goffice 0.2, but if anyone still has problems, please let
me know. For now, I've commented out the calls to functions that are
in goffice-0.3, and I'll uncomment them eventually once goffice-0.3 is
common in distros. However, it would be nice if I could use some kind
of macro to do this for me, such as
#ifdef GOFFICE_VERSION_0_3
goffice_0_3_call();
#else
replacement_code();
#endif
Is there anything like this?
When looking into the glade dialog, I'm a bit surprised about the multitude of
checkboxes for the possible field separators. I think this is probably an
area where you might consider different widget(s) eventually (a list view
with multiple selections possible?), but for now this should be fine.
The checkboxes are just an imitation of the import feature in
Gnumeric. I agree, eventually this should be changed to something a
bit easier.
I have some smaller suggestions on how you could improve your code even more.
I encountered some compile warnings:
gnc-csv-model.c: In function 'gnc_parse_to_trans':
gnc-csv-model.c:485: warning: 'begin_error_lines' may be used uninitialized in
this function
gnc-csv-model.c:485: warning: 'error_lines' may be used uninitialized in this
function
gnc-csv-model.c:487: warning: 'last_transaction' may be used uninitialized in
this function
These should be gone now. However, I cannot get any uninitialized
warnings to show up for me, because I am passing the following
warnings to gcc:
CFLAGS = -Werror -Wdeclaration-after-statement -Wno-pointer-sign
-D_FORTIFY_SOURCE=2 -Wall -g -O2 -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wno-unused
I am not sure how to get -Wall to appear after the -Wno-unused flag.
Christian mentioned that GNOME_COMPILE_WARNINGS is somehow adding that
in and that depends on the version of GNOME I'm running. I am running
2.18.1 (in Ubuntu 7.04); does anyone know how to fix this?
Then, I have some suggestions from the MS Windows front. You are using some
unix-specific file handling system calls. Although those are fine on Unix,
they don't carry over well to MS Windows, and in almost any case the glib
library has some more general function because of that.
I've now replaced those calls with the glib equivalents; it also has
added benefit of chopping out quite a bit of code!
And eventually I saw some instances of g_malloc(sizeof()) in your code... I
think as we are now in glib time we shouldn't have to deal with the sizeof()
anymore, and I'd suggest the following replacement:
Foo *x = g_malloc(sizeof(Foo)) - Foo *x = g_new(Foo, 1) // or even g_new0()
Okay, I've replaced all those calls.
On 7/10/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Tuesday 10 July 2007 00:53, Derek Atkins wrote:
Christian Stimming [EMAIL PROTECTED] writes:
Then, I have a conceptual addition with dates. Do you already have plans
for different date separators? In the struct date_format_internal there
is only '/'. Eventually, the code needs to take several different date
separators into account. I know of 2007/06/05 and 2007-06-05 and
05.06.2007, i.e. the separator is one of [/-.], but there might be
others. Maybe
http://en.wikipedia.org/wiki/Date_and_time_notation_by_country tells of
some, but maybe that page is just a prime example of the wiki principle
failing gloriously. Heh :-)
The QIF code has a decent date parser, although it's in scheme
right now. The regex looks like:
^ *([0-9]+) *[-/.'] *([0-9]+) *[-/.'] *([0-9]+).*$|^
*([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]).*$
In other words the seperators are a dash (-), slash (/), period (.),
and single quote ('). Also note that there's no requirement that you
use the same separator both times. E.g. you could use 7/1'07 and this
is a perfectly valid date.
That's true, but 7/1'07 has a different meaning than 7/1/07 esp. if bot
versions are used in the same file. This is important if you try to import
ancient data from the last century. Also, there is no consitant usage of the
apostrophe version among the various products even if they come from the same
manufacturer (Quicken in this case).
Thomas, sorry, could you clarify what the difference between 7/1'07
and 7/1/07 is for me? Is it a distinction between the years 2007 and
1907?
If so, is it actually used in that way frequently? If it is, then I
guess we probably have to specify separators. Otherwise, is it
reasonable to simply guess at the year if only
QIF/CSV import date parsing code
Hi Chintan, I think I'm at the point with the CSV import where I would be ready to integrate a date parser that could be used by both the QIF and CSV imports, so I was just wondering how far you are as far as date parsing code is concerned. I'm happy to write the date parsing function, but I thought I better check with you to make sure we don't independently write the same code twice. ;-) So, if you've already started on one, just tell me and I'll start tracking it. If not, is it alright with you if I write it? It would probably have a prototype like: time_t gnc_parse_date(char* str, int format); where format is in an enumeration containing the formats d-m-y, m-d-y, y-m-d, and y-d-m. (See Derek's email for how it would work: https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html) This does depend, however, on how big of a problem the issue Thomas raised is (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020950.html). In any case, just let me know what you think. Thanks, Benny ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF/CSV import date parsing code
Hi all, on Tuesday 10 July 2007 12:39, Benjamin Sperisen wrote: Hi Chintan, I think I'm at the point with the CSV import where I would be ready to integrate a date parser that could be used by both the QIF and CSV imports, so I was just wondering how far you are as far as date parsing code is concerned. I'm happy to write the date parsing function, but I thought I better check with you to make sure we don't independently write the same code twice. ;-) So, if you've already started on one, just tell me and I'll start tracking it. If not, is it alright with you if I write it? It would probably have a prototype like: time_t gnc_parse_date(char* str, int format); where format is in an enumeration containing the formats d-m-y, m-d-y, y-m-d, and y-d-m. (See Derek's email for how it would work: https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html) This does depend, however, on how big of a problem the issue Thomas raised is (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020950.html You might find some more information about the problem here: http://kmymoney2.sourceforge.net/online-manual/details.impexp.qifimp.html#id2512201 -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA - A crash turns an expensive computer into a simple stone! - pgpGZuc0hZCXb.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash 2.2.0 this weekend? Which dates precisely?
Chris, Nathan, and all, I think we're ready for 2.2.0. We've fixed a whole number of Windows bugs; we reduced the showstoppers on Windows to a minimum; and we've fixed a significant number of overall bugs as well. I think we can go ahead and release 2.2.0 at the next date that seems fit. As discussed earlier, we want to send the announcement out when not only the sources are uploaded, but the Windows binary is available as well. @Nathan and @Chris: which of the schedules at http://wiki.gnucash.org/wiki/Release_Schedule#Schedule seems good to you? Or, if not this weekend, which of the following weekends would work good? Once you've pointed out the dates that work, we'll agree on the final schedule. And then we'll have the GnuCash-On-All-Systems release! That's extremely cool. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some csv feedback
Thomas,
[EMAIL PROTECTED] writes:
The QIF code has a decent date parser, although it's in scheme
right now. The regex looks like:
^ *([0-9]+) *[-/.'] *([0-9]+) *[-/.'] *([0-9]+).*$|^
*([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]).*$
In other words the seperators are a dash (-), slash (/), period (.),
and single quote ('). Also note that there's no requirement that you
use the same separator both times. E.g. you could use 7/1'07 and this
is a perfectly valid date.
That's true, but 7/1'07 has a different meaning than 7/1/07 esp. if bot
versions are used in the same file. This is important if you try to import
ancient data from the last century. Also, there is no consitant usage of the
apostrophe version among the various products even if they come from the same
manufacturer (Quicken in this case).
Oh? This is news to me. What's the difference in meaning?
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some csv feedback
Ben,
Benjamin Sperisen [EMAIL PROTECTED] writes:
I just committed some changes that should make the lib/stf code
compile with goffice 0.2, but if anyone still has problems, please let
me know. For now, I've commented out the calls to functions that are
in goffice-0.3, and I'll uncomment them eventually once goffice-0.3 is
common in distros. However, it would be nice if I could use some kind
of macro to do this for me, such as
#ifdef GOFFICE_VERSION_0_3
goffice_0_3_call();
#else
replacement_code();
#endif
Is there anything like this?
The general way to do this is a configure test to tell whether
goffice_0_3_call() exists or not, and if not you'd compile
something like lib/goffice030/gofficecall.c which would contain
the implementation of goffice_0_3_call(). Then in the code you
always call goffice_0_3_call() and the implementation is either
the in-tree code or the external goffice code. See lib/glib28
for an example of glib-2.8 functions that we use.
When looking into the glade dialog, I'm a bit surprised about the multitude
of
checkboxes for the possible field separators. I think this is probably an
area where you might consider different widget(s) eventually (a list view
with multiple selections possible?), but for now this should be fine.
The checkboxes are just an imitation of the import feature in
Gnumeric. I agree, eventually this should be changed to something a
bit easier.
Yeah, I'd recommend a combo-box with the list of possible choices..
And the choices should be pre-pruned to the potential list based on
the actual data. E.g. if you see a date that looks like 1/1/2002
then you KNOW that it's either m-d-y or d-m-y and that it CANNOT be
y-m-d or y-d-m, so you should not present those options.
These should be gone now. However, I cannot get any uninitialized
warnings to show up for me, because I am passing the following
warnings to gcc:
CFLAGS = -Werror -Wdeclaration-after-statement -Wno-pointer-sign
-D_FORTIFY_SOURCE=2 -Wall -g -O2 -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wno-unused
Are you MANUALLY setting this, or did you just find this in your
makefile? You shouldn't manually set this.
I am not sure how to get -Wall to appear after the -Wno-unused flag.
Christian mentioned that GNOME_COMPILE_WARNINGS is somehow adding that
in and that depends on the version of GNOME I'm running. I am running
2.18.1 (in Ubuntu 7.04); does anyone know how to fix this?
Do you ./configure --enable-compile-warnings ?
The QIF code has a decent date parser, although it's in scheme
right now. The regex looks like:
^ *([0-9]+) *[-/.'] *([0-9]+) *[-/.'] *([0-9]+).*$|^
*([0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]).*$
In other words the seperators are a dash (-), slash (/), period (.),
and single quote ('). Also note that there's no requirement that you
use the same separator both times. E.g. you could use 7/1'07 and this
is a perfectly valid date.
That's true, but 7/1'07 has a different meaning than 7/1/07 esp. if bot
versions are used in the same file. This is important if you try to import
ancient data from the last century. Also, there is no consitant usage of the
apostrophe version among the various products even if they come from the same
manufacturer (Quicken in this case).
Thomas, sorry, could you clarify what the difference between 7/1'07
and 7/1/07 is for me? Is it a distinction between the years 2007 and
1907?
If so, is it actually used in that way frequently? If it is, then I
guess we probably have to specify separators. Otherwise, is it
reasonable to simply guess at the year if only given two digits (as I
suspect the QIF date parser does)? I really do like Derek's
recommendation to not ask the user for a separator, as it makes the
user interface simpler (not to mention the code ;-), so if it's
possible to go that way, I'm all for it.
IMHO you shouldn't ask the user for the separator and instead just
figure it out. The only date thing you need to ask the user is
the order of day, month, and year. Sometimes you disambiguate
this from the data. For example, if you have data that has
the following date, you know exactly which date-format to use:
1/13/2000
For numbers, you need to determine the radix and thousands separator.
Again, you can usually figure this out yourself; you only need to ask
the user in the case of ambiguities. For example, 1,000 is
definitely ambiguous (as is 1.000). But if you see:
1,000
2.34
This is no longer ambigious and you don't need to ask the user
for anything else.
Note that you don't have to ask the user a priori, you can just
ask the user to disambiguate later if you can't figure it out
on your own from the data. MOST of the time you can figure it
out, in which case asking the user is just superfluous.
Benny
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
Re: QIF/CSV import date parsing code
Thomas Baumgart [EMAIL PROTECTED] writes: You might find some more information about the problem here: http://kmymoney2.sourceforge.net/online-manual/details.impexp.qifimp.html#id2512201 Interesting. The way I'd handle it is to assume 70-99 - 1970-1999 and 00-60 == 2000-2060. If we find a year 61-69 consider it an error because, at least in GnuCash, we can't handle years prior to 1970. This will at least work for the next 50 years, and by then we can hopefully get rid of QIF. ;) I'd prefer not to require the users to set up a profile if I can avoid it. The less a user has to think about it the better, and in the case of QIF there's rarely an issue. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF/CSV import date parsing code
Benjamin Sperisen [EMAIL PROTECTED] writes: So, if you've already started on one, just tell me and I'll start tracking it. If not, is it alright with you if I write it? It would probably have a prototype like: time_t gnc_parse_date(char* str, int format); where format is in an enumeration containing the formats d-m-y, m-d-y, y-m-d, and y-d-m. (See Derek's email for how it would work: https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html) This does depend, however, on how big of a problem the issue Thomas raised is (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020950.html). In any case, just let me know what you think. I think you need two passes. You need one pass to go through the whole dataset and reduce the choices based on the data, then if there's an ambiguity you should ask the user, and THEN you can go and finish the parsing based on the user input (or go into a CSV profile and check it from there). If you have any questions even after my previous mail let me know and I can go into more detail. I think that this API is certainly reasonable for the second stage. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash 2.2.0 this weekend? Which dates precisely?
On 7/10/07, Christian Stimming [EMAIL PROTECTED] wrote: Chris, Nathan, and all, I think we're ready for 2.2.0. We've fixed a whole number of Windows bugs; we reduced the showstoppers on Windows to a minimum; and we've fixed a significant number of overall bugs as well. I think we can go ahead and release 2.2.0 at the next date that seems fit. Great! As discussed earlier, we want to send the announcement out when not only the sources are uploaded, but the Windows binary is available as well. @Nathan and @Chris: which of the schedules at http://wiki.gnucash.org/wiki/Release_Schedule#Schedule seems good to you? Or, if not this weekend, which of the following weekends would work good? I think the second option sounds better Alternatively, if the announcement should be sent out on a Sunday, here's how we could schedule this: Source package is tagged in SVN and uploaded on Thursday, July 12th. Binary package is created and uploaded by Saturday, July 14th (and needs to be copied to gnucash.org as well). Announcement is sent out on Sunday, July 15th. But I am flexible. Chris - If you could let us know when you are aiming at having the tarball up (date and, if possible, morning, evening, etc), I can minimize my response time in creating the binary. I'll try to hang out on IRC a bit more in the coming days. Nathan Once you've pointed out the dates that work, we'll agree on the final schedule. And then we'll have the GnuCash-On-All-Systems release! That's extremely cool. Regards, Christian -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Generating a PR buzz for 2.2.0
Hi Manfred! Thanks for the list, and my apologies for not responding more quickly. I have added it to the Wiki Nathan PS: you can sign up for an account on our wiki if you want. On 6/28/07, Manfred Usselmann [EMAIL PROTECTED] wrote: Hi Nathan, On Wed, 23 May 2007 10:26:09 -0400 Nathan Buchanan [EMAIL PROTECTED] wrote: On 5/18/07, Manfred Usselmann [EMAIL PROTECTED] wrote: --On Donnerstag, 17. Mai 2007 22:02 -0400 Nathan Buchanan [EMAIL PROTECTED] wrote: Anywhere else we can get advertising? Get magazines to include the Windows installer on an accompanying CD-Rom. Great Idea. I have created http://wiki.gnucash.org/wiki/PR_planning so that we can build up a list. Would you mind adding the magazines that you were thinking of to the list? I have no account to edit the wiki pages, but here are some wellknown German computer magazines I'm aware of: PC-Magazin http://www.pc-magazin.de/ PC-WELT http://www.pcwelt.de/ PC [EMAIL PROTECTED] http://www.pcintern.de/ PC Professional http://www.pc-professionell.de/ PCgo http://www.pcgo.de/ c't - magazin für computertechnik http://www.heise.de/ct/ com! Das Computer-Magazin http://www.com-online.de/ Chip http://www.chip.de/ ComputerBILD http://www.computerbild.de/ I'm sure a German GnuCash Windows version (with HBCI online banking support!) will cause a lot of attention and be regarded as a highlight of every magazine CD-Rom. Make sure to contact them early because they probably plan some time in advance. Here is a web page with links to alphabetical and categorized listings of German, Austrian and Swiss computer magazines in German language: http://www.utils.ex.ac.uk/german/media/computer.html http://www.utils.ex.ac.uk/german/media/compdeu.html Another listing: http://www.metagrid.de/Magazine/Computer__Internet/Computermagazine/ Manfred -- _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Got Mole problems? Call Avogadro at 6.02 x 10^23. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
trunk/po/de.po 15380: rebate should not be translated by Rabatt
Hi, AFAIK english rebate is much more general than german Rabatt, which is a special kind of discount. So I think, as split-register paired with Aufwendung is the other meaning, where Erstattung fits better. Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
