World: r3wp

I'll stick with ALSO.  ;-)

Izkata, about the timeout. It seems here, that when the open/binary 
returns, the data is immediately available, so the timeout has no 
effect. I'm on OS X, maybe it's different under windows?

Anyway, I can now see, how you use ALSO with ports. By using a function 
approach, you choose to copy the data out to some further external 
computation. And it's up to the user of the function to free the 
data, when finished. I would take an object approach and store the 
data in the object. Then external computation can work on the data 
in the object. I feel, it's confusing using ALSO, but maybe it's 
just me.

An object approach could look like this:

Ports: context [
	Port: none
	Data: none

	Pread: func [URL] [
		either error? try [Port: open/binary URL] [
			print ["Can't open:" URL]
			false
		][
			Data: copy Port
			close Port
			true
		]
	]
]

Using it would then be:

if Ports/Pread http://www.rebol.com[
	... do something with Ports/Data ...
]

Where I see a potential problem with ALSO, is if you in a function 
load a local var with a huge amount of data, say 1GB. And then to 
release that data ends your function with:
also copy local-data local-data: none


At that moment between the two arguments to ALSO, you have 2 GB of 
data allocated. The first 1 GB is freed, when the garbage collector 
comes to it.

So is this your assurance to us that we will never see ALSO in your 
code?

No no, I never say never. ehh ;-)

Geomol: [Izkata, about the timeout. It seems here, that when the 
open/binary returns, the data is immediately available, so the timeout 
has no effect. I'm on OS X, maybe it's different under windows?]

I'm on Ubuntu  ;)  but yeah, now that I think about it, that's true. 
 Originally it was written differently, and the error appeared to 
be on the copy.  I added it when mininova was timing out on certain 
requests due to high load - it seemed to make a difference then, 
but I don't know if it was coincidence or not.

mininova ? torrenting?

Yeah, the internal function that RSS plugins on Azureus use broke 
at some point, so I'm doing it this way now.  Much nicer, as I can 
collect more information, etc

If you're thinking I'm making a torrrent client in Rebol, not yet 
 ;)

I suspect R2 is not up to it ...

Probably not, but it would be interesting to try

Then again, R2 has surprised me with my current project

networking is not a strong point

Geomol, your last "potential problem with ALSO" is not exclusive 
to ALSO. It's a potential problem anywhere COPY is abused by a programmer 
not knowing what's going on.

The way to return the large amount of data and to release the local 
from it is of course like this:

	also local-data local-data: none

load-mp3-data: func [file /local contents][
	contents: read/binary file
	; <- modify contents here
	also contents contents: none
]

data: load-mp3-data %song.mp3

so this frees contents??

just to say there is no need  anymore to unset the local vars in 
R3

In the load-mp3-data function above, a large binary series is loaded 
and contents set to refer to it. The ALSO line returns the binary 
series and unsets CONTENTS so that it no longer refers to the binary 
series. The usage code below the function definition takes the return 
value (the binary series) and sets DATA to it.

So effectively the variable referencing the binary series has been 
switched with another one.

(Steeve, yep.)

Graham, no, it just "unhooks" the local word CONTENTS from the binary 
series data.

Which is a good thing to do, because now the function does not maintain 
a reference to the large binary series after it has been called.

If the contents var is not unset and then the load-mp3 function is 
not anymre called.

Then, the garbage collector can't free the serie because it stays 
handled by the local var contents.

Hmm.  So, one should deference local vars if they pointing to large 
data sets?

dereference

yes, In R2 we should

Steeve, yes, that's right.

didn't know that ...

Yes, in R2, functions don't bother to unset their local words on 
function exit. This was done for speed reasons. Most functions don't 
need to unset their locals.

I wonder if that would help with the problem I had before when I 
was doing OCR on image data .. and kept getting crashes

Where you running out of memory?

no

*Were you..

If I turned off recycle, the problem disappeared, but then memory 
eventually would run out

That was more likely some external library call problem.

not using external libraries

I was posting the data to a web server

web service

That was a memory leak, not really caused by the "local vars not 
unset on R2 function exit" behaviour. (But perhaps contributed, by 
misunderstanding, to the leak bug.)

Yes, Graham we need to clear those locals by setting them to none.

I use ASLO in R2-Forward for that reason - that was the original 
reason ALSO was suggested. You don't need ALSO for that in R3 since 
the locals unset themselves in the new function context model, but 
it is useful for closing ports and changing directories back.

Brian, are the parameters in R3 also unset in R3?

R3 has stack frames, so the entire frame - including the locals - 
is tossed after the function returns.

Closures are different though - a whole new context is created with 
each call, words and values both.

Closures are for doing "memory leaks" on purpose :)

Will we get any control over the stack?  So that we can potentially 
perform recursive operations without overflow?

Unlikely, since most tail recursion optimizations require an optimizer, 
or at least a compiler. Manual access to the stack is a security 
hole (unless the language is Cat). Accept that REBOL has real loops 
and that imperative programming is more efficient in an interpreted 
language :)

REBOL was designed to be interpreted efficiently. Don't compare it 
to languages that were designed to be compiled (like Haskell) or 
languages that aren't designed for efficiency (like Scheme).