World: r4wp

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?

No views on this at all.....Just noticed it as a difference and wondered 
if it was a principle or an accident.

looks like intended (to me)

notice that the value is type-checked

@Robert - do you think Saphirion could put up a newer source download 
if publishing to a repo is not going to happen in the near future?

Yes, sure, that is on the way

a newer download or the public repo?

newer source download