World: r4wp

(I can confirm Anodroid ARM port shows correct result)

OK.  Thanks for the confirmation.

Is this an R3 bug or feature? Duplicate word in a single object....

    ob: object [] append ob  [b: 2 b: 3 b: 4]
    == make object! [
        b: 2
        b: 3
        b: 4
    ]


    foreach w words-of ob [print get w]   ;; they are actually different
    2
    3
    4

that HAS to be a bug.

That what I thought, thanks -- but could not see it in curecode, 
and don't remember it in earlier versions. So it may be Something 
Very Clever :)

Nope, it's an APPEND bug. Please report it (and thanks for all the 
reports lately).

Thanks. Done.
http://curecode.org/rebol3/ticket.rsp?id=1979

@GrahamC: Thanks A LOT for prot-smtp.r and prot-send.r.  I was able 
to send an email from R3, but only after changing a line from:

	ehlo: any [ port/spec/ehlo "rebol3 user pc" ]
to
	ehlo: any [ port/spec/ehlo port/spec/email ]

My smtp server was throwing a 501 5.0.0 Invalid domain name

Thanks .. http://chat.stackoverflow.com/transcript/message/8019099#8019099

No, thank you!

On R3 ARM:

>> header: [
** Syntax error: missing "]" at "end-of-script"
** Near: (line 1) header: [


I guess we can't cut-n-paste multi-line scripts into the console 
at present.

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 ...