[Evolution-hackers] e-d-s pokeage ...

2006-02-14 Thread michael meeks
Hi there, So - I was pleased to see that the libebook .so remains unchanged from evo 2.4 to 2.6 - and I just did a little review to try to ensure that this indeed reflects an unchanged ABI ;-) It seems that is the case - which is great thanks - I need only to update a comment in

[Evolution-hackers] Please pay attention to compiler warnings.

2006-02-14 Thread Veerapuram Varadhan
Hi Hackers, I just saw another one in plugins/bbdb/bbdb.c. The very same gfree thingy. (evolution-2.6:28994): e-utils-WARNING **: can't load plugin '/home/bhargavi/mbe/lib/evolution/2.6/plugins/liborg-gnome-evolution-bbdb.so: undefined symbol: gfree' Please compile and make sure your patch

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 10:47 +0530, Parthasarathi Susarla wrote: Will this branch have likewise functionality? The disk summaries branch does something on those lines, but it also means a lot of disk I/O than before, and only after prolonged testing/usage would we now how well it would

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Lee Revell
On Tue, 2006-02-14 at 18:57 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14 at 11:06 -0500, Jeffrey Stedfast wrote: Imagine spastic users that do nothing but scroll all day long at extremely rapid speeds .. multiply that with 10.000 such users, and you still wouldn't have any problems

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 11:06 -0500, Jeffrey Stedfast wrote: Even for single-user, disk-summary-branch was slower than the current in-memory implementation. Try this one: Even for a single-user, running the entire system from disk was slower than the current put-everything-in-a-ram-disk

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 13:02 -0500, Lee Revell wrote: On Tue, 2006-02-14 at 18:57 +0100, Philip Van Hoof wrote: I really don't think the message IDs are the main source of bloat in Evo. I measured it ;-) 10.000 E-mails used +-8MB of memory. This is how I quickly measured it. gint s=0;

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 14:03 -0500, Lee Revell wrote: I really don't think the message IDs are the main source of bloat in Evo. I measured it ;-) 10.000 E-mails used +-8MB of memory. Do you think that's a problem? For evolution, it might be a lesser problem than for camel. I'd

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 21:15 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14 at 14:03 -0500, Lee Revell wrote: Do you think that's a problem? For evolution, it might be a lesser problem than for camel. I'd like to start using camel on mobile devices. Let me illustrate this specific case .

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Lee Revell
On Tue, 2006-02-14 at 21:30 +0100, Philip Van Hoof wrote: We can save some euros by fixing this flaw. We can make it possible to give poor children a very good E-mail client that uses camel. Is it still not worth fixing? I strongly disagree. Yes it is worth fixing, sorry for not

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
On Tue, 2006-02-14 at 19:40 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14 at 13:02 -0500, Lee Revell wrote: On Tue, 2006-02-14 at 18:57 +0100, Philip Van Hoof wrote: I really don't think the message IDs are the main source of bloat in Evo. I measured it ;-) 10.000 E-mails used

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
Have fun implementing this on your own. I guess you don't need my help. On Tue, 2006-02-14 at 19:03 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14 at 11:06 -0500, Jeffrey Stedfast wrote: Even for single-user, disk-summary-branch was slower than the current in-memory implementation.

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Jeffrey Stedfast
This example is total bollocks, you don't even understand how a uid is used or what it even is. I've explained it to you a number of times now and you still don't get it. UIDs are not guaranteed to be contiguous. Jeff On Tue, 2006-02-14 at 21:30 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 15:36 -0500, Jeffrey Stedfast wrote: we don't do that because the uids are not necessarily contiguous. You might have 1, 3, 4, 5, 7, 109, 110 Which is why I proposed the iterator/cursor. Whether or not that will be fast enough should be experimented with. And again, the

Re: [Evolution-hackers] ... and how camel should be

2006-02-14 Thread Philip Van Hoof
On Tue, 2006-02-14 at 19:40 +0100, Philip Van Hoof wrote: On Tue, 2006-02-14 at 13:02 -0500, Lee Revell wrote: I measured it ;-) 10.000 E-mails used +-8MB of memory. Correction. The uids don't use that many memory. You can more easily measure this by assuming that the largest uid-size is