World: r3wp

I would never do the first, because there is no close to be seen 
for every open.

So you don't really need to copy the port? It's just for a test, 
like:

port: open ....
while [port] [
....
]
close port

sorry, the content.

I give up. :-) gotta get back to coding.

:-) I need to see bigger examples to understand you guys.

ask Carl on Chat. I think that's best. It was his idea anyway.

Geomol: I wonder why you have a problem with 'also now. It was discussed 
on 10-Aug-2007 on r3-alpha in new-functions group - and you were 
one of the people who were in this discussion

Yes, I then said, I didn't see the need for it, but I suggested a 
good name. Now 1.5 years later, I still don't use it. I'm asking, 
if people use it, because if I see good use of it, I hope to use 
it myself.

I'm not using it.. I'm not coding in R3 yet. Also when I test 'also 
now, it looks that there is no speed gain.

Huh..  I didn't know there was an 'also - I defined my own function 
long ago that does what it does

I've used it in a couple places, almost always having to do with 
ports - it is much nicer than spanning 3 lines for the same thing

Do you have any code, I can see? To see how you use it.

John, consider if you have a local variable in a function.  Then 
calling also can clear that local variable.  This is what I use 'ALSO 
for the most and why it is way cool.

It is way cool when the item your returning is the very item you 
want to clear.

And why do you want to clear it? To save resources? But what then 
with the version, you return?

Yes to save resources.  For example, what if I just read an MP3 file 
into a word? I want to free that word so that it no longer is allocated 
to that data.

If you want to load more MP3s, it would be a good idea to reuse the 
same memory area. An example:

>> f: func [/local blk] [blk: []]   
>> a: f
== []
>> insert a 42
== []
>> a
== [42]
>> source f
f: func [/local blk][blk: [42]]
>> clear a
== []
>> source f
f: func [/local blk][blk: []]


You see, A and BLK inside F points to the same memory. Next time 
you call F, you can put some more stuff in BLK (read another MP3).

If you want to be able to completely remove BLK, I would do that 
using an object. Build the MP3 player as an object, instead of just 
a function. Makes sense?

Sure, John, but what if you don't want to load more mp3s?

Of if between loading mp3s you have other functions that are operating 
and you want to ensure that your keeping memory use at optimal levels?

I see no alternative to having the functionality of ALSO in those 
cases.

You still have to set the MP3 data returned from your function to 
none to release the memory (making the garbage collector to work). 
I would handle this situation either by making a refinement to my 
function or (probably better) creating the whole thing as an object.

that is what we do with ALSO, we set the return item to none.

also mp3data mp3data: none

f: func [/clear /local blk] [
	either clear [
		blk: none
	] [
		blk: []
		comment "do something with blk"
		 return blk
	]
]

But your memory isn't cleared by using ALSO! You still get something 
back from your function. You have to clear this later in your code.

no you don't have to.  The garbage collector will take care of that.

The also function should be used as the last line of your function.

I gotta run for a bit but will be back in about an hour or sooner.

Yes, I understand that. What I don't understand, is how you call 
these functions, and what does on with the data, you get returned 
from your function. Do you have code examples online, I can look 
at?

what *goes* on ...

Using ALSO returns some data. If your code look like this:

mp3-data: load-mp3-function


and that load-mp3-function ends with an ALSO, setting the local var 
to none, you still have a full copy in mp3-data. Actually you end 
up having 2 copies for some time, until the garbage collector frees 
the local version. Later in your code, you need to set mp3-data to 
none to free to memory (which the garbage collector does). Now, is 
this how you use ALSO and why you need it?

Most of mine are for conciseness - for example, when no data needs 
to be returned:

Client: first wait Listen
Data: also (copy Client) (close Client)

but, like before, say that happened in a function

Process: func [Client][
   ..do stuff..
   return also (copy Client) (close Client)
]

Client: first wait Listen
Logfile/add Process Client

I'll look for some actual code I'm using soon

Pread: func [URL /local Port][
   Port: open/binary URL
   Port/timeout: 3 * 60
   return also (copy Port) (close Port)
]

What happens, if the connection fails?

Does my version work the same as yours beside the timeout?

newPread: func [URL] [read/binary URL]

And can the timeout be set somewhere in the system object?

f: has [file][file: read %somefile also copy/part file 30 file: none]

My guess is, that your version using ALSO use the double memory, 
that mine does (because of the copy).

Paul:

f: does [copy/part read %somefile 30]

John, yes true but what if you want to do several things with the 
local in the function?  Are you going to copy it every time?

Then do:


f: has [file] [file: copy/part read %somefile 30 comment "do something 
with the file" return file]

Yeah my example used copy so that might defeat it.

f: has [q][q: [] append q read %blah remove/part q 20 also q q: none]

That doesn't work. your local q holds data after returning from F. 
(maybe an error)

>> f: has [q] [q: [] append q "kdfjkd" also q q: none]
>> a: f
== ["kdfjkd"]
>> a
== ["kdfjkd"]
>> source f

f: func [/local q][q: ["kdfjkd"] append q "kdfjkd" also q q: none]

It seems, q has data in the end.

I didn't try it :-)

My opinion right now is, that ALSO sucks big time! :-)
Maybe someone can convince me otherwise.