World: r3wp

right, in these specific cases, otherwise the behaviour may differ.

what would did you expect to get?

I guess, I was just surprised, that it worked with decimals. Then 
it can maybe be argues, if 3 // 3.4 should return an integer or a 
decimal.

argues = argued

the definition is as follows: if r = a // b, then a - r // b should 
be zero

Been thinking about it too....It is surprsing, but does make sense.
It's returning the remainder:
3 // 2.6 --> remainder is 0.4
3 // 3.4 --> remainder is 3

other formulation: if r = a // b, then a = some-integer * b + r

In rebcode, I guess the upcode rem is remainder. It works a little 
different there:
set a 3
rem a 3

now a is 0. If doing this:
set a 3.0
rem a 3

then a is 3.0.

I guess, it has to do with the internal floating-point representation 
of numbers.

rebcode's rem does *not* support decimals.

will it be possible to do easy types conversion with rebcode? regard 
me being stupid, but I regard following being  bug or at least inconsistence:

type? #{77}
== binary!    ; so no excuse it is a string later!

to-integer #{77}
== 119

to-binary to-integer #{77}
== #{313139}

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.