World: r3wp

BTW, Max: how old is the newest Slim version?

very ;-)  I fixed a little issue with interdependant libraries last 
month, but a part from that it has remained the same for years.

slim is practically the same as module in philosophy, and in many 
areas the same functionaly too.

yes, I remember our discussion about it

I use slim and prebol together within the sdk, it works very well. 
 I should use %include.r though, its much better and would solve 
a few little complexities I have with using the prerebol.r

when I get to working on the linking within distro-bot, I'll use 
%include.r instead of prebol.r... I also want to integreate %run.r 
from rebol.org into it.

it is quite surprising for me, that Carl is not a fan of the PREBOL 
approach, taking into account, that he invented it. I had a version 
of INCLUDE before PREBOL came and adapted it to the PREBOL standard 
afterwards

Carl's mind is too dynamic for static linking.

...but in REBOL nothing is static

prebol is... you have to build your script before executing it.... 
which is why I prefer %include.r

aha, that is what you mean

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