file size limitations and Celeste for 4.1

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

file size limitations and Celeste for 4.1

Jecel Assumpcao Jr
Yesterday, Celeste complained that my index and email files didn't match and that I should "salvage and compact". As I watched it rebuild the files, I noticed that the email file was just over 2GB, and so figured this might be a file size limit I have seen in other Linux applications. After six hours, Squeak had finished recreating the files but the result was even worse (and the original files were now gone).

So I will now start over with an empty email database and decided I might as well move from Squeak 3.9 to 4.1. Looking at squeaksource and at SqueakMap I see these versions:

SqueakSource:

Network-Mail Reader-ls.17.mczLex Spoon2006-08-30 12:38:47
Network-Mail Reader-bp.14.mczBernhard Pieber2004-09-18 13:38:50
Network-Mail Reader-bp.8.mczBernhard Pieber2004-05-21 20:26:11

SqueakMap:

  • 1-1.22 -
  • 2-1.23 - The Celeste Email Client with an AddressBook
  • 3-1.24 - The Celeste Email Client with an AddressBook
Where 3-1.24 is from 3 October 2004 2:47:19 pm. So I suppose that my best option is to get version 17 from SqueakSource and then merge my own patches plus do any changes needed for 4.1 (the right way to share these is through Mantis, right?).

This will have to wait a little while, but I don't like the webmail interface I am typing this on and so need to start this as soon as possible.

-- Jecel


Reply | Threaded
Open this post in threaded view
|

Re: file size limitations and Celeste for 4.1

Karl Ramberg
It's here also:
http://www.squeaksource.com/Celeste
also se the thread about Unnsuported packages
http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150441.html

Karl

On Thu, May 13, 2010 at 7:00 PM, [hidden email] <[hidden email]> wrote:
Yesterday, Celeste complained that my index and email files didn't match and that I should "salvage and compact". As I watched it rebuild the files, I noticed that the email file was just over 2GB, and so figured this might be a file size limit I have seen in other Linux applications. After six hours, Squeak had finished recreating the files but the result was even worse (and the original files were now gone).

So I will now start over with an empty email database and decided I might as well move from Squeak 3.9 to 4.1. Looking at squeaksource and at SqueakMap I see these versions:

SqueakSource:

Network-Mail Reader-ls.17.mczLex Spoon2006-08-30 12:38:47
Network-Mail Reader-bp.14.mczBernhard Pieber2004-09-18 13:38:50
Network-Mail Reader-bp.8.mczBernhard Pieber2004-05-21 20:26:11

SqueakMap:

  • 1-1.22 -
  • 2-1.23 - The Celeste Email Client with an AddressBook
  • 3-1.24 - The Celeste Email Client with an AddressBook
Where 3-1.24 is from 3 October 2004 2:47:19 pm. So I suppose that my best option is to get version 17 from SqueakSource and then merge my own patches plus do any changes needed for 4.1 (the right way to share these is through Mantis, right?).

This will have to wait a little while, but I don't like the webmail interface I am typing this on and so need to start this as soon as possible.

-- Jecel






Reply | Threaded
Open this post in threaded view
|

Re: file size limitations and Celeste for 4.1

Jecel Assumpcao Jr
Karl Ramberg wrote on Thu, 13 May 2010 19:29:47 +0200

> It's here also:http://www.squeaksource.com/Celeste

Right, the first set of links I gave were from there. But the actual
package is called Network-Mail Reader instead of Celeste.

> also se the thread about Unnsuported packages
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-May/150441.html

Thanks for the reference. An inbox to which I could post my Celeste
fixes would certainly be nice. If you are reading this, then I now have
Celeste running in Squeak 4.1 (but I haven't touched the 2GB limit and
have started a new mail database instead). I had not published my
previous fixes for Celeste because they were quick hacks all over the
system to deal with broken email messages. Having a UTF-8 decoder do a
"self error:..." when it doesn't like the input is not a friendly user
experience at all. I had previously patched things so it would return
some constant character and then just keep going. My current changes use
the exception system instead and replace the whole thing with an error
message, which has some disadvantages but seems more correct to me.

Even with the greater care I took this time, there are still a lot of
changes to stuff outside the package. I would have to review them to see
if they should go into Trunk rather than living as evil overrides.

There are two fixes that are needed which I haven't done, yet. My SMTP
server needs authentication - the code to deal with this was already
there (though broken) but there is no GUI to enable that option. For
now, I just used an inspector on the account object to set the option
directly.

The second issue is that #mimeDecode in RFC2047MimeConverter is broken.
It uses #nextPut: which will actually *encode* the characters instead of
decoding them. The reason why this seems to work was that if the
encoding is Latin-1 or the stream is binary, things are just passed on
unchanged. For UTF-8 text encoding (I am getting some of those on this
list these days) you get a double encoding, which at first looks a lot
like as if it had just been passed through unchanged.

Anyway, it is great to be back.
-- Jecel