libgnomeprint22-2.12.1. Fedora 10 uses
libgnomeprint22-2.18.5.
--
Stuart D. Gathman stu...@bmsi.com
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want
-bindings, and the .so files end up wherever the autotools
put them, in my case src/optiona/python-bindings/.libs/ .
I handle this case by symlinking the .so files to the directory with the
.py files for testing.
--
Stuart D. Gathman stu...@bmsi.com
Business Management Systems Inc
accounts, cash, etc.
--
Stuart D. Gathman stu...@bmsi.com
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go from here? commercial
) or book
closing code.
It might not even be that bad a change to the register. Add the tz field
to the in memory data, and a tweak to the date display code.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis
On Mon, 18 Aug 2008, Stuart D. Gathman wrote:
It takes more than a simple patch, but the date bug can be completely
squashed by simply storing the timezone in the in memory register. It could
be as compact as a time_t plus a 1 byte index into a timezone table. All
register dates
(scheduled
payments, etc), that is what happens unless you convert to a dayno first.
An offtopic plug for real dates.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis
Charles Day wrote:
a proposal to flag dates with a time of day of 00:00:00
The problem is that this is an obfuscated flag. If you're going to flag
dates, flag them with a new XML field. However unlikely, the 00:00:00
flag will fail, and you have the worst of all possible situations - code
Charles Day wrote:
I was not aware of this issue. My patch doesn't change the backend's file
writing code, so whatever timestamp is assigned by GnuCash is what gets
saved. If the time written isn't midnight, the patch will think that the
transaction is bug-affected when the file is read in
. I've heard those X will never, ever happen stories from customers
too. There is a grim satisfaction in seeing their sheepish look when X
happens. Especially, when I've already coded the hooks for X.)
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone
to
put it back...
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go from here? commercial
Ian Lewis wrote:
I'm curious though, and maybe you can fill me in, is the reason that
the timestamp is important that, from an accounting standpoint, the
transaction occurred on the day (in the timezone) that it was entered
into the register? Meaning that the date is June 6 because it was
Charles Day wrote:
Under what circumstances would an end user ever choose the option randomly
change the dates on my transactions when I change the timezone on my
machine?
Tell me how this proposal would cause random date changes. Only the
*display* of the timestamp changes, and only
Mike or Penny Novack wrote:
The key is that the register would display date,time, AND TIMEZONE.
The timezone lets the user recognize that ...
I am going to ask again.
On July 18th at 14:30 EST the bookkeeper enters a transaction
involving accounts whose time zones are all also
Glen Ditchfield wrote:
Stuart D. Gathman wrote:
The issue here isn't the data file (which I assumed we all agreed
included the needed info). The issue is that loading the
nice ascii timestamp with timezone into just a time_t field in memory
(even a 64 bit one) loses critical info
Nathan Buchanan wrote:
I agree that the 00:00 timestamp is a bug, but the 12:00Z or 10:01:00Z
simply works around the bug for 90% of the use cases. From the perspective
Not only that, but if you force the time of day in each timestamp to
12:00Z, then you no longer have a timestamp, but a
For what proprietary accounting products do you get to have a long and
heated argument with the developers about the best way to store dates?
Maybe if you are their biggest customer with a multi-million dollar
contract on the line. I just wanted to take time out from the argument
to say
Charles Day wrote:
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Nathan Buchanan wrote:
I agree that the 00:00 timestamp is a bug, but the 12:00Z or
10:01:00Z
simply works around the bug for 90% of the use cases. From
Charles Day wrote:
The basic idea is that in an account register the user enters a date
and time of day (or accepts the default time of day) in terms of that
account's timezone. When you view that transaction in another
register that has been set to a different timezone, the date and time
Charles Day wrote:
No, the transaction timestamp is stored, denoting the precise point in
time at which the transaction posted. The time zone is only needed
when converting to a date or time of day, and for that you have the
user's preferences (a default display time zone, a time zone per
just timestamps *is* missing crucial
information. If storing just the actual date doesn't sit with people, then
store a *complete* time and date - which includes timezone.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591
the
nice ascii timestamp with timezone into just a time_t field in memory
(even a 64 bit one) loses critical info: the timezone.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus
.
If there is some module that requires actual timestamps (say pickup and
delivery tracking), it can store a wider type, or tack-on a timeofday field.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis
simpler with dates rather than
timestamps. That is why we went with two different types for dates
vs. timestamps. We use 64-bit signed milliseconds since 1970 for
timestamps, just like Java.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591
and such - typically 2.8Ghz Pentium 4.
Maybe if the tip jar gets big enough? (...goes to get wallet...).
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song
written properly for security, PHP code is more difficult and
harder to read (IMO) than equivalent code in a language that keeps
code and data at arms length.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis
.
Is that what is happening on windows?
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go from here? commercial
. Sure, it is storing version trees of the fileset rather
than a collection of changesets for the fileset, but the above rant doesn't
seem to apply to SVN.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis
this was the main point of SVN, and the motivation for
replacing CVS - that it has atomic changesets that affect many files.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis
to re-write their lisp code.
Agreed for Java. However, looking at the simplicity of Smalltalk
(and to lesser extent Forth) made me want to re-write lisp code. And Prolog
is *very* thought provoking.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone
On Sun, 16 Oct 2005, Thomas Bushnell BSG wrote:
Stuart D. Gathman [EMAIL PROTECTED] writes:
Python (LISP semantics, modern syntax), or Ruby (Smalltalk semantics,
modern syntax) would be good choices.
You really think a white-space-dependent language is a modern
syntax?
Short answer
, if
they expect compliance with ever more complex tax codes.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go
.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go from here? commercial
? If people are willing
to shell out for Windows, they should shell out for apps too.
I guess the long term drawback to this approach is that the company
doing the selling would become financially dependent on Windows, and
there would then be a conflict of interest.
--
Stuart D
.)
Fortunately, gnucash was designed to support multiple UIs.
Some day, using Java or its successor, it will be possible to have
web apps with the responsiveness of a real GUI.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
runs the wiki as the apache user - not
recommended if the same apache instance is serving Gnucash files.
Also, for best performance, moinmoin needs a real database (it uses
bsddb by default).
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591
it fully
implements transaction processing and recovery for the single active
transaction.
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft
that it is harder to find the sources for RedHat Enterprise
since they've started selling the packaging as well as the service.)
--
Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis
37 matches
Mail list logo
