Graham Leggett <[EMAIL PROTECTED]> writes:
> - crashed with SIGSEGV once every 5 transactions or so
> - lost transactions that had been (repeatedly) entered and saved to disk
> - corrupted transaction data, descriptions were wrong, dates jumped to
> 2005 from 1999.
>
> This was the "stable" motif release of v1.2.3.
First off, I'm sorry you had so much trouble.
> When (if ever) is there a target for a real, working, useful
> release? Presently the only thing Gnucash is good for right now is
> a way to create some Gnome screenshots, nothing more. The trouble
> with Gnucash it would seem is that there is too much work going on
> with features, and almost none with bugfixes. It is way more
> important for a financial package to be consistant and accurate than
> other packages would need to be, yet Gnucash trails way behind in
> this.
You'll get no argument that accuracy and safety in the engine is one
of, if not the, single most important feature, but it's not as simple
as saying "go fix the engine". First of all, the engine is quite
complicated, so there are a *very* small number of people who *can*
fix it right now. This complexity isn't just gratuitous. The
engine's trying to solve a reasonably difficult problem. The point
here is that many of the people working on other things *couldn't* fix
engine problems without spending a lot of time learning the engine.
Second, unless people report the problems accurately, with repeatable
methods for reproducing the problem, it's very difficult to do
anything about it. I use the current CVS version for my data (with
the Lesstif front end), and it works pretty well now, though I do have
to save reasonably often because it will crash now and then. As far
as I know, I haven't lost any data, other than the problem I recently
reported that occurs if you fill up your filesystem, and yes, if
someone else doesn't get to it soon, I'm going to fix that one.
> - The "engine" and the various frontends be split and be developed
> as separate simpler packages.
This is already essentially done. For example, the engine is entirely
contained in src/engine AFAIK. If you don't agree, then you may have
detected a violation of the modularity we indended. Feel free to
report it and we'll see about fixing it.
> - The engine should be turned into a CORBA object so that a client
> going down in flames doesn't destroy data inside the engine.
We've had this discussion before (a long one). Though I'm not very
familiar with CORBA, as I recall, others who are feel that among other
things there are currently substantial security problems with this
approach, so we're not likely to pursue it soon. Further, though I
haven't thought about it carefully yet, unless you do some tedious
restructuring and (potentially buggy) caching, there's likely to be a
tremendous performance penalty.
Right now we handle the "safety" issue by making backup copies of your
files in all the beta versions, and keeping log files detailing what
has been done which could be used to recover after a crash (do we do
either of these in the stable tree? -- if not, then this doesn't help
people using that branch, perhaps we should turn it on). As I
mentioned before, in the current CVS version at least, if I save
often, I've only had minor problems which just involved restarting and
re-entering the data from before the last save. Annoying, but not
fatal.
We have support now for "transactions". Perhaps, we should make this
support stronger, perhaps add a feature that'll let GnuCash detect
lost transactions after a restart and offer to re-add them. Once
Christopher finishes the QIF import/text export (which will probably
supercede mine) mechanism, we could implement this pretty trivially by
spitting scheme forms to a log directory, one file per modification,
before we enter the data into the engine, then checking this directory
on startup for stragglers. If any are found, then we use the import
mechanism to suck them in. Files in this directory would be deleted
whenever a sucessful update was made. (This is just me thinking out
loud, so don't take it too seriously...)
> I'll have some free time coming up soon, and I've been trying to
> find a project to teach myself CORBA, unless there are any
> objections I'd like to start hacking away at getting the transaction
> engine into it's own package and CORBA server.
I'd talk this over with the other CORBA clueful people here first. In
general I'm not very excited about doing this. I think it's likely to
add a lot of build, install, and runtime complexity, including more
dependencies on other packages. Right now we're trying to avoid that.
I think the time might be better spent on tracking down the bugs in
the current code, or in adding crash reovery support. But I'll defer
to those who know CORBA better.
Also, bear in mind that most of the crashes I've seen were most likely
caused by the UI code (as you mention), and on the GNOME side at
least, we have been relying on a beta quality widget to implement the
register (GtkSheet). Heath is in the process of removing this
dependency, supporting our register directly on top of the gnome
canvas, which is quite stable AFAIK. This has the potential to let
move the GNOME side quite a bit forward in terms of stability.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
