World: r3wp

using my rewrite function

sorry, should be: digits: charset "1234567890" reverse rewrite reverse 
"1234567890" [[x: 4 digits] [(copy/part x 3) "," (pick x 4)]]

>> digits: charset "1234567890" reverse rewrite reverse "1234567890" 
[[x: 4 digits] [(copy/part x 3) "," (pick x 4)]]
== "1,234,567,890"

i wouldn't suggest doing it this way though ;)

to-comma: func [ n [number!]
	/local tx result
][
	tx: reverse form n
	result: copy ""
	while [ not tail? tx ][
		repend result [ part: copy/part tx 3]
		tx: skip tx 3
		if all [ not tail? tx 3 = length? part ][
			append result ","
		]
	]
	reverse result
]

no decimals ...

don't forget that if you use comma to group digits, you can't load 
it back in rebol anymore.

Rebol uses ' as a separator

to-comma: func [ n [number!]
	/local tx result parts left right
][
	one-comma: func [ tx /local result ][
		result: copy ""
		while [ not tail? tx ][
			repend result [ part: copy/part tx 3]
			tx: skip tx 3
			if all [ not tail? tx 3 = length? part ][
				append result ","
			]
		]
		result
	]
	parts: parse tx: form n "."
	left: reverse one-comma reverse parts/1	
	either found? parts/2 [
		right: one-comma parts/2
		rejoin [ left "." right ]
	][
		left
	]
]

handles decimal points as well.

>> to-comma 1
== "1"
>> to-comma 1234
== "1,234"
>> to-comma .1
== "0.1"
>> to-comma .1234
== "0.123,4"
>> to-comma 1234.1234
== "1,234.123,4"

I have trouble sending a BCC email with the new send function. Can 
anybody verify ? (I am using authenticated smtp)

h: make system/standard/email [ BCC: [copy-:-domain-:-com]]

send/header [to-:-email-:-com] msg h

Vaguely I think it should be: reduce ['bcc [copy-:-domain-:-com]]

no sorry, let me try...

don't think send supports cc

Yes, that's right, SEND is BCC by default.  Note the /show refinement: 
  /show "Show all recipients in the TO field"    That means by default 
they are not shown.

looking at send source, /show just clears the header to field, so 
it works when you send to multiple recipients and each one doesn't 
see who else received the email. When a message is sent to a single 
recipient the client shows the message is directed to you anyway. 
The trouble is this is not bcc

In this case, each message is individually addressed with only the 
recipient's email name appearing in the To field (similar to BCC 
addressing).

http://www.rebol.com/docs/core23/rebolcore-13.html- section 9.2

Sorry, the above to posts refer to the Core 2.3 docs. I have trouble 
with the "similar to bcc" If someone can provide some hints on how 
I should handle BCC then I will modify send source. To me this is 
a bug (i submitted to RAMBO) and I don't see what's the point of 
having BCC field in the standard header if this field is ignored

if you want bcc, just send the mail again addressed to the bcc recipient.

I think those fields are telling the email client how to send them. 
 It is up to you to implement them.

I can't think of any reason why an email client should ever receive 
an email with a bcc field.

Graham, I tried that but you get the same email than before with 
a different recipient but no BCC. I want to use BCC for some archiving 
project so I want to preserve the original To field like in real 
Bcc messages

Graham, I am not in the corporate world, but when I was Bcc was one 
of the hottest features, so many people used it to copy managers 
without the recipients being aware. I did like that use but it was 
widely accepted method to keep people in the loop

I did like
 --> I meant I didn't like

A semi-solution to this problem has been posted in RAMBO http://www.rebol.net/cgi-bin/rambo.r?id=4103&

This is a hack because the message shows the original headers so 
it's not true bcc but it partly solves my problem thanks

Joe, I had problems with BCC in a corporate mass emailing I did. 
 Even though it did not display the email address in the mail client, 
if you viewed the header of the mail message the BCC content was 
there.

A disgruntled recepient spammed the entire BCC list indicating our 
company didn't care or respect their privacy... just my luck.. .this 
was the first attempt to use Rebol for a valuable task at this job!! 
:-(

<ouch!>

smtp-port: 	open [scheme: 'esmtp]
msg:		head insert insert tail net-utils/export o-h newline msg
insert		smtp-port reduce [v-from reduce [v-to] msg]   	
insert		smtp-port reduce [v-from reduce [v-bcc] msg]

Hi Brock, this is how I fixed the bcc issue. I set up the right headers 
in o-h and then send the to message and afterwards the bcc message

Joe, did you mean that the BCC field with all the addresses should 
appear in the header of every recipient's email ?

If so, then that's not how it's supposed to work. BCC really does 
mean "blind carbon copy". The recipient should have no way of knowing 
other addresses. Your only standards-conformant remedy is to use 
CC.

is system/locale ever used for anything beyond the date requester? 
it would be nice if it were possible to localize date! type

send - i think there is a lot of confusion here

the BCC header field is a field used by mail clients to let users 
type addresses that will *not* be included in the header. it is, 
basically, a user interface. back at the time mail clients did not 
have a gui, and just processed mail from a file or by letting you 
type them on the terminal

so what a mail client does, is reading the mail, collecting the addresses 
from to, cc, and bcc, removing the bcc lines, and then sending the 
message to the collected addresses.

yes, B should stand for Blind .... it should prevent disclosing the 
person, you sent copy to ....

but send is not a mail client. it is a function to send email messages.

what send does (and should do!) is sending the specified message 
to the specified list of addresses. send does *not* collect the addresses 
from the mail header.

to make things easier, send will fill in a default mail header if 
the user has not provided one. however, if you are after something 
more complex than send [luke-:-rebol-:-com] "hi!" then you probably will 
want to pass your own header.

this header is sent as-is, except for a couple things such as setting 
To if you haven't set it (this is so you can have a header template 
and send many messages with it easily)

what send does *not* do and *should not* do is remove or change other 
header lines. in particular it will not remove any bcc: lines. the 
reason is, that you should *not* pass them at all, because it makes 
no sense.

now, since this is a very common error among users, it may be useful 
to let send remove bcc. personally, i will vote against this, because 
i prefer educating users (documentation) rather than keeping them 
stupid and happy. ;) even in the case we do it, send is still *not* 
collecting the addresses from bcc anyway - so we're just wasting 
time removing something that someone wasted time adding.

how about implementing an 'email function that does bcc etc?

so what you need to do now to send a message is - just send/header 
[list of addresses] msg header, with header being composed correctly 
- to should have what you want your recipients to see in to, from 
should have what you want your recipients to see in from, and so 
on; there should *not* be any bcc lines.

It just needs to wrap around send.