RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Derek Atkins
Hi,

One of the disks in the CVS/SVN/Wiki/etc server is slowly failing.  I
read the daily log reports and every week or so for the past month
I've received a report of a failed sector on hda, e.g.:

 WARNING:  Kernel Errors Present
end_request: I/O error, dev hda, sector ...:  2 Time(s)
hda: dma_intr: error=0x40 { Uncorrect ...:  2 Time(s)
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error } ...:  2 Time(s)

 Oct  4 22:40:13 raid1: hda6: rescheduling sector 18089128 
 Oct  4 22:40:19 raid1: hda6: redirecting sector 18089128 to another mirror 

So in order to prevent data loss, I'd like to replace the HDD.  I'm
considering replacing it with this 250G/16M Seagate drive:

  http://www.newegg.com/Product/Product.aspx?Item=N82E16822148143

Actually, I'd like to order TWO of these drives.  No, we don't really
need the extra space (we still have 40G free on /home, out of 56G
using a pair of 80G drives in RAID1), but I might as well replace both
drives at the same time as they're both about the same age.  This is
the cheapest 16MB cache drive I could find, and it's one of the
cheapest Seagate drives I could find (the only cheaper Seagate had
only a 2MB cache).

Granted, I could save $20 per drive by going with a 200G/8MB Maxtor:

  http://www.newegg.com/Product/Product.aspx?Item=N82E16822144211

I'm really hoping to avoid Western Digital.

I was planning to use the tip jar for this purchase, which is why I'm
soliciting opinions before I purchase anything.  Note that if I order
from NewEgg I can usually have the item delivered the next day.  On
the other hand I wont have time to work on the hardware until probably
October 27-28, so we have a little time to come to consensus.

So... Comments?  Suggestions?

-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: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Josh Sled
Derek Atkins [EMAIL PROTECTED] writes:
 I was planning to use the tip jar for this purchase, which is why I'm
 soliciting opinions before I purchase anything.  Note that if I order
 from NewEgg I can usually have the item delivered the next day.  On
 the other hand I wont have time to work on the hardware until probably
 October 27-28, so we have a little time to come to consensus.

 So... Comments?  Suggestions?

Sounds good to me.

(Are you thinking of doing the other os/software upgrades at the same time?)

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpzzcmgG574J.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Derek Atkins
Josh Sled [EMAIL PROTECTED] writes:

 Derek Atkins [EMAIL PROTECTED] writes:
 I was planning to use the tip jar for this purchase, which is why I'm
 soliciting opinions before I purchase anything.  Note that if I order
 from NewEgg I can usually have the item delivered the next day.  On
 the other hand I wont have time to work on the hardware until probably
 October 27-28, so we have a little time to come to consensus.

 So... Comments?  Suggestions?

 Sounds good to me.

 (Are you thinking of doing the other os/software upgrades at the same time?)

Yes, sorry, I should've made it clear that my plan would be to update
the hardware and then update to Fedora 7 at the same time, which is
why I would book a weekend for it.  I can get the disks effectively
overnight (NewEgg is great that way!) so it's just a question of
consensus on what disks to obtain and me making the time to actually
do the work.

 ...jsled
 http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]

-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

2007-10-05 Thread Josh Sled
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: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Chris Shoemaker
On Fri, Oct 05, 2007 at 10:29:55AM -0400, Derek Atkins wrote:
 Hi,
 
snip
 
 So... Comments?  Suggestions?

Good idea.
-chris
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Andrew Sackville-West
On Fri, Oct 05, 2007 at 10:40:29AM -0400, Derek Atkins wrote:
 Josh Sled [EMAIL PROTECTED] writes:
 
  Derek Atkins [EMAIL PROTECTED] writes:
  I was planning to use the tip jar for this purchase, which is why I'm
  soliciting opinions before I purchase anything.  Note that if I order
  from NewEgg I can usually have the item delivered the next day.  On
  the other hand I wont have time to work on the hardware until probably
  October 27-28, so we have a little time to come to consensus.
 
  So... Comments?  Suggestions?
 
  Sounds good to me.
 
  (Are you thinking of doing the other os/software upgrades at the same time?)
 
 Yes, sorry, I should've made it clear that my plan would be to update
 the hardware and then update to Fedora 7 at the same time, which is
 why I would book a weekend for it.  I can get the disks effectively
 overnight (NewEgg is great that way!) so it's just a question of
 consensus on what disks to obtain and me making the time to actually
 do the work.

I'm partial to seagate drives, especially those 5yr warranty ones but
regardless, I put some $ in the tip jar to help out with this and
thanks as always guys for great work!

A


signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Trevor Farlow
On 10/5/07, Andrew Sackville-West [EMAIL PROTECTED] wrote:

 On Fri, Oct 05, 2007 at 10:40:29AM -0400, Derek Atkins wrote:
  Josh Sled [EMAIL PROTECTED] writes:
 
   Derek Atkins [EMAIL PROTECTED] writes:
   I was planning to use the tip jar for this purchase, which is why I'm
   soliciting opinions before I purchase anything.  Note that if I order
   from NewEgg I can usually have the item delivered the next day.  On
   the other hand I wont have time to work on the hardware until
 probably
   October 27-28, so we have a little time to come to consensus.
  
   So... Comments?  Suggestions?
  
   Sounds good to me.
  
   (Are you thinking of doing the other os/software upgrades at the same
 time?)
 
  Yes, sorry, I should've made it clear that my plan would be to update
  the hardware and then update to Fedora 7 at the same time, which is
  why I would book a weekend for it.  I can get the disks effectively
  overnight (NewEgg is great that way!) so it's just a question of
  consensus on what disks to obtain and me making the time to actually
  do the work.

 I'm partial to seagate drives, especially those 5yr warranty ones but
 regardless, I put some $ in the tip jar to help out with this and
 thanks as always guys for great work!

 A


I'd say go for it with the 16MB cache Seagates, too.
Pulling myself out of the temporary poverty that is college, I couldn't add
much to the tip jar.  But I appreciate a software project that has been
solid for me for a couple of years now.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: gcc 4.2 warnings

2007-10-05 Thread Christian Stimming
Am Donnerstag, 4. Oktober 2007 22:56 schrieb Andrew Sackville-West:
 At jsled's prompting, I'm taking a stab at hacking my way through gcc
 4.2.1 (debian) warnings. And, at warlord's oh-so-kind prompting, I'm
 actually trying to do something about them.

Patches are always great! Thanks for picking up this work on the newest gcc.

However, in this particular case I think you didn't fix the warning the right 
way:

 --- engine/TransLog.c   (revision 16547)
 +++ engine/TransLog.c   (working copy)
 @@ -273,7 +273,7 @@
                 gnc_numeric_denom(amt),
                 gnc_numeric_num(val),
                 gnc_numeric_denom(val),
 -               drecn ? drecn : );
 +               drecn[0] == 0 ? drecn : );
     }
  
     fprintf (trans_log, = END\n);

The whole point of the expression (drecn ? drecn :  ) is in long form 
(drecn != NULL ? drecn : ), in other words, if the char pointer is 
non-NULL, use it, but otherwise use the pointer to an empty string. This is 
important for some OS which would crash if a NULL pointer is passed to 
printf() and friends, hence they should only get a (non-NULL) empty string. 
Your change, however, is a different expression: With your case, if the char 
pointer points to a non-empty string, use it, but otherwise use the pointer 
to an empty string.

Which points me to the question: Which gcc warning did you try to fix here?

Looking more into context, it turns out drecn is a local char buffer anyway, 
hence it can't be NULL anyway. Because of this, here (and only here) you 
should replace the expresssion direcly by drecn, i.e.

 -   drecn ? drecn : );
 +   drecn);

Thanks a lot for starting to fix these warnings!

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: RFC: Server disk slowly failing, I plan to replace it using tip jar.

2007-10-05 Thread Christian Stimming
Am Freitag, 5. Oktober 2007 16:35 schrieb Josh Sled:
 Derek Atkins [EMAIL PROTECTED] writes:
  I was planning to use the tip jar for this purchase, which is why I'm
  soliciting opinions before I purchase anything.  Note that if I order
  from NewEgg I can usually have the item delivered the next day.  On
  the other hand I wont have time to work on the hardware until probably
  October 27-28, so we have a little time to come to consensus.
 
  So... Comments?  Suggestions?

 Sounds good to me.

Good for me, too. After all, this is precisely that sort of issues what the 
tip jar is for.

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: gcc 4.2 warnings

2007-10-05 Thread Josh Sled
Christian Stimming [EMAIL PROTECTED] writes:
 Your change, however, is a different expression: With your case, if the char 
 pointer points to a non-empty string, use it, but otherwise use the pointer 
 to an empty string.

 Which points me to the question: Which gcc warning did you try to fix here?

The warning was TransLog.c:254: warning: the address of 'drecn' will always
evaluate as 'true'.


 Looking more into context, it turns out drecn is a local char buffer anyway, 
 hence it can't be NULL anyway. Because of this, here (and only here) you 
 should replace the expresssion direcly by drecn, i.e.

  -   drecn ? drecn : );
  +   drecn);

I suggested the {{{ drecn[0] == 0 ? [...] }}} form of the fix.

Of course, drecn[0] == 0 just means the string is already empty.
So, you're totally right; it should just be drecn.

But, there was a bit of a miscommunication about how to make the change,
anyways.  As you'd quoted, if drecn[0] == 0, then the string drecn is empty,
and it'll be printed.  Otherwise (when drecn actually has a value), it will
use  instead.

Thanks for the code review.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp1LYZkHTop0.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: gcc 4.2 warnings

2007-10-05 Thread Andrew Sackville-West
On Fri, Oct 05, 2007 at 09:22:53PM +0200, Christian Stimming wrote:
 Am Donnerstag, 4. Oktober 2007 22:56 schrieb Andrew Sackville-West:
  At jsled's prompting, I'm taking a stab at hacking my way through gcc
  4.2.1 (debian) warnings. And, at warlord's oh-so-kind prompting, I'm
  actually trying to do something about them.
 
 Patches are always great! Thanks for picking up this work on the newest gcc.

:). I don't know how much I can actually do but I'll poke away at it
here and there. If gives my computer something to do while I try to
grok the gnc:html-table-foo code to try and make it a little
snappier (that's the itch I'm currently trying to scratch as it now
takes me a good long while to run an income statement).

 
 However, in this particular case I think you didn't fix the warning the right 
 way:
 
  --- engine/TransLog.c   (revision 16547)
  +++ engine/TransLog.c   (working copy)
  @@ -273,7 +273,7 @@
                  gnc_numeric_denom(amt),
                  gnc_numeric_num(val),
                  gnc_numeric_denom(val),
  -               drecn ? drecn : );
  +               drecn[0] == 0 ? drecn : );
      }
   
      fprintf (trans_log, = END\n);
 
 The whole point of the expression (drecn ? drecn :  ) is in long form 
 (drecn != NULL ? drecn : ), in other words, if the char pointer is 
 non-NULL, use it, but otherwise use the pointer to an empty string. This is 
 important for some OS which would crash if a NULL pointer is passed to 
 printf() and friends, hence they should only get a (non-NULL) empty string. 
 Your change, however, is a different expression: With your case, if the char 
 pointer points to a non-empty string, use it, but otherwise use the pointer 
 to an empty string.
 
 Which points me to the question: Which gcc warning did you try to fix here?

jsled already answered this. THanks for the little lesson. I'll be
posting more of them soon.

 
 Looking more into context, it turns out drecn is a local char buffer anyway, 
 hence it can't be NULL anyway. Because of this, here (and only here) you 
 should replace the expresssion direcly by drecn, i.e.
 
  -   drecn ? drecn : );
  +   drecn);

okay. I think I understand. drecn is a pointer and as such has the
potential to be NULL which is very bad forthat one OS. But in this
case, drecn is locally declared as a pointer to a character buffer and
won't ever be NULL. hence, its okay to just pass it. right?


 
 Thanks a lot for starting to fix these warnings!

:)

A


signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: gcc 4.2 warnings

2007-10-05 Thread Andrew Sackville-West
On Fri, Oct 05, 2007 at 05:57:01PM -0400, Josh Sled wrote:
 Christian Stimming [EMAIL PROTECTED] writes:
  Your change, however, is a different expression: With your case, if the 
  char 
  pointer points to a non-empty string, use it, but otherwise use the pointer 
  to an empty string.
 
  Which points me to the question: Which gcc warning did you try to fix here?
 
 The warning was TransLog.c:254: warning: the address of 'drecn' will always
 evaluate as 'true'.
 
 
  Looking more into context, it turns out drecn is a local char buffer 
  anyway, 
  hence it can't be NULL anyway. Because of this, here (and only here) you 
  should replace the expresssion direcly by drecn, i.e.
 
   -   drecn ? drecn : );
   +   drecn);
 
 I suggested the {{{ drecn[0] == 0 ? [...] }}} form of the fix.
 
 Of course, drecn[0] == 0 just means the string is already empty.
 So, you're totally right; it should just be drecn.
 
 But, there was a bit of a miscommunication about how to make the change,
 anyways.  As you'd quoted, if drecn[0] == 0, then the string drecn is empty,
 and it'll be printed.  Otherwise (when drecn actually has a value), it will
 use  instead.

whoops. that's not good! 

A


signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


optimizing reports

2007-10-05 Thread Andrew Sackville-West
Hi guys, 

I'm bent on improving the speed of some of these reports and want to
bounce some ideas off you folks. The particular report I'm interested
in improving is the income statement. On my smaller file (133k) it
takes about 20 seconds to run a bog standard income statement. I
haven't timed it on my larger file (1.4M), but it takes way too
long (I usually switch over to /. please help me!).

My investigation into this points to the function
gnc:html-acct-table-add-accounts! in
reports/report-system/html-acct-table.scm. This function appears to be
the workhorse of the income statement but is also used in balance
sheet, budget and trial balance reports, so fixing it would likely
help those guys as well. 

Currently the report recurses through the account tree gathering
totals for each account and it sub accounts. It appears that it walks
all the way out to the leaf nodes at each level, so that the sub
account totals get calculated repeatedly making this a hugely
inefficient function. For example, giving this:

Toplvl--- A --- A1
   |-A2
   |-A3
   |-A4A4a
  |-A4b
 
To calculate the balances of all these, it would calculate the whole
tree for the balance ot Toplvl; re-calculate all of A sub-tree to get A's
balance; re-calculate A1; re-calc A2; re-calc A3; re-calc the whole A4
sub-tree; then re-calc A4a; re-calc A4b etc etc etc... bad.

I want to clean that up and what I'm thinking is to recurse through
the tree once totalling up each relevant account and returning those
totals in some structure that contains the accounts and their
totals. Then walk through the tree generating the output table based
on the required depth. This means I'd still be walking a tree
structure twice, but I'd only be doing the per-account math once. I
imagine the first walk would end up returning a list of toplevel
accounts, each member of which would be a cons of that account's
balance and a list of it subaccounts, each member of which would be a
cons... you get the idea.

So before I start hacking my fingers off, does this idea make sense?
(it does to me...) or is there something blatantly obvious that I'm
missing in this general idea? Also, if I'm mis-reading that code,
please let me know, but I think I have the gist of it pretty well.

A


signature.asc
Description: Digital signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel