[BUG]? Celeste message parsing error: At least one digit expected here

Bernhard Pieber bernhard at pieber.com
Sun Nov 11 16:01:22 UTC 2001


> Celeste should certainly tolerate badly formatted messages.  Can you
> figure out what is wrong with the messages?  I don't see your script.  I
> do see two copies of Timestampe>>fromDate:andTime: from Visualworks.
Oh, I see I should have made myself clearer. The script starts with
MailMessage from: 'Return-path: <vwnc-request at cs.uiuc.edu><snip>'. And then
follows the whole message string as a parameter. You should be able to
select from MailMessage from: until the end of my mail and do it. Then up
comes the debugger. But to answer your question:

> Is it a bogus Date: field that is messed up?  If so, could you try it
> again in a new image?  Celeste is pretty robust about handling bad
> Date's nowadays -- it looks like update 3906 did the trick, from back in
> April.
No, it's not a messed up Date: field. MailMessage>>from: calls
decodeQuotedPrintable on a string starting with the following:
'
--Boundary-=_nWlrBbmQBhCDarzOwKkYHIDdqSCD
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable<snip>'

This in turn does Integer>>readFrom:base: with a (ReadStream on: '_n') as
the first parameter which leads to the Error: At least one digit expected
here. So there seems to be some problem with the encoding of the attachment.

I also forgot to mention that I am using your FilteringCeleste change set -
which I find really great by the way. However, I just tested it with a fully
updated 3.1beta-4478 image and it has the same problem.

> By the way, the messages are downloaded first in order to be robust.
> The messages are first saved to disk, and only then deleted.  A priority
> in Celeste, at least so far, has been reliability.  Since saving is
> kinda slow, it's desirable not to do it too often.  Instead of making
> this mechanism more complicated, it seems sensible to wait a little and
> get duplicates avoidance working, which handily solves this problem...
Ah, I see. So the new messages are only saved once at the end of the fetch
and not one by one. Then that makes sense of course. I agree that
reliablility is most important for a mail database. Duplicates avoidance
would be great, of course.

Thanks again for looking into my problem!

- Bernhard





More information about the Squeak-dev mailing list