?
___
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
://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
, 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
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
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
+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 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
-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
. :-)
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
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
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
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
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
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
* 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 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
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
= 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
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 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
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
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
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
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
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
/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
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
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
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
101 - 177 of 177 matches
Mail list logo
