World: r3wp

they could just be part of a delayed load series module.  there are 
many missing series handling/probing functions in REBOL.  we end 
up writing them over and over.

remove-duplicates, extract-duplicates, remove-same, prefix?, suffix?, 
etc   the list is long.

how does remove-duplicates work?

like unique?

this implementation is order safe, removing the duplicates from the 
end rather than those in the begining

remove-duplicates: func [
	series
	/local dup item
][
	until [
		item: first series
		if dup: find next series item [remove dup]
		tail? series: next series
	]
	series
]

remove-duplicates, does it in-place

prefix? and suffix? just return true if a series starts with the 
same items in the same order as the second one.  
the second argument is the prefix to compare

so you can easily do:

unless suffix? file-name %.png [append file-name %.png]

the reason these are usefull is that when you chain them within other 
series handlers, you don't need to always add darn ( ) around the 
operators.

so what's the difference between unique and remove-duplicates ?

unique returns a new series.

like all  "set"  handling functions.  (exclude, extract, etc)

I rarely need unique... I often need remove-duplicates.

yeah, it's shame that unique make a new serie.

I was just curious, because even with new series unique is much faster.

faster, but not GC safe

its a shame that all "set" functions make new series.  we could just 
easily copy before calling unique:
new: unique copy serie

Agreed 100%

though there is a lot of memory overhead for large series, I'd rather 
have a refinement on all sets probably   /only  or something similar, 
to have them work "in-place"


come to think about it, maybe we could make a CC wish for this, seems 
like its been a topic of discussion for years, and pretty much eveyone 
agrees that both versions are usefull.

SWAP is another interesting one... takes two series and swaps their 
content, in-place.

I don't see your point with SWAP

INTERLEAVE is a very usefull function, using two series and mixing 
them up with many options like counts, skip, duplicates, all cooperating.

SWAP is interesting, though not as usefull... I don't remember when 
I used it.  ;-0

(that was supposed to be :-P)

anyway, I really think that we should accumulate all of the series 
functions we are using (even the more obscure ones) and make a big 
standard series handler module in R3.  it helps people who are learning 
REBOL since they don't have to figure out as much how to build these 
(somethimes non-obvious to implement) funcs.

this module could even be an internal delayed load extension... which 
can include some functions in C and others in REBOL mezz within the 
extension's module.

steeve, I think I was using SWAP for some sort of sorting using the 
/part refinement.

hehe I just discovered that SWAP is already part of R2 and R3   :-)

though its missing a few refinements to make it really usefull.

Steeve: "faster, but not GC safe" - in some nonstandard sense?

hum yeah, just to say, that lof of memory is allocated.

I know most of peoples don't bother.

I bother a lot  ;-)

But doing a sorting algorithm without any clue about memory alocations; 
is just ... clueless ;-)

well, I do now...

yeah GLASS has some leakages :-)

but not only GLASS, we have the same wory in any GUI engine

several tens of megabytes to just display a simple GUI pisses me 
off

its mostly that liquid caches a lot of things for data, so I'm now 
doing all I can for the processes to hit the GC less and less.
the reason is because it increases performance A LOT.

I know, it will better Max

the issue comes from the internal data model used by Rebol

In the next release of glass, in the TO DO file, I list a few measurse 
to increase performance and decrease ram use by concentrating on 
using as much persistent data than throw away recycling.  but that 
means a complete overhaul of liquid and glob (the rendering engine 
over liquid).

128 bit for a value slot is hurts a lot in some cases

yes.. that grows ram quickly.    but the biggest memory mongering 
in REBOL is the binding.

(by far)

liquid uses class, so its about 100-200 times less memory intensive 
than it would be otherwise.

and this can scale to 400 times faster when ram grows above 400MB 
(the GC is obviously exponentially slower)

I tried your demos with intensive recycles, but the only gain was 
3 MB among 30+ MB

I've done very little actual optimisation in liquid cause it works 
well and the lazyness is very efficient.  the lazyness actually helps 
a lot for GC because a lot of the data is never recomputed, its reused. 
 though because I'm only using one layer, the root frames end up 
composing the entire display a few times.

with 3 layers, I should bring that down a lot.  I'll also be rendering 
on a bitmap directly, enabling clipped region rendering, using only 
a widget's new drawing instead of the whole scene.

the rendering could be faster, but on contrary, more you use layers 
more you  should consume graphic memory