Hey Jeffrey,
I did some experimenting and after this it seems to work:
http://tinymail.org/trac/tinymail/changeset/3462
I had to get the value of folder_tell at the exact location where the
state is at CAMEL_MIME_PARSER_STATE_HEADER.
Then it worked.
I tested this against for example a testing
On Sat, 2008-01-26 at 23:22 -0500, Jeffrey Stedfast wrote:
> Something like the attached patch might work, tho it is untested.
I had to change
else if (!CAMEL_IS_SEEKABLE_SUBSTREAM (stream))
into
else if (!CAMEL_IS_SEEKABLE_STREAM (stream))
I don't know why you where testing
On Sun, 2008-01-27 at 11:27 -0500, Jeffrey Stedfast wrote:
> On Sun, 2008-01-27 at 13:44 +0100, Philip Van Hoof wrote:
> > This is very strange, though. It looks like stream=0x0 but the
> > mime-parser's stream ain't NULL.
>
> that just means the stream the parser is using is not a subclass of
>
On Sun, 2008-01-27 at 13:44 +0100, Philip Van Hoof wrote:
> This is very strange, though. It looks like stream=0x0 but the
> mime-parser's stream ain't NULL.
that just means the stream the parser is using is not a subclass of
CamelSeekableSubstream
Jeff
This is very strange, though. It looks like stream=0x0 but the
mime-parser's stream ain't NULL.
(gdb) print buffer
$1 = (GByteArray *) 0x80e4dc0
(gdb) print stream
$2 = (CamelStream *) 0x0
(gdb) print *mp
$3 = {parent = {klass = 0x80def80, hooks = 0x0, ref_count = 1, flags = 0}, priv
= 0x8272770}
Looks like the GByteArray is still being created.
(gdb) break camel-mime-part-utils.c:82
Breakpoint 2 at 0xb6dd541e: file camel-mime-part-utils.c, line 82.
(gdb) delete 1
(gdb) cont
Continuing.
Breakpoint 2, simple_data_wrapper_construct_from_parser (dw=0xb3f02800,
mp=0x827bcd0) at camel-mime-pa
We'll try this, and if it works for all mails that we wanted to test,
I'll let you know.
Thanks a lot! Adding Modest's project manager in CC
On Sat, 2008-01-26 at 23:22 -0500, Jeffrey Stedfast wrote:
> Something like the attached patch might work, tho it is untested.
>
> If this doesn't work, th
Something like the attached patch might work, tho it is untested.
If this doesn't work, then I suspect the problem is that the seek
position might get changed out from under the mime parser (assuming it
is using either a CamelStreamFs or an fd).
Note that camel_stream_fs_new_with_fd[_and_bounds](
On Sat, 2008-01-26 at 22:12 -0500, Jeffrey Stedfast wrote:
> On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote:
> > This is what happens if you try to open a truly large E-mail on a device
> > that has not as much memory available:
> >
> > Is there something we can do about this? Can we cha
On Sat, 2008-01-26 at 13:44 +0100, Philip Van Hoof wrote:
> This is what happens if you try to open a truly large E-mail on a device
> that has not as much memory available:
>
> Is there something we can do about this? Can we change the MIME parsing
> algorithm to be less memory demanding for exam
This is what happens if you try to open a truly large E-mail on a device
that has not as much memory available:
Is there something we can do about this? Can we change the MIME parsing
algorithm to be less memory demanding for example?
Note that GArray is not really very sparse with memory once y
11 matches
Mail list logo
