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
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
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
=
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
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
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 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 example?
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 change the
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
