Re: Speed
Ok Thanks. On 2017-10-25 20:48, David Woodfall wrote: Yes I have shell access. I have tried just setting mutt without imap to use maildir, but It only sees my Inbox and no other folders. Perhaps there's a way of doing it but I haven't managed yet. Sync the store to your local box by other means (see below) and read it that way. Or just run mutt on the server over ssh, but this has some disadvantages: saved attachments will be on the server and you'll have to download them (minor), and to handle PGP/GPG you'll have to put your secret key on the server (major). "Other means" are: 1. offlineimap - well tested and works great, but you still need IMAP. 2. maildirsync - no IMAP needed, but somewhat obscure and slow. 3. unison - if you can use an Ocaml compiler on the server :-P 4. rsync - if you only ever sync with ONE workstation, this MIGHT work (but I never tried it) 5. syncmaildir [*] - Somewhat new; I just started using it and I absolutely love it. Fast and syncs correctly every time. Myself I just switched from 3 to 5, when I could no longer tolerate the Ocaml version dependency nonsense. [*] http://syncmaildir.sourceforge.net/ -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: Speed
On 2017-10-25 20:48, David Woodfall wrote: > Yes I have shell access. I have tried just setting mutt without imap > to use maildir, but It only sees my Inbox and no other folders. > Perhaps there's a way of doing it but I haven't managed yet. Sync the store to your local box by other means (see below) and read it that way. Or just run mutt on the server over ssh, but this has some disadvantages: saved attachments will be on the server and you'll have to download them (minor), and to handle PGP/GPG you'll have to put your secret key on the server (major). "Other means" are: 1. offlineimap - well tested and works great, but you still need IMAP. 2. maildirsync - no IMAP needed, but somewhat obscure and slow. 3. unison - if you can use an Ocaml compiler on the server :-P 4. rsync - if you only ever sync with ONE workstation, this MIGHT work (but I never tried it) 5. syncmaildir [*] - Somewhat new; I just started using it and I absolutely love it. Fast and syncs correctly every time. Myself I just switched from 3 to 5, when I could no longer tolerate the Ocaml version dependency nonsense. [*] http://syncmaildir.sourceforge.net/ -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: Speed
No unusual headers. But I tried the options on that webpage and it seems to have improved. Thanks. On Di, 24 Okt 2017, David Woodfall wrote: I've been using mutt a fair while now. Lately I've been using it with imap and find that it can take a while to read headers. Are there any tricks to speeding up imap? I do have a header cache, but it still takes some time opening a folder with a 1000+ or so messages. Any tips? Are you using any unusual headers for e.g. coloring? That may make mutt need to fetch the complete message instead of fetching it from the cache. See the `:set imap_headers` for adding additional headers to the cache. Also you might want to check this article: http://www.codeblueprint.co.uk/2016/12/19/a-kernel-devs-approach-to-improving.html regards, Christian -- "How did you spend the weekend?" asked the pretty brunette secretary of her blonde companion. "Fishing through the ice," she replied. "Fishing through the ice? Whatever for?" "Olives."
Re: Speed
On 17-10-25 09:41:23, Christian Brabandt wrote: > Also you might want to check this article: > http://www.codeblueprint.co.uk/2016/12/19/a-kernel-devs-approach-to-improving.html Nice, thanks for sharing! Cheers, Georg signature.asc Description: Digital signature
Re: Speed
Yes I have shell access. I have tried just setting mutt without imap to use maildir, but It only sees my Inbox and no other folders. Perhaps there's a way of doing it but I haven't managed yet. On 2017-10-24 18:43, David Woodfall wrote: I've been using mutt a fair while now. Lately I've been using it with imap and find that it can take a while to read headers. Are there any tricks to speeding up imap? Is IMAP a hard requirement? Do you have shell access to the server? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: Speed
On Di, 24 Okt 2017, David Woodfall wrote: > I've been using mutt a fair while now. Lately I've been using it with > imap and find that it can take a while to read headers. > > Are there any tricks to speeding up imap? > > I do have a header cache, but it still takes some time opening a > folder with a 1000+ or so messages. > > Any tips? Are you using any unusual headers for e.g. coloring? That may make mutt need to fetch the complete message instead of fetching it from the cache. See the `:set imap_headers` for adding additional headers to the cache. Also you might want to check this article: http://www.codeblueprint.co.uk/2016/12/19/a-kernel-devs-approach-to-improving.html regards, Christian -- "How did you spend the weekend?" asked the pretty brunette secretary of her blonde companion. "Fishing through the ice," she replied. "Fishing through the ice? Whatever for?" "Olives."
Re: Speed
On 2017-10-24 18:43, David Woodfall wrote: > I've been using mutt a fair while now. Lately I've been using it with > imap and find that it can take a while to read headers. > > Are there any tricks to speeding up imap? Is IMAP a hard requirement? Do you have shell access to the server? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. Do obvious transformation on domain to reply privately _only_ on Usenet.
Re: Speed
I don't know if it's an option for your situation, but you might consider offlineimap. For a folder of size about 1000, it took 2 seconds to open it. Of course, this is after using offlineimap to download the messages locally. Scott -- Scott Kostyshak Assistant Professor of Economics University of Florida https://people.clas.ufl.edu/skostyshak/ On Tue, Oct 24, 2017 at 06:48:31PM +, David Woodfall wrote: > Thanks I'll give that a shot. > > > On Tue, Oct 24, 2017 at 06:43:03PM +0100, David Woodfall wrote: > > > I've been using mutt a fair while now. Lately I've been using it with > > > imap and find that it can take a while to read headers. > > > > > > Are there any tricks to speeding up imap? > > > > > > I do have a header cache, but it still takes some time opening a > > > folder with a 1000+ or so messages. > > > > > > Any tips? > > > > Switching to `lmdb` backend made a significant speed upgrade difference for > > me.
Re: Speed
Thanks I'll give that a shot. On Tue, Oct 24, 2017 at 06:43:03PM +0100, David Woodfall wrote: I've been using mutt a fair while now. Lately I've been using it with imap and find that it can take a while to read headers. Are there any tricks to speeding up imap? I do have a header cache, but it still takes some time opening a folder with a 1000+ or so messages. Any tips? Switching to `lmdb` backend made a significant speed upgrade difference for me.
Re: Speed
On Tue, Oct 24, 2017 at 06:43:03PM +0100, David Woodfall wrote: > I've been using mutt a fair while now. Lately I've been using it with > imap and find that it can take a while to read headers. > > Are there any tricks to speeding up imap? > > I do have a header cache, but it still takes some time opening a > folder with a 1000+ or so messages. > > Any tips? Switching to `lmdb` backend made a significant speed upgrade difference for me.
Re: speed of cacheing depends on terminal?
Thus spake Rocco Rutte [05/21/08 @ 09.18.56 +0200]: * [EMAIL PROTECTED] wrote: Thus spake Rocco Rutte [05/15/08 @ 16.16.10 +0200]: http://dev.mutt.org/trac/ticket/2978 I just downloaded the source and built. I don't use macports at all. BerkeleyDB compiles flawlessly on Panther and Tiger for me. Good, thanks for the feedback. Just to be clear, it's BerkeleyDB version 4.5 that works flawlessly. I haven't yet tried anything newer. -gmn
Re: speed of cacheing depends on terminal?
Hi, * [EMAIL PROTECTED] wrote: Thus spake Rocco Rutte [05/15/08 @ 16.16.10 +0200]: http://dev.mutt.org/trac/ticket/2978 I just downloaded the source and built. I don't use macports at all. BerkeleyDB compiles flawlessly on Panther and Tiger for me. Good, thanks for the feedback. Rocco
Re: speed of cacheing depends on terminal?
Thus spake Rocco Rutte [05/15/08 @ 16.16.10 +0200]: * [EMAIL PROTECTED] wrote: FWIW: I built using the BerkeleyDB libraries, since the other choices refuse to work with OSX. (Actually, I finally got mutt to build with gdb, but mutt behaved *really* weird with screen-drawing, so gdb is a no-go on OSX). How do you do that exactly? qdbm and gdbm are the only ones I found working on OS X via macports. For bdb there's a ticket open that it doesn't even compile: http://dev.mutt.org/trac/ticket/2978 I just downloaded the source and built. I don't use macports at all. BerkeleyDB compiles flawlessly on Panther and Tiger for me. http://www.oracle.com/technology/products/berkeley-db/db/index.html -gmn
Re: speed of cacheing depends on terminal?
Hi, * [EMAIL PROTECTED] wrote: FWIW: I built using the BerkeleyDB libraries, since the other choices refuse to work with OSX. (Actually, I finally got mutt to build with gdb, but mutt behaved *really* weird with screen-drawing, so gdb is a no-go on OSX). How do you do that exactly? qdbm and gdbm are the only ones I found working on OS X via macports. For bdb there's a ticket open that it doesn't even compile: http://dev.mutt.org/trac/ticket/2978 Rocco
Re: speed of cacheing depends on terminal?
[...] That's why they recently added $time_inc (it's not in a released version of mutt yet; just in the current development tree). Here's the description from the development manual: Sweet. My INBOX opens nearly instantaneously now. And I thought that it's the hcache being slow. Thank you -- Vlad pgpKCEHb8bwr9.pgp Description: PGP signature
Re: speed of cacheing depends on terminal?
* [EMAIL PROTECTED] on Saturday, May 10, 2008 at 18:07:04 -0400 1.5.17 with header caching enabled. I've got read_inc and write_inc set to 1000. Nevertheless, I've noticed that the process of evaluating the cache (when I switch into a big folder) is significantly slower when I use Terminal.app than if I use xterm/rxvt over Apple's X11. I never experienced that. Overall xterm might behave crisper, because Terminal.app is slow -- but not only for mutt. I do however notice slowness right after starting mutt (cold cache???), but then it runs fine. FWIW: I built using the BerkeleyDB libraries, since the other choices refuse to work with OSX. (Actually, I finally got mutt to build with gdb, but mutt behaved *really* weird with screen-drawing, so gdb is a no-go on OSX). I always used and use qdbm w/o prob. Both qdbm and mutt build just fine on 10.4.11. Also fink's mutt ships with qdbm. If with gdb you mean GNU dbm I once built mutt against gdbm from fink, again w/o without having the issues you describe. c -- Python Mutt utilities http://www.blacktrash.org/hg/muttils/
Re: speed of cacheing depends on terminal?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday, May 10 at 06:07 PM, quoth [EMAIL PROTECTED]: 1.5.17 with header caching enabled. I've got read_inc and write_inc set to 1000. Nevertheless, I've noticed that the process of evaluating the cache (when I switch into a big folder) is significantly slower when I use Terminal.app than if I use xterm/rxvt over Apple's X11. That's why they recently added $time_inc (it's not in a released version of mutt yet; just in the current development tree). Here's the description from the development manual: Along with read_inc, write_inc, and net_inc, this variable controls the frequency with which progress updates are dis- played. It suppresses updates less than time_inc milliseconds apart. This can improve throughput on systems with slow termi- nals, or when running mutt on a remote system. This is puzzling, since I thought caching has nothing to do with the terminal choice. Anybody know why this would be, and/or how I can do something about it? Caching doesn't have anything to do with the terminal choice, BUT since mutt is single-threaded, it can be slowed down by anything that requires updating the display. No operations in mutt can happen at the same time, so mutt has to pause what it's doing (e.g. caching) to update the terminal. If the terminal is slow, that pause can take longer, and will make the total action take longer. Put another way, the length of time required to do a given complex action is the sum of all time required to perform the components of that action. In the example of updating the cache, you are also asking mutt to update the display. In the simple example of a folder with 1000 messages, if read_inc is 1, you are asking mutt to update the display 1000 times, so the length of time required to cache those 1000 messages is the sum of the time to read 1000 messages, the time to write the necessary information to the cache, and the time to update the terminal 1000 times. Thus, the way to reduce the impact of a slow terminal is to make mutt update the terminal less often---by specifying a $read_inc of, say, 50 or 100. Using $time_inc allows mutt to condense display updates that are close together in time into a single display update, which reduces the impact of a slow terminal without reducing the granularity of the display (as increasing $read_inc does). FWIW: I built using the BerkeleyDB libraries, since the other choices refuse to work with OSX. (Actually, I finally got mutt to build with gdb, but mutt behaved *really* weird with screen-drawing, so gdb is a no-go on OSX). I use qdbm on my Mac and am very happy with it (it's *really* fast). If I recall correctly, several people have discovered odd performance problems with BerkeleyDB on OSX. ~Kyle - -- Those who profess to favor freedom, and yet depreciate agitation, are men who want rain without thunder and lightning. -- Frederick Douglass -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iEYEARECAAYFAkgnEosACgkQBkIOoMqOI172kACfTBzoMsAbrlREUDg05X77MGbv 1n0An1J5vuIywkXM8yur3obrHA5pQhf9 =fXd9 -END PGP SIGNATURE-
Re: speed of cacheing depends on terminal?
* [EMAIL PROTECTED] [EMAIL PROTECTED] [05-10-2008]: 1.5.17 with header caching enabled. I've got read_inc and write_inc set to 1000. Nevertheless, I've noticed that the process of evaluating the cache (when I switch into a big folder) is significantly slower when I use Terminal.app than if I use xterm/rxvt over Apple's X11. I run Mutt 1.5.17 via Terminal.app (on Leopard) with no such speed issues. I installed via macports. -- Sahil Tandon [EMAIL PROTECTED]
Re: Speed of opening Maildirs (was: Re: move messages at will?)
On 2001-08-22 17:01:40 +0200, Alexander Skwar wrote: Also the load when opening the Maildir is WAY higher compared to the mbox file. Load when opening the mbox is about 2, Maildir is about 6. Okay, I've got setiathome running, so one may substract 1 (? right?). Ouch. PLEASE make sure that (1) swapping isn't necessary, (2) your CPU is mostly idle when you do measurements, (3) mutt (or, for that matter, evolution) is the only process which competes for disk access. Opening the Maildir took close to 5 minutes (the first time), but at least the load only went up to 5 and the system also felt more responsible. That's interesting - seems to translate to less disk accesses per unit time, which could mean that evolution is a bit slower at opening maildir folders. (Bad enough, I can't make any reasonable measurements myself - I don't have Evolution installed, it's not available as a package for the distribution I use, and, finally, maildir is mostly kernel-bound here - at a certain point, ext2 eats most of the CPU.) The 2nd time it took 15 seconds (!!). I don't know, but judging this tremendous speedup, I suppose Evolution is keeping a cache of somesorts which causes it not to read the whole directory. That's just too much of a speedup, I'd say. Seems so. Now, such a cache will have to introduce explicit locking with maildir folders. But the entire point with this folder format is that you do not have to lock explicitly, because the locking which is needed happens in the filesystem, when it guarantees that directories are consistent. In mutt, changing from the default date/date sort to subject/date takes, uhm, 1 second. But enabling threads (thread/date) takes MUCH longer, to be exact, it took about 2 minutes 30 seconds. Try a newer version. Someone has contributed a patch which improves mutt's threading algorithm to O( n log n ); it is in mutt-1.3.21. -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: Speed of opening Maildirs (was: Re: move messages at will?)
On 23.08.2001 10:45:25 Thomas Roessler wrote: Ouch. PLEASE make sure that (1) swapping isn't necessary, (2) your CPU is mostly idle when you do measurements, (3) mutt (or, for that matter, evolution) is the only process which competes for disk access. Yes, I do know this. But, the system wasn't really busy, and those huge differences which I found cannot be due to some other process running. Maybe if I had tested it only once or twice - but I didn't. It was constantly in same area like I listed. That's interesting - seems to translate to less disk accesses per unit time, which could mean that evolution is a bit slower at opening maildir folders. Yes, that's right, and yes, Evolution is slower at the very first time. Now, such a cache will have to introduce explicit locking with maildir folders. But the entire point with this folder format is Yep, I don't understand this either. Try a newer version. Someone has contributed a patch which improves mutt's threading algorithm to O( n log n ); it is in mutt-1.3.21. I will! Thanks!
Re: Speed of opening Maildirs (was: Re: move messages at will?)
So sprach »Thomas Roessler« am 2001-08-23 um 10:45:25 +0200 : On 2001-08-22 17:01:40 +0200, Alexander Skwar wrote: [ mutt 1.3.19i ] MUCH longer, to be exact, it took about 2 minutes 30 seconds. Try a newer version. Someone has contributed a patch which improves mutt's threading algorithm to O( n log n ); it is in mutt-1.3.21. Yes, threading now is somewhat faster. This time, it took about 1 minute 50 seconds. Sadly, it's still a lot slower than Evolution :( Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 14 hours 43 minutes
Re: Speed of opening Maildirs (was: Re: move messages at will?)
On 2001-08-21 23:02:13 +0200, Alexander Skwar wrote: While on the topic of Maildir. I also just recently checked out Maildir support in mutt 1.3.19i again. And, well, I'm not at all impressed :( To test, I've converted a 50 MB mbox with ~5000 messages to Maildir. Opening the mbox in mutt took about 9 seconds. Opening the Maildir took close to 31 (!) seconds! Why is it taking mutt so *EXTREMELY* long to open large Maildirs? I also checked out Evolution, and Evo only took something close to 10 seconds to open the Maildir - but in Evolution it takes ages to sync mbox'es... But that's OT here. Did you do the mutt test several times, so kernel caches could kick in? -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: Speed of opening Maildirs (was: Re: move messages at will?)
So sprach »Thomas Roessler« am 2001-08-22 um 10:23:05 +0200 : Did you do the mutt test several times, so kernel caches could kick in? No, I did not. But in Evolution it's also very fast the very first time a Maildir is opened. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 6 hours 36 minutes
Re: Speed of opening Maildirs (was: Re: move messages at will?)
On 2001-08-22 13:50:42 +0200, Alexander Skwar wrote: No, I did not. But in Evolution it's also very fast the very first time a Maildir is opened. Right after you read it with mutt? I'm not talking about mutt caches, but about operating system caches. Please perform the timing experiment with both mutt and Evolution several times, without doing much in between. -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: Speed of opening Maildirs (was: Re: move messages at will?)
So sprach »Thomas Roessler« am 2001-08-22 um 14:04:14 +0200 : Please perform the timing experiment with both mutt and Evolution several times, without doing much in between. Timing sheet: Mailer| Action | Time --+-+-- mutt | Open mbox - 1st run | 55 seconds mutt | Open mbox - 2nd run | 22 seconds mutt | Open MDir - 1st run | n/a mutt | Open MDir - 2nd run | 3 minutes 40 seconds --+-+-- Evolution | Open mbox - 1st run | 40 seconds Evolution | Open mbox - 2nd run | 10 seconds Evolution | Open MDir - 1st run | about 5 minutes Evolution | Open MDir - 2nd run | 15 seconds Explanations: Okay, I now converted an even larger mail spool to Maildir. This one is about 154M and has 33271 messages in it. Opening the Maildir takes about 3 minutes 40 seconds. This is, after I had opened it already several times. Also, when I close mutt, it takes another 20 seconds for mutt to exit. On the bottom of the screen, mutt writes: Mailbox unverändert. (Mailbox unchanged (?)). Opening the mbox file (which I had converted to the above Maildir with mutt), takes close to 55 seconds the first time I open the mbox (ie., when the mbox is not cached by the system) and only 22 seconds afterwards. Also quiting mutt is WAY faster. Only a delay of 1 or 2 seconds. Also the load when opening the Maildir is WAY higher compared to the mbox file. Load when opening the mbox is about 2, Maildir is about 6. Okay, I've got setiathome running, so one may substract 1 (? right?). On to the Evolution results. Opening the Maildir took close to 5 minutes (the first time), but at least the load only went up to 5 and the system also felt more responsible. The 2nd time it took 15 seconds (!!). I don't know, but judging this tremendous speedup, I suppose Evolution is keeping a cache of somesorts which causes it not to read the whole directory. That's just too much of a speedup, I'd say. Now, Evolution is really bad with mbox'es. Not so much when it comes to comparing opening speeds, but much more so when a message is deleted from a mbox. This just takes ages. So I wouldn't recommend mbox to anyone using Evolution. Anyhow, opening the mbox took 40 seconds. Having a look at the mutt mbox times, I'd assume that the mbox was still cached by the system. Opening the mbox in a 2nd run, it took Evolution only about 10 seconds to open it. This really makes me believe that it somehow caches it. Also sorting is WAY faster in Evolution than it is in mutt. The above times already contain the time used to sorting the spool. Resorting it (eg. changing from Subject to Sender) takes no time (1 second). Enabling threaded mode also takes no time. In mutt, changing from the default date/date sort to subject/date takes, uhm, 1 second. But enabling threads (thread/date) takes MUCH longer, to be exact, it took about 2 minutes 30 seconds. The Evolution times stay somewhat constant even after I did some things. I *really* get the impression that it caches it somehow. Alexander Skwar -- How to quote: http://learn.to/quote (german) http://quote.6x.to (english) Homepage: http://www.digitalprojects.com | http://www.iso-top.de iso-top.de - Die günstige Art an Linux Distributionen zu kommen Uptime: 9 hours 10 minutes
Re: speed problem
On 2001-06-15 12:31:30 -0600, Troy Heber wrote: If I select the text portion of the message and press enter it comes up instantly. However, when I select the message and press enter from the main inbox (I think it's called the pager or the inbox) it takes 4 minutes 28 seconds! If I press Q to go back to the pager and try to view the message again I have the same problem. If I exit mutt and come back in and try to view the message again I have the same problem. I can view any other message in my inbox except this one. Also If I press v to view the attachments, then tag and forward them to myself. The message is fine! So I believe that the problem is something in the message header. Do you happen to have some rather complex regular expressions which are used for header coloring? (Actually, I'd be curious where you got these regular expressions from since you are the second one to ask about this version of the problem today - I'm almost tempted to assume that some linux distribution has screwed up their default configuration...) -- Thomas Roesslerhttp://log.does-not-exist.org/
Re: speed problem
On Fri, Jun 15, 2001 at 12:31:30PM -0600, Troy Heber wrote: I'm running mutt 1.2.5i and I am experiencing a very strange problem. When I attempt to read messages from certain senders it takes minutes to display the message. For example if I press v on the message to see the attachments it comes up instantly. These are the attachments on one such message: I 1 no description [text/plain, 7bit, iso-8859-1, 2.2K] A 2 flu5xben_pentium4_01.xls [applica/vnd.ms-exc, base64, 25K] Could it be that you have an auto_view setting for 'application/vnd.ms...' and mutt is trying to invoke the app for viewing the attachment. what you describe seems more related to the attachment then anything to do with the headers... Hanif. -- Hanif Ladha [EMAIL PROTECTED]
Re: speed problem
Thanks for the suggestion, but I complete disabled all of my autoviews (I never had any for this MIME type anyway) and that did not resolve the problem. Any other suggestions? Thanks, Troy On 06/15/01, Hanif Ladha wrote: On Fri, Jun 15, 2001 at 12:31:30PM -0600, Troy Heber wrote: I'm running mutt 1.2.5i and I am experiencing a very strange problem. When I attempt to read messages from certain senders it takes minutes to display the message. For example if I press v on the message to see the attachments it comes up instantly. These are the attachments on one such message: I 1 no description [text/plain, 7bit, iso-8859-1, 2.2K] A 2 flu5xben_pentium4_01.xls [applica/vnd.ms-exc, base64, 25K] Could it be that you have an auto_view setting for 'application/vnd.ms...' and mutt is trying to invoke the app for viewing the attachment. what you describe seems more related to the attachment then anything to do with the headers... Hanif. -- Hanif Ladha [EMAIL PROTECTED] -- ___ _/ Troy Heber _/Software Engineer _/_/_/_/_/_/ Technical Consulting Lab _/ _/_/ _/Hewlett-Packard Company _/ _/_/_/_/ _/ Email: [EMAIL PROTECTED] _/ Phone: 970.898.3240 i n v e n t ___
