ata-server'
make: *** [all] Error 2
[sbox-SDK_PC: ~/dev/evolution-data-server] >
By the way, Nokia dudes: We are waiting for the device to become
available here in Belgium. Oh and ... since I won one at Guadec. I can't
wait! Send it! :-) *spasm, spasm*
--
Philip Van Hoof, software devel
-data-server. Creating a new specialised 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 dev
On Tue, 2005-09-27 at 01:04 +0200, Philip Van Hoof wrote:
Hey Ross,
I noticed you've read this thread,
[CUT]
> ps. It stops here. But I'm not sure whether this is related to the Maemo
> platform, since I can reproduce this build-error on a non scratchbox
> environment.
>
On Wed, 2005-09-28 at 09:37 +0300, Tor Lillqvist wrote:
> On on, 2005-09-28 at 01:39 +0200, Philip Van Hoof wrote:
>
> > However. Building "servers" first also temporarily fixes the issue.
>
> But shouldn't it have been built first in any case? It's me
n be useful: tell me.
--
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
Evoluti
GtkWidget. And then also replace the GtkHtml widget
with a GtkMozEmbed that has been set editable (check our go-evolution
wiki for more information about that).
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x
On Tue, 2005-10-11 at 22:38 +0200, Philip Van Hoof wrote:
> First of all:
> http://bugzilla.gnome.org/show_bug.cgi?id=318611
> http://bugzilla.gnome.org/attachment.cgi?id=53342&action=view
> I know it's unavoidable in projects like Evolution, yet it's always nice
>
On Wed, 2005-10-12 at 09:45 +0800, Not Zed wrote:
> On Tue, 2005-10-11 at 22:38 +0200, Philip Van Hoof wrote:
> > Of course should the programmer here have used this:
>
> Why? If there is a public data information, then there's no reason to
> use an accessor.
T
On Tue, 2005-10-11 at 22:38 +0200, Philip Van Hoof wrote:
> First of all:
> http://bugzilla.gnome.org/show_bug.cgi?id=318611
> http://bugzilla.gnome.org/attachment.cgi?id=53342&action=view
This new version of the patch forward declares the entire EMsgComposer
struct, moves the _PR
]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/freax/cvs/gnome/evolution-data-server'
make: *** [all] Error 2
[EMAIL PROTECTED]:~/cvs/gnome/evolution-data-server $
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
his is trivial).
GtkMozEdit by default uses the default theme of Mozilla (for the
scrollbar, fonts and in-the-document embedded controls). I haven't
investigated how difficult it would be to change this. I'm guessing this
is not very difficult.
--
Philip Van Hoof, softw
On Mon, 2005-10-17 at 02:49 +0300, Tor Lillqvist wrote:
> On sö, 2005-10-16 at 14:20 +0200, Philip Van Hoof wrote:
> > There's however a few issues and things to add:
>
> One more point is that switching GtkMozEmbed will require an unknown
> amount of work on the Win3
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 a
On Wed, 2005-11-30 at 09:42 +0100, Philip Van Hoof wrote:
> So how do I solve my situation then? ;-)
>
> I have multiple E-mail accounts that I use for sending. But only a few
> real 'mailboxes' for receiving. Some of the E-mail accounts are aliases
> to others.
>
Once it wasn't possible to set the receiving type to None. It looks like
it's possible now and this feature enables the possibility to enable
such a send-only E-mail account indeed.
Perhaps this should be documented in a end-user documentation?
> Sorry for the false alarm/whining.
directory
Should be checked for in the configure stage, no?
--
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
___
Evo
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 th
ution developers!
It's not good that I (an experienced developer) have to spend a few
hours fixing stuff and searching for solutions just 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
s in a string (or whatever or however). You'd have to
again duplicate this type of hacks into high level code to cope with
that.
Wouldn't fixing the implementations for camel_session_construct and
camel_mkdir be a better solution?
--
Philip Van Hoof, software developer at x-tend
home
http://bugzilla.gnome.org/show_bug.cgi?id=331017
--
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
rt of the disk summary branch was the right thing to do.
Let's pick it up.
Difficult is fun.
> On Mon, 2006-02-13 at 18:29 +0100, Philip Van Hoof wrote:
> > http://bugzilla.gnome.org/show_bug.cgi?id=331017
--
Philip Van Hoof, software developer at x-tend
home: me at pvan
or so visible rows
would be read. The 9.990 others wouldn't.
On Mon, 2006-02-13 at 22:38 +0100, Philip Van Hoof wrote:
> On Mon, 2006-02-13 at 15:10 -0500, Jeffrey Stedfast wrote:
> > This would take several years to implement - likely to require complete
> > rewrites of at lea
If the users start to scroll lots of times through their summary 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 would
tion" slow. In contrary. Using such an engine might be a possible
component, why not?
--
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
_
t nevertheless I'm very
interested 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
ht
m-disk 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
Evo
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 measu
p'ed shared libraries are added
to the count. Please don't use it.
> Personally I think Evo is already slow enough, and we cannot afford to
> trade off any speed to save memory.
So we just load everything in memory?! Why not also load all the e-mails
of all your folders into memor
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
rator/cursor. Whether or not that will be
fast enough should be experimented with.
And again, 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 intere
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
tream=0x8067a38) at camel-data-wrapper.c:175
--
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-ha
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
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
7;d use the
original malloc()'d memory. This memory copying is probably causing the
memory segmentation I 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
gnom
7;d use the
original malloc()'d memory. This memory copying is probably causing the
memory segmentation I 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
gnom
implementation. I don't think the complexity is going 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 cours
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: va
to the
opensource community to get myself stuck in hacks.
I strongly disagree with hacks. I don't support hacks. I will not use
hacks. I will fork if I'm forced to use hacks.
--
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome
add a '\0' at the end of each
string in the file, and it will add one 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 develop
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.
>
>
-utils.c:236: warning: dereferencing type-punned pointer
will break strict-aliasing rules
make[1]: *** [camel-string-utils.lo] Error 1
make[1]: Leaving directory
`/home/pvanhoof/repos/gnome/cvs/evolution-data-server/camel'
make: *** [all-recursive] Error 1
[EMAIL PROTECTED]:~/repos/gnome/cvs/evoluti
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
> >
te string got leaked 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:
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
> > developer
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
> #include
> #include "libedataserver/e-memory.h"
> #include
> #include
> #i
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-ut
On Sat, 2006-07-08 at 00:52 -0600, Veerapuram Varadhan wrote:
> On Fri, 2006-07-07 at 08:26 +0000, Philip Van Hoof wrote:
>
> Every little change to a message, like marking it
> read/unread/important/flagging etc will result in mmap'ed write, which
> in turn has overhead on
On Fri, 2006-07-07 at 18:35 +0200, Philip Van Hoof wrote:
> It's almost working
This patch is actually functional and working.
Some notes:
- It will only work with the IMAP provider (not IMAP4). This is because
you need to do two or three small fixes in the provider-specific stuff.
I
_pstring_strdup(from->mlist);
--
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
Ev
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 deve
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 and camel-folder-summary.c
o. This
w that I started really looking into its code. Is libspruce
ready Fejj? ;-)
--
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 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
>
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
>
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 beca
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
s at the subject location. So right after the
uid string in the summary file.
--
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.
the version number in the filename).
http://pvanhoof.be/files/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
came
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
; return;
>
> g_free (token);
> }
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:/
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 patche
ns as we work on the patch.
> Boy, I am thrilled about this !!!.
Good :). That was my intention. In the hopes that you guys will now pick
it up, and restart improving Camel like in the good old days. The GNOME
development platform *needs* a good E-mail infrastructure. The GNOME
user
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 techn
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
> > cam
example in case you want to pass version information from a to b.
--
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
_
cant reduc-
tion in used memory .. if you indeed avoid 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
___
On Tue, 2006-07-11 at 22:28 +0200, Philip Van Hoof wrote:
> Somebody definitely needs to explain me how he managed to write
> mail_list_magic[0].pattern into the summary file of some of my mailing
> lists ;-)!
>
> http://pvanhoof.be/files/mail_list_magic_in_summary.png
>
&g
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 clea
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 pic
isted by Fejj in
this E-mail). Like what Microsoft once told us: Where do you want to go?
ps. I'm definitely going to use this mmap implementation for some Camel
packages that I'll be building for certain mobile devices. Without it,
it's not really possible to use tinymail with fo
IL PROTECTED]:~/repos/tinymail/trunk$ dpkg --status libcamel1.2-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
g
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 ;-) --
>
&g
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 libr
to the business at hand ?
>
> 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 de
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
&g
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 pvanhoo
I guess 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 wro
http://pvanhoof.be/files/camel_folder_summary_with_mmap_fixes11_data_alignment03.diff
The camel_folder_summary_load method is where all this starts.
On Sat, 2006-07-15 at 10:15 +0200, Philip Van Hoof wrote:
> On Fri, 2006-07-14 at 17:15 -0400, Jeffrey Stedfast wrote:
> > ah,
On Tue, 2006-07-11 at 01:14 +0200, Philip Van Hoof wrote:
> On Mon, 2006-07-10 at 22:44 +0200, Philip Van Hoof wrote:
> > Please test.
o. This fixes07 fixes the camel_file_util_decode_string method in such a
way that it still supports the old pstrings. This also fixes all issues
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
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 i
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 t
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
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.
; is simply never assigned, yet being 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
. I only tested 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
you
have to remember that I'm not getting paid to do this. That I have a
daytime job and a girlfriend.
--
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-te
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 fo
ts test it then?!
> I'd just hate to see a rush job come out of this
>
> Jeff
>
>
> 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'm waiting for the decis
d it scares me.
> >
> > I'd just hate to see a rush job come out of this
>
> Yeah, it needs good testing. Philip says he'll cook a patch so that I
> can use it with my system's e-d-s RPM for daily use. Then I can test it
> with my normal mailbox.
It might
tests (or other tests) for this, I
will ask for payment.
--
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_data_server__m
ore freedom to
> do such research work than HEAD. Correct me if I am wrong. :-)
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, softw
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 +0000, Philip Van Hoof wrote:
> > > If Novell wants me to implement unit tests (or other tests) for this,
> >
for it" and (re)implement it in a clean and perfect way. I
would be equally interested to go for your disk summary ideas. Heck, I
would even join your team if their mission was to replace Camel with
your libspruce in Evolution. And I do know how insane that would be.
ps. What I expressed h
e-time-utils.c,
e-data-server-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:
e-memory.c, e-msgport.c, e-sexp.c, e-time-utils.c,
e-data-server-util.c, md5-utils.c
--
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:/
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
&g
t; that isn't build by camel-lite-builder.
The idea is to keep the "Camel" that comes out of camel-lite-builder ABI
and API compatible with a normal Camel build.
I've put "Camel" between double quotes not to show that there's a
difference, but to show that ther
1 - 100 of 268 matches
Mail list logo
