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
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
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
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
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
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;
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
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 .
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
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
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.
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
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
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
14 matches
Mail list logo