World: r3wp

instead of having frames not related to a rebol word and  still allocated 
in memory until the GC decides to do he's job ;)

But I also admit my opinion is probably useless until I've studied 
and tested various garbage collection schemes.

Slow ?  slower than what letting the memory as this for sure  !!!!

that's right - slower.

but slower than making a recycle on every show function calls in 
Vid application like what was done in  rebgui  ?? I don't think so 
;)

you're trying to fight the system without coming up with a better 
one, that's all.

What is the true basic problem ?? I have in rebol memory chunks unrelated 
with world on the diccionnary of rebol  and this make the memory 
management just impossible because it dépends on too many things 
unrelated with coding ...

Anton well we are limited basicly be C capabilities If recylcle know 
what to frames to erase it"s normal to ask why those frames are not 
cleared before using new ones ;)

that's logic nothing more ;)

Anton well we are limited basicly by C capabilities If recylcle know 
what to frames to erase it"s normal to ask why those frames are not 
cleared before using new ones ;)

hundreds of line C code are spent into the recycle function but only 
one line could be used free () :)

well i'm too simpling the thing ...

Rebol is not the only one to use GC but it's the only one to give 
coders so little control upon it ;)

C is definitely not Rebol. But consider this:
	a: b: context [data: "love me"]
	a: none
Obviously the object should not be freed yet.

The question is, should a full recycle occur (checking for unattached 
values) ?

I think that would make setting words very slow and degrade performance 
terribly.

(After all, just about every second word in rebol code is a set-word.)

Anton it depends if a; and b; store each the cloned content ;)

No, the object is shared in this case.

>> recycle
>> stats
== 2936994
>> a: make object! [print "I love rebol but not GC"]
I love rebol but not GC
>> stats
== 2937746
>>

and

>> recycle
>> stats
== 2936994
>> a: b: make object! [print "I love rebol but not GC"]
I love rebol but not GC
>> stats
== 2937810
>>

as size are different into the 2 examples maybe the object is clonned 
...

No, they are not cloned. I can assure you of that.

you have it twice in memory but in fact no because if you make a: 
b: make object! [ test: 'test"]

And you should recycle and check stats multiple times before and 
after each test.

then a/test: "test200" print b/test

this shows the content to the shared object change ;)

sometimes the returned stats value is not stable.

Anton both code are witen into 2 separated consol

But we are polluting, I go to Performance group to continue this 
discussion...

if you make a:  make object you use less memory than a: b: make object! 
that's a fact ;)

in rebol there is an allocation table that will allow us to know 
if a data is share betwin several word  in the rebol diccionary

and obviously you will clear only single related data

where in the heck is that damn prompt...

henrik don't know I don't have tested it under linux ...

happens in core too now... no problems with an older rebol/view

Doing any startup scripts ? Check your user.r

no such file. created an empty user.r and now it won't start at all

you're trying to fight the system without coming up with a better 
one, that's all.

 OH OH Comon we are talking about a serrious issue and that's not 
 because I make  a criticise of the system that I have a better solution 
 ....

Did you install the binary into the same directory as your other 
Views ?

yes

shadwolf -> I meet you in "Performance" group

mmm.

ypu can say I hate capitalism because it makes  little people very 
ricth and most of the people just poor  without having a rechange 
solution ;)

running scripts directly as an argument works....

debian? you lack a config-file for teminal which name i forgot.

There's a quick workaround maybe - run a "halt" script. Does it give 
a console then?

termcap?

its in some old package for backward compatiility

shadwolf: try setting all inbuild functions to none and see if the 
system needs less memory. maybe that helps

ah... let me check...