World: r3wp

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 ...

eg. write ftp://ftp.rebol.com/uploads%matrix.mov

UDP implementation? (Needed for dns:// scheme to work?)

Still need a place for set-net, network timeouts, email object .... 
commonly used parse rules and bitsets, network error handlers

Pekr, there is no "overhaul" of the approach.  I spent several months 
on the new design, and it's much better than R2.  There may be a 
few small tweaks to make and a few issues to consider, but other 
than that, it's quite good.

The first thing people need to know is that THIS IS NOT R2!  The 
first mistake is to approach ports the same as R2. That will not 
work here.

not overhaul of ports, but schemes. Ppl were thinking about FSM etc.

Graham is corrrect.  We need to finalize a base context for networking.

I would propose a Networking Module that can hold misc functions 
and variables, debugging modes, etc.

In R3, you can create a module inline with one line of code.  That's 
where to start.

Once we understand the exports, we can then formally define the module, 
title, export list, etc.

The model is good, but most of the wrapper and helper code needs 
work, or revamping.

Also, for testing purposes... if you need to add a system/standard 
object, just unprotect and append to the object. I think the kernel 
will accept that. (But, do not reMAKE the standard object!)

btw - were exports "finalized? Remember you posted blog about it. 
Ditto read/write topic (Prunning down the read/write blog ... and 
following talking about read/string)

Man this system is slow.... help!  Let's move this puppy!... I mean 
world.

I really think we need an EXPORT word that make exports easier to 
manage. Simple I think.

You were supposed to do the rewamp, no? :-) Now as Graham produces 
schemes, we will be lazy to redo it :-)

I thought it is slow because I run it from USB flash ... I am in 
Hungary on business trip for 3 days .... :-)

Carl, the design od that was finalized and the work will be done 
this week.

Pekr, do you mean rewamp? Are you sure you're not visiting Transylvania?

(Romania)

B: sounds good.