Re: [GNC-dev] Gnucash.org DNSSec expired March 14th.

[Linas Vepstas]

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

[Linas Vepstas]

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

[Linas Vepstas]

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:
> >
> >  * 
> > (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

[Linas Vepstas]

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
> sign on the first split in the lots either. For the current (business)
> code the result is rather arbitrary. Sometimes the first split is a
> payment, sometimes it's an invoice. Whichever is first gets its value
> reversed. So sometimes all values are negative, sometimes they're all
> positive. And the amounts alter negative/positive to properly balance
> the lot.
>
> So from a business perspective, this implementation doesn't make sense
> at all. I don't know whether it does 

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Linas Vepstas]

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

[Linas Vepstas]

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: www.gnucash.org/pub/gnucash

[Linas Vepstas]

  - 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

[Linas Vepstas]

Excellent, thanks!


On 20 February 2014 02:33, Geert Janssens janssens-ge...@telenet.be 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: Manually trigger update of www.gnucash.org?) (Re: htdocs patch: downloads news)

[Linas Vepstas]

2009/11/18 Derek Atkins warl...@mit.edu:
 Quoting Linas Vepstas linasveps...@gmail.com:

 2009/11/18 Derek Atkins warl...@mit.edu:

 FYI,

 Christian Stimming stimm...@tuhh.de 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
attachment: eth0-year.pngattachment: web-year.png___
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)

[Linas Vepstas]

2009/11/18 Derek Atkins warl...@mit.edu:
 FYI,

 Christian Stimming stimm...@tuhh.de 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)

[Linas Vepstas]

2009/11/18 Derek Atkins warl...@mit.edu:
 Quoting Linas Vepstas linasveps...@gmail.com:


 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

website errors

[Linas Vepstas]

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

[Linas Vepstas]

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]

[Linas Vepstas]

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 meta 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]

[Linas Vepstas]

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]

[Linas Vepstas]

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]

[Linas Vepstas]

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

Re: [EMAIL PROTECTED]: Some problems on gnucash.org]

[Linas Vepstas]

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 GNU Project.

I was shopping around GnuCash to whomever I thought might beintersted.
Standing relationship was that if the GNU Project had any talk about
finaincial type software, the GnuCash folks would get cc'ed on the 
conversations.

 It is also my understanding that the GNU Project very much helped  
 Linux Global Partners put money behind the company Linas ran  
 (GNUMatic) 

Don't beleive so. RMS and Gnu in general have a history of being 
allergic to the smell of money. If they put 

[EMAIL PROTECTED]: Some problems on gnucash.org]

[Linas Vepstas]

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 
a href=http://www.gnu.orgGnu Project/math.

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

[Linas Vepstas]

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: Run a Wiki on www.gnucash.org?

[Linas Vepstas]

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?

[Linas Vepstas]

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?

[Linas Vepstas]

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: What can I do?

[Linas Vepstas]

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: version and version_check

[Linas Vepstas]

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?

[Linas Vepstas]

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

[Linas Vepstas]

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: annoyance reduced

[Linas Vepstas]

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: incorrect severity

[Linas Vepstas]

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: Adding a from and thru date to a register report

[Linas Vepstas]

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: QOF merge code ready

[Linas Vepstas]

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: SQL merge [was Re: Welcome back]

[Linas Vepstas]

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
 
Menu - Edit - Undo
Menu - 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

Re: Welcome back

[Linas Vepstas]

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

SQL merge [was Re: Welcome back]

[Linas Vepstas]

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: number in words

[Linas Vepstas]

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: Welcome back

[Linas Vepstas]

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

[Linas Vepstas]

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

[Linas Vepstas]

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 controlled by the Splits
  themselves.  When you merge in the splits you get their parent
  account just fine.
 
 Will this work reliably if the parent is a new account created by the merge? 
 (Possibly in a new AccountGroup too?) At present, I don't have any rules to 
 stipulate that certain objects should be compared or committed before or 
 after any others. That could be something for merge-helper: to define, 
 although I'd rather not (for speed reasons). 

I can't answer

Re: gnome2 graphing status

[Linas Vepstas]

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: Email Invoices

[Linas Vepstas]

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: Email Invoices

[Linas Vepstas]

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: g_return

[Linas Vepstas]

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: Welcome back

[Linas Vepstas]

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

[Linas Vepstas]

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: Email Invoices

[Linas Vepstas]

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 business name as of invoice date.  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

[Linas Vepstas]

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: OFX download problems

[Linas Vepstas]

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

[Linas Vepstas]

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

[Linas Vepstas]

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

Re: Null Account and more

[Linas Vepstas]

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: QofSetterFunc

[Linas Vepstas]

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

[ANNOUNCE] DWI-0.6.0 Object/Gtk/SQL mapper

[Linas Vepstas]

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: Null Account and more

[Linas Vepstas]

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:
 
   act:name/

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:
 
   act:name/act:name

 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

  act:name/

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: QofSetterFunc

[Linas Vepstas]

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

[Linas Vepstas]

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: Null Account and more

[Linas Vepstas]

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: gdb debugging

[Linas Vepstas]

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: merge logic cascade

[Linas Vepstas]

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: [QT Checkwriting program]

[Linas Vepstas]

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?

[Linas Vepstas]

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: Wishes to the new G-Wrap maintainer?

[Linas Vepstas]

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

[Linas Vepstas]

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: How to use the Wiki????

[Linas Vepstas]

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: Report Writing Tips

[Linas Vepstas]

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: Wishes to the new G-Wrap maintainer?

[Linas Vepstas]

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: Bundling G-Wrap

[Linas Vepstas]

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: Bundling G-Wrap

[Linas Vepstas]

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: FreeBSD compile

[Linas Vepstas]

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: gnucash from CVS

[Linas Vepstas]

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: [Gnucash-changes] fix yet another intermediate-math overflow bug.

[Linas Vepstas]

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: Improved checks for scanf %lld and %qd as per gc-devel mail.

[Linas Vepstas]

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

How to use the Wiki????

[Linas Vepstas]

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: Wishes to the new G-Wrap maintainer?

[Linas Vepstas]

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

Re: [Gnucash-changes] remove 32-bit limits that show up in division calculations (could cause

[Linas Vepstas]

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: fix the test case; it really is an overflow on division, there's a

[Linas Vepstas]

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: donating

[Linas Vepstas]

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: More KMyMoney peeking: is our file format clearly documented?

[Linas Vepstas]

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=4496256forum_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

Search [was Re: donating]

[Linas Vepstas]

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: donating

[Linas Vepstas]

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

Re: More KMyMoney peeking: is our file format clearly documented?

[Linas Vepstas]

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: More KMyMoney peeking: is our file format clearly documented?

[Linas Vepstas]

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?

[Linas Vepstas]

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: Search [was Re: donating]

[Linas Vepstas]

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: donating

[Linas Vepstas]

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]

[Linas Vepstas]

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

[Linas Vepstas]

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

[Linas Vepstas]

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

[Linas Vepstas]

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: automatic ex/import of data

[Linas Vepstas]

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: QOF iteration and callbacks

[Linas Vepstas]

On Fri, Jun 18, 2004 at 04:49:37PM -0400, Derek Atkins was heard to remark:
 Neil Williams [EMAIL PROTECTED] writes:
 
  one can then ask, at run time, what parameters are associated with a given 
  type, even if those parameters were not known at compile time.
  src/doc/html/group__Class.html
 
 Yes, at this point there are no APIs to implement this.  

Whoops.  It is straightforward enough to add a 'for-each' function.
I'll see if I can do that right now.

  hoping I don't have to copy a whole batch of these sections from the source 
  tree:
 
 Right now this is what you need to do.

Ugh.  copying ... bad.  Foreach, much better.  My only concern is that
I am not convinced that simply asking for all paramters is the right
thing to do for whatever it is that you are doing.  There are very few
realistic situations where knowing 'all' parameters is the right thing.
Most other cases require specialized knowledge of what the object really
is  does.

--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

[Linas Vepstas]

On Sun, Jun 20, 2004 at 04:28:43PM +0100, Neil Williams was heard to remark:
 On Sunday 20 June 2004 4:12, Linas Vepstas wrote:
  On Fri, Jun 18, 2004 at 04:49:37PM -0400, Derek Atkins was heard to remark:
   Neil Williams [EMAIL PROTECTED] writes:
one can then ask, at run time, what parameters are associated with a
given type, even if those parameters were not known at compile time.
src/doc/html/group__Class.html
  
   Yes, at this point there are no APIs to implement this.
 
  Whoops.  It is straightforward enough to add a 'for-each' function.
  I'll see if I can do that right now.
 
 I've posted the code as it was this morning (see other message) and I can 
 explain why a GSList of parameter names is sufficient for me and, probably, 
 would be better than a foreach of the entire list for my needs.

Hmm. I've found that the foreach() style of programming is better
ifor many reasons, and want to support only that.  I was tickled to 
notice the other day that even the Linux kernel is migrating to 
a foreach style of coding.

It should be easy for you to take a foreach interface and build 
a gslist if that's what you want. 

 The original scenario involved just adding a single invoice - in that case, I 

I haven't yet read the back-emails. If you're working with invoices,
why would you need to know about all objects or all paramters?  
Don't you already ahve a clear idea of what an invoice is?

--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

[Linas Vepstas]

On Sun, Jun 20, 2004 at 12:02:28PM -0400, Derek Atkins was heard to remark:
 
 The idea here is a general BookMerge, to allow you to combine two
 books together.  This has many purposes:

Ahh, OK, that makes sense. I've sort-of wanted that feature for a 
while. (well, for gnotime, actually, but ... hey.)

Anyway, I have now checked into the cvs head branch the following:


/** Type definition for the class callback function. */
typedef void (*QofClassForeachCB) (QofIdTypeConst, gpointer);

/** Call the callback once for each object class that is registered
 *  with the system.  The 'user_data' is passed back to the callback.
 */
void qof_class_foreach (QofClassForeachCB, gpointer user_data);

/** Type definition for the paramter callback function. */
typedef void (*QofParamForeachCB) (QofParam *, gpointer user_data);

/** Call the callback once for each parameter on the indicated
 *  object class.  The 'user_data' is passed back to the callback.
 */
void qof_class_param_foreach (QofIdTypeConst obj_name,
  QofParamForeachCB, gpointer user_data);

--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)

[Linas Vepstas]

On Fri, Jun 18, 2004 at 11:33:46AM -0400, Derek Atkins was heard to remark:
 
 Basically, I think we need to re-think the C-scheme interaction,

I've wanted to change gnucash reports to a completely different 
mechanism, somthing that uses e-guile or the nearly-equivalent
trick I use in gnotime.  (This is what I asked the coder to code
initially, but they didn't want to do it that way.)

I am loathe to start any discussion on this right now, because
I'm busy with other things.


 and how scheme is used as an extension/configuration language.

Yeah, I guess it didn't quite work out as envisioned. 

Gnome GConf seems to be the standard gnome way of soring config
entries.  I don't quite like the way GConf is currently 
implemented, but I'm guessing that it should be pretty future-proof,
and get improved eventually.

--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

[Linas Vepstas]

On Sun, Jun 20, 2004 at 12:16:20PM -0400, Derek Atkins was heard to remark:
  void qof_class_foreach (QofClassForeachCB, gpointer user_data);
 
 We already had qof_object_foreach_type(); why do we need a
 qof_class_foreach()?

I am thinking about merging object and class into one thing. 
Maybe.  Any remarks pro or con appreciated.

But right now, they're distinct, and in principle, just because
one is used doesn't mean the other is.  The foreach-lists could
be different.

--linas

p.s. the consideration driving the 'merge' thoughts is that I need
to provide an API to declare how objects/class paramters map to 
sql tables and fields.  I've got an API that does this now, but its
not 'generic' and sufficiently abstracted yet.


-- 
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

[Linas Vepstas]

On Sun, Jun 20, 2004 at 05:12:09PM +0100, Neil Williams was heard to remark:
 
 The final code should open up all sorts of possibilities, like closing books 
 easily 

I've already got code that closes books; its been checked in and
operational for a while (years?), except that the business classes 
aren't yet supported.  Also, its a bit of a hash as to how the 
backends are supported (file vs. sql).  A closed book goes into 
its own file.

Book closing makes copies of all the accounts, but sorts trasnactions
into old and new.  There's some subtle interplay between transactions 
lots  opening balances on equity accounts.  Also, derek suggests that 
instead of copying accounts, they should be version with a copy-on-write 
scheme, which I am thinking about.   These are all meta-issues I want 
to both write the code for, and to defer until I get farther with the 
generic sql backend work. (basically, until I get the copy-on-write
into the generic backend so that business obs can be supported).

--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)

[Linas Vepstas]

On Sun, Jun 20, 2004 at 12:44:10PM -0400, Derek Atkins was heard to remark:
 
  Gnome GConf seems to be the standard gnome way of soring config
  entries.  I don't quite like the way GConf is currently 
  implemented, but I'm guessing that it should be pretty future-proof,
  and get improved eventually.
 
 My only concern is distributed computing.  So long as the user's gconf
 data is stored in their home directory and not in some central gconf
 database then I don't mind using gconf.  

gconf2 stores all config info in a central DB; the old/deprecated
gconf1 stored them in files.

I am not sure why exactly gconf2 is centralized; but I do beleive
its a true network daemon, so that in principle, you could get the
gconf2 settings from other machines ... maybe.  I really don't 
understand how that's supposed to work.   Its a good question for
one of the desktop lists.

(once again, I wish I could have the same desktop on all of the 
various computers I work on ... but I can't, at least not easily,
not without nfs mounts and other hacks.)

--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

[Linas Vepstas]

On Sun, Jun 20, 2004 at 12:45:37PM -0400, Derek Atkins was heard to remark:
 [EMAIL PROTECTED] (Linas Vepstas) writes:
 
  On Sun, Jun 20, 2004 at 12:16:20PM -0400, Derek Atkins was heard to remark:
   void qof_class_foreach (QofClassForeachCB, gpointer user_data);
  
  We already had qof_object_foreach_type(); why do we need a
  qof_class_foreach()?
 
  I am thinking about merging object and class into one thing. 
  Maybe.  Any remarks pro or con appreciated.
 
 What's the difference now?

Well, you're the guy who made this distinction when you wrote 
the code way back when ... :)

-- object defines the relationship to the 'backend'.
-- class defines parameters.

historically, parameters could only be queried, and 'class' was used
only by the query subsystem.  The objects were used only for the 
backend interaction.

 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 ... 

--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))

[Linas Vepstas]

On Sun, Jun 20, 2004 at 07:26:56PM +0200, Thomas Viehmann was heard to remark:
 Derek Atkins wrote:
  show-stopper if you tie a user's gnucash configuration to a single
  machine.  I'd rather keep the existing scheme-based configuration than
  lose the ability to have the same desktop on multiple machines (I
  already have this feature in my environment).
 
 AFAIU, networking needs to be enabled in /etc/orbitrc (which it isn't by
 default at least in Debian), 

Network security fears ... 

 then settings will be shared across the
 network and written by the first gconfd activated by the user, assuming
 $HOME is shared.

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.

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.

--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

[Linas Vepstas]

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

Re: g-wrap (was Re: QOF won't link)

[Linas Vepstas]

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