Re: DBI backend configure failure

2008-07-15 Thread Phil Longstaff
OK Phil Mark Johnson wrote: > Phil Longstaff wrote: >> Mark Johnson wrote: >> >>> Configure fails as follows: >>> >>> checking for libgoffice-0.5 >= 0.5.1... no >>> checking for libgoffice-0.4 >= 0.4.0... no >>> checking for libgoffice-0.3 >= 0.3.0... no >>> checking for libgoffice-1 >= 0.0.4

Re: DBI backend configure failure

2008-07-15 Thread Mark Johnson
Phil Longstaff wrote: > Mark Johnson wrote: > >> Configure fails as follows: >> >> checking for libgoffice-0.5 >= 0.5.1... no >> checking for libgoffice-0.4 >= 0.4.0... no >> checking for libgoffice-0.3 >= 0.3.0... no >> checking for libgoffice-1 >= 0.0.4... no >> configure: error: Cannot find

Re: time_t

2008-07-15 Thread Mike or Penny Novack
I would pay close attention to what Graham says here. > I didn't say that *all* timestamps were unnecessary, what I said was > that dates that are actually dates, and not times, are being stored as > times, and that this is incorrect. > > For an example, look at the date entered in a transaction

Re: time_t

2008-07-15 Thread Graham Leggett
Derek Atkins wrote: I think this is being caused by dates that are actually dates and not times, being stores as times. You think incorrectly. There are LOTS of reasons to store times in transactions. There ARE timestamps in the real world. And there are reasons that some people want to act

Re: time_t

2008-07-15 Thread Derek Atkins
Hi, Quoting Graham Leggett <[EMAIL PROTECTED]>: > Derek Atkins wrote: > >>> Different database engines have different column types for storing >>> dates/times, so I'm using a 'MMDDHHMMSS' char string. >> >> ... in what timezone?Do you always convert to UTC? > > The current XML file doesn'

Re: time_t

2008-07-15 Thread Graham Leggett
Derek Atkins wrote: Different database engines have different column types for storing dates/times, so I'm using a 'MMDDHHMMSS' char string. ... in what timezone?Do you always convert to UTC? The current XML file doesn't convert to UTC, and as a result my computer is stuck in the UT

Re: time_t

2008-07-15 Thread Nathan Buchanan
On Tue, Jul 15, 2008 at 2:30 PM, Nathan Buchanan <[EMAIL PROTECTED]> wrote: > > On Tue, Jul 15, 2008 at 1:43 PM, Phil Longstaff <[EMAIL PROTECTED]> > wrote: > >> Derek Atkins wrote: >> > Quoting Phil Longstaff <[EMAIL PROTECTED]>: >> > >> >> Different database engines have different column types f

Re: DBI backend configure failure

2008-07-15 Thread Phil Longstaff
Mark Johnson wrote: > Configure fails as follows: > > checking for libgoffice-0.5 >= 0.5.1... no > checking for libgoffice-0.4 >= 0.4.0... no > checking for libgoffice-0.3 >= 0.3.0... no > checking for libgoffice-1 >= 0.0.4... no > configure: error: Cannot find libgoffice. > > I have libgoffice-

Re: time_t

2008-07-15 Thread Nathan Buchanan
On Tue, Jul 15, 2008 at 1:43 PM, Phil Longstaff <[EMAIL PROTECTED]> wrote: > Derek Atkins wrote: > > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > > > >> Different database engines have different column types for storing > >> dates/times, so I'm using a 'MMDDHHMMSS' char string. > > > > ... in

Re: time_t

2008-07-15 Thread Phil Longstaff
Derek Atkins wrote: > Quoting Phil Longstaff <[EMAIL PROTECTED]>: > >> Different database engines have different column types for storing >> dates/times, so I'm using a 'MMDDHHMMSS' char string. > > ... in what timezone?Do you always convert to UTC? > >> Phil > > -derek > ... converte

Re: time_t

2008-07-15 Thread Phil Longstaff
Derek Atkins wrote: > Graham Leggett <[EMAIL PROTECTED]> writes: > >> Nathan Buchanan wrote: >> >>> I'm a bit out of my league here...but I believe a long (or long int) >>> is defined to be a minimum of 32 bits - so if you're still using a >>> 32 bit system(?) (or processor?) you may still get a 3

Re: time_t

2008-07-15 Thread Derek Atkins
Quoting Phil Longstaff <[EMAIL PROTECTED]>: > Different database engines have different column types for storing > dates/times, so I'm using a 'MMDDHHMMSS' char string. ... in what timezone?Do you always convert to UTC? > Phil -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT M

Re: time_t

2008-07-15 Thread Derek Atkins
Graham Leggett <[EMAIL PROTECTED]> writes: > Nathan Buchanan wrote: > >> I'm a bit out of my league here...but I believe a long (or long int) >> is defined to be a minimum of 32 bits - so if you're still using a >> 32 bit system(?) (or processor?) you may still get a 32 bit time_t. > > You're righ

Re: GnuCash software

2008-07-15 Thread Josh Sled
All of this is more appropriate for the gnucash-user mailing list. "Hotel Plein Ciel" <[EMAIL PROTECTED]> writes: > 1) Register me as user and request you to send me, if any, registration > code. There is no registration process or registration code. > 2) I wish to sibscribe in your mailing l

Re: need help with program

2008-07-15 Thread Josh Sled
Jessica Goulding <[EMAIL PROTECTED]> writes: > I am having trouble with my gnucash software. I hope this is the place to > get help. The gnucash-user list is more appropriate. > When I try to open my saved account hierarchy to continue work, I get this > message: > > Can't parse the URL C:\

GnuCash software

2008-07-15 Thread Hotel Plein Ciel
Kansara Mahendra P. O. Box 511 Djibouti / Republic Tel +253-353115 Fax +253-353115 Email [EMAIL PROTECTED] 15/07/2008 Good day. First of all I wish to thank you for offering free accounting software. I wish to : 1) Register me as user and request you to send me, if any, registration code.

Re: time_t

2008-07-15 Thread Charles Day
On Tue, Jul 15, 2008 at 1:23 AM, Nathan Buchanan <[EMAIL PROTECTED]> wrote: > Hi! > > On Mon, Jul 14, 2008 at 11:33 AM, Charles Day <[EMAIL PROTECTED]> wrote: > >> On Mon, Jul 14, 2008 at 8:07 AM, Stuart D. Gathman <[EMAIL PROTECTED]> >> wrote: >> >> > On Mon, 14 Jul 2008, Martin Preuss wrote: >>

Re: time_t

2008-07-15 Thread Graham Leggett
Nathan Buchanan wrote: I'm a bit out of my league here...but I believe a long (or long int) is defined to be a minimum of 32 bits - so if you're still using a 32 bit system(?) (or processor?) you may still get a 32 bit time_t. You're right - the 64 bit RHEL5 system showed sizeof(time_t) to be

Re: time_t

2008-07-15 Thread Nathan Buchanan
On Tue, Jul 15, 2008 at 5:25 AM, Graham Leggett <[EMAIL PROTECTED]> wrote: > Nathan Buchanan wrote: > > I guess the real question is - can we wait a couple years for a 64 bit >> time_t? Probably, I think. >> > > Are there any systems in wide use that aren't yet 64 bit time_t? I was > under the im

Re: time_t

2008-07-15 Thread Graham Leggett
Nathan Buchanan wrote: I guess the real question is - can we wait a couple years for a 64 bit time_t? Probably, I think. Are there any systems in wide use that aren't yet 64 bit time_t? I was under the impression that OSes had already changed. A quick look under MacOSX Leopard shows time_t

Re: time_t

2008-07-15 Thread Nathan Buchanan
Hi! On Mon, Jul 14, 2008 at 11:33 AM, Charles Day <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 8:07 AM, Stuart D. Gathman <[EMAIL PROTECTED]> > wrote: > > > On Mon, 14 Jul 2008, Martin Preuss wrote: > > > > > Though he currently doesn't need to enter dates which are outside the > > scope

Re: weird SWIG syntax error with "inline" keyword

2008-07-15 Thread Christian Stimming
Am Mittwoch, 9. Juli 2008 20:16 schrieb Mark Jenkins: > Christian wrote: > > We either need to upgrade this > > (on trunk) to 1.3.31 or we need to add a workaround for versions lower > > than 1.3.31, which would mean adding "-Dinline=" to SWIG_PYTHON_OPT. > > If we're going to do this, we shouldn't