shell
is also feasible.
Evolution-data-server is less memory intensive than the (current) shell.
ps. I altered the Evolution mailing list address in the CC header,
because that mailing list has changed since a few months.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof
It looks like current CVS does not allow sending E-mails uing disabled
accounts.
I very often disable E-mail accounts to make it possible to choose
between multiple of my E-mail addresses.
Why is this possibility blocked?
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof
On Wed, 2005-11-30 at 13:49 +0530, Parthasarathi Susarla wrote:
Hey Philip,
On Wed, 2005-11-30 at 00:38 +0100, Philip Van Hoof wrote:
It looks like current CVS does not allow sending E-mails uing disabled
accounts.
I very often disable E-mail accounts to make it possible to choose
/usr/include/gconf/2 -I -g -O2 -Wall -Wmissing-prototypes
-Wno-sign-compare -c e-msgport.c -MT e-msgport.lo -MD -MP
-MF .deps/e-msgport.TPlo -fPIC -DPIC -o .libs/e-msgport.o
e-msgport.c:39:18: error: nspr.h: No such file or directory
Should be checked for in the configure stage, no?
--
Philip Van
On Sat, 2005-12-24 at 11:46 +0100, Philip Van Hoof wrote:
e-msgport.c:39:18: error: nspr.h: No such file or directory
Should be checked for in the configure stage, no?
Same for the flex tool. It's not being checked at the configure stage,
yet it's needed during the build.
AC_PATH_PROG
to get evolution
building.
Any new potential developer is simply going to let it be, and start
thinking: Oh well .. bad luck for evolution. I'm not going to
contribute that fantastic idea that I had a few minutes ago.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot
view,
the Linux kernel will probably put some of these indexes in memory
buffers.
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 at all.
--
Philip Van Hoof, software
and planning to help.
Difficult is fun.
:) Am glad this discussion has begun.
Same.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
implementation.
Duh.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers mailing list
Evolution
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
into memory!! That will speedup evolution!
No it wont.
But it will slowdown the rest of your computer.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be
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
, the ids aren't the main problem I'm experiencing. The main
problem is that I can't receive the uids in a sorted order, and that I
can't specify in which header information I'm interested.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
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
On Mon, 2006-03-13 at 12:54 +0100, Philip Van Hoof wrote:
Is there a reason why g_mutex, e_mutex and pthread_mutex are used in a
mixed may on libcamel?
This patch replaces that pthread_mutex. But it looks like there's
something wrong with the write_to_stream function pointer ...
In my debugger
On Mon, 2006-03-13 at 12:54 +0100, Philip Van Hoof wrote:
Is there a reason why g_mutex, e_mutex and pthread_mutex are used in a
mixed may on libcamel?
Note that the GStaticRecMutex can also be used as non-static:
http://mail.gnome.org/archives/gtk-list/2002-January/msg00045.html
It looks
mentioned above. If you'd implement it like this,
you'd better at least used gslice.
But anyway ;)
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime
mentioned above. If you'd implement it like this,
you'd better at least used gslice.
But anyway ;)
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime
to payoff in real
improvements for a mmap() implementation of it. But I would,
nevertheless, be very interested in the experiment.
Note that there's an mmap() on Windows and that glib abstracts it with
some glib API. I would of course use the glib abstraction API for this.
--
Philip Van Hoof, software
Camel makes some aggressive memory segmentation happen when loading
the folder summary.
This fixes that.
This is NOT yet the mmap() idea. That will come later.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x
to the length-bytes in front of
the strings .. also in the file (which is forward compatible, so going
back to an older Evolution version will work with the same summary
files).
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work
On Thu, 2006-07-06 at 23:47 +0400, Mikhail Zabaluev wrote:
В Чтв, 06/07/2006 в 21:23 +0200, Philip Van Hoof пишет:
Tinymail depends on Camel. Camel gets shipped with e-d-s. Tinymail
doesn't use *any* of the other e-d-s softwares, libraries nor its data.
I don't see a problem; you can
On Thu, 2006-07-06 at 23:22 +0200, Philip Van Hoof wrote:
On Thu, 2006-07-06 at 15:18 -0400, Jeffrey Stedfast wrote:
For some strange reason I thought the pstring stuff already did that,
oops. I guess I was thinking of similar code I wrote a few years back
for another project
or something afaics).
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime-tables.c
Index: camel-string-utils.c
On Fri, 2006-07-07 at 08:28 +0100, Ross Burton wrote:
On Thu, 2006-07-06 at 22:49 +0200, Philip Van Hoof wrote:
Yes sure. But packaging is often specific for all devices. There's
mostly also no e-d-s nor camel packages for the target device. So
developers basically have to do all this dirty
On Fri, 2006-07-07 at 08:26 +0100, Ross Burton wrote:
On Thu, 2006-07-06 at 21:23 +0200, Philip Van Hoof wrote:
Not strictly true. From camel/ in EDS HEAD:
#include libedataserver/e-data-server-util.h
#include libedataserver/e-iconv.h
#include libedataserver/e-memory.h
#include
It's almost working
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime-tables.c
Index: camel-file-utils.c
= camel_pstring_strdup(from-subject);
camel-folder-summary.c: to-from = camel_pstring_strdup(from-from);
camel-folder-summary.c: to-to = camel_pstring_strdup(from-to);
camel-folder-summary.c: to-cc = camel_pstring_strdup(from-cc);
camel-folder-summary.c: to-mlist = camel_pstring_strdup(from-mlist);
--
Philip Van
This patch is unrelated to the mmap() patches that I've also been
sending.
It basically avoids an strdup() by implementing a smarter free_token().
ps. I'm keeping Varadhan and Jeffrey in CC because the mailinglist
aren't working (or very slow).
--
Philip Van Hoof, software developer at x-tend
? ;-)
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http
On Mon, 2006-07-10 at 09:57 +0200, Philip Van Hoof wrote:
On Sun, 2006-07-09 at 18:08 +0200, Philip Van Hoof wrote:
On Sun, 2006-07-09 at 14:59 +0200, Philip Van Hoof wrote:
Note about this E-mail. I'm assuming people who will read this, have a
technical in-depth knowledge of Camel
On Sun, 2006-07-09 at 18:45 +0200, Philip Van Hoof wrote:
This patch is unrelated to the mmap() patches that I've also been
sending.
It basically avoids an strdup() by implementing a smarter free_token().
ps. I'm keeping Varadhan and Jeffrey in CC because the mailinglist
aren't working
Please test.
It should consume *A LOT* less memory. Especially in offline mode
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
? camel-mime-tables.c
/camel_folder_summary_with_mmap_fixes08.diff
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
camel_folder_summary_with_mmap_fixes08.diff.gz
Description: GNU Zip
On Tue, 2006-07-11 at 21:57 +0200, Philip Van Hoof wrote:
On Tue, 2006-07-11 at 16:47 +0200, Philip Van Hoof wrote:
On Tue, 2006-07-11 at 13:17 +0200, Philip Van Hoof wrote:
This is a version (version eight) that actually works (afaics).
This version (version nine) fixes a leak when new
);
}
Of course. Yes, that is better.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers
On Tue, 2006-07-11 at 22:51 +0200, Philip Van Hoof wrote:
On Tue, 2006-07-11 at 22:28 +0200, Philip Van Hoof wrote:
I didn't alter the code that writes the summary file. So I'm confident
that this bug also happens for people who aren't using the mmap patches
yet.
Yes I did. And the very
* a good E-mail client on top of that.
Etcetera
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution
On Tue, 2006-07-11 at 23:14 +0530, Harish Krishnaswamy wrote:
I'm removing the patches mailing list ;-)
On Tue, 2006-07-11 at 16:47 +0200, Philip Van Hoof wrote:
Currently it's obviously consuming more memory when new messages arrive
(compared to the mmap technique). In Evolution
On Wed, 2006-07-12 at 10:17 -0400, Jeffrey Stedfast wrote:
On Sun, 2006-07-09 at 13:04 +0200, Philip Van Hoof wrote:
These can be replaced with the new camel_pstring_add using FALSE as
parameter. Replacing them will also remove the need for the normal
camel_pstring_strdup and therefore also
it).
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers mailing list
Evolution-hackers
On Wed, 2006-07-12 at 16:30 +0100, Ross Burton wrote:
On Wed, 2006-07-12 at 17:14 +0200, Philip Van Hoof wrote:
What advantages does being able to dist camel on its own have, over
simply packaging it in a separate package like OpenEmbedded and Debian
do:
It's cleaner in my opinion :-), and I
On Wed, 2006-07-12 at 17:00 +0100, Ross Burton wrote:
On Wed, 2006-07-12 at 17:39 +0200, Philip Van Hoof wrote:
It's cleaner in my opinion :-), and I can more easily create a tar.gz
release.
Cleaner for what reasons?
Because it will be more easy to pick which libraries you will use
headers. My promise with tinymail is that I'm going to support such
amounts on devices like the Nokia 770. So I will.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http
-8 | grep
Version
Version: 1.6.1-0ubuntu5
[EMAIL PROTECTED]:~/repos/tinymail/trunk$
http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11.diff
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot
On Wed, 2006-07-12 at 17:19 -0400, Jeffrey Stedfast wrote:
On Wed, 2006-07-12 at 20:05 +0200, Philip Van Hoof wrote:
-- Oh by the way. There's a huge amount of Re: strings in my memory
at this moment. We can probably improve that too ;-) --
Yea, I've been wanting to overlap strings
On Thu, 2006-07-13 at 10:24 +0100, Ross Burton wrote:
On Wed, 2006-07-12 at 19:13 +0200, Philip Van Hoof wrote:
This is only for the case of the developer who is both writing an
application and developing the underlying libraries, and is also only
using a subset of the libraries, right
?
Let us spend our energies together on the camel-mmap patch instead.
I agree. Nevertheless, it's my opinion that evolution-data-server can be
better organised. It's, however, not blocking me. It's just annoyances.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote:
On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:
I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
proposing to put a configure.ac file in its directory. Moving Camel out
of evolution-data-server
While the x86 handles unaligned access, ARM doesn't. The patch will not
work on architectures that don't handle unaligned access.
I will try to fix it, but I don't have a lot experience in this field.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome
this means that the summary file format can't be kept backward
compatible as I will have to take a look at the unit32 encoder, the
##type encoder and the string encoder
Well, if somebody feels brave, feel free to assist me ;-)
On Fri, 2006-07-14 at 19:23 +0200, Philip Van Hoof wrote:
While the x86
On Mon, 2006-07-10 at 22:44 +0200, Philip Van Hoof wrote:
Please test.
It should consume *A LOT* less memory. Especially in offline mode
And I'll just continue with fixes06
- Implements it for nntp, imapp, imap4, groupwise and fixes some of the
problems in the local implementation.
Remark
On Tue, 2006-07-11 at 13:17 +0200, Philip Van Hoof wrote:
This is a version (version eight) that actually works (afaics).
This version (version nine) fixes a leak when new messages arrive.
However. The implementation/architecture of Camel requires that new
messages get transformed
On Tue, 2006-07-11 at 16:47 +0200, Philip Van Hoof wrote:
On Tue, 2006-07-11 at 13:17 +0200, Philip Van Hoof wrote:
This is a version (version eight) that actually works (afaics).
This version (version nine) fixes a leak when new messages arrive.
This version (version ten) fixes a few
On Wed, 2006-07-12 at 09:12 +0530, Harish Krishnaswamy wrote:
On Tue, 2006-07-11 at 20:33 +0200, Philip Van Hoof wrote:
On Tue, 2006-07-11 at 23:14 +0530, Harish Krishnaswamy wrote:
ps. I think we should do a in-depth tech-meeting about this stuff. What
do you think, Harish? I have a few
On Fri, 2006-07-14 at 19:23 +0200, Philip Van Hoof wrote:
While the x86 handles unaligned access, ARM doesn't. The patch will not
work on architectures that don't handle unaligned access.
I will try to fix it, but I don't have a lot experience in this field.
Second attempt to introduce data
used! Eeek! *scared
by my own mistakes now*. Very strange that didn't crash and burn on x86
but does crash on ARM.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http
this (on the device) with the imap implementation.
ps. Other people, please test this?
On Mon, 2006-07-17 at 20:47 +0200, Philip Van Hoof wrote:
Eeeek. Look at what I just found in my own patches!!
static CamelMessageInfo *
message_info_load (CamelFolderSummary *s, FILE
On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote:
On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote:
I agree with 1,2,..3 and 4. I will make sure 1 will be finished soon.
Probably this evening with a compile-time option (--enable-mmap)
I'm waiting for the decision
, Federico Mena Quintero wrote:
On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote:
I'm waiting for the decision (yours) of making this optional using a
compilation flag or at run-time.
Let's do this in the usual manner:
0. Polish the patch in the usual way: make sure
, saying thank you.
Looking at the patch technically AND testing it (and if it doesn't
perform, giving me numbers that compare it with the original implement-
ation) is all I'm asking for.
If Novell wants me to implement unit tests (or other tests) for this, I
will ask for payment.
--
Philip Van
. :-)
I agree here. Bringing it to HEAD might be to early. Nevertheless would
I be indeed very pleased if a lot people test this on a lot config-
urations.
Thanks for considering the patch.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot
On Wed, 2006-07-19 at 09:53 -0500, Federico Mena Quintero wrote:
On Wed, 2006-07-19 at 01:10 -0600, Veerapuram Varadhan wrote:
On Tue, 2006-07-18 at 23:05 +, Philip Van Hoof wrote:
If Novell wants me to implement unit tests (or other tests) for this,
I will ask for payment.
I am
-util.c, md5-utils.c and of course their .h files. The
files compile (without any changes) without needing any of the other
libedataserver code files.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http
On Thu, 2006-07-13 at 11:35 +0100, Ross Burton wrote:
On Thu, 2006-07-13 at 12:25 +0200, Philip Van Hoof wrote:
I wasn't (am no longer) proposing to move camel/ out of e-d-s. I was
proposing to put a configure.ac file in its directory. Moving Camel out
of evolution-data-server
On Thu, 2006-07-20 at 10:05 +0200, Philip Van Hoof wrote:
On Mon, 2006-07-17 at 15:35 -0400, JP Rosevear wrote:
I think you're only real example is camel, which shares code with the other
pieces anyhow.
Knowing is a good idea.
Hrmm. After re-reading my own stuff, I apologise
On Sat, 2006-07-22 at 00:00 +0300, Tor Lillqvist wrote:
on 2006-07-12 klockan 19:13 +0200 skrev Philip Van Hoof:
It simply looks like Evolution developers didn't know where to stack all
these Evolution libraries. And thought .. oh, we already had this
Evolution data server thing .. lets
+12) bytes per header.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
___
Evolution-hackers mailing list
of the provider, everything works perfect
for every provider.
I see strange code. While I'm awake. Begin used like regular code. It
doesn't crash. Only developers that want to see it, see it. Regular
developers don't know it's strange code.
--
Philip Van Hoof, software developer at x-tend
home: me
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
typedef struct {
CamelFolderSummary *fs;
int nth;
MemoryMessageInfo *m;
} CamelMessageInfo;
#define camel_message_info_from (x) \
((x)-m ? (x)-m-from : (x)-fs-sstart+*((x)-fs-istart
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
To read message n, you would simply do something like:
from = sstart + *(istart + (sizeof (int) * 4 * n) + 1)
subject = sstart + *(istart + (sizeof (int) * 4 * n) + 2)
to = sstart + *(istart + (sizeof (int) * 4 * n) + 3)
flags
On Thu, 2006-09-07 at 21:48 -0500, Federico Mena Quintero wrote:
On Thu, 2006-09-07 at 21:14 +0200, Philip Van Hoof wrote:
The *new*/*extra* idea is to create a second index file which contains
the offsets to the pointers in the camel summary file. Then mmap also
that file. Extra because
On Fri, 2006-09-08 at 11:22 -0500, Federico Mena Quintero wrote:
On Fri, 2006-09-08 at 10:37 +0200, Philip Van Hoof wrote:
1. What is the maximum length of those strings? What is the maximum
length of one message header in the summary file? In the message info
struct, can you use short ints
, feel free to ask in PM or on
evolution-hackers, which I'm subscribed to.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be
://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment04.diff
But it's not recommended for non-software developers. It's not easy to
get it working unless you have a good knowledge of compiling softwares
like Evolution and its dependencies.
--
Philip Van Hoof, software
?
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot
the tinymail framework to allow a tool like SyncML to
do such funky stuff.
Please get in touch.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog
On Sun, 2006-10-22 at 15:41 +0200, Philip Van Hoof wrote:
In the code I have found no real reason to why this was done in
separated loops (steps) rather than one step and at the end of the loop,
free the data already. Especially for the third step (x), which seem to
consume most memory while
On Tue, 2006-10-24 at 01:56 +0200, Philip Van Hoof wrote:
static guint32
imap_get_uids (
{
...
while ((type = camel_imap_command_response (store, resp, ex)) ==
CAMEL_IMAP_RESPONSE_UNTAGGED)
{
...
if (size 0
. If you diff camel-imap-folder.c of
Evolution's Camel with this camel-imap-folder.c of Tinymail's Camel, and
remove those API calls, you'll have a working Camel that doesn't use the
mmap stuff but that will receive and update summary faster from IMAP,
using less memory.
--
Philip Van Hoof, software
On Tue, 2006-10-24 at 13:34 +0200, Philip Van Hoof wrote:
The only API call that makes this incompatible with a normal Camel is
the camel_folder_summary_dump_mmap. If you diff camel-imap-folder.c of
Evolution's Camel with this camel-imap-folder.c of Tinymail's Camel, and
remove those API
).
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org
-folder-summary.c
https://svn.tinymail.org/svn/tinymail/trunk/libtinymail-camel/camel-lite/camel/providers/imap/camel-imap-folder.c
If I can assist people with bringing their Camel into this shape, then
please let me know.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome
On Thu, 2006-11-16 at 16:13 +0100, Philip Van Hoof wrote:
I did another round of checking where the memory of Camel is going to in
tinymail's Camel.
I have also tested its Camel with Evolution with success.
Tinymail's Camel has the following features:
Next to these features, tinymail's
On Thu, 2006-11-16 at 11:41 -0500, Joe Shaw wrote:
Hey Joe,
On Thu, 2006-11-16 at 16:13 +0100, Philip Van Hoof wrote:
o. The CamelFolderSummary uses mmap. This significantly reduces memory
usage because an mmap is on-demand paged.
Does the on-disk format of the CamelFolderSummary
response.));
if (stream)
camel_object_unref (CAMEL_OBJECT (stream));
return NULL;
}
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
ps. The locking code of the imap provider is really, really broken or
done in an absolutely insane way.
On Tue, 2007-01-09 at 02:18 +0100, Philip Van Hoof wrote:
Hi there,
I just finished this one, so there's probably a huge amount of bugs in
it. I know I should first debug them away before
can grab and release it themselves if they need to run
* multiple commands atomically.)
Easy == different
On Tue, 2007-01-09 at 03:47 +0100, Philip Van Hoof wrote:
Bweachrgg. It seems camel_imap_command_response performs an extra
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock) (for some
,
_(Could not find message body in FETCH response.));
if (stream)
camel_object_unref (CAMEL_OBJECT (stream));
return NULL;
}
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http
About this one and FYI:
On Wed, 2007-01-10 at 20:46 +0100, Philip Van Hoof wrote:
@@ -386,6 +433,11 @@
if (pop3_store-cache fi-uid)
camel_data_cache_remove(pop3_store-cache, cache,
fi-uid, NULL);
}
+
+
+ /* TNY TODO
has gone in camel-lite that I
wouldn't allow copyright ownership reassignment for).
Most of these features are still in this is a hack status. And they
might not be really useful for a desktop E-mail client (they are crucial
for mobile devices).
--
Philip Van Hoof, software developer
home: me
http://bugzilla.gnome.org/show_bug.cgi?id=397130
Please review.
Thanks
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
Evolution-hackers mailing list
Evolution
I'm of course planning to get this stuff upstream. But I have to warn
the dreamers.
A lot of it is/was done as a hack. That's because I envision that
someday I actually will switch from using Camel to most likely fejj's
libspruce.
With Camel this was for the last feature, IDLE support, almost
On Wed, 2007-02-07 at 08:58 -0700, Veerapuram Varadhan wrote:
On Wed, 2007-02-07 at 11:36 +0100, Philip Van Hoof wrote:
Of all those features/implementations that you have mentioned so far, I
could list 2 of them fit the interest of evolution - mmap (without
summary format changes - adding
On Wed, 2007-02-07 at 21:40 +0100, Gilles Dartiguelongue wrote:
It'd be nice to see the work for IDLE make it to mainline too.
I would like to warn that the work for IDLE pulls nearly each and every
change to the IMAP code with it, as a dependency.
The IDLE work requires changes to dealing with
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
timeouts and other such problems (it'll take a while, since Evolution
fetches a ridiculous large amount of headers for each message for
building its summary).
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
On Thu, 2007-06-07 at 08:25 +0200, Gilles Dartiguelongue wrote:
Le jeudi 07 juin 2007 à 01:53 +0300, Philip Van Hoof a écrit :
Without immediately writing to disk work, the download by itself will
consume around 120 MB of RAM, and will most likely fail due to network
timeouts and other
On Thu, 2007-06-07 at 03:05 -0600, Sankar P wrote:
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
It improves the situation by setting your url-string to have the
basic_headers option. In the imap code of Camel, it will then ask for
less headers (but still way too much
On Thu, 2007-06-07 at 09:25 -0400, Jeffrey Stedfast wrote:
On Thu, 2007-06-07 at 10:56 +0300, Philip Van Hoof wrote:
The best way is to ask for the ENVELOPE and the remaining info using the
normal BODY.PEEK method.
Have you actually ever tested this theory? or did you just pull this out
1 - 100 of 177 matches
Mail list logo