World: r3wp

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.

I couldn't but I see the difference using it.

It seems hard to use, it often result in using twice the memory, 
that people expect. And it might even lead to pad program structure.

pad -> bad

newPread: func [URL] [read/binary URL]  ;  I only want the large 
timeout in this function, not in other 'read calls


f: has [file] [file: copy/part read %somefile 30 comment "do something 
with the file" return file] ; I'm also going for readability, otherwise 
I would have done something like this with the original code

John, actually the piece I think I was showing you the first time 
is what I meant.  The series in the second one is actually desired 
behavior.

f: func [/local q][q: "blahblahblahblahblah" also q q: none]

Is this expected behaviour?

>> f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> a: f
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> insert a "hmm"
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "hmmblahblahblahblahblah" also q q: none]
>> a: none
== none
>> source f
f: func [/local q][q: "hmmblahblahblahblahblah" also q q: none]

Izkata, you got a point with your Pread. But it's not a secure function, 
because it may crash. Let me see, how I would make such a function...

Works for me John

>> a: f: has [q][q: "blahblahblahblahblah" also q q: none]
>> a
== "blahblahblahblahblah"

Now do:
source f

>> f
== "blahblahblahblahblah"
>> a: f
== "blahblahblahblahblah"
>> source f
f: func [/local q][q: "blahblahblahblahblah" also q q: none]

what is wrong with it?

So what does your q: none at the end do? It doesn't release any memory.

I believe it does.  I believe that q will be freed.

You can see, it doesn't this way:

>> f: func [/local q][q: "blahblahblahblahblah" also q q: none]
>> a: f
== "blahblahblahblahblah"
>> insert a "more blahblahblahblah"
== "blahblahblahblahblah"
>> source f

f: func [/local q][q: "more blahblahblahblahblahblahblahblahblah" 
also q q: none]

Look at the source of f. Notice the "more blahblah...."