World: r4wp

value -- Maximum value of result or series (modified when series)

Should have a comma:


value -- Maximum value of result, or series (modified when series)

Moving from the 'random topic back to prot-send.r, I found a somewhat 
serious bug with attachments and base-64 encoding.  I sent the exact 
same attachment using webmail and R3.


at position 32677 in the email sent by webmail (the headers are slighly 
different sizes and the base-64 line breaks are different between 
the two clients) we have the following data:


eMHgCm4jUznXtDnpVKaErkAc107QbjVC6siyHYBu96hxLUjnXDKeWqPOTzVmWxuUY7kJ+lRGF16x

tn6VmO4ncYpZX34HYU0qw7EU3afSgdyUKCvy1s6DpEN3doL93jtyD9089Caq6bZO0g3Llj0Wu8t9

OhsNDu7uUK9wYiq/7OeOK1p03Mwq1eXRbnnUVuZJcKCecD3rctbVbYjdy5/Si1ks7WTLyAerYzUH


at position 32521 in the email sent by R3, we have the following 
data:


vaHNtZYHTmoHtcDpXRSQDk1UeMHgCm4jUznXtDnpVKaErkAc107QbjVC6siyHYBu96hxLUjn
XDKeWq

doL93jtyD9089Caq6bZO0g3Llj0Wu8t9OhsNDu7uUK9wYiq/7OeOK1p03Mwq1eXRbnnUVuZJ


I copied the three lines of data around where the problem occurs. 
 On the short line in the R3 data, the following sequence is missing:


POTzVmWxuUY7kJ+lRGF16xtn6VmO4ncYpZX34HYU0qw7EU3afSgdyUKCvy1s6DpEN3


You can imagine the kind of trouble that causes with binary data. 
;-)

Other than that, the two series are identical.

Before delving deep into R3 code, does anyone have any knowledge 
or idea of why this is happening?  Could it be a problem with buffer 
allocation around the 32K boundary?

Example (allow me to be a bit "unreasonable"):

random/seed 0
block: reduce [1 2 random 100] ; == [1 2 31] (in R3)


now being ordered "Pick a random value from BLOCK" I may (not very 
intelligently, I know) expect that I am required to pick 31 because 
that is the only random value in there (absurd, but compatible with 
the text, as I see it)

While being ordered "Pick a value from BLOCK at random", I would 
just pick whatever I like

I am not a native speaker, though, (but Bo understood my concern, 
I think), so I may be wrong when interpreting the sentences.

Unfortunately, English is pretty random itself. All of those sentences 
could have ambiguous interpretations.

I like "Pick a value from a series at random" because the potential 
ambiguity would be whether any value is picked at all, which you 
could say always happens in some other docs if you feel it to be 
necessary to resolve the ambiguity.

Hmm, right, that ambiguity remains in the text

So, maybe it wasn't a good idea to suggest a change, I am not sure

For native English speakers understanding of English is probabalistic, 
based on cultural preconceptions. So you pretty much have to hope 
for the best.

You can throw more words at the problem to try to make things less 
ambiguous, but that doesn't always work and tends to make your speech 
patterns a little off-putting or overbearing. Some people don't take 
well to overly-precise English. You have to balance things.

I am not writing a ticket for it, then, since it looks like not needing 
an improvement.

(or at least not requiring one)

Your other doc string changes were more necessary.

@Bo .. no idea on why the binary attachments are different.

can you capture the attachment before sending and dump them to see 
if the problem is in building the attachment or sending it ...

@GrahamC:  Yes. I am going to try to find the source of the problem. 
This used to be my job at RT. ;-)

(One of my jobs)

Great .. saves me from debugging this.  not my favourite task

So far, I've gotten all the way to where the message is being written 
to the smtp port without finding any problems.  It looks perfect 
up until that point.  Unfortunately, this means I'll probably have 
to go into prot-smtp.r to track the problem further.

That's not good then ..

So, I take it the issue is with files greater than 32Kb?

I managed to send pdfs and mp3 larger than that with no errors ... 
and I think zip files so that it would test integrity but never did 
any checksum testing

So it seems.

It could be specific to R3 on Arm.  I'll try it on Windows before 
tracing any further.

So R3 on Windows works fine.  It seems to be a problem related to 
R3 Arm.

This part of the output seems to indicate that the messages get split 
on 32K boundaries:

C: sending 32K
=== Client event: wrote
C: sending  17834  bytes of  17834
=== Client event: wrote

Yes, I create a 32Kb buffer to send files in parts

That's my best guess as to where the problem is happening, but I 
haven't gotten to that point yet.

buffer size here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L66

and sending here https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L284

Thx!

I'm running out of time for this evening.  I may have to hold off 
until Tuesday morning (Monday mornings are crazy for me).

so it waits for the 'wrote event and then once that  happens it writes 
again

which is here and thereafter https://github.com/gchiu/Rebol3/blob/master/protocols/prot-smtp.r#L312

wonder if reducing the buffer size in r3/droid might help?

or arm as it may be

Reducing the buffer size causes breaks at each boundary.  Increasing 
it seems to fix the problem for my attachments less than 64k,

so if it fits inside the buffer size it's ok?

Yes.  If it fits inside the buffer size, it works perfectly.  Tested 
and verified.  It may be fixed in the latest build, but I don't have 
the latest ARM Linux build, and won't have time to build it until 
tomorrow at the earliest.

How about writing to a file and sending to the port and seeing if 
there's a difference ...

so both semi concurrently

I don't have an ARM machine available to test

If I make the buffer 64KB, then there are no problems.

stil need to sort out whether the issue is in the rebol port or userland

Has this been discussed as an R2/R3 change? in R2 the variable used 
in a FOR is hard to mess with:
     for nn 1 5 1 [prin nn nn: 3]
    12345
     for nn 1 5 1 [prin nn unset 'nn]
     12345

But in R3:
     for nn 1 5 1 [prin nn nn: 3]
     144444444444444444444444444444444444444 <esc>
     for nn 1 5 1 [prin nn unset 'nn]
     1** Script error: unset! type is not allowed here

FOR has too many bugs in R2 for me to even want to list them all. 
Is this property something you mind about?