World: r3wp

and slim, which has the same dynamic and static linking capabilities.

...but INCLUDE (in essence) is just a combination of PREBOL and DO, 
so nothing really new

IMHO Carl should use %include.r in the next releases of sdk (R2 or 
R3).

Not invented here
 may be a problem...

...but I will try to convince him

yes Carl does seem to have that trait... which many of us share. 
 ;-)

(that is why we use REBOL ;-) - to  be able to do everything on our 
own

use the angle that is actually simpler to use than prebol... cause 
it really is.

should write that to the discussion page

I do think that Carl is starting to open up to other people's ideas. 
 most of the bad decisions in R1 & R2 where not of Carl's design... 
so that usually makes one weary.

but now that he has a group of like-minded people, changes are much 
lower that we don't think in the same lines.

changes = chances

I think he will accept ideas as long as they are well tested and 
the code is up to his standards.

but the philosphy must also align.  and that is usually where he 
is harder to convince.

it helps if you know his philosophies or if he tells you what he 
wants.

yes indeed.

How do I bind foreach word value to external block? I want to do 
this:

rec: [name last-name adress streeet]

foreach rec data [print [name last-name address street]]

I need to somehow "bind it" :-)

you forgot to mention how your data look

Doesn't matter.

foreach :rec data [print [name last-name address street]]

Use a get-word.

ah ;-)

I need to evaluate our phone provider CSV data for one year. And 
they mix cell phone and normal phone on the invoice, so I need to 
go down and download details. And as it is pread across per month 
files, I want to do simple counter in REBOL. With read/lines ... 
and subsequent foreach line data [ ... parse line "," .....] REBOL 
is really cool to do such data manipulations ...

If you make an object with images, blocks and a lot of data and then 
set the object to none, and the data inside is not referenced elsewhere, 
will everything else inside be properly deallocated?

Perhaps not - 

>> stats
== 67680368

>> a: make object! [

[    b: make block!  1000000

[    c: make block!  1000000

[    d: make block!  1000000

[    e: make block!  1000000

[    f: make block!  1000000

[    ]

>> stats

== 167685587
>> a: none

== none
>> stats

== 167686079

>> recycle

>> stats

== 167685527

interesting, thanks

Which is probably to be expected as the values referenced by the 
fields in the blocks have not been de-referenced. Looks as though 
you'll have to do it yourself:

>> stats
== 167686051

>> a: make object! [                       
[    b: make block!  1000000                 

[    c: make block!  1000000                 

[    d: make block!  1000000                 

[    e: make block!  1000000                 

[    f: make block!  1000000                 

[    ]
>> stats

== 267690882
>> a/b: none

== none
>> a/c: none

== none
>> a/d: none

== none
>> a/e: none

== none

>> a/f: none

== none

>> recycle

>> stats
== 167687087

I'm sure there's a better way but this should work:


>> foreach word remove first a [do join "a/" [word ": none"]]  ;; 
provided your object is called a

this is very interesting. I think there should be an easier way to 
do this.

in R3, 
>>set a none

in R2, that should work
>> set bind first a a none

hmm...
>>set a none
It works for both...

Peter, here's some R3 fun. To do the initial block allocation in 
R3:
    a: make object! 5
    foreach w [b c d e f] [extend a w make block! 1000000]
or maybe this way:
    a: object [b: c: d: e: f:]
    foreach w a [set w make block! 1000000]
To clear your way:
    foreach w a [set w none]
Of course Steeve's method works too, and better :)

henrik: the GC doesn't deallocate on demand... you can have several 
hundred megs of RAM allocated... and sundendly the RAM goes down. 
 and some things do not cause the rebol executables to shrink.


images, in my experience cause memory leaks, where they never get 
de-allocated from RAM under some circumstances.


in theory if you remove all references to a context, its content 
is supposed to deallocate, but when passing anything through view, 
all bets are off.

I've had 400MB pictures stay stuck in RAM, with absolutely no GC 
happening, not even going through view... just loading the image, 
without assigning it... its stuck  :-(

the easiest and FASTEST object clear:  

foreach itm next obj [set in obj itm none]

That next will trip you up in R3 .... but the set can be simplified 
(as per Brian's example above)
   foreach itm obj [set itm none]

that's a nice improvement in R3

oops... forgot the first in there hehehehe

foreach itm next FIRST obj [set in obj itm none]

such "manual garbage collections" should not be necessary in general, 
if there are no references left

well as pointed above, images definitely do not follow the "no references 
left" argument of the GC.

load %some-image.png


not even assigned once... causes a permanent memory use in the last 
version of which I had to use huge images.  I ended up using image 
magic which was able to use the equivalent of 20 GBs of image data 
in a single 75 minute composition.

Previous discussion on subject....Gabriele says memory is never released 
back to the opsys:

   http://www.rebol.org/aga-display-posts.r?offset=-1&post=r3wp152x2970

yes, but that is a different matter

that's quite a problem, but is it possible to allocate space and 
load new image data into that location?

Diffferent, but related......memory may be deallocated within REBOL's 
sphere of influence one the items have no more references; but it 
is not (it seems) dellocated back to the opsys until the REBOL thread 
closes.


That can create several problems ..... eg an application that uses 
a huge peak memory load at startup, and would like to hand it back 
for the next 8 hours of running. It's all in the arena of efficient 
memory management.

There is a difference between loading image using 'load function 
and loading using 'load-image function (which is used by VID). The 
second one stares data in cache.

And I see no problem with the first one:
>> recycle stats
== 4384079
>> x: load %/f/IMG_0783.jpg
== make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E4A35304F3A35483E34...
>> recycle stats
== 7531902
>> x: none
== none
>> recycle stats
== 4384079
>> load %/f/IMG_0783.jpg
== make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E4A35304F3A35483E34...
>> recycle stats
== 7531950
>> recycle stats
== 4384127

Maxim, you said that the problem occurs when the image has been used 
in View. What if the face object that was created for the image was 
not properly unset, like we've talked about above?

Maxim, do you know this:
>> view layout [image %/f/IMG_0783.jpg]
>> second second :load-image
== [%/f/IMG_0783.jpg make image! [1024x768 #{
4E707A59767C5D7172565F5A4D4E464E4A3F554D4258504558494254453E
4F40394E3D364A373148332E...

?? load-image