some csv feedback

[Derek Atkins]

Ben,

"Benjamin Sperisen" <lasindi at gmail.com> 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)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available