Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-03-04 Thread Philip Van Hoof
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-03-04 Thread Philip Van Hoof
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Philip Van Hoof
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, then

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Philip Van Hoof
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 =

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Philip Van Hoof
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Jeffrey Stedfast
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-27 Thread Philip Van Hoof
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-26 Thread Jeffrey Stedfast
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?

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-26 Thread Jeffrey Stedfast
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

Re: [Evolution-hackers] Loading really large E-mails on devices with not enough Vm

2008-01-26 Thread Jeffrey Stedfast
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