Re: PalmOS port and conduit
Scott Bundy writes: > I noticed on the webpage that you guys are looking for someone to do the > palm port of gnucash with conduits, etc... If someone has not already > signed up for this, I would like to volunteer my services, or at least > help out if someone already has started on this. There has been a lot of talk, but I don't think anyone has started on it. Are you proposing to actual port gnucash to the palm? A simpler first step might be to make a conduit from the palm expense app to gnucash. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Clark Jones writes: > A thought has occurred to me: A possible solution would be to "migrate" > to C++ (not a humongous project, since a quick look through a "tar -tvzf" > of a source-tarball reveals that it's mostly in C) and then use C++'s > ability to "overload" the normal operators to, in essence, construct > "custom fixed-point data types". > It's a good thought, and the use of C++ operator overloading is convenient for this kind of thing, but there is a rather large problem. You may have noticed on the way through that we use Scheme for a substantial amount of our functionality, and that we use a tool called g-wrap to make the C functions available through Scheme. Wrapping C++, particularly when we will have to use C++ classes and overloading, would get rather ugly, to say the least. The pain of having to write gnc_money_plus(x, y, z) rather than x = y + z will be relatively small by comparison, I believe. In fact, as most of the actual calculations are going to be performed in Scheme (the reports are all in scheme) the nastyness of using (as distinct from implementing) gnc_money_plus isn't really all that nasty. However, if we can't find a C library for doing this that meets our needs, turning fixpoint arithmetic code that we write into a library that could be used for other applications is worth some careful consideration. Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: PalmOS port and conduit
Dave Peticolas writes: > Scott Bundy writes: > > I noticed on the webpage that you guys are looking for someone to do the > > palm port of gnucash with conduits, etc... If someone has not already > > signed up for this, I would like to volunteer my services, or at least > > help out if someone already has started on this. > > There has been a lot of talk, but I don't think anyone has started > on it. Are you proposing to actual port gnucash to the palm? A simpler > first step might be to make a conduit from the palm expense app to > gnucash. > > dave Dave, I've already discussed this with Scott, and he is keen to implement a fully-fledged Palm app of his own, which would be something "in the spirit of" and be able to share data with GnuCash, but would not be a real port given the huge divergence in the two platforms. Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: PalmOS port and conduit
Robert Graham Merkel writes: > Dave Peticolas writes: > > Scott Bundy writes: > > > I noticed on the webpage that you guys are looking for someone to do the > > > palm port of gnucash with conduits, etc... If someone has not already > > > signed up for this, I would like to volunteer my services, or at least > > > help out if someone already has started on this. > > > > There has been a lot of talk, but I don't think anyone has started > > on it. Are you proposing to actual port gnucash to the palm? A simpler > > first step might be to make a conduit from the palm expense app to > > gnucash. > > > > dave > > Dave, I've already discussed this with Scott, and he is keen to implement > a fully-fledged Palm app of his own, which would be something "in the > spirit of" and be able to share data with GnuCash, but would not be a real po > given the huge divergence in the two platforms. Sounds good! dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Attempt to build RPM fails
On Thu, Jun 29, 2000 at 05:35:21PM -0700, Dave Peticolas wrote: > Graham Leggett writes: > > File not found: /var/tmp/gnucash-1.4.1/usr/man/man1/gnucash.1 > > File not found: /var/tmp/gnucash-1.4.1/usr/man/man1/gnc-prices.1 > > There does seem to be an error further up in that the man files > are not getting installed in the expected place. However, the > rpms may still get built, I'm not sure. Check the RPMS and SRPMS > directory to see if they showed up. The RPMs will fail to build if the spec file lists a file that cannot be found. You'll either have to fix the problem causing the man pages not to be installed, or comment out the two lines listing the man pages near the end of the spec file. kdy -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Money transfer between accounts
Bill Gribble wrote: > > "Charles M. Gagnon" <[EMAIL PROTECTED]> writes: > > Actually, this would be convenient for any type of currency, > > not only for EURO currencies. It should also be allowed > > between expense/income account and bank accounts. > > > > I'm running into the same problems with CAD and USD bank > > accounts. > > You need to use an intermediate "currency trading" account. Make an > account of type "Currency" that has USD as its currency and CAD as its > Security. In this account, you can "buy" CAD for USD and the Price > field in the register (it's basically a stock register) represents the > exchange rate (USD per CAD). > > You can transfer money to/from either CAD or USD-denominated accounts > from a currency account like this. Let me cite Linas from his GnuCash Project Goals: > Need to support multiple currencies. Work is needed in the GUI. The engine > currently supports multiple currencies by treating them as securities, thus > allowing currency trading. The currency-trading register needs a complete > overhaul as it is obtuse and unintuitive. I strongly agree here. > A simplfied way of dealing with one-shot currency exchanges needs to be > implemented, essentially just a simple calculator popup. I volunteer here (soon now, really) > Status: Need to rethink wether the one-shot exchanges should in fact be > recorded full-fledged in the engine. Also: EURO support is currently > hacked in: the EURO is treated as a 'special' currency. Virtually all the > euro code can be fully generalized (and should be). I hacked the EURO code and I will generalize it. Question to Linas: Have you made up your mind yet how to record one-shot exchanges in the engine? I don't know the engine well enough yet, so any hints will be appreciated. Herbert. -- Herbert Thoma FhG-IIS A, Studio Department Am Weichselgarten3, 91058 Erlangen, Germany Phone: +49-9131-776-323 Fax: +49-9131-776-399 email: [EMAIL PROTECTED] www: http://www.iis.fhg.de/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Hello Robert, >>> Robert Graham Merkel <[EMAIL PROTECTED]> 30.06.00 09:31:59 >>> perhaps I understand something wrong but I think one of the purposes of operator overloading in C++ is to be able to write something like "x = y + z" instead of "gnc_money_plus(x, y, z)", even if the "+" operator does complex, not necessarily arithmetic operations instead of just a simple addition. At least I use it that way... Bye, Ralf -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, 30 Jun 2000, Ralf Gorholt wrote: > perhaps I understand something wrong but I think one of the purposes of > operator overloading in C++ is to be able to write something like "x = y + > z" instead of "gnc_money_plus(x, y, z)" You are correct. However Robert was pointing out that you do not have that capability on the scheme side of things. Personally, I think that this is one weakness in the present approach to report generation. I would prefer to see an implementation that does the calculations in the engine (as directed by the report generator) and only does the displaying in the external part. That way we would be able to take advantage of database implementations of the summation in the case that we use an SQL database for the store. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
PC Expo Plug
Just an interesting tidbit... Mark Bolzern plugged Gnucash in his keynote at PC Expo. Unfortunately there was only about 140-150 people there... but still cool. Here is the URL to the RealAudio version of the keynote. http://www.zdnet.com/zdtv/cgi-bin/zdvmod_smi/zdtvradio/06262000/i_linux_000629.rm -- Jeremy Collins, Web Developer LinuxMall.com [EMAIL PROTECTED] [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup v2
> On Wed, 28 Jun 2000, Robert Graham Merkel wrote: > > But what if some catastrophic event happens while the modified log > > file is written to disk? Couldn't you possibly lose the entire log? > > I think not, but I don't know for sure. I was thinking that GnuCash > would open() the log for appending only, and every now and then write a single > log entry using a single write() call. What are the chances of a write error > destroying data earlier in the log? War stories, anyone? > (When chopping off the front of a log, GnuCash would use the same > write-and-move procedure as it would when saving the database.) When appending to a file, unless the end of file is exactly aligned on a physical block boundary, the entire last block must be rewritten. This puts the (partial) contents of the last block at risk. Note that physical blocks on modern hard disks are much larger than the nominal 512 bytes oa 1k that Linux uses internally. -- hendrik -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jun 30, 2000 at 01:19:03PM +0200, Ralf Gorholt wrote: > > perhaps I understand something wrong but I think one of the purposes > of operator overloading in C++ is to be able to write something like > "x = y + z" instead of "gnc_money_plus(x, y, z)", even if the "+" > operator does complex, not necessarily arithmetic operations instead > of just a simple addition. At least I use it that way... > Can't scheme be made to do that? I mean, it knows enough to overload arithmetic operators for integer and floating-point already. Wouldn't this just be another numeric type? -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
> Clark Jones writes: > > > A thought has occurred to me: A possible solution would be to "migrate" > > to C++ (not a humongous project, since a quick look through a "tar -tvzf" > > of a source-tarball reveals that it's mostly in C) and then use C++'s > > ability to "overload" the normal operators to, in essence, construct > > "custom fixed-point data types". > > > > It's a good thought, and the use of C++ operator overloading is > convenient for this kind of thing, but there is a rather large > problem. > Don't want to start a language flame war, but after listening to several weeks of C++ propaganda, I am no longer able to remain silent. In my experience (which includes writing a C++ parser and semantic analyser in C++ --- I'm not exactly a C++ novice), C++ is a slippery slope. You start out innocently enough defining a few operators to improve notation, and maybe a machanism for automating reference counting. After a while, you start using more and more of the metaprogramming tools built into the system and it becomes more and more difficult to know what your program is doing (and if it is doing the right thing). It takes ths utmost discipline to refrain from this behaviour in C++, a discipline that is alien to the gung ho style with whoch the C++ language was invented. In fact, the discipline needed is very close to restricting oneself to the subset of C++ that is essentially equivaleng to C semantically, which poses the question, why not stick with C? -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Richard Wackerbarth <[EMAIL PROTECTED]> writes: > Personally, I think that this is one weakness in the present approach to > report generation. I would prefer to see an implementation that does the > calculations in the engine (as directed by the report generator) and only > does the displaying in the external part. This is being planned. We have the same concerns; currently there are a few places in the code where things like reports are generated by iterating over all the splits. That functionality should be set up so that a different backend could help performance if the underlying data abstraction supports some operations directly. Of course there will be computations that aren't in the engine, but if you have a good set in there you can reduce the problem significantly. Finishing the process of publishing the Query API to scheme is a start. After that, we need to start specifying what kind of processing primitives the engine should have. Any thoughts? b.g. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Robert Graham Merkel <[EMAIL PROTECTED]> writes: > It's a good thought, and the use of C++ operator overloading is > convenient for this kind of thing, but there is a rather large > problem. C++ operator overloading is almost never the right thing to do, IMO. The operators already have meanings of their own, and they never quite match the semantics of the overloading function, so you end up having to read the 'foo_t::operator+' code anyway just to see exactly what it means to '+' two foo_t together. If it's not obvious exactly what it means to add two foo_t together with + when you see it in the code, then the syntax is obstructive and you'd be better served with an explicit function call that doesn't fool the eye into thinking something different is happening than actually is. In this case, if we are going to use a completely different number representation, does anyone actually believe it's just going to be a matter of defining a class and then piping the code through sed -e 's/double/GNCNumeric/g' ? We're going to have to rewrite a big chunk of the engine and the surrounding gnucash application to make it work right. I think it's the right thing to do, but in this case it will be a LOT better to have all our dependencies on double math cause blatant compilation errors rather than be silently made to "work" by the existence of an operator+ for the new type. The semantics of adding numbers together (and subtracting, and multiplying) is very different when the operation could result in the loss of information, and when the application needs to control the way in which that information is preserved or discarded. Not to mention that we have to put an entire infrastructure in place for handling the appropriate precision of representation throughout the application, and for converting values to and from our "special" number representation for input and output. I have enough experience with c++ to be very, very skeptical about the possibility that it will be a net win for us. c is bad enough about encouraging you to shoot yourself in the foot; c++ practically pulls the trigger for you. > However, if we can't find a C library for doing this that meets our > needs, turning fixpoint arithmetic code that we write > into a library that could be used for other applications is worth > some careful consideration. Please be careful about use of the term "fixpoint". It implies that the smallest-countable-unit is related to the unity-unit by a power-of-ten relationship. That's true for US Dollars, but it's not something we can assume for other currencies or for other numeric values that we will want to represent in this format. Even if we *can* find a fixed-point library out there, it's not what we need, IMO. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Money transfer between accounts
Herbert Thoma wrote: [...] > > A simplfied way of dealing with one-shot currency exchanges needs to be > > implemented, essentially just a simple calculator popup. > > I volunteer here (soon now, really) I'm not at all familiar with the internals of GnuCash, but it would seem to me that if someone is going to go to the trouble of implementing a calculator popup, they might as well make it available whenever you're entering data into a "currency" field (e.g., a "credit" or a "debit"). Also, the currently displayed "value" in the "calculator" should transfer from/to the field in question "automagically", at least when the popup is first brought up and every time the "=" key is hit. Quicken has something like this, and although it's useful, frankly, for my purposes it's pretty far down on my personal "wish list", but here we have a saying that "a job worth doing is worth doing right". Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Bill Gribble wrote: [...] > Please be careful about use of the term "fixpoint". It implies that > the smallest-countable-unit is related to the unity-unit by a > power-of-ten relationship. That's true for US Dollars, but it's not > something we can assume for other currencies or for other numeric > values that we will want to represent in this format. Even if we > *can* find a fixed-point library out there, it's not what we need, > IMO. Well, floating point is definitely NOT the proper solution for US dollars (or any other currency of which I am aware -- anybody know a currency still in use that isn't decimal? The UK abandoned the "shillings & pence" in the '60's). One could use multiprecision integer and represent US dollars in "cents", but that becomes a real pain in the tush, and so is not a proper solution, either, IMHO. The one place I can think of where you still see fractions commonly is in stockmarket quotations, e.g., nonsense like "73 213/256". However, the SEC has told the U.S. stock markets "thou shalt decimalize", and though I don't recall off hand exactly when the deadline is, it's within the next few months. Also, I think if you dig into it, you'd find a rule that the smallest fraction they're allowed to use (at least for things over $1) is 1/256. Although the SEC doesn't have any direct control over non-US stock markets, "international market forces" (i.e., brokerage firms moaning and groaning about having to maintain two different systems) tend to keep them all doing pretty much the same things. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Bill Gribble writes: > Richard Wackerbarth <[EMAIL PROTECTED]> writes: > > Personally, I think that this is one weakness in the present approach to > > report generation. I would prefer to see an implementation that does the > > calculations in the engine (as directed by the report generator) and only > > does the displaying in the external part. > > This is being planned. We have the same concerns; currently there are > a few places in the code where things like reports are generated by > iterating over all the splits. That functionality should be set up so > that a different backend could help performance if the underlying data > abstraction supports some operations directly. Of course there will > be computations that aren't in the engine, but if you have a good set > in there you can reduce the problem significantly. > > Finishing the process of publishing the Query API to scheme is a > start. After that, we need to start specifying what kind of > processing primitives the engine should have. Any thoughts? I've just been thinking about this quite a bit (in between rebuilding my gnome setup after trying to add various CVS bits and having to remove them again . . .). I'll post a summary of this and other issues tomorrow morning. Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Money transfer between accounts
On Fri, 30 Jun 2000, Clark Jones wrote: > If someone is going to go to the trouble of implementing a > calculator popup, they might as well make it available whenever you're > entering data into a "currency" field (e.g., a "credit" or a "debit"). > Also, the currently displayed "value" in the "calculator" should transfer > from/to the field in question "automagically", at least when the popup is > first brought up and every time the "=" key is hit. I often use this feature in Quicken to calculate the allocation of expenses between accounts. For example, when I get a bill for "pest control" at my rental properties, I need to charge a portion of it to each individual property. So I take the total bill and divide by the number of properties to calculate how much to assign to the first property. It is much easier than having to go "off line" to perform the calculation. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Clark Jones <[EMAIL PROTECTED]> writes: > Well, floating point is definitely NOT the proper solution for US dollars That's not what we are talking about. We know that floating point is a bad solution. The point I was trying to raise was that "fixed point" implies decimal fractions, but there are plenty of places that we need non-decimal fractions. They can still be represented exactly (i.e. non floating point), just not using a decimal-fixed-point library. > The one place I can think of where you still see fractions commonly is > in stockmarket quotations, e.g., nonsense like "73 213/256". However, > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > I don't recall off hand exactly when the deadline is, it's within the next > few months. Partially true, but stock prices are an important part of gnucash, and while the US stock exchange is going decimal "pretty soon", there are historical prices which will always be in 64ths and the bond market is not likely to decimalize any time soon (according to Jon Trowbridge, who does this stuff for a living; is that a correct interpretation of your mail to me?). handling integer-penny balances in bank accounts is the easy part of the problem that we have to address. The harder part is correct handling of stock/mutual transactions with fractional-penny results and how that interacts with the smallest-transaction-amount of currencies. Thus it makes sense to have all the parts of the equation (price, share amount, and total value) represented in the same form, which I argue should be more akin to a rational number than to decimal fixed point. I am working on a more concrete proposal about this which I'll probably send around early next week. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, 30 Jun 2000, Clark Jones wrote: > Well, floating point is definitely NOT the proper solution for US dollars On this, I think we finally agree. > One could use multiprecision integer and represent > US dollars in "cents", but that becomes a real pain in the tush, and so > is not a proper solution, either, IMHO. But that is exactly the common implementation of "fixed point", namely "scaled integers". > nonsense like "73 213/256". However, > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > I don't recall off hand exactly when the deadline is, it's within the next > few months. Except that all of the historical data will still be in the old system for some time. In addition, we still have to handle "$1.99 per dozen" -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jun 30, 2000 at 01:39:07PM -0500, Bill Gribble wrote: > Clark Jones <[EMAIL PROTECTED]> writes: > > in stockmarket quotations, e.g., nonsense like "73 213/256". However, > > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > Partially true, but stock prices are an important part of gnucash, and > while the US stock exchange is going decimal "pretty soon", there are > historical prices which will always be in 64ths and the bond market is > not likely to decimalize any time soon (according to Jon Trowbridge, > who does this stuff for a living; is that a correct interpretation of > your mail to me?). Yes. There are also lots of other examples from futures markets, which are a wonderful source of pricing perversity. For example, 10yr and 30yr US Govt Bonds trade in 32nds, and 5yr Bonds trade in 64ths. Soybeans futures (as well as Corn, Oats and Wheat) are quoted in 1/8th of a cent per bushel. Maybe these markets will decimalize (as the UK govt bond market recently did), but the historical prices will be with us forever. :-/ -JT -- GNU/Linux: Free your mind and your OS will follow. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Money transfer between accounts
On Fri, 30 Jun 2000, you wrote: > Herbert Thoma wrote: > [...] > > > A simplfied way of dealing with one-shot currency exchanges needs to be > > > implemented, essentially just a simple calculator popup. > > > > I volunteer here (soon now, really) > > I'm not at all familiar with the internals of GnuCash, but it would seem to > me that if someone is going to go to the trouble of implementing a calculator > popup, they might as well make it available whenever you're entering data > into a "currency" field (e.g., a "credit" or a "debit"). Also, the currently > displayed "value" in the "calculator" should transfer from/to the field > in question "automagically", at least when the popup is first brought up > and every time the "=" key is hit. > > Quicken has something like this, and although it's useful, frankly, for my > purposes it's pretty far down on my personal "wish list", but here we > have a saying that "a job worth doing is worth doing right". > > Clark > -- I am currently developing such a calculator "engine" for gnucash. The calculator is needed by the "financial calculator" I have developed. Dave has agreed to do the GUI. I hope it could be used by any part of gnucash, not just the financial calculator. The calculator engine is currently finished - it has the four functions (+ - / * and grouping with ( and ) ).. Other operators can be added easily as needed. Also named variables are recognized and supported. It is totally independent of the underlying numeric representation -after following the discussion here about the representation - I decided early on that the representation (and actual arthmetic operations should be independent of the parser/evaluation "engine". I am currently documenting the API for Dave and anybody that wants to use it. This should be completed in a few days and I will bundle the whole thing together and send to Dave. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problems on Slackware 7.0 Dist.
Jon Trowbridge wrote: > On Wed, Jun 28, 2000 at 01:16:01PM -0500, Bill Gribble wrote: > > Budman <[EMAIL PROTECTED]> writes: > > This isn't referring to QT the graphics toolkit; it's QThreads, the > > guile cooperative threading library. qthreads should be a part of the > > standard guile distribution; try running 'guile-config link' to > > see if guile knows where to find qthreads. On my system (debian) > > it prints this: > > > > $ guile-config link > > -L/usr/lib -lguile -lqthreads -ldl -lm > When I did this, it didn't show the -lqthreads. Did the older version 1.3.2 require qthreads? > > In older versions of guile, qthreads wasn't built by default: You had > to run configure with the --enable-threads (or was it > --enable-qthreads?) option for libqthreads to be built. This caused > no end of problems. > > The three posibilities here are: > > (1) You built guile from sources yourself, and didn't say > --enable-threads when you ran configure. The solution is > to re-build/re-install, adding this option. > Woohoo! :) I recompiled guile with the --with-threads option. That did it. Thanks for the help! Rich -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Trying to get started
I'm trying to get started using gnucash 1.4.1 under FreeBSD 4.0. When I compiled g-wrap 0.9.4 I got the following message: gwrap-rscheme.c:19: rscheme.h: No such file or directory __ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Trying to get started
>I'm trying to get started using gnucash 1.4.1 under
>FreeBSD 4.0. When I compiled g-wrap 0.9.4 I got the
>following message:
>
>gwrap-rscheme.c:19: rscheme.h: No such file or
>directory
Try this patch:
--- configure.orig Wed Jun 28 14:13:30 2000
+++ configure Wed Jun 28 14:13:56 2000
@@ -1594,7 +1594,7 @@
fi
# Extract the first word of "rs", so it can be a program name with args.
-set dummy rs; ac_word=$2
+set dummy rscheme; ac_word=$2
echo $ac_n "checking for $ac_word""... $ac_c" 1>&6
echo "configure:1600: checking for $ac_word" >&5
if eval "test \"`echo '$''{'ac_cv_path_RSCHEME'+set}'`\" = set"; then
I submitted a port for g-wrap to the ports tree yesterday, so hopefully
it will make it into the tree soon. I also just submitted patches to
upgrade the gnucash port to 1.4.1, so hopefully that will make it into
the tree in a few days. I can send you the port I've put together,
if you'd like.
Matt
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
gnucash 1.4.1
Hello gnucash-list, I have installed gnucash 1.4.1 with the rpm-File (I use SuSE 6.4) The installation was OK (I have got no message), but when I try to run gnucash I get a message about missing libguile.so.4 (I have installed libguile.so.6) and later libreadline.so.3 ( I have installed libreadline.so.4). Can anybody help me? Thanks Poldi -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, 30 Jun 2000 07:13:03 MST, the world broke into rejoicing as
Randolph Fritz <[EMAIL PROTECTED]> said:
> On Fri, Jun 30, 2000 at 01:19:03PM +0200, Ralf Gorholt wrote:
> >
> > perhaps I understand something wrong but I think one of the purposes
> > of operator overloading in C++ is to be able to write something like
> > "x = y + z" instead of "gnc_money_plus(x, y, z)", even if the "+"
> > operator does complex, not necessarily arithmetic operations instead
> > of just a simple addition. At least I use it that way...
>
> Can't scheme be made to do that? I mean, it knows enough to overload
> arithmetic operators for integer and floating-point already. Wouldn't
> this just be another numeric type?
Come on, people. The issue is _not_ what "object system" is being
used, or what language is being used, but rather _what the numeric
representation should be_.
If I see another suggestion that GnuCash be rewritten in C++ because
C++ offers some aspects of operator overloading, I'm going to scream.
The suggestions, to that end, have really amounted to:
"Why don't we adopt C++? It has some cool object stuff, and if
we adopted that, I'm sure someone could come up with a data
representation that would be suitable."
To put the issue off to "Well, if we adopt C++, someone else will think
of something..." is an aggravating waste of bandwidth.
C and C++ have the _same_ basic sets of basic data types; any money
representation that is expressible in C++ is equally expressible in C.
Moving to C++ does not magically add in a horde of new numeric data types.
If you have ideas on a _data type_, then by all means speak up.
Suggesting mere syntactic sugar misses the point of the exercise, which
is a _DATA TYPE_.
Options that leap to mind involve the following:
-> The numeric amount should involve a "big integer," and a radix.
Thus,
struct {
gint64 amount;
gint8 radix;
} basic_money;
-> There should be some indication of the currency that is involved.
Thus...
struct {
char curr[3];
gint64 amount;
gint8 radix;
} more_complex_money;
There is a bit of a problem with this; there is the redundancy that
the radix is determined by the currency, so that we would need _two_
structures that "cross link":
struct {
char curr[3];
gint8 radix;
} curr_info;
struct {
char curr[3];
gint64 amount;
} linked_complex_money;
Further than that, the way the currency works _may_ be date-dependant.
For instance, if Mexico does a redenomination of their currency due to
rampant inflation, we might need to have "old pesos" and "new pesos."
In effect, the amount depends on the date on which it occurs. Mind
you, that starts making things cross-link _even more_, which seems
to me to be a bad thing.
Frankly, I think the best option is:
struct {
char curr[3];
gint64 amount;
gint8 radix;
} more_complex_money;
as this combines the data that we want to know about, and diminishes
the need to look up more.
By the way, I am willing to assume decimal amounts, as even the
stock markets are "decimalizing." If that be not the case, then
my "favorite" representation is:
struct {
char curr[3];
gint64 numerator;
gint64 denominator;
} complex_money;
The other _major_ alternative would be to look to the OMG's
FBO:Curr class, which uses the IDL "fixed" type. fixed maps, in
C, to:
struct {
CORBA_unsigned_short _digits;
CORBA_short _scale;
CORBA_char _value[ceiling((intpart + decimals)/2)];
} CORBA_fixed_whatever;
If others have suggestions for _data structures_, feel free to
suggest reasons why your _data structure_ is preferable to one
of the above.
Please _don't_ waste bandwidth arguing over the merits of different
forms of object overloading, unless you figure that will contribute
_significantly_ to determining an appropriate _data structure_.
--
[EMAIL PROTECTED] -
Re: PC Expo Plug
Jeremy Collins wrote: > > Just an interesting tidbit... Mark Bolzern plugged Gnucash in his > keynote at PC Expo. Unfortunately there was only about 140-150 people > there... but still cool. > > Here is the URL to the RealAudio version of the keynote. > > http://www.zdnet.com/zdtv/cgi-bin/zdvmod_smi/zdtvradio/06262000/i_linux_000629.rm > > -- > Jeremy Collins, Web Developer > LinuxMall.com > [EMAIL PROTECTED] > [EMAIL PROTECTED] > Excellent demonstration of RealPlayer 7.0 for Linux. :) Sounds pretty good, and seems stable as well. That's a long damn 'clip', though. -- Matthew Vanecek Visit my Website at http://mysite.directlink.net/linuxguy For answers type: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' * For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, 30 Jun 2000, Christopher Browne wrote:
> Come on, people. The issue is _not_ what "object system" is being
> used, or what language is being used, but rather _what the numeric
> representation should be_.
To a large extent, I agree.
> C and C++ have the _same_ basic sets of basic data types; any money
> representation that is expressible in C++ is equally expressible in C.
> Moving to C++ does not magically add in a horde of new numeric data types.
Some languages make it easier to define and manipulate structured data,
particularly when there are multiple variants of that data, but the
fundamental representation is equivalent.
> If you have ideas on a _data type_, then by all means speak up.
I don't think that we should have ** A ** data type. The code needs to be
written is such a manner that we can change the representation and affect
ONLY the "operator" (aka methods, etc) implementation.
> Suggesting mere syntactic sugar misses the point of the exercise, which
> is a _DATA TYPE_.
I suggest:
struct {
currency *denomination;
monetary_value_t amount;
} generic_money;
struct {
char curr[3]; /* Currency Name */
char currency_symbol;
monetary_value_t unity;
...
various proc* to implement money --> display string, etc.
} currency;
struct {
SQL_money value;
} monetary_value;
or
struct {
gint64 value;
} monetary_value;
or
struct {
CORBA_whatever value;
} monetary_value;
or ...
as may be appropriate
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
gnucash 1.4.1
Poldi Winkler writes: > Hello gnucash-list, > I have installed gnucash 1.4.1 with the rpm-File (I use SuSE 6.4) The > installation was OK (I have got no message), but when I try to run > gnucash I get a message about missing libguile.so.4 (I have installed > libguile.so.6) and later libreadline.so.3 ( I have installed > libreadline.so.4). Can anybody help me? Unfortunately, the standard RPM doesn't work on SuSE. You can either build gnucash yourself, or wait until we get a SuSE-specific RPM built. Sorry about this. Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Richard Wackerbarth wrote: > > On Fri, 30 Jun 2000, Clark Jones wrote: > > > Well, floating point is definitely NOT the proper solution for US dollars > On this, I think we finally agree. :-) > > One could use multiprecision integer and represent > > US dollars in "cents", but that becomes a real pain in the tush, and so > > is not a proper solution, either, IMHO. > > But that is exactly the common implementation of "fixed point", namely > "scaled integers". This may have changed in the 20 years or so since I was actually dealing with them, but the "business oriented" languages usually do it with "binary coded decimal", rather than scaled integers. Since few processors support BCD in their instruction sets (the exception that comes to mind off hand is the Z-80) this is one of the reasons that the code they produce is so _OOOWWW_. > > nonsense like "73 213/256". However, > > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > > I don't recall off hand exactly when the deadline is, it's within the next > > few months. > > Except that all of the historical data will still be in the old system for > some time. A thought that has occurred to me is that the examples that people are coming up with are all "binary fractions" of either dollars or cents. This may be a useful observation... > In addition, we still have to handle "$1.99 per dozen" I think that no matter how we slice it, "7 at $1.99 per dozen" is always going to involve some roundoff error, especially if "dozen" is a "baker's dozen"! Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Report calculations in the engine
There has been some discussion recently over whether the engine should have features that allow extracting higher-level summary information (such as totals etc.) for reporting purposes. In the medium to long term, it would be great to move gnucash to support multiple users, with the engine backend sitting on a server and the client(s) communicating with the server (possibly using CORBA or some similar method). We may even have multiple implementations of the engine, some of which may support different methods of extracting report-relevant data - and, for that matter, multiple implmentations of the client - who knows, we might even have implementations of both client and server which are by third parties. Therefore, discussions of what's appropriate to go into the engine and what should go into the UI should be taken in that context. Looking at the kind of reports that are likely to be needed (a full discussion of required reports will be in a subsequent mail), they can be broadly categorised as transaction reports, total reports (where balances at a point or changes in balances over an interval are summarised), and investment reports, where various non-trivial calculations are performed on the splits in an account or multiple accounts (such as calculating cost basis and ROI). Transaction reports may involve large numbers of transactions, but all that needs to be done is to extract the relevant splits and send them to the UI for rendering. Once we have the query interface wrapped, to allow the efficient extraction of relevant splits from the engine, that's about as efficient as we're likely to get. Shifting any more computation into the server is just placing more processor and memory load on that server, makes modifying the reports more difficult (it's much easier for users to customise the rendering of their reports if the rendering is done at the client end), and makes the server bigger, uglier, and less maintainable. As stated previously, investment reports (I'm generalising here) require some rather non-trivial calculations that vary from report to report and undoubtedly from country to country. The good news with investment reports, however, is that they are unlikely to involve hundreds of thousands of transactions. Typically, they will be used by home and small business users, and involve hundreds, thousands, or at the very outside tens of thousands of transactions - the sort of thing that comfortably sits inside the main memory of a modern machine. Therefore, it's not going to overload the server, or overload the network, if we send those transactions to the client to process - again, provided the query interface allows us to efficiently extract the relevant transactions. Doing the complex calculations in the client also keeps that complexity out of the engine, which is again a good thing. However, "total reports" could be done rather more efficiently if, instead of sending all the splits to the client for calculating totals, those totals were calculated by the engine. This would require very little engine code, greatly reduce network traffic, would allow "optimized" methods that a database-backend engine could use, would cause very little extra work for the engine (in fact, the reduction in network traffic might give us a net reduction in processor load), and simplify the client reporting code. So, in essence, I would argue for a small extension to the query interface to allow totals rather than split lists to be returned, wrapped, like the rest of the query engine, for use by the Scheme reporting code. Anything more complex than totals, etc. etc. should be kept away from the engine - if it turned out that similar calculations were being used in multiple reports we should generalise them on the client side and keep them out of the engine. Comments? Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
