World: r3wp

send [to: [x-:-y] subject: "i am back"] "had great hollidays"

send  is just the example of what the word does SOME things more 
than it should, but not all, and does not fully explain everything. 
 We are used to a lot of consistency in rebol. and if a word makes 
email shortcuts but not all of them... I understand the frustration 
which can come from a mistake, when you can't really know how -REBOL's- 
mail handling is performed... no matter what are the standards.

But, how about dropping 'send and switching to 'email completely 
in R3? 'send is a nice word for rebservices etc. IIRC Carl noted 
that somewhere.

Then in case of email 'send could be stupid without *any* headers, 
and 'email the dialected smart version.

http is supposed to be handled in rebol, yet I had to rewrite my 
own http-post function to talk to a webservice operating only in 
http1.1 of which rebol had a lot of trouble handling.  yet the service 
was compliant and rebol was not.

Good idea volker.

Volker - nice suggestion, really, isn't Linux shell using mail or 
email command too? Would make sense ... to even blockify its input 
arguments ...

make send more stupid so we assume/expect less of it.  and make a 
proper email function which handles most common useage like a mail 
client does it.

visitor. cu

?

suden visitor. Have to talk in person :)

I've got a question. open/skip does not work?

open/seek ?

That was added later. /skip works thru some networking IIRC.

I need it on files

Try seek, and then use 'skip etc. IIRC that works. (needs the newer 
rebols)

hm, works strange, but works :)

port: open/direct/skip url size ; resume position <- this can fail 
when file is complete already

I just spent a couple of nights working on a batch-downloader.

Anton, yes bcc is a blind copy. Gabriele explains it better than 
I did.  I found it very easy to code the new send function with the 
snippet above . The trick is to compose the right header and then 
send the message to both the to and bcc recipients. The MTA does 
remove the bcc field so the to: recipient or even the bcc: recipient 
do not have a bcc header field

It does seem that the bcc issue is caused by the presence of bcc 
in system/standard/email. Perhaps send could raise an error if it 
finds bcc set - and or - remove bcc from system/standard/email.

Maxim, re http-post. Are you talking about a bug in the http scheme? 
You seem to be implying something structural. Is the issue fixed 
in the new versions of REBOL or still present?

Brett, bcc is set to none by default so it doesn't cause any issues. 
If the field is set and exported as part of the header, the mail 
transfer agent will remove it

yes the scheme had issues with content lenghts.  and I needed to 
post in 1.1 which is not handled directly by the scheme AFAICT.

I though I've got it working but it was a mistake. I'm still not 
able to use /skip refinement on files succesfully. Does anybody now, 
if it's possible to OPEN or READ file from some offset? I saw some 
bug filled in RAMBO two years ago :(((

p: open file
p: skip p 123
data: copy p
IIRC

open/seek

so /skip refinement is good for what?

I cannot use copy/part in this case :(

/skip : Backward compatibility. It helps with resume through http 
AFAIK.

So how can I succesfully write read/binary/part/skip ?

write %test.txt "123456789"
p: open/seek %test.txt
p: at p 4
probe copy/part p 4

Thanks

Do I need reduce/deep? Example:
x: 0.123
v: reduce/deep [ [- x 1.0 1.0] [0.0 0.0 0.0] ]

v should now hold: [ [-0.123 1.0 1.0] [0.0 0.0 0.0] ]
But reduce don't have a /deep refinement, and if I do:
v: reduce [ [- x 1.0 1.0] [0.0 0.0 0.0] ]

those inner blocks ain't reduced. Is there another easy way? I don't 
wanna have REDUCE inside the block.

compose/deep ? Also a reduce-deep would be a few lines.

Yeah, I guess. compose/deep require parens inside the block. I could 
make a reduce-deep function, but that'll hit performance. REDUCE 
is native. Should reduce/deep be part of REBOL 3 maybe?

For sure.

You need a lot performance?

I'm using this feature in the OpenGL API, I'm working at. Maybe I 
could do a late reduce, when accessing the inner blocks.

Volker, yes I need all the performance, I can get for this.

Is there a time when one doesn't want inner blocks to be reduced?

 I don't wanna have REDUCE inside the block.

 Is that only inconveniert, or would it really make problems? Maybe 
 some kind of automatic rewriting could help?

James,  parse-rules inside a block?

Yep. You're right.

I was just thinking how this particular behavior has caused me some 
trouble in the past but I see why they did it that way.

You would think  there would be a "complete" reduce parameter though 
that just works the way one would think it would.

Would rebcode be an option? Or a dll for some datastructures?

Volker, a rebcode version will probably make sense later, but I'm 
under OSX right now, where the rebcode is an old version.

I doubt  i find a good idea, so if i am boring just say stop.

Would it work to flatten the datastructure? /skip instead of nested 
blocks? Tehn 'reduce would work.

Well, that could work. But the situation is, that the datastructure 
is made by the user, so it should be as straight-forward as possible. 
Example of a structure:

vdata: [	
	[- X 0.0 Z] [X 0.0 Z] [- X 0.0 - Z] [X 0.0 - Z]	
	[0.0 Z X] [0.0 Z - X] [0.0 - Z X] [0.0 - Z - X]	
	[Z X 0.0] [- Z X 0.0] [Z - X 0.0] [- Z - X 0.0]
]


I think, I'll do a late REDUCE of the inner blocks, when I access 
them. But thanks for your ideas! :-)