World: r3wp

If pure functions which serve datatype conversion work one way, it 
is imo inconsistent that it does not work the same way in the reverse 
mode ....a

If you want to convert a number to binary, number must be enclosed 
in brackets, to binary! [119] , not to binary! 119

so your example should look like:

to binary! reduce [to integer! #{77}]
== #{77}

we are not converting here string of "119" values, but integer!

why?

that's what's written in documentation

I don't know the reason

And you cannot convert numbers bigger than 255

I said no excuses or silly walkarounds. We are converting integer. 
Take your calculator and look how it converts it ;-)

to binary! [256]
== #{00}

This is not a workaround, that's in the documentation :)

Kru - interesting example with integer in the block, but even more 
twisted imo :-)

http://rebol.com/docs/core23/rebolcore-16.html#section-2.1

To convert an integer into its binary value, pass it in a block

so we take binary as an argument, convert it to integer. Then we 
take exactly the same integer, and convert it back to binary and 
we get different result? :-))

It is like doing 3 * 7 = 21 on calculator, then pressing /, 7, enter, 
and not getting back to 3!

I don't understand what do you mean. If you've got integer less than 
256, you'll get same result

Pekr: why don't you check RAMBO and put it there (if not already 
present)?

I am far from being expert in assembler etc., but imo the proof of 
misconception in the first place is, that it has to be explicitly 
stated in the docs. Imo it is because naturally one would expect 
different result ... :-)

Ladislav: well, because maybe it is intended? We have it this way 
for ages, lots of code relies on it!

and because I know my knowledges are limited here, I ask gurus for 
some sane explanation of concept behind such logic, maybe there is 
one?

take it as my advice

ok, I just wanted to discuss it here first, to not flood Rambo by 
unnecessary input ....

It may be already there, though

so, direct question - do you personally think current state is ok 
from "language purity" pov? :-)

#3820? :-)

I don't think it's ok, that to binary! treats integer! as string!, 
but it's in the docs...

I don't mind that much about "language purity" as it may look. It 
is inconvenient above all.

Kru: thanks a lot, adding to-block to the code solves it ;-)

Pekr: solves it for one-byte integers and that's not so good :)

:-)

How do you change the content type of outgoing emails?  I want to 
change the charset to UTF-8...

Meh, just create a custom header...

Be careful of using the BCC feature with emails.  I sent mails at 
one time were the BCC recipients were viewable in the header information 
from within Outlook.  A disgruntled recepient then SPAMMED all who 
were BCC'd using my companies email address as the from Address.... 
Corporate Security didn't like me very much.

... they eventually identified the spammer by the way  :-)

Don't you mean .. beware of using "Outlook" ?

I think if you BCC someone in an email it should not appear in the 
header of an email.  I don't know the spec, but it doesn't make sense 
if you want to hide who received an email that is displayed in the 
mail header.

We've discussed this before, and the RFC does allow the BCC header 
to appear.

SEND does not take the recipients from the header, so it has no reason 
to preprocess it. if you include a BCC header, it's because you want 
it to pass... otherwise, why do you include it?

What ? I'm shocked. I always thought CC was for allowing the recipients 
to see the list, and BCC was for the mail processor to split apart 
and hide. Are you sure about that being in the RFC Graham ? I would 
believe you otherwise but I'm in denial.

I know mail sent with Outlook did not show the BCC'd recipients in 
it.

Seems there are two scenarios, both of them should not send the complete 
list of the BCC'd users in the mail message....
The 
Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains

   addresses of recipients of the message whose addresses are not to 
   be

   revealed to other recipients of the message.  There are three ways 
   in

   which the "Bcc:" field is used.  In the first case, when a message

   containing a "Bcc:" field is prepared to be sent, the "Bcc:" line 
   is

   removed even though all of the recipients (including those specified

   in the "Bcc:" field) are sent a copy of the message.  In the second

   case, recipients specified in the "To:" and "Cc:" lines each are 
   sent

   a copy of the message with the "Bcc:" line removed as above, but 
   the

   recipients on the "Bcc:" line get a separate copy of the message
   containing a "Bcc:" line.  (When there are multiple recipient

   addresses in the "Bcc:" field, some implementations actually send 
   a
   separate copy of the message to each recipient with a "Bcc:"
   containing only the address of that particular recipient.)"

(sorry about the word-wrap)

http://www.faqs.org/rfcs/rfc2822.html

Many implementations use the 

Bcc:" (blind carbon copy) field described in section 3.6.3 to facilitate 
sending messages to recipients without revealing the addresses of 
one or more of the addressees to the other recipients.  Mishandling 
this use of "Bcc:" has implications for confidential information 
that might be revealed, which could eventually lead to security problems 
through knowledge of even the existence of a particular mail address. 
 For example, if using the first method described in section 3.6.3, 
where the "Bcc:" line is removed from the message, blind recipients 
have no explicit indication that they have been sent a blind copy, 
except insofar as their address does not appear in the message header. 
 Because of this, one of the blind addressees could potentially send 
a reply to all of the shown recipients and accidentally reveal that 
the message went to the blind recipient.  When the second method 
from section 3.6.3 is used, the blind recipient's address appears 
in the "Bcc:" field of a separate copy of the message. If the "Bcc:" 
field sent contains all of the blind addressees, all of the "Bcc:" 
recipients will be seen by each "Bcc:" recipient.  Even if a separate 
message is sent to each "Bcc:" recipient with only the individual's 
address, implementations still need to be careful to process replies 
to the message as per section 3.6.3 so as not to accidentally reveal 
the blind recipient to other recipients."

First quote from section 3.6.3. "Destination address fields"
Second quote from section 5. "Security"

It states in the site that the RFC has been updated to handle security 
considterations... so our email implementation seems to be based 
on an older, out-of-date RFC.

As Gabriele says, 'send doesn't use the header for addressing.  It 
is up to you to implement how email is sent, and to whom.

Sorry, I don't understand those arguements.  From my perspective 
Rebol is sending all the BCC'd recipients when an email is sent. 
 Unless you are telling me it is up to the mail server to not pass 
the BCC along.  I somehow don't think so.