World: r3wp

Re: Server limit...is that when using /only or both methods?

I was just saying that when a server receives a bulk mail, (from 
any client) it will (should) definitely restrict the list size.

oK thanks...

Now get back to Glass! development! ;-)

within rebol, I'm not sure how this is handled.  but I know that

oops... ingnore last sentence... I know nothing  :-)

looks like my host cutsoff at 10 addresses.when not using /only refinement


using /only I can't test because I only have 4 address to test send 
to and it seems to strip out duplicate addresses whcih is how I tested 
above

Use the BCC: (blind carbon copy) field to specify a list of recipients 
who will not see the other email addresses.
I think you need to set bcc in a custom header.

Just a question for REBOL School for me too: is there a way to send 
HTML emails with embedded images ?

Why not ask it in Rebol School, then :) ?

Because I thought I was in REBOL School... sgrunt !

How do I create a string with a single caret ?

rejoin [  a "^" b ] doesn't work
but rejoin [ "a" "^^" "b" ] gives me 
a^^b

It only looks that way. There's only one caret in that string:
     length? "a^^b"
    == 3
    print "a^^b"
    a^b

the data file I'm using is full of carets :(

It would be nice if we could set the escape character ...

If you use READ or READ/LINES, you should find that REBOL handles 
the carets properly.
Ditto. TO-STRING READ/BINARY
Other cases may be problematic :(

In a datafile, the ^ should not escape anything

I think you'll find it doesn't.....Create a data file in a text editor 
with just a single caret. Then use READ to read it into REBOL. It 
should have  a length of 1.

that's where I get confused about caret handling

Maybe it is too automatic....Try playing with tests like this until 
it becomes clearer:
    to-string #{5e}
    == "^^"
    length? to-string #{5e}
    == 1

Graham... LOAD does the escaping, READ does not. does this help? 
MOLD also does the escaping, so if you PROBE at the console you see 
that, but it has nothing to do with what is actually in memory.

Makes sense :)

One of those annoyances ...

>> to-local-file %"/c/program files/rebol/rebol.exe"
== "c:\program files\rebol\rebol.exe"

>> rejoin [ "call " to-local-file %"/c/program files/rebol/rebol.exe" 
]
== "call c:\program files\rebol\rebol.exe"

>> quoted-to-local-file: func [ f ][ rejoin [ {"} to-local-file f 
{"}] ]

>> rejoin [ "call " quoted-to-local-file %"/c/program files/rebol/rebol.exe" 
]
== {call "c:\program files\rebol\rebol.exe"}

I presume Linux escapes the spaces so it's not an issue on that platform

Nope - Linux systems are usually much worse with spaces, so they 
tend to not have spaces in directory names.

I thought linux used a backslash to escape spaces

Ok, same problem with Linux.  Just checked. Rebol doesn't escape 
special characters like spaces.

Linux uses either single quotes, or a \ it seems

bit messy ....

CALL in R2 does the local file conversion though. Let me check whether 
it does escaping.

graham, the shell doesn't escape them either.

>> call/console [%/C/WINDOWS/system32/cmd.exe "/c echo" %.]
C:\Program Files\REBOL\View

you have the same problems when you create batch files in Windows. 
 its an OS thing AFAIK

actually, just typing the command in the console requires you to 
properly escape spaces or quote the path.

CALL does the TO-LOCAL-FILE itself, and wraps with double quotes 
automatically.

but only if you use block mode for CALL, Graham was using a string, 
which allows us to make sure things are formatted properly, cause 
sometimes, when specifying arguments, this crap gets very mystical. 
 :-)

Right. That's why I was mentioning the existence of block model to 
Graham :)

(and why I made that distinction explicit  ;-)   even I almost missed 
that "detail"

Yeah, and the R3 CALL doesn't do anything like that yet. Time to 
edit the host code?

Graham, what about using REBOL words to do that job.. like:

>> rejoin [ "call " mold to-local-file %"/c/program files/rebol/rebol.exe" 
]
== {call "c:\program files\rebol\rebol.exe"}

MOLD can produce a string with braces instead {} - not good for the 
command line.

I've been playing a little with Gabriele's async http, and I note 
that the subport only sends back close and error events to the main 
awake handler.

If you want to do a progress meter, you'll need the read and write 
events as well.  Easy enough to add back in.  I wonder if this shouldn't 
be improved so that we can use it as standard in core 2.7.8.

Redirects are also not done ...

ahttp basically just does what I needed for the Detective... R3's 
http is much closer to the real thing.

So we should look for your R3 http for inspiration? :)

I pushed the two small changes to github http://github.com/gchiu/Rebol2/blob/4b59b6e2cb5c06076e7251c311c575b189d4bf77/Protocols/prot-ahttp.r

This Git GUI is not very intuitive to use ...

tried tortoise git? works pretty well

or is this linux?

windows