Re: Fwd: World friendlier printable invoices
Stuart D. Gathman [EMAIL PROTECTED] writes: On Wed, 3 Oct 2007, Josh Sled wrote: 3/ it sucks. 3 is not very specific :-) Let me help. IMO the main problem with PHP is its strength - the string subsitution model. Shell programming has I think it is neither a very good programming language or a clean templating language. (FWIW, Perl also has a big ugly language mark in its 'con' column, imho.) -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpLhZSWiyj5B.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Dear Derek, Attached please find output of svn diff re gnucash business invoice reports. Sounds like you may be right about changing the options. When I get time I will attempt a test crash by reverting to old reports and opening a gnucash printable invoice, saving then closing gnucash, copying new onto old reports then restarting gnucash. Any hints on how to get useful log or debugging output here? In anticipation, why does it have to crash? Can this be fixed to allow a more graceful, user friendly failure? Bryan On 10/3/07, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available svn.diff.out Description: Binary data ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Josh Sled wrote: Chris Shoemaker [EMAIL PROTECTED] writes: Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. While certainly people are free to do as they will, I think it makes sense to have a rational discussion about the particular language/templating system. Lurking in this list, I have only read the last postings, so excuse me if I'm wrong: Would it pay to let PHP access the invoice data (sth. like a PHP module with bindings to gnc model) ? Then, PHP, widely adopted for html templating, could handle all sorts of forms. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Dear Derek, OK. I tried to crash the program as I previously described using the 2.2.1 latest stable gnucash for Debian Sid. Plus, I tried with an open invoice. IT WILL NOT CRASH. Maybe I fixed the problem by properly localising the Total ex Tax code with those mystery underscore thingies. Maybe it is a problem specific to the 2.0 branch. Dunno. So, unless someone else would like to test it first, can you load the new code into trunk? This will do me until some deus ex machina gives us HTML templates for printable invoices. Best regards to all, Your bleeding user, Bryan Cebuliak Brisbane Oz On 10/3/07, Bryan Cebuliak [EMAIL PROTECTED] wrote: Dear Derek, Attached please find output of svn diff re gnucash business invoice reports. Sounds like you may be right about changing the options. When I get time I will attempt a test crash by reverting to old reports and opening a gnucash printable invoice, saving then closing gnucash, copying new onto old reports then restarting gnucash. Any hints on how to get useful log or debugging output here? In anticipation, why does it have to crash? Can this be fixed to allow a more graceful, user friendly failure? Bryan On 10/3/07, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Bryan Cebuliak [EMAIL PROTECTED] writes: copying new onto old reports then restarting gnucash. Any hints on how to get useful log or debugging output here? Take a look at the logging functions at src/scm/main.scm:165 . In anticipation, why does it have to crash? Can this be fixed to allow a more graceful, user friendly failure? Sure, go for it! :) In particular, check out the error handling shim in src/app-utils/gfec.c, and where it's called from src/bin/gnucash-bin.c in `try_load_config_array(...)` and `load_user_config(...)`. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpm0piAmCxDs.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
P. Christeas [EMAIL PROTECTED] writes: Lurking in this list, I have only read the last postings, so excuse me if I'm wrong: Would it pay to let PHP access the invoice data (sth. like a PHP module with bindings to gnc model) ? Then, PHP, widely adopted for html templating, could handle all sorts of forms. Sure. I think there's two main approaches: 1/ use an explicitly language-neutral templating language such as ClearSilver. 2/ pick a new preferred reports language and use a templating system written in it (python: mako, genshi; perl: Template::Toolkit, HTML::Mason; php: itself) As for picking PHP as that language, I think it has some important marks in its 'Con' column. 1/ it appears to be a very large dependency (relative to perl or python) 2/ it's not already installed on system- or desktop- boxes (in the way perl or python have been for a while now). 3/ it sucks. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpGQtGXQ3kfS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
On Wed, 3 Oct 2007, Josh Sled wrote: As for picking PHP as that language, I think it has some important marks in its 'Con' column. 1/ it appears to be a very large dependency (relative to perl or python) 2/ it's not already installed on system- or desktop- boxes (in the way perl or python have been for a while now). 3/ it sucks. 3 is not very specific :-) Let me help. IMO the main problem with PHP is its strength - the string subsitution model. Shell programming has the same problem for the same reason. Code is built by string substitution and then executed. This make templating very easy and powerful, but is a security and stability nightmare. The problem is that it is *hard* to properly sanitize strings in PHP or unix shell so that they don't do nasty things when substituted, and the result executed. Even accidentally nasty substitutions are common bugs. When written properly for security, PHP code is more difficult and harder to read (IMO) than equivalent code in a language that keeps code and data at arms length. -- Stuart D. Gathman [EMAIL PROTECTED] Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154 Confutatis maledictis, flamis acribus addictis - background song for a Microsoft sponsored Where do you want to go from here? commercial. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
As I've said over and over, the REAL answer is to integrate e-guile and then invoices could be an HTML-template with embedded guile, instead of a scheme program that happens to generate HTML. I'm still waiting for someone to offer to implement that. :-D -derek Quoting Monte Jewell [EMAIL PROTECTED]: I'm a gnucash newbie but very experienced with proprietary billing systems for small law offices. I'm reading everything I can find on how to edit the gnucash templates, but my invoices still look like I'm selling automotive parts (not that there would be anything wrong with that if I wasn't actually drafting separation agreements . . . ) I want to help and to gnu use-share-study-improve the code, esp with nonprofit projects that I volunteer with who have no money to be spending on proprietary licenses but have to do it anyway. This invoice editing problem is kicking my butt so far. mj *** Monte Jewell PC Attorney at Law 500 N Higgins Ave Ste 107 Missoula MT 59802 www.montejewell.com -Original Message- From: Derek Atkins [EMAIL PROTECTED] Date: Tue, 02 Oct 2007 10:09:56 To:Bryan Cebuliak [EMAIL PROTECTED] Cc:gnucash-devel@gnucash.org Subject: Re: Fwd: World friendlier printable invoices Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
I'm a gnucash newbie but very experienced with proprietary billing systems for small law offices. I'm reading everything I can find on how to edit the gnucash templates, but my invoices still look like I'm selling automotive parts (not that there would be anything wrong with that if I wasn't actually drafting separation agreements . . . ) I want to help and to gnu use-share-study-improve the code, esp with nonprofit projects that I volunteer with who have no money to be spending on proprietary licenses but have to do it anyway. This invoice editing problem is kicking my butt so far. mj *** Monte Jewell PC Attorney at Law 500 N Higgins Ave Ste 107 Missoula MT 59802 www.montejewell.com -Original Message- From: Derek Atkins [EMAIL PROTECTED] Date: Tue, 02 Oct 2007 10:09:56 To:Bryan Cebuliak [EMAIL PROTECTED] Cc:gnucash-devel@gnucash.org Subject: Re: Fwd: World friendlier printable invoices Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
On Tue, Oct 02, 2007 at 11:03:29AM -0400, Derek Atkins wrote: As I've said over and over, the REAL answer is to integrate e-guile and then invoices could be an HTML-template with embedded guile, instead of a scheme program that happens to generate HTML. I'm still waiting for someone to offer to implement that. :-D Just for the record, and because, as you point out, this has been repeated several times... I agree that the solution is an html templating system. However, there are many better examples than eguile, if one is willing to use a scripting language other than guile. I, for one, would not recommend anyone actually attempt to integrate e-guile, as that is essentially equivalent to writing and maintaining our own templating system. Also, I think it's very unlikely that anyone will ever get it to do anything impressive. Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. If I only had the time... -chris -derek Quoting Monte Jewell [EMAIL PROTECTED]: I'm a gnucash newbie but very experienced with proprietary billing systems for small law offices. I'm reading everything I can find on how to edit the gnucash templates, but my invoices still look like I'm selling automotive parts (not that there would be anything wrong with that if I wasn't actually drafting separation agreements . . . ) I want to help and to gnu use-share-study-improve the code, esp with nonprofit projects that I volunteer with who have no money to be spending on proprietary licenses but have to do it anyway. This invoice editing problem is kicking my butt so far. mj *** Monte Jewell PC Attorney at Law 500 N Higgins Ave Ste 107 Missoula MT 59802 www.montejewell.com -Original Message- From: Derek Atkins [EMAIL PROTECTED] Date: Tue, 02 Oct 2007 10:09:56 To:Bryan Cebuliak [EMAIL PROTECTED] Cc:gnucash-devel@gnucash.org Subject: Re: Fwd: World friendlier printable invoices Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Quoting Josh Sled [EMAIL PROTECTED]: Just for the record, and because, as you point out, this has been repeated several times... I agree that the solution is an html templating system. However, there are many better examples than eguile, if one is willing to use a scripting language other than guile. I, for one, would not recommend anyone actually attempt to integrate e-guile, as that is essentially equivalent to writing and maintaining our own templating system. Also, I think it's very unlikely that anyone will ever get it to do anything impressive. I strongly agree with this, on all points. That's fine. I don't have a strong opinion.. But honestly, have you looked at e-guile? It's like 100 lines of scheme code, if that. http://woozle.org/~neale/src/eguile is the main site, which points to http://woozle.org/~neale/src/scheme/eguile.scm for the actual meat of the code. Basically, we would need to copy-and-paste that code into gnucash, and then write a report wrapper around it that loaded the proper runtime environment for the report template. I don't see why it's so bad to have our own templating system. Or maybe what you mean and what I mean are completely different things? Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. I suspect the eguile work is much less than 80 hours. Honestly, if I actually had the time I bet I could do it in about a day. The real work is writing the report-code that takes the template file, sets up the pointer to the GncInvoice* and then runs the template (or complains when there is an error). While certainly people are free to do as they will, I think it makes sense to have a rational discussion about the particular language/templating system. If I only had the time... I strongly agree with this, too. :/ Yeah.. :-( -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Chris Shoemaker [EMAIL PROTECTED] writes: On Tue, Oct 02, 2007 at 11:03:29AM -0400, Derek Atkins wrote: As I've said over and over, the REAL answer is to integrate e-guile and then invoices could be an HTML-template with embedded guile, instead of a scheme program that happens to generate HTML. I'm still waiting for someone to offer to implement that. :-D Just for the record, and because, as you point out, this has been repeated several times... I agree that the solution is an html templating system. However, there are many better examples than eguile, if one is willing to use a scripting language other than guile. I, for one, would not recommend anyone actually attempt to integrate e-guile, as that is essentially equivalent to writing and maintaining our own templating system. Also, I think it's very unlikely that anyone will ever get it to do anything impressive. I strongly agree with this, on all points. Instead, if there is anyone interested, I would recommend that they adapt the swig .i files to the popular scripting language of their preference, and use the popular templating system of their choice. This is a far better engineering decision, IMO, and far easier to do, also. It's probably about 80 hours work to the initial working system for someone already familiar with the relevant tools. While certainly people are free to do as they will, I think it makes sense to have a rational discussion about the particular language/templating system. If I only had the time... I strongly agree with this, too. :/ -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpoc2OeNqqiB.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Thanks, Derek. I will have to read up on how to work subversion. Then I will run diff for the second time ever. In the mean time, you have the complete code and the knowledge to fix the crash problem. Ah, but the time? At least I have solved my own little problem about editing gnucash invoice titles and column names. I'll get back to you after I RTFM and do a few test crashes. Your test crash dummy, Bryan On 10/3/07, Derek Atkins [EMAIL PROTECTED] wrote: Hi, Bryan Cebuliak [EMAIL PROTECTED] writes: Pardon me, I am really very new at this. Would you like me to do that now with the files or have you already done it? Will just a plain diff file.scm filenew.scm diffoutfile do the trick? Usually the way to do it would be: svn diff Attached please file the diff output files including the total ex tax localisation changes. Unfortunately you: a) ran diff manually b) didn't use '-u' to create a unified diff Also, do you have an idea why opening gnucash with a saved fancy-invoice report in the old format using the new fancy-invoice.scm etc crashes gnucash? The same may happen with the the other files. Not tested yet. This is avoided if the old report tab is closed prior to saving before upgrading the invoice files. This is a show stopper if it happened with a gnucash upgrade. Umm... Without really seeing your changes (while my brain can process a unified diff, I can't really process a non-context/non-unified diff) I can only guess. My first guess is that you changed the available options so that when gnucash reloads the options into the report it fails. But I don't know without seeing the code and seeing the crash backtrace. It would be allowed in a major release change, but certainly not within a stable release. E.g., this happened between 1.6 - 1.8 and again from 2.0 - 2.2. (It might have happened from 1.8 - 2.0 too, but I don't recall). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fwd: World friendlier printable invoices
Bryan Cebuliak [EMAIL PROTECTED] writes: I will run diff for the second time ever. In the mean time, you have the complete code and the knowledge to fix the crash problem. Ah, but The identity of reports is by name, so you may care to use a different name for the report (at least during development), to prevent those types of crashes. As well, it would allow you to have the old and new versions both available for comparison at runtime. -- ...jsled http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] pgpK8Q79VjqZu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
