Re: [GNC-dev] Gnucash.org DNSSec expired March 14th.
At this time, the system seems to be automatically signing, on a timely and regular basis, a file that was manually signed some months ago, containing the expired signature. Obviously, this is wrong. So far, my attempts to get it to not do this have been met with failure. I've been scouring the documentation and the blog articles, and my version of bind9 does not seem to do what all the bloggers and docs say it should; at least, not without cryptic errors of all varieties. I'll try again tomorrow. I'm deeply unhappy with dnssec; it's the worst technology I've ever had the displeasure of using. I'm finding it quite difficult to avoid writing a tirade. --linas On Tue, Apr 6, 2021 at 7:28 PM Derek Atkins wrote: > Hi Linas, > > The GnuCash DNSSec signer stopped working a month ago and the domain > signatures expired March 14th. Any chance you could kick it? > > Also, any chance we could set up some validator to notify if the > expiration is impending? > > Thanks, > > -derek > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > > -- Patrick: Are they laughing at us? Sponge Bob: No, Patrick, they are laughing next to us. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [Hosted Weblate] Neuer Alarm in GnuCash/Glossary
It should now be working.
Stabbed in the back again, by some combination of kernel "consistent
network interface names", udev persistent-network config files, and
systemd, which magically decided to rename some my network interfaces in
yet another way, different than ever before.
Given that the hardware didn't change, and that none of the network config
files changed, this is infuriating. Yes, upon a reboot, I guess I probably
did boot to a new kernel, udev and systemd. Why does updating the software
cause the network configuration to get screwed up? It's a mockery: the
software issues inconsistent network names that are not persistent... it's
flabbergasting.
-- Linas
On Sun, Feb 7, 2021 at 2:59 PM Linas Vepstas wrote:
> Lost electric power yesterday, for 6 hours. When it came back up, I forgot
> to check everything. Apache is running, but somehow nothing is connecting.
> So I guess networking is borken? Debugging now.
>
> --linas
>
> On Sun, Feb 7, 2021 at 10:57 AM John Ralls wrote:
>
>> Looks like the server is down. ns1.linas.org responds to pings,
>> ns1.gnucash.org and www.gnucash.org don't.
>>
>> Regards,
>> John Ralls
>>
>>
>> > On Feb 7, 2021, at 7:49 AM, Frank H. Ellenberger <
>> frank.h.ellenber...@gmail.com> wrote:
>> >
>> > Hi Linas,
>> >
>> > the webserver is unreachable. Forwarded is the first alarm, which I got.
>> >
>> > Regards
>> > Frank
>> >
>> > Weitergeleitete Nachricht
>> > Betreff: [Hosted Weblate] Neuer Alarm in GnuCash/Glossary
>> > Datum: Sun, 07 Feb 2021 11:49:19 -
>> > Von: nore...@weblate.org
>> > An: frank.h.ellenber...@gmail.com
>> >
>> >
>> >
>> > # Neue Warnung
>> >
>> > [Hosted Weblate](https://hosted.weblate.org) /
>> > [GnuCash](https://hosted.weblate.org/projects/gnucash/) /
>> > [Glossary](https://hosted.weblate.org/projects/gnucash/glossary/)
>> >
>> > ## Kaputte Projektwebsite-URL
>> >
>> > Dieses Projekt ist falsch eingerichtet.
>> >
>> > Die URL der Projektwebsite verweist auf einen nicht existierenden Ort:
>> >
>> > * <https://www.gnucash.org/>
>> > (HTTPSConnectionPool(host='www.gnucash.org', port=443): Max retries
>> > exceeded with url: / (Caused by
>> > NewConnectionError('> > 0x7fe99a7b0320>: Failed to establish a new connection: [Errno 110]
>> > Connection timed out')))
>> >
>> > [Alle Warnungen
>> > anzeigen](https://hosted.weblate.org/projects/gnucash/glossary/#alerts)
>> >
>> > ## Komponenteninformation
>> >
>> > Sprachen|
>> > [29](https://hosted.weblate.org/projects/gnucash/glossary/) |
>> >
>> |-|--
>> > Alle Zeichenketten | 6.032
>> > | Übersetzte Zeichenketten
>> > | 4.931 |
>> > 81% Nicht übersetzte Zeichenketten | 573
>> > | 9% Zeichenketten mit
>> > Handlungsbedarf | 1.101
>> >| 18% Zur Bearbeitung markierte Zeichenketten | 528
>> > | 8%
>> >
>> > [Anzeigen](https://hosted.weblate.org/projects/gnucash/glossary/)
>> >
>> > [Weblate, das freie kontinuierliche
>> > Übersetzungssystem.](https://weblate.org/)
>> >
>> > ▸
>> > [Benachrichtigungseinstellungen](
>> https://hosted.weblate.org/accounts/profile/#notifications)
>> >
>> > ▸ [Deaktivieren Sie diese
>> > Benachrichtigung](
>> https://hosted.weblate.org/accounts/unsubscribe/?i=210599:1l8iZ5:cpJd6RqX2pxP8qQab1Nf1sDlT4sEJmVcHRn4M-NiUNM
>> )
>> >
>> > Generiert um 7. Februar 2021 12:49.
>> >
>> >
>> > ___
>> > gnucash-devel mailing list
>> > gnucash-devel@gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
>>
>
> --
> Patrick: Are they laughing at us?
> Sponge Bob: No, Patrick, they are laughing next to us.
>
>
>
--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] [Hosted Weblate] Neuer Alarm in GnuCash/Glossary
Lost electric power yesterday, for 6 hours. When it came back up, I forgot
to check everything. Apache is running, but somehow nothing is connecting.
So I guess networking is borken? Debugging now.
--linas
On Sun, Feb 7, 2021 at 10:57 AM John Ralls wrote:
> Looks like the server is down. ns1.linas.org responds to pings,
> ns1.gnucash.org and www.gnucash.org don't.
>
> Regards,
> John Ralls
>
>
> > On Feb 7, 2021, at 7:49 AM, Frank H. Ellenberger <
> frank.h.ellenber...@gmail.com> wrote:
> >
> > Hi Linas,
> >
> > the webserver is unreachable. Forwarded is the first alarm, which I got.
> >
> > Regards
> > Frank
> >
> > Weitergeleitete Nachricht
> > Betreff: [Hosted Weblate] Neuer Alarm in GnuCash/Glossary
> > Datum: Sun, 07 Feb 2021 11:49:19 -
> > Von: nore...@weblate.org
> > An: frank.h.ellenber...@gmail.com
> >
> >
> >
> > # Neue Warnung
> >
> > [Hosted Weblate](https://hosted.weblate.org) /
> > [GnuCash](https://hosted.weblate.org/projects/gnucash/) /
> > [Glossary](https://hosted.weblate.org/projects/gnucash/glossary/)
> >
> > ## Kaputte Projektwebsite-URL
> >
> > Dieses Projekt ist falsch eingerichtet.
> >
> > Die URL der Projektwebsite verweist auf einen nicht existierenden Ort:
> >
> > * <https://www.gnucash.org/>
> > (HTTPSConnectionPool(host='www.gnucash.org', port=443): Max retries
> > exceeded with url: / (Caused by
> > NewConnectionError(' > 0x7fe99a7b0320>: Failed to establish a new connection: [Errno 110]
> > Connection timed out')))
> >
> > [Alle Warnungen
> > anzeigen](https://hosted.weblate.org/projects/gnucash/glossary/#alerts)
> >
> > ## Komponenteninformation
> >
> > Sprachen|
> > [29](https://hosted.weblate.org/projects/gnucash/glossary/) |
> >
> |-|--
> > Alle Zeichenketten | 6.032
> > | Übersetzte Zeichenketten
> > | 4.931 |
> > 81% Nicht übersetzte Zeichenketten | 573
> > | 9% Zeichenketten mit
> > Handlungsbedarf | 1.101
> >| 18% Zur Bearbeitung markierte Zeichenketten | 528
> > | 8%
> >
> > [Anzeigen](https://hosted.weblate.org/projects/gnucash/glossary/)
> >
> > [Weblate, das freie kontinuierliche
> > Übersetzungssystem.](https://weblate.org/)
> >
> > ▸
> > [Benachrichtigungseinstellungen](
> https://hosted.weblate.org/accounts/profile/#notifications)
> >
> > ▸ [Deaktivieren Sie diese
> > Benachrichtigung](
> https://hosted.weblate.org/accounts/unsubscribe/?i=210599:1l8iZ5:cpJd6RqX2pxP8qQab1Nf1sDlT4sEJmVcHRn4M-NiUNM
> )
> >
> > Generiert um 7. Februar 2021 12:49.
> >
> >
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
>
--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Re: Lots in Account screen : Value sign
Wow... you're asking me to remember something from 12 years ago ...
Here's my best guess: for a "lot", I had the mental model of starting with
100 of something ... e.g. 100 cans of paint, and then selling them off in
dribs and drabs. Thus, the first entry, that opens the lot, has a sign that
differs from all the others. By definition, there can be only one such
entry in the lot, -- by definition, all of the other entries must have the
opposite sign. Lots can only shrink and get smaller.
So -- I buy 100 cans of paint at $10 per can, then sell 20 at $15 a can,
then sell 35 at $17 a can, then sell 45 at $12 a can, closing out the lot
(forever, since all the paint in that lot is now gone).
Lots could be shares of stock, could be cans of paint, cartons of milk
marked by expiration date -- anything that is naturally counted in
non-monetary units, and come in lots (i.e. you want to sell/use/drink the
oldest milk first, so you really do want to track the date/lot-number).
More abstractly, lots could be shipments to a customer, unfilled or
partially filed orders, whatever --
With this concept of a lot, its impossible to add more to the lot -- once
opened, it can only be depleted. Thus, the split that opens the lot is
"special". By assumption, its the very first split; it doesn't really make
sense for it to be any other. That is, I can't sell cans of paint that I
don't yet have. At least, that was the initial conception of how lots work.
Now, we all have read the news about corporations that sell things before
the customer takes delivery, leading to various accounting scandals. I
suppose there are other legitimate uses of lots, which somehow get
overdrawn before they are stocked up. Or something. But that got
confusing to think about, and was not a part of the design.
I'm not at all clear as to why payments or invoices are going through the
lot system, other than maybe you bill someone $100 and they pay you in
installments? Ans so you want to match up the installments with the
original invoice, until its paid off? I guess that's a valid use of
lots... If the sign is wrong for that special, first entry, then that's the
fault of whomever opened that lot.
--linas
On Wed, Aug 24, 2016 at 11:07 AM, Frank H. Ellenberger <
frank.h.ellenber...@gmail.com> wrote:
> Hi Linas,
>
> do you remember the reason?
>
> Regards
> Frank
>
> Weitergeleitete Nachricht
> Betreff: Re: Lots in Account screen : Value sign
> Datum: Tue, 23 Aug 2016 17:51:30 +0200
> Von: Geert Janssens
> Organisation: Kobalt W.I.T.
> An: gnucash-devel@gnucash.org
>
> On Thursday 18 August 2016 10:31:54 Chris Good wrote:
> > Hi,
> >
> >
> >
> > I'm documenting using lots to calculate investments capital gains.
> >
> >
> >
> > Please see the attached screenshot.
> >
> >
> >
> > The sign of the Value in the 'Splits free' panel seems inconsistent.
> >
> > Why is the sign of the initial acquisition +ve, but -ve for the
> > following 2 reinvested dividends?
> >
> > The program contains the following:
> >
> > gnucash/src/gnome/dialog-lot-viewer.c line 523:
> >
> >
> >
> > /* Value. Invert the sign on the first, opening entry. */
> >
> > currency = xaccTransGetCurrency (trans);
> >
> > valu = xaccSplitGetValue (split);
> >
> > if (node != split_list)
> >
> > {
> >
> > valu = gnc_numeric_neg (valu);
> >
> > }
> >
> >
> >
> > I'd like to explain why this is done?
> >
> > Perhaps something to do with the Business scrubbing?
> >
> >
> >
> > Regards,
> >
> > Chris Good
>
> Hi Chris,
>
> I can only speak about the business features. I have 0 experience with
> investments capital gains.
>
> From that business perspective, I believe you have found a bug in the
> code. It seemed to have slipped by when I merged a patch in 2011 which
> introduces the pane with unassigned splits.
>
> The code that inverts the first split was originally introduced by Linas
> in 2003 (in commit https://github.com/Gnucash/gnucash/commit/1a997993 )
> for the other pane, the one displaying the splits *in* a selected lot. I
> don't know why he introduced this behavior. There is no additional
> explanation with the commit.
>
> It was later reused for displaying splits in the free splits pane.
> However I don't think it makes sense there to revert the first free
> split. That's just some arbitrary split. So I believe that's wrong.
>
> And to be honest, I don't understand the motivation either to revert the
&g
Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide
The mailing list is the right place to make this contact. I (personally) have no problems with this, but the other developers should also think about this and reach some agreement. --linas On Sat, Jul 2, 2016 at 4:29 PM, Fabio Benevenuti wrote: > Dear GnuCash developers, > > Pleae let me know if there is a main “GnuCash Documentation Team” > coordinator or legal advisor to which I should address this question. > > Thanks in advance, > > Fabio Benevenuti > > > Mensagem encaminhada > Assunto: Authorization for commercial derivative work of GnuCash Tutorial > and Concepts Guide > Data: Sat, 2 Jul 2016 17:41:58 -0300 > De: Fabio Benevenuti > Para: Aycinena, J. Alex > , Bullock, Tom > , Champagne, Carol , > Ellenberger, Frank > , Evans, Mike > , Good, Chris > , Herman, Dave > , Lapham, Jon > , Lyttle, Chris > , Marchi, Cristian , > Ralls, John , Ratliff, Robert > , Simpson, Mark > , Stimming, Christian > , Thuree, Bengt > , T, David > > Dear members of GnuCash Documentation Team and other Contributors, > > I have been using GnuCash since 2007 for personal finances management. > Also, since 2015, I am also a student at a Bachelor of > Accountancy/Accounting Science course. > > I am planning to write a small e-book/guide in Portuguese about personal > finances using GnuCash to be published and commercialized electronically > through services such as Lulu (lulu.com), Amazon and other distributors. > > In this small e-book/guide I would like to reuse some parts of “GnuCash > Tutorial and Concepts Guide” to be translated to Portuguese. > > Your “GnuCash Tutorial and Concepts Guide” is already made available > through GNU Free Documentation License (GFDL) which I understand as > allowing use, commercialization and development of derivative works of > your guide. > > Notwithstanding the liberties already granted by GFDL, I would like to > clarify with you, copyright holders and contributors, if there is any > restriction regarding the reuse, translation, production of derivative > works of “GnuCash Tutorial and Concepts Guide” and its commercialization. > > Also, let me know if there is a main “GnuCash Documentation Team” > coordinator or legal advisor to which I should address this question. > > Thanks in advance, > > Fabio Benevenuti > > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: www.gnucash.org/pub/gnucash
Excellent, thanks! On 20 February 2014 02:33, Geert Janssens wrote: > On Wednesday 19 February 2014 15:18:03 Linas Vepstas wrote: > > > > - remove the old content where we can, possibly moving the old > > > > tarballs to sourceforge > > > > Re: bandwidth: I expect to get a 1 gigabit fiber optic within the > > next 6 months or so, maybe sooner, and so should be able to support > > dramatically more content. > > > > > - install a permanent redirect to the actual gnucash front page if > > > > > > > anyone tries to load one of the old links. > > > > If this is saying what I think its saying, then yes, please. I > > noticed a while ago that there's a lot pf gnucash-related link-rot. > > There are dozens of older pop-software sites that wrote about GnuCash > > over the years, and included URL's to now-missing content. Google > > and yahoo and bing continue to dredge these up and show them to > > people, who then click on the links. These show up as errors in the > > log-file. At one point, I did a sweep of the log file, and installed > > redirects for everything that I could find there, but perhaps its > > time to do that again. Or possibly you have better technology for > > this than I do; my hacks were low-level. > > > I parsed the logs for 404 messages earlier this week and have added > redirects for the links that had a valid referral link. In all that > fixed broken links on 5 or so old news/blog sites. > > It also turned up some broken links in our own website code :( Got those > fixed as well. > > If you're interested, the redirects are configured in .htaccess. > > It is my intention to do this from time to time. It had been a while > though. > > Geert > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: www.gnucash.org/pub/gnucash
> > > - remove the old content where we can, possibly moving the old tarballs > > to sourceforge > Re: bandwidth: I expect to get a 1 gigabit fiber optic within the next 6 months or so, maybe sooner, and so should be able to support dramatically more content. > - install a permanent redirect to the actual gnucash front page if > > anyone tries to load one of the old links. > If this is saying what I think its saying, then yes, please. I noticed a while ago that there's a lot pf gnucash-related link-rot. There are dozens of older pop-software sites that wrote about GnuCash over the years, and included URL's to now-missing content. Google and yahoo and bing continue to dredge these up and show them to people, who then click on the links. These show up as errors in the log-file. At one point, I did a sweep of the log file, and installed redirects for everything that I could find there, but perhaps its time to do that again. Or possibly you have better technology for this than I do; my hacks were low-level. Anyway, link-rot is evil: these popular-news sites drive a lot of traffic to GnuCash, and anything we do that results in 404 not found is just hurting ourselves. -- Linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: www.gnucash.org/pub/gnucash
This caught my eye: > >> Besides, it's rather > >> hard to argue that gnucash belongs there in any form, since we're not > >> part of Gnome. > > Linas could explain the historical relations. > GnuCash is one of the founding members of the Gnome Foundation. I helped draft the Articles of Incorporation (or rather, provided one draft, which was completely rewritten...) and then, much later, stood on a podium with a dozen other founders at the press conference announcing it. The room was jammed with reporters, not even standing room, with some of the more important people not even able to get into the room, and one of those big giant studio-TV cameras aimed at us. The Gnome Foundation announcement got covered by the New York Times, and a bunch of other national papers. We had top-notch PR at the time. So, yes, in this sense, GnuCash is very much a part of Gnome. Distribution-wise, it was never in practice a part of the Gnome desktop distribution, for practical and technical reasons. The Gnome Desktop consisted of the window manager, the panel, a bunch of applets, admin/preferences guis, and an assortment of basic apps (gif viewer, games, etc.) By contrast, GnuCash was already a large, complicated app by then. None of the Gnome guys knew anything about accounting or finance, and weren't in the slightest bit interested in such topics. In addition, GnuCash already had its own website, source repository, mailing list and ftp site long before Gnome even existed (The original GnuCash had a LessTif/Motif interface) so we didn't need to get these from Gnome, and were never dependent on them. (I think we had a Gnome wiki for a while). Thus, Gnome never packaged GnuCash, much in the same way that it didn't package a word-processor or web browser. These were distro-provided add-ins. Finally, I think our checkbook-register-style interface made the Gnome human-interface design guys apoplectic. They preferred much much more basic interfaces: large simple buttons, single text-entry fields on big canvas, no user preferences menus, and all other menus simplified as much as possible. GnuCash broke all of these rules (and yes, sadly, there were partly right: GnuCash was a little bit too complicated, with too many menus, too many choices.) The inability of GnuCash to move with the pack when human-interface guidelines changed really meant that it evolved on its own, and did not follow the beaten path. Ergo, today, GnuCash is de facto not a part of Gnome. -- Linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Manually trigger update of www.gnucash.org?) (Re: htdocs patch: downloads & news)
2009/11/18 Derek Atkins : > Quoting Linas Vepstas : > > Going forward the plan is to announce SF as the download site, > so we shouldn't have people banging on you for downloads. I > do understand your pain; the daily/nightly builds are only > available from my network and that's been pegged at times, too. I don't mind the source-code tarballs; that's fine. The 80MB windows file hurt. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Manually trigger update of www.gnucash.org?) (Re: htdocs patch: downloads & news)
2009/11/18 Derek Atkins : > FYI, > > Christian Stimming writes: > >> Derek, can you manually trigger an update of the website? Thanks! > > I tried to update the website manually and I got an SVN error back, > which explains why it failed: > > Conflict discovered in 'news/090723-2.3.3.news'. The server shows: -rw-r--r-- 1 svn-mirror gnc-www 5943 2009-07-23 11:38 090723-2.3.3.news i.e. the file permissions look good, the ownership looks good, the size looks good, and the file hasn't been touched since the day that it was posted. I skimmed the contents, looked like plain-old ascii/html text like it should. What's the actual diff? --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Manually trigger update of www.gnucash.org?) (Re: htdocs patch: downloads & news)
2009/11/18 Derek Atkins : > Quoting Linas Vepstas : > >> 2009/11/18 Derek Atkins : >>> >>> FYI, >>> >>> Christian Stimming writes: >>> >>>> Derek, can you manually trigger an update of the website? Thanks! >>> >>> I tried to update the website manually and I got an SVN error back, >>> which explains why it failed: >>> >>> Conflict discovered in 'news/090723-2.3.3.news'. >> What's the actual diff? > > I don't know. What does 'svn diff' say? I can only see the output > of 'svn update' when I force the update from here. Doohh. My bad. Yes, I'd previously altered this file by hand. This was when someone popped up on IRC, offering an alternate download URL for the windows binaries. I've reverted the changes, svn update should now work. FYI, bandwidth was maxed out for several weeks, mostly with people downloading the *huge* windows binaries. It's not that there were a lot of downloads; rather, its that each download was hefty. It took a month for traffic to settle down. Attached is a graph of traffic for the last year (note the left-right direction, most recent data is on the left.) I got a new internet provider at end of feb, that's the cause of the traffic uptick. The giant kaboom in July was the first-ever gnucash-on-windows announce. Traffic has been significantly higher ever since. Other peaks are presumably other announces. Also attached is a website-hits-per-minute graph. Notice that it does *not* resemble the traffic graph. The heavier traffic would seem to be due entirely to the windows binaries. --linas <><>___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
website errors
Hi, Attached is a list of recent gnucash website errors, run through sort|uniq. Some of these appear to be actual website problems, such as missing png images that are missing from the v 2.0 docs. It'd be cool if someone could fix these. Most of the errors, however, are bogus: clearly many are mistyped hand-typed URLs. Some appear to be hacking attempts, exploiting old php bugs. Some appear to be bad links on other people's websites. One somewhat sad category is that, over the years, the old mailing list archives seem to be getting corrupted (or were always corrupted?) Anway .. here it is ... --linas gnc-errs.gz Description: GNU Zip compressed data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GnuCash in openinventionnetwork Linux list
Hi, The recent announcement of Google's participation lead me to review the list of packages considered to be a part of the "Linux Envirnonment Component". (http://www.openinventionnetwork.com/pat_linuxdefpop.html) I noticed the absence of one notable package, GnuCash, and was lead to wondering why this list was the way it was. It seems to include some obscure, rarely-used packages, while also failing to include some major, widely available packages. For example: GnuCash is not on this list. GnuCash is a personal and small business finance manager; it is the foremost such package used by Linux desktop users. By "foremost" I mean: most widely used of all such packages, most well known, the oldest (ten years old this October), and the most sophisticated. GnuCash is under the GPL license, and is nominally an FSF-affiliated project. I thought perhaps that desktop applications were excluded from this list: but that is not the case, as I see other large, complex packages listed, including: -- epiphany, a web browser -- evolution, an email/addressbook/calendering app -- F-Spot, a photo album manager -- firefox, a web broswer -- gaim, an online chat client -- gnomemeeting, a teleconferencing tool -- HelixPlayer, an audio player -- OpenOffice.org, an office suite I consider the above packages to be "peers" of GnuCash, both in the profile of the type of user who would use it, and in the overall size, complexity and invested development effort. (At one point, a study put GnuCash in the top 1% of all open souce apps, in terms of developer community investment, based on a lines-of-code count, as well as the extensive documentation, and multiple language translations.) I would be interested in finding out more how the list at http://www.openinventionnetwork.com/pat_linuxdefpop.html was generated, and what the criteria for inclusion are. Also, somewhat strange, unexplained, and notable is the specification of version numbers included in this list. Thank you, Linas Vepstas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: Re: umlauts in online help]
Hi Josh, On Tue, Apr 10, 2007 at 09:39:13AM -0400, Josh Sled wrote: > Hey Linas... > > I can't seem to use .htaccess files in the website to control the > Content-Type of the served content. Hmm. Looks to me like its in svn, so it should be accessible to you... > Can you please modify the > server-wide config to return UTF-8 as a default, rather than ISO-8859-1? I just did. Should be working now. apache.conf, AddDefaultCharset utf-8 > Thanks... Welcome. > > > http://www.gnucash.org/docs/v2.0/de_DE/gnucash-help/help.html > > > http://www.gnucash.org/docs/v2.0/C/gnucash-help/help.html > > > > > > Even in the english version there are artefacts in the navigation parts. > > > > The content is UTF-8. There is a in the HTML saying as such. I > > can't seem to get apache on www.gnucash.org to serve the content as > > UTF-8, however. > > > > rather we just served UTF-8 properly. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [EMAIL PROTECTED]: Some problems on gnucash.org]
On Thu, Aug 10, 2006 at 05:39:31PM -0400, Chris Shoemaker wrote: > > AFAIK, neither GnuCash documentation nor GnuCash developers > have ever (publicly) claimed to be part of either Project, despite the > fact that such relationships would seem natural to some. Hmm. As the author of what I beleive is still a rather large chunk of the GnuCash code, I'll say it now. I participated in the founding of the Gnome Foundation, re-wrote and criticized several drafts of the charter. Voted in the elections for years. I never sought office in the Gnome Foundation, although I nominated Leslie, the PR person, to the board, a position which she got on the second try. As to the FSF: I've worked the FSF booth at trade shows, I've presented myself as an FSF representative in conversations with a company that was thinking of opening up thier Visual Basic macros (woo hoo). I've shared beers with... well, I'm not sure who, but they were FSF leadership, and I know I had fun. (Have they ever paid me money? No. Not even a stinkin free t-shirt? No. I wish. Skinflints.) --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [EMAIL PROTECTED]: Some problems on gnucash.org]
On Thu, Aug 10, 2006 at 05:16:32PM -0400, Chris Shoemaker wrote: > Hi Linas, > If we're talking about the same "standard" FSF assignment > form, it's designed to assign copyright of the entire existing > Work, not just future changes. That's why they require that the > Assigner(s) be sole copyright holder(s) for the Work. Was that > requirement met? I'm going to have trouble answering that, because that is not how I remember the assignments working. The way I remember/understood it was that the assignment simply allows the assignee to claim copyright. The code is essentially forked at that time, with the original author retaining copyright in one forked branch, and asignee is allowed to claim copyright on the other. Insofar as these two copies are the same, the net effect is that the original author retains copyright, and FSF can claim copyright as well. I do not remember any provisions for sole authorship. I am not a lawyer; the above is my recollection of what I thought I'd signed six years ago. > Robert Merkel claimed that no copyright had been assigned on > July 6, 2001. (His last contribution was in May, 2001.) Was that > true? I would have to dig through a file cabinet in the garage. Although different people signed these at different times, and some had to be nagged, I was under the impression that everyone signed them. But maybe not. > More to the point, if the FSF had been assigned copyright to > all of GnuCash in 2000, why did you and others continue to mark files > as copyright held by yourselves? Because that is my understanding of how the assignment works. > The whole thing seems very messy, > especially since GnuCash has been actively developed since then by > developers that never signed an assignment contract. Why should this matter? > I'm pretty confused by the implication that FSF became the > copyright holder for GnuCash in 2000, They would not be the sole copyright holder, they would be one among many. There are maybe 20 or 30 or more copyright holders, depending on how you wish to treat small patches. The only copyright concern I have is that I remember catching a certain Gnumatic employee going through the files fairly systematically, removing older copyright notices, and placing thier name in instead. This is a major violation as far as I'm concerned. I beleive I caught this early, and put a stop to it; I am not sure if all files were restored to thier original condition. On the other hand, another employee, Rob Browning, systematically failed to add his name to the files he authored, even after being asked repeatedly to do so. Funny how that goes. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [EMAIL PROTECTED]: Some problems on gnucash.org]
Hi Derek, Been a long time, good to hear from you. On Thu, Aug 10, 2006 at 09:52:59AM -0700, Derek Neighbors wrote: > I could be totally full of crap, but have been around a while. I can > add some history (from my perception)... Hopefully Linas will correct > me where I am wrong. Happy to oblige. So, "for the hstorical record": > On Aug 10, 2006, at 9:10 AM, Chris Shoemaker wrote: > >On Thu, Aug 10, 2006 at 01:07:14AM -0700, Thomas Bushnell BSG wrote: > >>Christian Stimming <[EMAIL PROTECTED]> writes: > >> > >Maybe you were just joking around, (I do see a smiley), but if you're > >seriously asserting that GnuCash was ever "released under the auspices > >of the GNU Project"[1], which appears to be definitive of GNU > >packages, then I would expect GnuCash's documentation to have declared > >itself to be GNU software. I've been unable to find any evidence that > >this was ever true. Do you have any? If not, I believe you are > >mistaken. > > At the time that GNUCash appeared to be friendly with the GNU Project > there wasn't much documentation about GNUCash in general. I don't > think it or propagating relationships in what existed was a primary > focus. In a nutshell, just because documentation doesn't state > anything doesn't prove a ton (in either direction). > > >I admit that the FSF has apparently declared GnuCash to be "a GNU > >package" for at least some time. [2] But, the FSF's own definition of > >a GNU package seems to require that the software authors declare their > >software to be so. I have no explanation for this inconsistency. More preciesly: Not long after X-Accountant was renamed to be GnuCash (X for the X11 X Window System), RMS wrote to complain that we can't just call of Gnu-something unless we mean it. We wrote back to assure him that, yes, it was under the GPL, and made a nominal oath of loyalty and fealty to the principles of FSF and GNU. At that point (circa 1997 or 1998) GnuCash was declared to be the "official GNU software accounting project", and was listed in the Gnu/FSF software directories as such. (Next to Derek Neighbors project, I beleive). In 2000, at the request of RMS, all of the developers employed by Gnumatic filled out the standard FSF copyright assignment forms and sent them in to the FSF. I think RMS was concerned that a corporation like Gnumatic might take the source and make it proprietary/closed source, a not unreasonable concern given my experience. A third relationship was that Gnumatic was involved in the initial setup and publicity for the Gnome Foundation. Other than this, there was little formal or informal communication or GNU/FSF; none of the regular GnuCash developers were regular GNU project developers. > RMS' email to this list was asking this project to FIX this problem. > I admit that it seems a bit delayed. For the record some time ago > GNOME put Open Source on their home page and it caused quite a > problem (as obviously they were at the time one of the most prolific > GNU projects). A long standing problem is that Free and Libre (Liberty) are mangeled into the same word in the english language. Thus, the intended meaning is "Libre software", but this isn't catchy, and doesn't jump off the lips and into the brain. By contrast "Open Source" works well, but has the wrong meaning (thanks due to ESR). And no one can think of a catch phrase to replace "Free Software", which unfortunately just doesn't work very well, because of that other meaning of "free". > >As for RMS's implication that "the GNU Project" wrote GnuCash [3], > >GnuCash's authors are quite well noted in GnuCash's source and AUTHORS > >file. I don't know of the official membership of the GNU Project - > >perhaps it's a circular definition, but of those contributors, you, > >Thomas, are the only one I know of that's apparently associated with > >the GNU Project. > > I think only the developers can say. Here is where I think some of > the roots (or my understanding of them) are confused. It is my > understanding that Linas took an X-accountant program which was no > longer maintained and gutted it to not be dependent on Motif. Yes. > My > interactions with Linas certainly made me believe he was very > connected to the Free Software Foundation AND the GNU Project No. Or rathr, only by virue of being and old-timer, and having made noise on various mailing lists in 1995. I didn't become a true belever till much much later. > because > I was introduced to him via RMS as needing to collaborate for the > betterment of the G
Re: [EMAIL PROTECTED]: Some problems on gnucash.org]
Hi, I responded at length in the last note, but thought to recap very breifly here. On Thu, Aug 10, 2006 at 02:41:07PM -0400, Chris Shoemaker wrote: > any "This is GNU software" statement certainly casts doubt in my mind, Up to about 1999/2000, I personally wrote about 80%-90% of all of the code in GnuCash. At that point, employees of Gnumatic (of which I was CEO) stepped in, and the lines-of-code count doubled or tripled. > the fact, given that copyright was not being assigned to FSF. All Gnumatic employees who were coders filled out an assignment-of-copyright form to FSF, before Gnumaic dissolved. This implies that of all the code in GnuCash, as of mid-2000, about 90%-95% of it was originated by people who had signed FSF assignments. > I think what he wrote was true. ? Who is "he"? and what did "he" write that might be untrue? > (unless we're all > mistaken and GnuCash really is a GNU Package, in which case serious > clarification is appropriate.) Technically, GnuCash is a GNU Package, as explained in detail in the last email. This does not mean that the Gnu Project provided either money or manpower, or even disk space, or CVS or a bug tracker or even a web server space. In fact, it provided none of these things. (Or rather, GunCash did not make use of Savanah). The only thing that Gnu provided was the GPL license, and the promise to promote GnuCash as the "official" GNU accounting solution. In return, GnuCsh promises to use phrases like "Free Software", and to honour feature requests coming from FSF/Gnu for feature requests, collaboration requests, and requests to answer questions about financial software. I would love to build a similar bridge with Gnome, which has long had the habit of treating GnuCash as an un-important, third-tier non-member of the Gnome Project. Despite the fact that I was there to help found the Gnome Foundation, and despite my trying to promote GnuCash within the Gnome desktop project. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[EMAIL PROTECTED]: Some problems on gnucash.org]
Hi Josh, I guess you are maintiaing the website at this moment. I received this note from RMS. We should link to gnu.org somewhere near the begining, e.g. GnuCash is personal and small-business financial-accounting software, freely licensed under the GNU GPL and available for GNU/Linux, *BSD, Solaris and Mac OSX. GnuCash is part of the http://www.gnu.org>Gnu Project. A harder change would be to hack the logo and change it from "open source finance software" to "free software for financial management" or "free software for finance". --linas - Forwarded message from Richard Stallman <[EMAIL PROTECTED]> - From: Richard Stallman <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Some problems on gnucash.org Reply-To: [EMAIL PROTECTED] This is the message that bounced didn't get a response, which is what led me to look for how to reach you nowadays. It is about what I saw on gnucash.org. Right at the top, it says "open source finance software". Meanwhile, it doesn't mention being part of the GNU project. Would you please fix that? There are also places further down that say "Linux" when they ought to say "GNU/Linux". Meanwhile, it looks like a lot of progress has been made lately. Congratulations on the new release. (I didn't know about it before, because I am not on the mailing list.) - End forwarded message - ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updating www.gnucash.org
On Fri, Apr 07, 2006 at 07:20:37PM -0400, Josh Sled wrote: > On Fri, 2006-04-07 at 12:09 -0500, Linas Vepstas wrote: > > Remind me again what needs to be done; i.e. the addr of the svn > > repository and how to pull from it. > > $ svn checkout http://svn.gnucash.org/repo/htdocs/trunk > [local-dir-name] > $ svn update > > Thought it may be that we acutally want to put the > synced-with-the-website sources on a branch, so that trunk can be for > development commits, and one needs to be somewhat explicit to > "publish" > content. Maybe http://svn.gnucash.org/repo/htdocs/branches/published > ? Decide now ... we should do this now, before getting distracted by other things. > That sounds right to me. The actual "port-knocker" is a function of > what you're comfortable with: I'd be more comfortable coming up with the final answer in a way that is not permanently visible in the public mailing list archives. - I'm planing on replacing a failing hard-drive on gnucash.org this Sunday. Wish me luck -- should be straighforward, but such things sometimes trigger a cascade of other problems. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: updating www.gnucash.org
On Thu, Apr 06, 2006 at 10:57:28AM -0400, Josh Sled wrote: > [Linas, I hope this message reaches you; I'm not sure which email > address works for you; [EMAIL PROTECTED] never seems to get a response.] That address is mail-bombed by 5K-10K spams a day, and I'm finding it very hard to keep it usable. If there are any glitches, the 1 GB-sized /var/ directories on the mail spoolers fill up, and then I have to go manually clean those up. I also suspect that the spam filtering setup is discarding valid messages as well. :-( The IBM address is limited to only a few dozen spams a day. And I have to read it to stay employed :-) > For a while now, presently, and especially with the recent work Neil has > done and the gnucash 2.0 release coming up, it would be nice to have a > way to effect (large-scale) change on www.gnucash.org. Yes. > I understand that it's been discussed (off-list) to do some sort of > commit-invoked notification to inform www.gnucash.org to update from > SVN... I'm wondering when you will set that up? "Real soon now" .. maybe even later today if I'm not feeling too stressed. > Is there anything > preventing it? I have to grep for the old email that that described what needed to be done ... > How can I help hasten the setup? Remind me again what needs to be done; i.e. the addr of the svn repository and how to pull from it. My plan was: -- pull down svn once by hand, make sure its OK. -- Copy it into place. -- set up a cron job to pull nightly -- set up some sort of "port knocker" that would initiate a pull on demand. Do you ave any preferences/suggestions for how to do this? --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: To Linas: Re: htdocs and mail-search?
On Fri, Jan 20, 2006 at 11:32:33AM -0500, Derek Atkins was heard to remark: > For the record, I think this is fine. Hopefully Linas will reply. FYI, I am sort-of receieving mail at [EMAIL PROTECTED], although mail on the gnucash mailing lists is shunted to a mailbox that I rarely open. > Neil Williams <[EMAIL PROTECTED]> writes: > > > In order to make mirroring possible, I may have to move things around > > relative > > to Linas' current locations. I don't mind. Just realize that some scripts may have a hard-coded dependency on the location. --- There's someone in Canada who is intreested in mirroring gnucash.org; I will forward the email in a few days. WHile mirroring may be good, I am concerned that the outfit be trustworthy, i.e. not be the source of trojans inserted into mirrored binaries, etc. --linas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Run a Wiki on www.gnucash.org?
Hi, On Sun, Oct 31, 2004 at 10:55:51AM -0500, Derek Atkins was heard to remark: > Hi, > > The wiki at gnomesupport.org that we've been using has chronic > problems. It's down a significant portion of the time, and it's > just plain hard to maintain. > > So, how hard would it be to run a wiki on www.gnucash.org? I could > certainly put one on cvs.gnucash.org but I think that www is more > appropriate. Linas, what say you? I know you're busy with other > things, but would definitely appreciate your input on this. My #1 concern is security; that enabling a Wiki will allow a system compromise. --linas p.s. hi after long abscense, I'm getting mail-bombed. -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: What can I do?
On Fri, Sep 03, 2004 at 07:47:09PM -0700, David Harrison was heard to remark: > > I'll help out where I can. Great! > As for your question about Amazon, have you taken a look at the Amazon > associate program? Linux.org has this on their home page, the Linux for > Non-Geeks book. From a quick look, it appears that you get 5% from the > sale of the book. My only question is who picks the book. This is > definitely something to look at though. Well, with some luck, maybe these would be books that get mentioned & discussed on the mailing list ... I think we've had discussions along the line of "good accounting books" before ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: What can I do?
On Fri, Sep 03, 2004 at 06:56:56AM -0700, David Harrison was heard to remark: > I have been poking around there already. So, I guess I'll feel free to > change/add things to the wiki pages? Yes. Adding a wiki page, and/or documentation about the 'double dating' discussion would be a big help. > I guess in my original question, I > was wondering if there were any priorities? well, the hard part of a volunteer organization is finding something that the volunteer will enjoy doing; if this isn't done, the person leaves the community. In the light of this, 'priorities' are almost meaningless. Unfortunately, its almost impossible to guess what turns you on; only you can do that; you have to get comfortable with us, and find a place where you fit in. What I'd like to see is a larger and growing, active community, together with a real 'gnucash foundation'. This means a network of accountants working with gnucash users. This means having wiki editors who can keep things up to date; documentation writers who can keep the balance between the wiki contents and the documentation. Web masters who can balance the web contents with the wiki contents. There's a zillion-and-one technical projects: interoperability software, so that gnucash data can be imported and exported, so that gnucash can do all those things people want it to do. A 'gnucash foundation' would obtain web-based income without turning the website into an advertising wasteland. I dunno, can we make money refering accounting books through Amazon?? In short, I'd like to tie gnucash into the broader set of accounting activities going on in the world; can you help with that? --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: What can I do?
On Thu, Sep 02, 2004 at 08:55:04PM -0700, David Harrison was heard to remark: > Hi all, > > I am wondering what I can do to help with the development of GnuCash? > > Let me start by introducing myself. I am almost finished obtaining my designation > as a CGA (Certified General Accountant) here in Canada. Last night (Wednesday) I > wrote my last exam in order to get my Bachalor's degree in Accounting Sciences (the > degree is a requirement for obtaining a CGA designation). Assuming I passed this > exam, I will be done - yeah!!! Simply hanging out on the user's mailing list can help: we occasionally get remarks "what would a real accountant have to say about this?" and so it would be nice to ahve a real accountant answer ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: version and version_check
Unearthing some old email I'd missed (disk overflow): On Sun, Aug 15, 2004 at 11:38:55AM -0400, Derek Atkins was heard to remark: > Neil Williams <[EMAIL PROTECTED]> writes: > > > Should version and version_check be compared/set in a merge? > > _maybe_. IIRC these are used for object versioining between the > engine and the backend. Yep. Until the backend is fully developed, I don't want to encourage any general use, because I'm nt sure how these will turn out. > > Various objects use these members in the structs, they can be merged using > > QOF_TYPE_INT32 with no bother - question is, should they? > > I've never heard of QOF_TYPE_INT32. I don't think we have one, nor do > I think we should have one. I can't imagine any user-servicible parts > that are only 32-bits wide. We've got QOF_TYPE_NUMERIC for numeric > values and QOF_TYPE_INT64 for non-"numeric" numbers. For political and possibly technical reasons, it might be wise to make the qof types look more like the glib gobject types. But I see no immediate need to go that way just yet. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: CVS snapshots?
On Mon, Aug 30, 2004 at 07:10:55PM -0700, David Grant was heard to remark: > Is there CVS snapshots for gnucash? Tarballs nightly, or when > developers feel like it, etc... No. -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Forward of moderated message
Hi, On Sat, Aug 28, 2004 at 12:31:28PM -0400, [EMAIL PROTECTED] was heard to remark: > From: Pieter Valentijn <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] Please don't post to the announce amiling list, its moderated. > Subject: CASH Software is claiming there name. > > Hi Im the Dutch programmer for TurboCASH like GNuCASH a opensource > accounting package. > The Dutch company CASH has send me a letter summuning me to take down > the dutch site www.turbocash.nl > And not to use the name CASH in anny actifitys that surround accounting > package's. They wrote me a letter witch i had to sign for. This is called a "registered letter", and lawyers like to use these to prove that you received the letter. You can always refuse to accept registered letters. Drives the lawyers nuts. > Telling me to stop using the name CASH. All do i did not think of the > name my self and they nevver phoned or maild me about it. > I just wat to lett you guys about it couse you are probebly next. They > seem to have a registerd trademark in the Benelux for the name CASH. > I hope this wil end soon but im pritty confiused at the moment. Im just > a programmer working for the world to make a good accounting package and > they sew me :-( You need to study Dutch/EU trademark law a bit. Find a freind-of-a-freind who is a lawyer or is in law schoo, and get them to give you an overview. In the US, they cannot do this because 'cash' is a common word, and one cannot trademark common words. Its less clear to me what Dutch law may say about this. Note also: in the United States, there are 57 different trademark categories. Thus, some company could trademark "gnucash", for example, for use on a line of refridgerators, and still couldn't make us stop because no consumer could ever mistake a refridgerator for an accounting program. The two are in different 'categories'. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QOF merge code ready
Looks good to me. Check it in ... This is going into the qof.sourceforge.net cvs. If its not too much trouble, make a corresponding patch for gnucash.org One minor comment: Carefule with adding documetnation like this: > +/** QofIdType declaration */ > typedef const char * QofIdType; > +/** QofIdTypeConst declaration */ > typedef const char * QofIdTypeConst; > > #define QOF_ID_NONE NULL > @@ -112,10 +114,25 @@ typedef const char * QofIdTypeConst; > (obj); \ >})) > > - > +/** QofEntity declaration */ > typedef struct QofEntity_s QofEntity; > +/** QofCollection declaration > + > [EMAIL PROTECTED] e_type QofIdType > [EMAIL PROTECTED] is_dirty gboolean > [EMAIL PROTECTED] hash_of_entities GHashTable > [EMAIL PROTECTED] data gpointer, place where object class can hang arbitrari data > + > +*/ > typedef struct QofCollection_s QofCollection; This doesn't seem to contain any information that isn't already in the C code. i.e. just reading teh C code will tell you everything here already. So I'm not to thrilled with this, it just clutters things up needlessly, wihtout adding value. Something better may have been: 'is_dirty is a boolean flag that, when set indicates that the object has been modified but has not yet been saved to disk.' That's something you wouldn't get by reading the header file. Let this one slide, but in general don't do this unless there's real true value add. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Adding a from and thru date to a register report
On Wed, Aug 25, 2004 at 10:36:56AM -0400, Josh Sled was heard to remark: > Presently sticking "no email before coffee" note to monitor... snork snundle glrphhh rotfl -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: incorrect severity
On Wed, Aug 25, 2004 at 02:29:25PM -0700, Thomas Bushnell BSG was heard to remark: > > See http://bugzilla.gnome.org/show_bug.cgi?id=97559. > > The desire to paste a transaction into the scheduled transactions > window is an enhancement request. > > But there is a minor bug also: the right-click menu offers a "paste" > option in this context. It shouldn't offer that option when the > actual functionality doesn't exist. So can the severity of this bug > be increased to "trivial" or "minor"? A good way to handle this is to open a duplicate bug, that just handles the bug and not the enhancement. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: annoyance reduced
Hi, On Wed, Aug 25, 2004 at 02:38:32PM -0700, Thomas Bushnell BSG was heard to remark: > > Ok, I've now finished reviewing all the existing Debian gnucash bugs. > There are about twenty that I'm waiting to hear back from the > submitters to see if they are still having problems in a recent > version (generally because I could not reproduce the problem). > > I expect maybe one or two of those will turn out to be genuine bugs. > > I hope to be able to spend some effort working on actually fixing bugs > now. Excellent! Thank you! --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Welcome back
On Thu, Aug 19, 2004 at 09:28:31PM +0100, Neil Williams was heard to remark: > On Wednesday 18 August 2004 3:10, Linas Vepstas wrote: > > The GUI that uses book-merge needs to make a copy of the book first. > > If the merge is aborted mid-way, you still have a copy of the original. > > Yes, this sounds cpu-sucking to me. And we don't have an > > infrastructure for making copies at this time. So we'd need to deal > > with that ... > > From the backend docs: > "In the current design, a session may hold multiple books. For now, exactly > what this means is somewhat vague, and code in various places makes some > implicit assumptions: first, only one book is 'current' and open for editing. Well, I wrote those words back-when, with narry a thought about holding duplicate copies of a book. So this is terra incognito > QofSession *s1 = qof_session_new(); > QofBook *targetBook = qof_book_new(); > qof_session_begin ( s1, targetBook, "target_id", FALSE, FALSE); > // so far, simulating what happens already? > // then add: > QofSession *s2 = qof_session_new(); > QofBook *importBook = qof_book_new(); > qof_session_begin ( s2, importBook, "import_id", FALSE, FALSE); > qof_session_swap_data(s2, s1); > qof_session_end (s2); > > Would this give access to targetBook read-write and importBook read-only? No. First of all, session_swap_data() is a funked-up concept, and I was planning on getting rid of it some day. Just keep the two sessions open, you don't need to swap data between them. Hmm. I'm now thinking that making a copy of a book before merging is a bad idea. ... it presents a number of conceptual problems, and why introduce problems if they're not really needed? The file backend has an 'undo' that works by simply not saving the changed book. So, to abort a merge, you simply don't save; instead, you can re-read the original data from the file. For the SQL backend, we will need to have an 'undo' feature, the details of which are TBD, and which you would best ignore at this time. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL & merge [was Re: Welcome back]
On Wed, Aug 18, 2004 at 10:36:06AM -0400, Derek Atkins was heard to remark: > Honestly, what I'd like to see is a QOF-level 'history' log where you > can revert the history > > -> Edit -> Undo > -> Edit -> Redo Yow. Arbitrarily deep, I suppose. Presumably clustered into 'changesets'. OK, I'll think about that. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
SQL & merge [was Re: Welcome back]
An earlier thread voiced concerns about undo for SQL backends. If an SQL db can support transactions, then there already is a natural undo mechanism. Postgress supports this, I don't think mysql does. Thus, it could work, in principle, as follows: ;; on gnucash startup, issue the SQL BEGIN statement; ;; user does gui stuff, such as hand-entering, or lots of merge, etc. ;; user clicks on "save" menu entry, which causes the SQL COMMIT to be issued. ;; user fails to click on save, and instead chooses 'exit w/o save' in which case we do an SQL ROLLBACK, and all changes up to the previous BEGIN are dumped by the SQL db. Thus it gets file-system like semantics. Unfiortuantely, I don't think one can nest begins/commits :( Anyway, I'll keep this in mind during the SQL backend work. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Welcome back
On Wed, Aug 18, 2004 at 12:15:06AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > Can't we just move the merge function out of the book-merge routine, and > > put it into the per-object routine? > > I'm not convinced this always works. Sometimes I think you need > multi-object merges (c.f. Transactions v. Splits, which are separate > QOF objects but should probably get merged as a 'transactional' unit). Sure ... in this case, the split-merge routine would be a no-op, and the transaction-merge routine would do the 'real' work. Nothing wrong with that, as long as (for example) the currency-merge routine doesn't have to know about splits. Also, I think that doing it this way would help resolve order dependencies: so that currencies are merged before accounts, accounts are merged before transactions, etc. rather than having things mereged in some random order. > > I'm not sure I understand how merge will be used. I think Derek is > > thinking about a conflict case, where there are two transactions that > > should be the "same" transaction, and thus should be "merged" (?) > > except that one transaction has 2 splits and the other has 3. > > Clearly the "right answer" is not necessarily a transation with 3 > > splits. Prusmably, the "correct answer" is to have the user pick one > > of the two transactions, and throw the other (and its splits) away. > > > > In this case, we don't want to run "object-merge" on the two > > transactions at all... > > I can think of multiple uses: Sorry, I meant to imply "I don't understand the algorithmic steps that are taken during merge, specifically in the case of conflict resolution". I don't understand what part of the algo is done in the engine merge code, and what part of the logic is implemented in the GUI code. I'd like to see teh overview pseudocode (is it on some web page I've managed to ignore?) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Welcome back
On Tue, Aug 17, 2004 at 09:20:37PM +0100, Neil Williams was heard to remark: > On Tuesday 17 August 2004 2:44, Derek Atkins wrote: > > [EMAIL PROTECTED] (Linas Vepstas) writes: > > >> A book-merge: function is an excellent idea. I'll get that done. > > > > > > OK, let us know how this goes. Although we could add support for lists > > > and trees into qof (to handle the lists of splits and the account tree) > > > I'm not sure that I want to burn the brain cells right now to figure out > > > the 'right' way of doing thiis, not just yet. By contrast, the > > > book-merge-per-object call seemed like a simple catch-all. > > Ah - first gotcha. I think a name change would be helpful here. I can see that > book-merge: would be misleading as we have already diverged. ?? I don't understand the above sentance. Oh, OK, maybe I do, see below. OK, lets pick a differnt name. lets call it "object-merge". > Any per-object merge runs into user problems. I am all too familiar with the > problems of per-collision data handling, as I mentioned in one of the very > early posts on this code. I got stuck in a loop with a Palm sync that just > went on and on and on and on and ON presenting new conflicts for resolution > without ever giving a hint of how many were still to come. I gave up at 200. > Most other users would never get beyond 50. Can you count the number of potential conflicts by doing a 'dry run' first? Speaking of which, how does the gui and book-merge interact? That is, what is the sequence of calls that must be made to merge? > The fatal flaw in this approach > is then obvious - those first 200 conflicts were committed to the final > database as you went along because each object was dealt with in turn. If the > user aborts, the final book is in complete chaos. YUK! The GUI that uses book-merge needs to make a copy of the book first. If the merge is aborted mid-way, you still have a copy of the original. Yes, this sounds cpu-sucking to me. And we don't have an infrastructure for making copies at this time. So we'd need to deal with that ... > The merge runs on a per-book basis for two simple reasons. > > 1. When the Init() is complete, the user intervention loop has a clear and > accurate value for the total number of conflicts to be resolved by the user. > To do this, all import objects must be compared before any user intervention > is sought. The user then gets a simple choice based on accurate information - > if the number of conflicts is too high, the user can abort immediately. The > level that determines 'too high' cannot be determined in advance. Good, yes. > 2. Any abort prior to the commit stage is absolutely safe, nothing is changed > in the target book until every conflict is resolved. If the user aborts at > any point before the final commit, everything is left exactly as it was > found. OK, right. So ... explain to me what the steps are to do this. I will then turn around and propose the same API back to you, except that API will now be per-object, instead of per-book. > > > own merge routine to 'do the right thing' for that object type. For > > > us 'lazy' object developers, provide a generic merge routine that > > > we can use if an object is fully qof compliant. > > Fully qof-compliant objects wouldn't need an object-specific merge routine > defined. No, I was proposing that it be the 'default routine' ... > Having a value 'book-merge: NULL,' would be misleading to other developers. It > could easily lead people to think that the object will NOT be merged. Yet if > an object is fully QOF compliant, it's all handled by the book merge routine, > so no special object behaviour is required. Can't we just move the merge function out of the book-merge routine, and put it into the per-object routine? > Instead, I need the object to help me with any non-compatible parameters, > difficult objects, awkward values and post-commit code that simply doesn't > fit in to a generic book merge module. > > e.g. If an object needs to recalculate balances or lists of Splits after a > commit but before control is returned to the main GnuCash process for > editing. > > I was thinking of what might be better termed: merge-helper: > rather than the possibly misleading book-merge: what would merge-helper do? > > I agree. I think you can safely ignore the lists in most objects > > (except, perhaps, transactions) as those objects will get merged into > > the book later. For example, you don't need to worry about the > > Account SplitList, because that's really "control
Re: number in words
On Tue, Aug 17, 2004 at 03:29:42PM -0300, Nikos Charonitakis was heard to remark: > > > 136 eur=one hundread thirty six and 0/100 > > > Can be similar strings available in other languages? > > > > No, a special module would have to be written. > > which is the module responsible for english? > can we use this as template and just add greek and other language words? There is no such module. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Welcome back
On Mon, Aug 16, 2004 at 11:23:52PM +0100, Neil Williams was heard to remark: > > > > outstanding issues here: > > > http://www.codehelp.co.uk/code/problems.html#AEN378 > > > > I think you might be able to work around many/most of these issues > > (such as the commodity issue, the account group issue, the split/lot > > lists, and maybe even the sched xaction issues) by adding a "book_merge" > > routine to qofobject.h, and then letting each object implement its > > own merge routine to 'do the right thing' for that object type. For > > us 'lazy' object developers, provide a generic merge routine that > > we can use if an object is fully qof compliant. > > A book-merge: function is an excellent idea. I'll get that done. OK, let us know how this goes. Although we could add support for lists and trees into qof (to handle the lists of splits and the account tree) I'm not sure that I want to burn the brain cells right now to figure out the 'right' way of doing thiis, not just yet. By contrast, the book-merge-per-object call seemed like a simple catch-all. > > OK, I'm still jet lagged. What's you sourceforge id? > > codehelpgpg Done. Please note that I currently keep qof and gnucash in sync manually, and that this is a potentially error-prone process. Let me know if anything looks funny. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: number in words
On Tue, Aug 17, 2004 at 01:27:18PM -0300, Nikos Charonitakis was heard to remark: > Hi > 136 eur=one hundread thirty six and 0/100 > Can be similar strings available in other languages? No, a special module would have to be written. > Is there strings in po file responsible for these kind of messages? No, > For my language (Greek) this is not an issue right now cause gnucash > cant be used properly in Greek but its a good thing to get warmed up for > a gnome-2 release! Someone should start fixing whatever the greek problems are, now, and not later. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: g_return
On Mon, Aug 16, 2004 at 11:39:02PM +0100, Neil Williams was heard to remark: > On Monday 16 August 2004 10:48, Linas Vepstas wrote: > > > (Doesn't look right to me). > > > > What doesn't look right? > > Documentation? For what? > This caught me by surprise and I spent a little time (with ? The way gnc-trace works hasn't changed for many years, so I am uncertain as to what you are refering to. > Derek in this thread) investigating when that time could have been useful on > something else. I was trucking along fine until one cvs update and suddenly I > had no messages. (I knew I hadn't fixed all the bugs, so it was disconcerting > to see a lack of errors!) I am not aware of any changes to gnc-trace that would cause the symptoms that you are reporting. The code that writes to /tmp/gnucash.trace has been in there since roughly forever; the error messages have *always* been hidden. I'm truly sorry you lost a lot of time on this, but I have no idea quite what the problem was, or how you fixed it. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Email Invoices
On Mon, Aug 16, 2004 at 05:57:34PM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > Yes, well, that, and also asking the user what subject line to use, > > and asking them if they want to compose a cover letter to explain the > > attachment, and helping them choose the list of email addreesses out > > of thier address-book, and then remembering those addresses so that > > we can re-use them next time ... > > The subject line can be hard-coded into a preference. The cover well, that woul'd rather suck, now wouldn't it? > letter, IMHO, can again be a short text as a preference.. "Here is > your invoice from as of ". The email > address is already stored in the customer information. We must be talking about two different things. My Cover letters say things like, "Hi Joe, this is what I was telling you about over the phone, and the details are half way down, talk to you later, bye". You're talking about form letters, and for that, I suppose that's great. But *none* of my interesting gnucash reports are "invoices", none have "customers" associated with them. I usually just email snippets out of the register reports. So solving the problem narrowly for business invoices just leaves me cold; its a broader problem than that. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: g_return
On Mon, Aug 16, 2004 at 10:16:10PM +0100, Neil Williams was heard to remark:
> On Monday 16 August 2004 8:22, Linas Vepstas wrote:
> > > As is, that is completely silent, no message at all.
> >
> > Make sure that the code in src/engine/gnc-trace.c isn't dumping all
> > messages to a logfile (e.g. /tmp/gnucash.trace or something like that).
>
> Aha! Thanks Linas!
>
> Was this intended?
Is there some trite change that wrecks things, like a line that's
commented out? I might of checked in something like that by accident.
> Diff for /gnucash/src/engine/gnc-trace.c between versions 1.2 and 1.2.20.8
> void gnc_log_init (void)
> {
>fout = stderr;
>fout = stdout;
>fout = fopen ("/tmp/gnucash.trace", "w");
>g_log_set_handler (G_LOG_DOMAIN, G_LOG_LEVEL_MASK, fh_printer, fout);
> }
> (Doesn't look right to me).
What doesn't look right?
You, as developer, can pick whatever 'fout' you want; there's three
in there to just help remind you that this is the place where you
can play with the setting (as opposed to trying to redirect i/o
in some other way). If you turn on 'debug', you will get megabtyes of
traces that are impractical to sent to stdout, thus they get sent to
file, which can then be grepped...
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Welcome back
cc'ing gnucash-devel, On Mon, Aug 16, 2004 at 08:27:18PM +0100, Neil Williams was heard to remark: > Hi Linas, > > Glad to see you back on the lists, hope your break was relaxing. Thank you, it was, but unfortunately, just an eye-blink. > Just an update, I've got qof_book_merge working with simple QOF objects (ones > that resolve only to fundamental QOF types) and I'm now putting in links to > more complex objects to provide support for compound objects. As long as all > objects are registered with QOF, I will be able to merge the data by storing > the GUID of the linked object and using that in the comparison and merge. Note that currently, gnc-commodity doesn't use guid's, it uses a char * get_unique_name(). There's pro's and con's to this, you've bumped into one of the cons. I haven't thought much about whether the core qof object system should provide support for unique id's that are not guid's. --- pricedb also acts wacky. > I've submitted a patch that increases the coverage of QofSetterFunc > definitions across the engine and business objects and there's a summary of I thought this was applied before I left? > outstanding issues here: > http://www.codehelp.co.uk/code/problems.html#AEN378 Ah, indeed. -- gains_split: don't worry about that; its recomputed/deleted/added automatically during 'scrub'. -- account-group: shouldn't be an issue, since each account can identify its parent by guid, so you just hunt for that guid, and add-to-parent. Err, ahh, hmm. I see the issue now: there is no generic qof 'add-to-parent' routine, is there ... -- split-list, lot-list. .. interesting ... I think you might be able to work around many/most of these issues (such as the commodity issue, the account group issue, the split/lot lists, and maybe even the sched xaction issues) by adding a "book_merge" routine to qofobject.h, and then letting each object implement its own merge routine to 'do the right thing' for that object type. For us 'lazy' object developers, provide a generic merge routine that we can use if an object is fully qof compliant. > What do you think about the discussion between Derek and myself about QOF and > enums? Is it worth creating a QOF_TYPE_ENUM or should QOF_TYPE_INT32 be > sufficient for get_ and set_ of enums? I'm still plowing through my emails. If anything, I want to make the qof types be more and more like the glib-gobject types, and I think those don't have an enum. There shouldn't be any problems working with the numeric values of enums. > Plus, I promise not to mess up QOF CVS - could you add me to the list of > developers for QOF on SourceForge, please? I'll test and build everything > before a commit and I'll only change any files outside qof_book_merge to > tweak the documentation, not to change the code. OK, I'm still jet lagged. What's you sourceforge id? --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: g_return
On Thu, Aug 12, 2004 at 12:03:55AM +0100, Neil Williams was heard to remark:
> On Wednesday 11 August 2004 10:33, Derek Atkins wrote:
> > Neil Williams <[EMAIL PROTECTED]> writes:
> > > I even tried g_return_if_fail(1 == 2);
> >
> > This should definitely trigger...
>
> That's what I figured. (Glad to know I'm not going bonkers).
>
> I have narrowed the problem, somewhat and I think it's not down to a system
> config but a makefile config. I must have fiddled once too often with a
> Makefile because of this snippet:
> int main(int argc, char** argv)
> {
> gint result;
> QofBook *testbook, *mainbook;
> Account *testaccount, *testaccount2;
>
> /* engine initialising */
> printf("Gnucash Version %i.%i.%i\n", gnucash_major_version(),
> gnucash_minor_version(), gnucash_micro_version());
> //g_return_val_if_fail((1 == 2), 55);
> gnc_engine_init(argc, argv);
> g_return_val_if_fail((1 == 2), 55);
>
> As is, that is completely silent, no message at all.
Make sure that the code in src/engine/gnc-trace.c isn't dumping all
messages to a logfile (e.g. /tmp/gnucash.trace or something like that).
--linas
>
> Uncomment the first g_return and the message appears.
> ** CRITICAL **: file example-gncBookMerge.c: line 158 (main): assertion `(1 ==
> 2)' failed.
>
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Email Invoices
On Mon, Aug 16, 2004 at 11:15:02AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > I did look into what it takes to have gnucash be able > > to email out invoices, but there is not yet any > > easy/simple/painless way to add this feature to gnucash yet. This > > has been discussed in the desktop-devel (gnome/kde) mailing lists. > > Well, we can just assume "/usr/lib/sendmail -bt" is available and > feed it the outgoing email. ;) > > Better yet, make that a configuration parameter... > > IMHO the hard part is generating the MIME message and including the > PDF (or HTML) of the invoice. Yes, well, that, and also asking the user what subject line to use, and asking them if they want to compose a cover letter to explain the attachment, and helping them choose the list of email addreesses out of thier address-book, and then remembering those addresses so that we can re-use them next time ... Yes, hacking in crappy email support is not hard, but 'doing it right' is a lot more work. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Email Invoices
On Mon, Aug 09, 2004 at 02:48:56PM +0100, Maf. King was heard to remark: > On Monday 09 Aug 2004 14:33, Your Name wrote: > > Anyone here ever think this will be a feature that gnucash supports? > > > > i am continuing to use peachtree because i can email invoices, and it > > still seems to be more feature rich than gnucash, i have looked at > > mybooks pro but they want $795 for that, any ideas if gnucash is still > > under development? > > Hi, > > Not exactly an answer to your question, but you could print the guncash > invoices as pdfs and email those - not an "out the box 1-click solution" but > will achieve the same result... I did look into what it takes to have gnucash be able to email out invoices, but there is not yet any easy/simple/painless way to add this feature to gnucash yet. This has been discussed in the desktop-devel (gnome/kde) mailing lists. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnome2 graphing status
On Fri, Aug 13, 2004 at 11:30:35AM +0200, Christian Stimming was heard to remark: > >So, I've been looking into the gnome-office-graphing [GOG] stuff, and > >noticed that it doesn't have a feature of guppi we were using, which is > >the ability to bind the graphical region associated with a data-series > >element to an action ... in the case of gnucash ... with the appropriate > >register being opened in response to a bar-section or pie-wedge being > >clicked on. > > I'd say we just have to bite the bullet and admit that we have to drop > the interactivity feature. Just to have "something" so that > gnucash-gnome2 eventually got the graphing features up and running. I agree. But do just stub out the register id code; it shouldn't be too hard to add the click-identification to GOG (its just a bunch of intersections). I'm cc'ing Jody Goldberg, the (lead?) devel on GOG as an FYI ... --linas p.s. yes, I'm back from vacation ... -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: OFX download problems
On Wed, Jul 28, 2004 at 08:07:42PM -0500, Jeremy Jongsma was heard to remark: > OK. Which section would it fit best under, or should I create a new one? Up to you. You probably want to link to the devel wiki at http://linuxwiki.de/GnuCash_2fDevelTexts rather than the user's wiki. You had some neat ideas, I didn't want to loose track of them ... --linas > Linas Vepstas wrote: > >On Wed, Jun 16, 2004 at 11:33:08PM -0500, Jeremy Jongsma was heard to > >remark: > > > >>OK, the bank OFX information has been updated to work with Money's new > >>data format. See http://www.jongsma.org/gc/ > > > > > >Can you please link this into the gnucash wiki? > > > >--linas > > > > -- > Jeremy Jongsma > [EMAIL PROTECTED] > http://www.jongsma.org > ___ > gnucash-devel mailing list > [EMAIL PROTECTED] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: OFX download problems
On Wed, Jun 16, 2004 at 11:33:08PM -0500, Jeremy Jongsma was heard to remark: > OK, the bank OFX information has been updated to work with Money's new > data format. See http://www.jongsma.org/gc/ Can you please link this into the gnucash wiki? --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: linking gnucash to data in postgres
Hi, I'm reading old, stale email. On Thu, Jun 17, 2004 at 04:26:22PM -0400, Joseph Mack was heard to remark: > I was wondering if it was possible to use the database features of > postgres linked to entries in gnucash (I'm currently using gnucash-1.4) > I had a quick look on the docos on the gnucash website but didn't see > anything that seemed to address the problem. > > Case: My son's soccer league has about 1000 kids in it. There are also > coaches, referees, sponsors, suppliers of T-shirts, playing fields, > times > > Looking at just the kids, there would be entries in the database for > each kid (name, address, birthdate, season, division, team...) > including payment of fees, check#... > > Is it possible to on receipt of registation for a kid, to update the > information for the kid as well as enter the financial information > (check number, amount paid) and have the financial information appear > in the gnucash view of the database? I think the thread conclcuded that 'gnucash won't do this" but in fact, I beg to differ. The genericizing work that I'm doing now opens the door to this, although at the current rate of development, this is years away. This is a good example of where people really do want this kind of customizability, and my opaque diatribes about dwi and qof and what-not all tie into this. FWIW, Derek Neighbors gets it: gnue is trying to build the generic framework first, and an accounting app on top of it later. I'm doing the opposite: got the accounting app, now trying to build the generic framwork. Same goal, different paths. Evolutionary convergence is the bio term. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[ANNOUNCE] DWI-0.6.0 Object/Gtk/SQL mapper
Hi, I've just put up a new version of DWI at dwi.sourceforge.net This version now uses the automake build system for easier builds/installs, and adds some QOF examples. DWI is a system for specifying relationships between objects and SQL tables, and as such, is kind-of like an "ORM" Object-Relational Mapping. DWI differs from most ORM's in that 1) its not Java based, 2) It can hook directly to Gtk widgets, 3) It can be used with Glade to build GUI apps, 4) It supports multiple object systems (Gtk, GObjects and QOF) I've started building a generic QOF object backend using DWI; this will also qualify as a kind of "ORM", except that it is meant to be caching and fully multi-user (i.e. it will automatically synchronize object instances living within different applications on different machines.) Future builds of QOF will require installing this version of DWI to get the DWI backend to work. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QofSetterFunc
On Sun, Jul 25, 2004 at 10:29:05AM +0100, Neil Williams was heard to remark: > On Sunday 25 July 2004 12:23, Linas Vepstas wrote: > > On Sat, Jul 24, 2004 at 07:48:57PM +0100, Neil Williams was heard to remark: > > > I see that most qof_class_register calls set a NULL in place of the > > > possible QofSetterFunc. I couldn't find a single (QofSetterFunc) with a > > > grep of src/ but maybe that's just me. > > > :) its a place holder, haven't gotten around to filling it in. > > > > Or just that nobody had a > > > use for them, yet? > > > Yes. > > > > Can I change each qof_class_register section to use appropriate Set > > > functions, where they exist? > > > Yes. > > OK. There are, naturally, some QofAccessFunc routines that are simply not > suitable for a corresponding QofSetterFunc - ones that rely on calculated > balances etc. Yes. > Are your SQL needs going to be similar to the merge: Yes. > This would lead to a useful check: > If param_setfcn is NULL, ignore the param_getfcn for the comparison rules. > > Is that too simple. > (expected answer, Yes.) > :-)) Yes, and its a good trick too, to distingusih 'real' paramters from 'synthetic' ones. > > I've converted most things to use QofEntity; I was planing on converting > > most things to actually use QofInstance (so that they would all have a > > common setter for the KVP tree, and some other common items.) Prices > > stick out like a sore thumb, and would need a major overhaul. There > > are other odds-n-ends, such as currencies. > > I know, that's a problem in the merge - haven't figured that out yet. Try pestering me a bit down the road, I'd like to do this cleanup. p.s. I'll be out for 3 weeks so there'll be radio silense. > As we'll both be using the same setter functions, I'm hoping our needs are > similar? Yes. That's why the setters are there :) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Null Account and more
On Sun, Jul 25, 2004 at 08:41:15AM -0500, Perry Smith was heard to remark: > Could you explain that to me? GnuCash attempts to avoid the "gratuituous" introduction of minus signs, since that leads to all sorts of programming and presentation errors. To keep things simple, gnucash asks that everything sum to zero. This avoids the problem of trying to keep track of what's on the "left", what's on the "right", how to handle multi-column linked equations, etc. > The documentation (design document) says that the value of an account > is equal to the splits in it plus the sum of all of the subaccounts. That is correct. > If some are income and others are expenses, I don't see how that can be > true. Because there is no sign difference between the two. > The design document also causes me to worry because it does not sound > like the engine is using GAP rules. By that I mean that: > > Liabilities = Assets + Owners Equity GnuCash uses: 0 == Liabilities + Assets + Owners Equity > So, the sum of the splits in a transaction do not sum up to 0, they > balance out -- which is a more complex question. No its not more complex, its (absolutely, totally and completely) identical. > i.e. If I pay from > an asset (e.g. Cash) to a liability (e.g. Note), the equation looks > like: > > -100 (Note Liability account) = -100 (Cash asset account) No. > It should not (from an accountant's perspective) look like: > > 0 = -100 (Cash account) + 100 (Liability account) Accountants don't read source code. They see the correct values presented to them in the gnucash reports. The gnucash displays things the way an accountant wants to see them, in the correct left/right column. > The same is true for income and expense. If I pay for gas from my > salary income it would look like: > > 100 (salary income) = 100 (gas expense) That's how its presented in the register/reports. Internally, its represented as 0 == 100 (salary income) + -100 (gas expense) > But if gas is a child of salary, it seems to me that it would be > incorrect: > > +- 100 salary > |-+- 100 gas > > would make salary be 200 Right, which is why we don't do it that way. Values in income and expense accounts all have the same sign, and not opposite signs. Thus, the total is zero, not 200. To repeat: income and expense accounts are identical, except for column labels. This allows us to keep the math simple, inside the engine; to present the correct info to the user we just fiddle the column labels. For example, in the above equity example: most people like to think they have positive equity, and so that is how gnucash dislays it, even though internally, and by GAP standards, equity is "negative". --linas > > On Jul 24, 2004, at 10:02 PM, Linas Vepstas wrote: > > >On Fri, Jul 23, 2004 at 09:31:55AM -0500, Perry Smith was heard to > >remark: > >>So, I'm hearing that an income account can have a child that is an > >>expense account. O.k. That seems odd to me but o.k. > > -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Null Account and more
On Fri, Jul 23, 2004 at 09:31:55AM -0500, Perry Smith was heard to remark: > So, I'm hearing that an income account can have a child that is an > expense account. O.k. That seems odd to me but o.k. These two account types are nearly identical, except for the labels on the columns :) There's not even a minus sign difference between them, although the reason for that is good bit more subtle (a kind of ah-ha moment). --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QofSetterFunc
On Sat, Jul 24, 2004 at 07:48:57PM +0100, Neil Williams was heard to remark:
> I see that most qof_class_register calls set a NULL in place of the possible
> QofSetterFunc. I couldn't find a single (QofSetterFunc) with a grep of src/
> but maybe that's just me.
:) its a place holder, haven't gotten around to filling it in.
The setters are used in qof and I think in gnotime.
> I've got my own code to work when e.g. Account.c has a corresponding
> QofSetterFunc defined:
> { ACCOUNT_NAME_, QOF_TYPE_STRING, (QofAccessFunc)xaccAccountGetName,
> (QofSetterFunc) xaccAccountSetName },
Yep, that's the idea.
> Was it an oversight not to specify QofSetterFunc's?
No.
> Or just that nobody had a
> use for them, yet?
Yes.
> Can I change each qof_class_register section to use appropriate Set functions,
> where they exist?
Yes.
> (If they don't, I'll cross that bridge when I get to it!)
Heh.
I've converted most things to use QofEntity; I was planing on converting
most things to actually use QofInstance (so that they would all have a
common setter for the KVP tree, and some other common items.) Prices
stick out like a sore thumb, and would need a major overhaul. There
are other odds-n-ends, such as currencies.
I was planning on adding reference counting to QofInstance. ...
I was planing on changing gnc-event to send out references to entities
and not to guids
Since my whiz-bang SQL backend requires the setters, I was holding off
till then ...
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Null Account and more
On Fri, Jul 23, 2004 at 09:56:31AM -0500, Perry Smith was heard to remark: > Sorry... Another question: > > The accounts with no name have: > > The above is legal markup for sgml for the below. However, I was under the impression that XML did not allow this ... not sure ... > Instead of what I would expect as: > > > I'm not an XML buff so that may be correct. If not, I'll look into > that problem as well while I'm at it. Another SGML equivalent for this is which I think is also not allowed in xml ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Null Account and more
On Thu, Jul 22, 2004 at 11:11:56AM -0500, Perry Smith was heard to remark: > > When gnucash imported this, it created a sub account under "Interest" > called "Fidelity Ultra" and Fidelity Ultra has a subaccount with no > name. I can see this in the xml as well as the Accounts window. There Possibly a bug in the qif importer ??? > "Interest" in quicken as well as gnucash is an expense but Fidelity > Ultra is an income account and the account with no name is an income Bad. 'Fidelity Ultra' should be an asset account of some kind, not an income account. You cannot use income/expense accounts to hold anything of value. Income/expense accounts are meant only to record income or expenses, for use in cash-flow type reports. I'm thinking that the qif importer should be changed to prevent user from ever mapping a QIF account to an income/expense account (since I don't think quicken even has the concept of income/expense, right?) > account as well. A sub account with a different type from the parent. > Is that allowed? sort-of. income/expense accounts can be children of each other, asset accounts can be children of other asset accounts, but one must never mix income/expense with assets. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: merge logic cascade
This is very long email, please cut-n-paste it into your documentation somewhere. Dumping it to a file in src/docs is sufficient if you are lazy. On Sun, Jul 18, 2004 at 04:08:33PM +0100, Neil Williams was heard to remark: > PS: What is in KVP parameters? e.g. in Account, what would be contained in the > QOF_TYPE_KVP parameter? Assorted misc data. Voided transactions are marked as such in the kvp data. I think account tax info is stored in the kvp. KVP is a simple catch-all for data that people need to store when they add new features, without having to go through the pain of modifying the core structures. src/doc/kvp.txt contains a list of all teh currently used kvp values. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gdb debugging
On Wed, Jul 21, 2004 at 06:48:03PM -0500, Perry Smith was heard to remark: > In my experience with dbx and IBM's xlc compiler, you have to turn off > optimization to get anything useful from dbx. > > Is the same true with gdb and gcc? tradiionally no, but it does seem to be getting worse :( > Do I need to recompile at least > part of gnucash without optimization? Can't hurt, in the past, though this was un-needed. > I'm looking at the stack trace > in the middle of the database save and some things look o.k. but a lot > of things look pretty trashed out. stack trace call arguments seem to be increasingly wacky as the years roll by. but if you pop up the stack, you can usually view the actual values of variables without many problems. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QT Checkwriting program]
FYI. --linas On Sat, Jul 17, 2004 at 08:38:37PM -0500, [EMAIL PROTECTED] was heard to remark: > Dear GNUCash Developer, > > I am writing a QT C++ version of a Check writing > program for Linux. It is similar to Versa Check's > software. It is for U.S. Currency Only. I am building > a website for it. > > http://members.verizon.net/~amp_linux > > I am going to take a look at your software for some > interface ideas. > > > Thanks, > Andrew M. Patterson > > -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Just How Big is GnuCash, Really?
Just for fun, I made a graph of the number of lines of code in GnuCash, as a function of time. http://www.gnucash.org/en/sizing.phtml If you've had trouble swimming through that mass of source code, think of it this way: printed out on paper, and bound into volumes, it would amount to several dozen copies of Tolstoy's "War and Peace", roughly a bookshelf-width's worth of source code. Mind you, this is source code (and docs) crafted and debugged by actual humans, this is *not* autogenerated code. Tools (such as glade or g-wrap) can generate gazillions of lines of code automatically; I'm not counting those. Every last line counted here was typed in, edited, indented, tweaked, debugged, refactored, multiple times, by human hands. Given that we have about 400 outstanding bugs in bugzilla, that works out to about one bug per thousand lines of code, or one bug per 50 pages of printout. This bug count is actually not atypical for software projects; its near the norm. Using the "COCOMO" sizing model, very crudely, this amounts to about 75 man-years of effort, and thus, assuming American salaries and overhead costs, over 5 million dollars to develop. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New to SQL
On Wed, Jul 14, 2004 at 01:02:05PM -0500, Perry Smith was heard to remark: > Yes, I too would be most happy to help. I'm finally in a position to > work on this stuff. I may be confused but having a real database > backend is very attractive to me for a number of reasons. p.s. gnucash-devel not gnucash-user is teh right place for this discussion > > On Jul 14, 2004, at 11:29 AM, Derek Atkins wrote: > > >[EMAIL PROTECTED] (Linas Vepstas) writes: > > > >>I'm engaged in a very round-about development of a generic sql > >>backend, > >>with the goal of supporting the new features, and a larger collection > >>of sql db's. Unfortunately, its a big project and I'm able to devote > >>only a few weekends a month to make progress. > > > >By any chance, Linas, do you have a roadmap or some way to get help > >from others interested in donating effort to this feature-set? Heh. Barely enough time to read my email, and they want road maps ... The overall idea is to create a "generic" object infrastructure to map C objects (specifically Qof objects) to SQL tables in an "automatic" way. The mapping would be safe for multi-user, simultaneous updates (i.e. do the corect locking/versioning, etc). The technology I've picked for this is, (ahem, excuse the favoritism), my own: a smash-up of qof and dwi (see sourceforge). status & roadmap: -- 1. Use dwi to specify the mapping of qof object 'param' to sql table field. (Done) -- 2. Save & restore qof object to sql database, using above mapping. (Done) -- 3. provide versioning support, so that multi-user updates can be properly handled. (Started) -- 4. provide table locking (Started). -- 5. step back, look what else there remains to be done (e.g. figuring out how to support the business object COW). -- 6. Implement a proof-of-concept in 'gnotime', iron out the gotcha's there, before moving to gnucash. The current demo code is in qof/dwi CVS only. the tarballs are way downleavel). See dwi/examples/qof-proto which I have just barely started beating into the qof "backend" framework, which see qof/examples/backend. Good luck. Not listed in the above: -- a. DWI currently requires compile-time linking to gtk, even though there is absolutely no reason for this for the above. gtk is needed for other DWI features. This needs to be replaced by some kind of plugin/dynamic load stunt. This is technically hard/dirty; I'll reject patches that do this wrong. -- b. test dwi with various other db's (I've only done postgres). -- c. implement/flesh out the db login proceedures. -- d. change gnc-event to use qof entity pointers instead of guid pointers. -- e. clean up core gnucash objects to use QofInstance. Figure out what else is common between all gnucash objects (e.g. COW ??), and add that to QofInstance. -- f. "refactor" price query, so that it uses the standard qof query mechanism instead of the hacky thing its doing now. I really really need help with the letter tasks a.-f. and working on those will not put you on a collision course with where I wanted to go with things. (except possibly COW, which is potentially hard/paradigm breaking, so I'll be staring at that real hard). These tasks are also probably a lot easier than trying to grok the big-picture of the mainline qof backend development, especially if you are new to qof. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bundling G-Wrap
Hi Rob, Good to hear from you ... On Sun, Jul 11, 2004 at 12:31:15PM -0500, Rob Browning was heard to remark: > ... good answer ... > In any case, until/unless the above happens, the easiest thing to do > is to just include the version number in the library name, works for me. That's a good, pragmatic solution, and it is what everyone else does. (for presumably the same reasons; more or less all of gnome uses libtool). > provide a symlink for dlopen/dynamic-link: > > /usr/lib/libfoo.so.N > /usr/lib/libfoo-N.so -> libgw-guile-foo.so.N That works too, maybe even more elegant. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Wishes to the new G-Wrap maintainer?
On Mon, Jul 12, 2004 at 08:54:22PM +0200, Andreas Rottmann was heard to remark: > OK, but I think as long as you are consistent, it's IMHO no problem to > break API on minor version numbers :-p What I really want to do is to say "thank you for taking over maintainership, and let us all wish for a bright and happy future." But you just won't let me, will you? I really just don't get it. What's wrong with just incrementing the major version number every time you do this? So what if we get to version 59.1 ? What's wrong with that, as compared to a version 5.9.1 that's backwards-incompatbible with version 5.8.0, which will mess everyone up? Look, I can't stop you from doing what you really want to do. But there are tens of thousands of gnucash users and a sizable fraction of them keep getting smashed by versioning problems. This is bad for gnucash and its bad for Linux in general. You can do whatever you want, but to echo Derek's sentiments, it might be best to cut our losses right now, fold the existing g-wrap into gnucash, and avoid these future breakages before they occur. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bundling G-Wrap
On Fri, Jul 09, 2004 at 05:58:43PM +0200, Andreas Rottmann was heard to remark: > I'm willing to change this. Thanks, that would be really great! My aplogies, I think its better you hear the complaints before you start, not after. > libgwrapguile-dev - Development package for libgwrapguile1 > libgwrapguile1 - g-wrap: Tool for exporting C libraries into Scheme interpreters > Packages of g-wrap 1.9.0 are in preparation (I'll take over Debian > maintainership, too), That's great, I love debian maintainers! > the main package of which will be named g-wrap > (suprise, surprise). That's fine; just make sure that users can still install libgwrapguile1 so that existing package dependencies dosn't get broken. Having dual devel environments as well is, um, important: The GnuCash developers will need to be able to continue patching & fixing the g-wrap 1.3.4-based gnucash for some indefinite period of time (I'm guessing over a year) even while we port over to a g-wrap 2.0; so loading both devel environments on one machine is a kinda-gotta-have. Again, this is the expression of the major-vs-minor version number tirade: Its OK if libfoo-1.4-dev clobbers the files in libfoo-1.2-dev because its expected that libfoo-1.4-dev is backwards compat. However, libfoo2-dev *must* be installable in parallel with libfoo-1.4-dev so that both are usable. Again, the version numbering problem is a technical problem, not a mater of taste or opinion. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Wishes to the new G-Wrap maintainer?
On Fri, Jul 09, 2004 at 06:15:35PM +0200, Andreas Rottmann was heard to remark:
> [EMAIL PROTECTED] (Linas Vepstas) writes:
>
> > Whenever an api changes in an incompatible manner, please bump the
> > major version number. That's what major version numbers are for.
> >
> Sorry, but there is no "standard scheme" for version numbers everyone
> must adhere to.
Actually, for libraries, there is ... incorrect version leads to
linkage breaks. Its actualy a technical problem, and not a matter
of taste or opinion.
> I prefer to use minor version number as "branch
> indicator" (like the Linux kernel, GNOME, ...). Branches may break
There is considerably more freedom of interpretation when dealing
with an application. Applications don't have API's that migh break
backwards compat; you can choose version numbers that make good
slogans ("win95").
But Gnome is not the example you think: when Gnome broke backwards
compat, they *did* bump the major version number to 2.0; they didn't
call it 1.6. Note also that Gnome 2.4/2.6 is still backwards compat
with Gnome 2.0. They've already announced that Gnome 3.0 will be
incompat with 2.6.
Note that the Linux kernel is also a bad example: the 2.6 kernel is
backwards compat with the 2.4 and also the 2.2 kernel as well;
you can dual boot all of these without breaking a thing (i.e not
breaking the syscalls in glibc). And I've dual-booted 2.0 to 2.2
so I suspect they're all compatible. The kernel guys know they
can't break compat; if they had, everyone would be pissed off
and on BSD or Hurd by now.
> Yeah, but G-Wrap has a homepage and its own file release area now.
Bravo. Thank you for taking over g-wrap. Sorry for sounding so
grumpy and grouchy, it just comes from years of picking up after
other peoples messes.
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Report Writing Tips
On Mon, Jun 28, 2004 at 08:09:45PM -0400, Peter Long was heard to remark: > >>two. For example I would like a report the shows how the Unrealised > >>Gains/Losses item are calculated. > > > I use two different currencies in my accounts and I have noticed that my > balance sheets never seem to balance. It turns out that the Unrealized > Gains(Losses) line item in the Liabilities section of the balance sheet > was wrong from the time I first used a currency other than USD. I see > that someone has already opened a bug report on this issue but I did not > want to just sit around waiting for a fix. I thought I might as well get > my hands dirty and try figure out why it was wrong. So generating a > report that shows the "workings" for that line item is my first step > toward fixing it. Actually my first step was just to generate ANY report. :) I'm not surpirsed that the existing cap gains report is broken, the problem is harder than that. Here's the story so far, and I'm sorry I didn't write sooner: -- There's code in CVS head that automatically computes realized/unrealized gains for everything. It does this by assigning transactions to 'lots' and comparing buy & sell values in the lot. It then adds a balancing entry showing the gains. Lots are built using a FIFO policy. In theory, its "easy" to add other policies. Its fully automatic in the sense that if you edit anything anywhere, all the other gains are auto-recomputed, etc. I think it all works but it hasn't been ultra-super-duper tested. -- There's a 'lot editor' GUI in one of the menus, it allows you to look at the contents of a lot and tweak it. Its simplistic but should work. -- There are no reports that display this info; the current cap-gains report displays I have no clue what ... It would be great if you wrote that report. Please work with CVS HEAD, since all other mechanisms of computing cap gains will be deprecated ... Let me know how its going. I can elaborate on the above at much greater detail ... just ask; athough my answers are sometimes slow. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: How to use the Wiki????
On Tue, Jul 06, 2004 at 12:43:31PM +0200, C. Gatzemeier was heard to remark: > > I think you are right that a wiki can have a good effect, the german linuxwiki > has evolved to be quite helpfull, not only on GnuCash and HBCI issues. > I'd like to ask if someone could add a [de] link to > http://linuxwiki.de/GnuCash aside the new wiki menu entry on gnucash.org? Done. I also re-organized the english wiki this morning, splitting up the faq by topic, hopefully making it both more readable and more editable. If you've answered questions about how to use GnuCash in the past, such as the recurring "VAT" conversation ... please go out and edit the wiki & update the entries. If you've been looking for a way to contribute but your not a programmer, this is the way to do it. --linas p.s. Accountants/book-keepers looking for business are encouraged to advertise thier services at http://gnomesupport.org/wiki/index.php/GnuCashAccounting -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FreeBSD compile
On Wed, Jul 07, 2004 at 10:43:12PM -0400, Derek Atkins was heard to remark: > Linas: you should be more careful to try to maintain gcc 2.9 Yes, but those inline C99 declarations are just so much prettier ... hard ... to ... resist --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Wishes to the new G-Wrap maintainer?
On Wed, Jun 30, 2004 at 12:10:41PM -0400, Derek Atkins was heard to remark: > > Fixed in 1.9.0 (released today). Unfortunatly, 1.9 and 1.3 wrapsets Whenever an api changes in an incompatible manner, please bump the major version number. That's what major version numbers are for. In other words, if version numbers were used correctly, then a version number such as 1.9 implies that its 100% backwards comaptible with 1.3, but that it adds a bunch of new features. Sounds to me like you should be calling your thing 'version 2.0' and not 'version 1.9'. Although, if we went back to the begining, and done this correctly, you'd be working on version 6.0 :) This was one of my major beefs with g-wrap: things like version 1.3.2 not being backwards compat with version 1.3.1 ... who could possibly guess? Certainly, no unsuspecting user ... This is why I like to see smaller packages lumped together: maintainership duties are shared, and the senior maintainers are more likely to catch this kind of bug, before it gets released into the wild. > > are incompatible; an 1.3 compatibilty layer or conversion tool is > > planned, however. Would be nice .. > What was wrong with the old interface?!? I don't think I saw an answer to that ... > > 1.9.0 has dropped the GLib binding; it is now provided by guile-gnome, > > which targets GLib/GTK+ 2. The 1.3/1.4 line is mostly stalled, but I > > might release a 1.4.0 with a few bugfixes and targetting GLib 2.0, for If its bug fixes, then call it 1.3.5 If it targets a different version of glib, then call it 2.0.0 > If this is the case we may just pull 1.3.4 into our tree, fix the > problems that currently exist, and just subsume the code and ignore > future g-wrap. Should have done this a very very long time ago. We do it for lots of other packages ... why not this? Andreas, we usually try not to do this, but its a great technique if a package has a dependency on another packge that is obscure, rare, unmaintined, etc. This simplifies things considerably for the distro maintainers and for the casual user who wants to compile from the tarball or CVS. If one doesn't do this, one finds that most folks are left googling for non-existant web-sites (such as used to be the case for the g-wrap site) or ftp-sites (which is why we have saved old copies of g-wrap on the gnucash site, until non-savannah, its not clear it was available anywhere else). This kind of pain makes it less likely that a distro will pick up a package, and it hurts the popularity of the app. (Some of the larger distro's didn't pick up gnucash until version 1.6, nearly *5 years* after gnucash-0.9 came out. I don't know the reason, but difficulty of building the thing surely played a part.) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FreeBSD compile
On Wed, Jul 07, 2004 at 11:23:56AM -0700, Carl was heard to remark: > We are trying to compile the CVS 1.9 HEAD version of gnucash on FreeBSD 4.9 > and running into lots of errors. It looks like we might have compiler > version issues or other configuration problems. > > Who is supporting the FreeBSD port of GnuCash? We want to check if what we > are seeing is expected or if we should be fixing and reporting the problems. Don't know who is handling this; if you hear no answer after a while, send patches. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bundling G-Wrap
On Tue, Jul 06, 2004 at 04:22:59PM +0200, Andreas Rottmann was heard to remark: > > [ CC'ing g-wrap-dev, guile-gtk-general. The discussion is about that > since G-Wrap now comes without GLib bindings, the GnuCash folks have a > dependency more, which they seem utterly opposed to ] No, don't misunderstand/misquote on purpose. You know what this is about. > > My take on this? g-wrap should probably be a standard part of guile, > > or swig, or something, and not a stand-alone package. The complaint was about the proliferation of package dependencies and the linux version of the old microsoft 'dll hell'. Any given day of the week, the mailing lists are dominated by discussion of people who cannot successfully build/install gnucash. That is just plain wrong. People should be talking about something else, and not the difficulty of install. The problem is the proliferation of packages that are poorly maintained and don't have properly defined pkg-config or automake macros or whatever, or are growing oldy/moldy/rancid due to lack of maintainer activity. I beleive that the problem could be solved by merging smaller packages into bigger ones, where maintainers could share the work of upkeep. > - bundling it with Guile: would mean _way_ too slow releases Which is HIGHLY PREFERABLE to NO RELEASES which is what g-wrap has had for 3-4 years now. G-Wrap is broken, busted and no one is maintaining it, and it basically just sucks because of this, and it is the leading #1 poster child for everything that can possibly go wrong with an independent package release. I'd like to avoid re-living all of the mistakes of the past; the problem of packaging being the biggest. (Surely you don't want to hear how 1.3.4 is incompatible with 1.3.1? or that the package is (was?) identified as "g-warp" on debian ... a clever naming twist that makes it impossible to find, or the guile warnings that it currently spews?) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Wishes to the new G-Wrap maintainer?
On Wed, Jun 30, 2004 at 02:39:48PM -0400, Derek Atkins was heard to remark:
> Andreas Rottmann <[EMAIL PROTECTED]> writes:
>
> >> #ifdef SWIG
> >> %module mymodule
> >> %{
> >> #include "myname.h"
> >> %}
> >> #endif
> >>
> > This will only work if the header file is simple.
Gnucash header files are simple, intentionally. This was a design goal.
swig should be able to parse them without any problems.
> have to handle the glib types (gboolean, gint, gint64, etc) and a few
> gnucash structures that are passed by value (e.g. gnc_numeric).
This shouldn't be hard. My only compaint about swig was that I could
never figure out how to convert GList's to perl lists. This was
something I really really wanted, since part of teh power of perl is
auto-list-processing.
Coincidentally, what is the 'correct' way of handling typing in scheme?
Say I have a list of accounts, how do I differentiate that from a list
of transactions? How can I tell teh type of a list element?
> > Sorry, but I disagree here. Modularity is good,
Up to a point. Modular design is good. Itty bitty installable
packages bite the big one. Small packages make it hard for the
package maintainer, make it hard for the distro, and make it hard
for the app developers, an you get all that difficulty without any
reward, without actually solving any real problems.
> > Users should be using a distribution which provides package management
> > (and not compile packages at all).
Clearly, you've never heard of Gentoo.
> My point is that while modularity is good, tons of tiny little
> packages is not. C.f. dependency hell.
GnuCash has been living in dependency hell for 5 years, and its ironic,
because this was something that Windows used to suck at. Now its turned
around, its gotten a lot better on windows, and worse on Linux. Tiny
little packages suck.
My take on this? g-wrap should probably be a standard part of guile,
or swig, or something, and not a stand-alone package.
--linas
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
___
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
How to use the Wiki????
Hi, I was thinking to myself "to make gnucash more accessible, users should be encouaraged to actively work on the wiki, to answer the commonly occuring qeustions (e.g. macosx, VAT, etc.) So I went to the wiki, and saw that it was a jumble, and wanted to clean it up. For example, development questions like "why is it written in C" are high up in the FAQ, when questions like, "how do I do VAT" or "how do I create invoices" should clearly be a lot higher. The FAQ needs to be busted up into pieces. Sections on business features, sections on the code base, sections on how-to-install, and especially sections on actual accounting tasks. So anyway ... I click 'edit' and it asks me for a username ... and then says "Invalid password or userid." ... and there is not the slightest hint on how to recover from that. Can it email me my password? no .. any random userid gives the same error. Ahem, exactly what good is a wiki if you can't edit it? G.. I was inspired to whack on the Wiki by Tim O'Rielly, who wrote the below. We need to figure out how to get teh Amazon effect, and I saw the wiki as maybe one way to get there. --linas > > Amazon is perhaps even more interesting. Unlike eBay, whose > constellation of products is provided by its users, and changes > dynamically day to day, products identical to those Amazon sells are > available from other vendors. Yet Amazon seems to enjoy an > order-of-magnitude advantage over those other vendors. Why? Perhaps it > is merely better execution, better pricing, better service, better > branding. But one clear differentiator is the superior way that Amazon > has leveraged its user community. > > > In my talks, I give a simple demonstration. I do a search for products > in one of my publishing areas, JavaScript. On amazon.com, the search > produces a complex page with four main areas. On the top is a block > showing the three "most popular" products. Down below is a longer search > listing that allows the customer to list products by criteria such as > best-selling, highest-rated, by price, or simply alphabetically. On the > right and the left are user-generated "ListMania" lists. These lists > allow customers to share their own recommendations for other titles > related to the given subject. > > > The section labeled "most popular" might not jump out at first. But as a > vendor who sells to amazon.com, I know that it is the result of a > complex, proprietary algorithm that combines not just sales but also the > number and quality of user reviews, user recommendations for alternative > products, links from ListMania lists, "also bought" associations, and > all the other things that Amazon refers to as the "flow" around > products. > > > The particular search that I like to demonstrate is usually topped by my > own JavaScript: The Definitive Guide. The book has 192 reviews, > averaging 4 1/2 stars. Those reviews are among the more than ten million > user reviews contributed by amazon.com customers. > > > Now contrast the #2 player in online books, barnesandnoble.com. The top > result is a book published by Barnes & Noble itself, and there is no > evidence of user-supplied content. JavaScript: The Definitive Guide has > only 18 comments, the order-of-magnitude difference in user > participation closely mirroring the order-of-magnitude difference in > sales. > > > Amazon doesn't have a natural network-effect advantage like eBay, but > they've built one by architecting their site for user participation. > Everything from user reviews, alternative product recommendations, > ListMania, and the Associates program, which allows users to earn > commissions for recommending books, encourages users to collaborate in > enhancing the site. Amazon Web Services, introduced in 2001, take the > story even further, allowing users to build alternate interfaces and > specialized shopping experiences (as well as other unexpected > applications) using Amazon's data and commerce engine as a back end. > > > Amazon's distance from competitors, and the security it enjoys as a > market leader, is driven by the value added by its users. If, as Eric > Raymond said in The Cathedral & the Bazaar, one of the secrets of open > source is "treating your users as co-developers", Amazon has learned > this secret. But note that it's completely independent of open source > licensing practices! We start to see that what has been presented as a > rigidly constrained model for open source may consist of a bundle of > competencies, not all of which will always be found together. > -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Improved checks for scanf %lld and %qd as per gc-devel mail.
On Sun, Jul 04, 2004 at 11:24:06PM -0400, Derek Atkins was heard to remark: > Log Message: > --- > Improved checks for scanf %lld and %qd as per gc-devel mail. Scanf seems to be frequently broken in different libc's, I've always strongly recommended that atoll be used instead, which always seems to work reliably. Note that atoll is no harder to use that scanf. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] fix yet another intermediate-math overflow bug.
On Sun, Jul 04, 2004 at 09:43:11AM -0400, Derek Atkins was heard to remark: > Linas, > > This code looks like it could still overflow if either of the denom's > are negative. Granted, denoms _shouldn't_ be negative, but someone > could theoretically create one that way. Yes, well, negative denominators are supposed to mean something completely different, and I don't feel like debugging that. numeric (a, -b) is supposed to have a value of a*b not -a/b I don't think this is used anywhere, but I didn't want to break what is there. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash from CVS
On Sun, Jul 04, 2004 at 08:52:36PM -0400, Derek Atkins was heard to remark: > > Vitaly Lipatov <[EMAIL PROTECTED]> writes: > > > For long time I get the same error with gnucash from CVS: > > ./configure > > ... > > checking if scanf supports %qd conversion... no Ahh .. now I see the reason for the change ... I am not sure that gnucash actually uses scanf anywhere ... I'm pretty sure it uses only atoll, but I did not actually grep and verify. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: fix the test case; it really is an overflow on division, there's a
On Sat, Jun 26, 2004 at 07:30:46PM -0400, Derek Atkins was heard to remark: > Linas Vepstas <[EMAIL PROTECTED]> writes: > > > fix the test case; it really is an overflow on division, > > there's a bunch of huge prime numbers involved. > > Unfortunately this test-case actually came from test-query.. It had > created a random transaction that happened to have those two values as > the amount and value and was trying to compute the shareprice. I'm trying to fix the make-random-transaction so that it won't gen insane data. Harder done than said. > Could you please explain exactly what a division overflow means? if x=a/b and y =c/d then x/y = (a*d)/(b*c) If, after eliminating all common factors from the above, the if the numerator and/or denominator are *still* greater than 2^63 then its an overflow. > If this test-case really is going to over-flow on this operation then > we need to fix all the other tests to make "reasonable" random > gnc-numerics. Go run 'test-query' and watch it fail consistently Yes. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] remove 32-bit limits that show up in division calculations (could cause
On Sat, Jun 26, 2004 at 12:52:06PM -0400, Derek Atkins was heard to remark: > Since this code is duplicated in both div128 and rem128, should we > perhaps pull this out into a new subroutine? Or is that not worth > the hastle? I thought it was not worth the effort. -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Search [was Re: donating]
On Thu, Jun 24, 2004 at 11:46:43AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > On Thu, Jun 24, 2004 at 11:21:03AM -0400, Derek Atkins was heard to remark: > >> > >> https://lists.gnucash.org/search/ > > > > Oh. Well. I didn't know that. Its not linked in anywhere. > > I'm not sure why -- I've sent out the url a number of times > already (at least once previous to you specifically). As > for not being linked in anywhere, it's linked in from the > email list info page and archive page. Sorry. Now that I have spam under control ... I'm reading more mail. > I try not to modify the main website at all. Perhaps we should move > the main website to being in CVS and then pull the website docs out of > CVS? That would make it easier for people to update the site? Just a > suggestion web site is in cvs already, just not on a pserver. There's maybe a dozen people who have write access to the website. Ssh login's work better, at least for managing news items because the odd way news works, but I have low incentive, got all those other things to fix ... of course almost no one ever logs in ... > No, I'm not rsyncing the website, and the menu's aren't pulled in by > SSI. What's SSI? --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: donating
On Thu, Jun 24, 2004 at 07:09:40PM +0100, Neil Williams was heard to remark: > On Thursday 24 June 2004 3:18, Linas Vepstas wrote: > > server competition. I own more effing servers that I know what to do > > with. The hard part is running the machines, not buying the hardware. > > For example, search is still/again broken. > > You're welcome to use the archive search code or I could adapt it for use on > the rest of the site, or do a second version for the main site, the options > are there if you want some help with the search routine on www.gnucash.org OK, I guess I missed the mail thread where this was discussed. I'll try to copy it over to the main site ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Search [was Re: donating]
On Thu, Jun 24, 2004 at 11:21:03AM -0400, Derek Atkins was heard to remark: > > https://lists.gnucash.org/search/ Oh. Well. I didn't know that. Its not linked in anywhere. Hmm. I thought you were rsyncing the web site? The menus didn't update since last night. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: More KMyMoney peeking: is our file format clearly documented?
On Thu, Jun 24, 2004 at 11:17:04AM -0400, Josh Sled was heard to remark: > I wish the generation side was as direct, data-driven and -- ideally -- S, My big dream is that the same data-driven marshalling I'm trying to do for sql will also work idnetically for xml. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: More KMyMoney peeking: is our file format clearly documented?
On Thu, Jun 24, 2004 at 11:23:48AM -0400, Josh Sled was heard to remark: > The G2 port needs to be completed, first, however. :/ Yes, G2 port first. > * delete gnc-modules Move from gnc-mocules to old-fashioned shared libs. This second. > Smaller, Faster, Leaner. Simplicity. This third. > * reports move from guile-generated to embedded-guile. This too. -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: More KMyMoney peeking: is our file format clearly documented?
On Thu, Jun 24, 2004 at 11:13:03AM -0400, Derek Atkins was heard to remark: > frontend. Gnucash just has too much crap in it. :) Yes, well we have to de-crapify it. There's nothing 'unreal' about that, its just real work that really needs to be done. GnuCash development has stalled, and its stalled for 2 or 3 technical reasons, and the crapification is one of them. Until things like this are cleared up, development will stay stalled. This is like a city: no one will build beautiful houses until the roads, sewers and fresh water are in good condition. Unfortunately, good sewer workers are hard to come by ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: donating
On Thu, Jun 24, 2004 at 10:21:20AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > I'd like to avoid large sums accumulating in a paypal account, > > because of all the stories of paypal thefts. That money could > > just go 'poof' and that would be bad. > > I've never heard a first-hand account of these kinds of thefts. Yes, well, if it got so pervasive that everyone had a first-hand story, it would be a crisis, wouldn't it? There are a number of open source project tip jars that have been gutted; google around. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Search [was Re: donating]
On Thu, Jun 24, 2004 at 10:21:20AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (Linas Vepstas) writes: > > > For example, search is still/again broken. > > Which search functionality? Searching the mailing lists work. I don't mean 'googling for gnucash mailing lists', I mean using the search box on the website, the one on the lower-left corner of all of the web pages. Yes, Gogle is pretty damned effective, but I think having a functional search on our own website could be even better. > It's possible that searching the website does not, but I don't > have much control over that. ;) Yes, well, as you pointed out, you do have root access to the machine, so you could control it in theory. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: More KMyMoney peeking: is our file format clearly documented?
Hi, > It would've been nice if they just decided to write a Qt frontend > to GnuCash, but I can certainly understand why they don't. Let me say it again ... the major reason for 'modularizing' gnucash was to allow other projects and programmers to use the modules in thier projects. Schemeifying the modules just f**it up. They were supposed to be separately installable shared libs, nothing more, nothing less. We really have to de-schemeify the modules. > > The developer working on the gnucash importer had some interesting > > things to note: > > http://sourceforge.net/mailarchive/forum.php?thread_id=4496256&forum_id=7103 > > quote: > > > > "3. Since I couldn't find any definition of the GC file structure, > > I've based the code purely from what I've been able to deduce from my > > own file, and a few small test files created for the purpose. " In particular, the goal of the gnucash "engine" has (always) been to provide a GUI-neutral, indeed, OS-neutral way of accessing financial data through a well documented, supported API. This GUI neutrality is what allowed the Motif and GTK versions of GnuCash to co-exist, and even helped start a KDE port, back when, until it withered. --linas p.s. Christian, or whomever has this ability, please cross-post this message to the KDE lists. As the maintainer/author of significant non-GUI chunks of GnuCash, I really do have an interest in somehow sharing or collaborating ... -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: donating
On Thu, Jun 24, 2004 at 09:13:01AM -0400, Derek Atkins was heard to remark: > "Tomas Pospisek's Mailing Lists" <[EMAIL PROTECTED]> writes: > > OTOH if the amount is high you'll get inquires about "who got the money"? > Right now we've got about $500. That would be enough to: I'd like to wait a few more months, and then hand out equal shares to the pool of active/recently active writers & developers, and possibly some translators (I don't know how to gauge translation effort; I beleive translating the docs would be hard work, but no ones done that yet). I'm not sure, I think that list might have 10 or 12 names on it. If more money rolls in, then maybe there could be some token amounts for hardware & network costs, but I don't want to encourage hardware/ server competition. I own more effing servers that I know what to do with. The hard part is running the machines, not buying the hardware. For example, search is still/again broken. > Or we can just keep it for now and wait and use it later. I'd like to avoid large sums accumulating in a paypal account, because of all the stories of paypal thefts. That money could just go 'poof' and that would be bad. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: donating
On Tue, Jun 22, 2004 at 09:52:53AM -0500, Linas Vepstas was heard to remark: > > A prototype web page explaining how to donate to the gnucash project > can be reviewed at > > http://www.gnucash.org/en/donations.phtml Its now linked to the various menus and other pages. It also contains a summary of the current financial position. Is this a good idea? a bad idea? Will more people donate if they don't know how much money we have? Or will they donate when they see how open and transparent our records are? --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: donating
A prototype web page explaining how to donate to the gnucash project can be reviewed at http://www.gnucash.org/en/donations.phtml Let me know if you have suggestions/changes. I can either link this page directly into the main menu, just under the 'how to help' item, or instead, list it on the how-to-help page. Suggestions? Can someone make me a project admin on the sourceforge gnucash page? I've discovered I cannot view the donated amounts; I'd like to prepare a mini-balance sheet, for inclusion on the donations page. I'm not sure if its time yet to figure out how/to-whom to disburse the funds. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: automatic ex/import of data
On Wed, Jun 09, 2004 at 12:18:08PM -0400, Derek Atkins was heard to remark: > "Tomas Pospisek's Mailing Lists" <[EMAIL PROTECTED]> writes: > > >> > 1. do there exist hooks where a script or external application can be > >> >called when a transaction is entered? > >> > 2. is there a possiblity to call gnucash through some kind of RPC, from > >> >the command line or as a daemon to add a transaction? > > > that is *not* familiar with gnucash's internals? > > Hmm, I dont know. I suspect that #1, adding hooks into the objects Hmm, Derek is already familiar with gnucash internals, and he plumb forgot about src/engine/gnc-event.h which is used by various GUI elements to figure out when to redraw. Trnasactions, lots, periods, accounts, sched txn's, prices, books and freqspecs all generate these events. Yes, the current interface to gnc-event is ugly and I plan to redo it to fit with qof. > #2 is probably going to take a LOT longer. Well #2 was the #1 reason for doing this scheme thing in the first place. All *other* reasons for doing scheme were secondary to providing scriptability. Scheme was not needed for reports, nor was it needed for any other reason. It was needed *solely* to provide scriptability. I guess we failed at that ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: automatic ex/import of data
On Fri, Jun 18, 2004 at 05:25:01PM +0200, Christian Stimming was heard to remark: > Hello Tomas, > > Tomas Pospisek's Mailing Lists schrieb: > >1. do there exist hooks where a script or external application can be > > called when a transaction is entered? > >2. is there a possiblity to call gnucash through some kind of RPC, from > > the command line or as a daemon to add a transaction? > > I thought at least for your described question #2 the "--evaluate" > command line option of gnucash would be of some help. I.e. your > cybercash frontend could come up with some scheme statements that would > actually create a transaction and add it to the appropriate places -- at > least that's what I would expect... One of the goals of scheme-ifying gnucash was to allow exactly #2, and even make it easy. The idea was that you'd write a little scheme script that did whatever you wanted, and pushed the data into/out-of gnucash. But nobody or almost nobody does/did that, so we have little track record for this. FYI, the earlier incarnation used perl for this; the current perl-based price lookup is a vestige of that. Almost no one used the perl bindings either. Anyway, I have no idea if we suceeded or failed with the scheme bindings. Failed, I suppose, in that no one uses them or cares very much ... > As for the question #1, no, there is nothing available at the moment. Actually, there is something, sort-of. There are C-language 'gnc events' generated whenever a transaction is created/modified/destoyed. These events are used to tell the GUI when to update. I am not sure if there are scheme wrappers for these events or not. If there are scheme wrappers, then that's your script hook. Note that I am planning on changing the C-language api to these events, to make them richer and more powerful. I'll try to maintain some amount of backwards compat, but am not sure right now. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gconf2 (was Re: g-wrap (was Re: QOF won't link))
On Sun, Jun 20, 2004 at 05:37:55PM -0400, Derek Atkins was heard to remark: > > > As a side note, corba does have this 'service discovery' feature, this > > thing where you can ask "who holds the gnucash config data" and there > > would come this response "oh, machine 10.0.0.1 holds it", so the user > > does not need to specify any explicit machine name for the service. > > I have no idea if gconf uses this, it would be cool if it did. > > I dont know.. Corba just seems so overkill for configuration > parameters, especially when a simple set of dotfiles would suffice! corba is overkill, but I was really trying to illustrate the idea of network service discovery. since orbit is corba, I just was wondering aloud if gconf might already have this built in. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gconf2 (was Re: g-wrap (was Re: QOF won't link))
On Mon, Jun 21, 2004 at 02:40:44AM +0200, Thomas Viehmann was heard to remark: > More or less the combination of both is done. If there is no active > gconfd, one is initialized from data stored in (a configurable location > which usually is) $HOME/.gconf. Further instances will than contact this > gconfd, thus ensuring consitency of data and immediate availabilty of > changes in the data. And the latter is (for purposes of the more common > gconf installations) the benefit over plain dotfiles. Really!? I had no idea ... is this discussed somewhere on some web page? I think this is an under-advertised fieature of gconf ... --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gconf2 (was Re: g-wrap (was Re: QOF won't link))
On Mon, Jun 21, 2004 at 12:23:23AM +0200, Tomas Pospisek's Mailing Lists was heard to remark: > On Sun, 20 Jun 2004, Linas Vepstas wrote: > > > It would be seriously cool if gconf was distributed, so that, e.g. > > when machine 2 shows up on net, its gconf would sync with that from > > machine1. After sync machine1 could be shut down, or whatever ... > > machines could come & go, join the party & leave... the data would > > persist. > > User updates config on machine2, logs out, machine2 goes down. Next time > user starts up he'll have lost his updates if machine2 didn't come up yet. > Whuah, hard problems here... :-P Well, the updates on machine 2 would have to be broadcast back to machine 1 and/or machine 3. Ideally, every machine at the "party" is in sync with all the others at the party. Like the eternal flame, as long as there's at least one machine in the party, the party goes on. And if the party is broken up ... tough luck. Version numbers and such might help reconstruct things if the various machines went thier own way for a while, and then rejoined the party. Versioning is hard... but I think something usable that did 'the right thing' almost always could be built. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: g-wrap (was Re: QOF won't link)
On Mon, Jun 21, 2004 at 12:16:23AM +0200, Tomas Pospisek's Mailing Lists was heard to remark: > > OTOH, as a complete ignorant, I was able to find my way through gnucash > rather quickly and fix/add what I needed, thanks to modularisation I > think. yes, and no, we've tried to make gnucash out of distinct pieces, and that's what helped you. The goal was always to have those, and to have a set of shared libs that implement various functions. But the way those distinct pieces were wrapped into scheme-wrapped shared-libs is what didn't work out. --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QOF iteration and callbacks
On Sun, Jun 20, 2004 at 02:20:17PM -0400, Derek Atkins was heard to remark: > > But I see no reason not to combine them.. > Unless there is a strong reason why queriable objects and 'storable' > objects need to be (or should be) different. OK. > >> So what's your conceptual distinction between a QofObject and a > >> QofClass? > > > > I dunno. Something that only knows about parameters vs. something that > > knows about lots of other things as well. Maybe 'class' should be > > a base-class for 'object'. Better names for these things might help > > too ... > > True. I was sort of thinking in terms of "g_object" (or gtk_object).. > Which sort of makes some basic level of sense to me.. *shrugs* Is this an explicit statement of support for g_objects? In the past, you've seemed allergic to them, and so we've developed this system thats sort of similar and sort of different. Should the qof guts slowly migrate to be tightly integrated to g_objects? Or maintain a loose affiliation? I certainly have the urge to start using the same naming conventions where possible. (Working on qof has helped me get a grip on where they're similar and where they're different, and I've enjoyed that...) --linas -- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 ___ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
