World: r4wp

I don't believe this works anywhere yet.

I tried to find a submitted bug in Curecode, but couldn't find one, 
so I submitted one.

The rebolbot has a multiline console :)

Very cool!

More prot-send.r testing.  Had the hardest time trying to get 'send 
to work with my mail server.  Found I had to change a line in prot-send.r 
to :


 smtp-port: [ scheme: 'smtp host: (user/smtp) user: (user/user) pass: 
 (user/pass) ehlo: (find/tail user/email 
@
) timeout: 600 ]


as EHLO on my SMTP host was expecting only the domain portion of 
the email address instead of the entire email address which is what 
I had been trying.

Bo, Have you forked Graham's scripts to push fixes for these?

Bo, you could have asked me :)

These aren't fixes ... you just have to know what ehlo expects

@GrahamC: I understand what you're saying, but how do mail programs 
like Outlook and Thunderbird figure out what to send EHLO?

The expected EHLO parameter is the client's hostname.

Outlook and Thunderbird can "just" look up what your local machine 
claims to have configured as hostname.

Previously we could use read dns:// .. but that doesn't work in R3

Windows has a gethostname API. I always liked the read dns:// feature 
though.

RANDOM help: "Pick a random value from a series" . The text looks 
a bit inaccurate to me. Wouldn't one of:

Randomly pick a value from a series

or

Pick a value from a series at random


For me, these reflect more accurately what is random. Any opinions?

I like the current text. What makes it unclear, or inaccurate to 
you?

I understand what Ladislav is saying.  The current text implies that 
there is a series of random values, and one will be picked.

Or it could mean that there is a series, and one of the values will 
be picked randomly.

I think Lad's two suggestions are both more clear.

What was wrong with the R2 text?

  "Return single value from series."


But the doc string for 'value isn't helpful with regard to series 
values either.

I would make it a bit more readable though.

  Return a single value from the series.

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