World: r3wp

Geez, if you gave me the host code, I'll probably end up in the science 
channel ....

Has any decision been made to use Gab's rlp format for documentation 
and code generation yet ?

No decision yet. It certainly will do for now.

If I have 

a: :print 
or
a: %file.txt

how can I check for what it is ?


switch type? a [ function! [ print "function" ] file! [ print "file" 
]

switch type? a reduce [ function! [ print "function" ] file! [ print 
"file" ]

switch to-word type? a [...

TYPE?/word is best for now - less overhead than the REDUCE method.

ah yes, couldn't remember what the specific method was.

that evaluates the function

Less overhead than TO-WORD too.

switch type?/word :a [...

Nope .. then I have to check for native!

I guess I could use 

function! native! [ .... ]

case [any-function? :a [...] file? :a [...]]

ahh.. ok

CASE is used for that stuff a lot in the mezz code.

there's this example on http://www.rebol.net/wiki/Port_Examples

 copy-file: func [
       "Copy a large file"
       from-file to-file
       /local file1 file2 data
   ] [
       file1: open from-file
       file2: open/new to-file
       while [not empty? data: read/part file1 32000] [
           write file2 data
       ]
       close file1
       close file2
   ]

where is the skip occuring to advance thru the from-file?

Does the skip occur automatically on a file port?

If so, this seems to be the only documentation!

All ports in R3 are like /direct ports in R2, autoadvancing with 
an internal position.

There are no series-like ports in R3.

Good to know

If I write a 100Mb file to a tcp port ... does R3 automatically write 
it in chunks for me?

It is documented, as I recall, as part of the basic port model.

I would expect so, but you'd block your task! until it was done if 
you do it in one WRITE. And that means blocking quite a bit until 
tasks are properly working.

BrianH, silly question, but where does the async nature of R3 ports 
then go, if writing blocks?

You can use async by providing a handler, or use one of the sync 
wrapper functions. If you use the sync wrappers it is still internally 
async, but not as far as you know.

And other tasks can still do their stuff, once we have those.

that being the case, I can just write 32,000 bytes each time there 
is a wrote event

Check first, and remember to manage your buffers well.

Seems to have worked .. managed to upload 32Mb using ftp

Brian: pipe was not posted publicly, though, nothing that i know 
of is using it (i did it for Maarten but he didn't use it :), so 
at this point is a lone function in a lone file... given that it 
will need adaptation to work in R3, feel free to make a R3 version 
out of it. it would be hard to claim copyright on that even if I 
wanted to. ;)

I've added a REBOL forum to my new vbulletin forum .. since reboltalk 
seems to be done 
http://synapse-ehr.com/forums/forumdisplay.php?3-Rebol

done => down.

the disarmed state of error objects in R3 is REALLY cool... simplifies 
code and switches them to usefull data, which is an alien concept 
to most other languages.

success?: all [
	done: try [parse data rules]
	not error? done
	not string? done
]


here strings are the return type for parse block created (syntax?) 
errors in the source data

Use :done so the error doesn't trip.

Not always needed, but good for bulletproof code :)

in R3 it doesn't trip anymore which is what my post is about, the 
only place where :get-words have been usefull for me are for passing 
functions as values or to handle unset values.

by tripping, I assume it means, if the parse somehow returns a function, 
that when run would cause an error, hence the get-word!.

Yeah, I picked up on that later Maxim :)

also serves as a security measure

How are things going on adding a few schemes?  


I mentioned that I would review the docs and add more examples; however, 
if someone has implemented a simple scheme example, like finger or 
such, then let's use that as the starting point, clean it up (if 
necessary), and put it on the wiki for others to learn from.

As mentioned in chat, most of the common schemes are now "done"

Most need sync wrappers around them, and some actors to provide the 
previous way of doing things

http://rebol.wik.is/Rebol3/Schemes

Ok, that's great.  So, by "sync wrappers" you mean some kind of internal 
utility to deal with the sync/async differences when called from 
the user level?

As related to:

http://www.rebol.net/wiki/Ports:_Synchronous_and_Asynchronous_Operations

there is one very usefull doc describing device communication (don't 
remember the name now), but stil some things are going to be missing 
...

current implementation is not what I thought is going to happen - 
the rehaul of aproach we are taking for schemes. Some ppl are also 
confused by read/write function names vs read, write event names, 
and IIRC Graham also noticed few other issues ...