World: r3wp

#4149 - Pre AGG, line-pattern had problems. I submitted feedback 
on it long ago, but never needed it badly enough to pester RT about 
it.

Ladislav, while it nice to see APPLY being put on the front burner 
(RAMBO 3575), I have a problem with Carl's proposal. His examples 
clearly do not evaluate their function argument (like HELP or SOURCE), 
but this would prevent using APPLY with anonymous functions. It would 
be preferable to require the function to be specified with a get-word 
like this:
    f: func [a b] [a + b]
    a: [1 2]
    apply :f a

For that matter, how would Carl's APPLY handle refinements? Using 
the positional arguments like the rebcode APPLY opcode?

I actually read #3575 before making the #4106 proposal you dismissed 
- that's why #4106 covered those cases in the proposal.

The mapcar extension seems cool though.

If you automatically repeat the apply when appropriate, that could 
lead to some really obscure, hard-to-debug code. An /all option?

gregg, AGG still has issues with line-pattern.

oh... sorry, I didn't realise you where saying that the issue is 
there since a long time.

I guess its a dialect loophole.

#4085 - I think the submitter "-X-" is a certain individual who was 
active around that time (22-Apr-2006) and who was banned from our 
world.

Henrik - can you post your interpreter version here?

(the one which does not crash under OSX)

1.3.2.2.4

anton, is it the same individual who is banned on rebol.org? and 
the ML?

I can't confirm that, but just analyse the language used and you 
can see it's in rant mode.

the email address does not match, so it's not the "antropomorphization" 
guy.

(i really can't see how divide returning decimal would be a show 
stopper though.)

b: reduce [path [()] 1] - isn't this a bug which should be put to 
RAMBO?

BTW, the purpose of the PATH function is unclear to me

I'm not sure if it's bug because it's really hard to guess what should 
PATH do :) It does not return any value, I don't know.

Hi Rebolek, 

that's unfair! PATH quite often returns an error about an "invalid 
path value: ...." ;-)

(I meant, it's unfair to say, that it does not return a value. About 
returning a value that's worth having ... well, that's another can 
of worms altogether ;-)

Ingo you're right :) 
So description of PATH should look like:

USAGE:
    PATH value selector

DESCRIPTION:
     Path selection. Returns error! or nothing.
     PATH is an action value.

ARGUMENTS:
     value -- (Type: any)
     selector -- (Type: any)

the only problem with this description is what is your "nothing"?

it think, that the bug is PATH being exposed

it would be nice to have a working PATH action though (not the current 
one which seems to be an internal thing)

speaking about VID memory leak. "but its some intermittent thing... 
like I said previously, I never got around to tracking it... I only 
know something within VID, especially when creating many stylesheets 
dynamically, eventually grows mem use a lot."

glayout, being a nested VID engine, will effectively call layout 
many times each one might have its own style word calls.

so if you specify many variations of button, for example, it seems 
like if the WHOLE stylesheet is saved separately. over and over.

closing and freeing (setting to none) all code-related references 
to the shown views never amounted to releasing the used up ram.

showing/closing the same windows over and over has even caused memory 
leaks for me.

Alright, these are serious issues, so I would like to set up a demo 
of this and try to isolate.

its not always obvious, but in larger apps (the likes of altme) there 
is a memory increase all the while you play around...

Can you write some quick code which shows the first idea.

I remember that I was able to get the same issues using only VID, 
so GLayout was not the source cause... it was only amplifying a VID/View 
bug.

I can understand it's harder to find bugs hiding out in larger apps.

How to track memory usage within rebol - probably stats...

yess. I will try to write up a very small and unsexy test... give 
me 5

Mmm.. stats is more featured than it used to be.

yes.

the GC in 1.3.2 was improved a lot.

there are MUCH less mem crashes then there used to be.

I think I'll try to make a forever loop and log stats to a file, 
then maybe graph the stats to see what happens towards the end.

(Providing I show any crashes this way).

I was able to allocate 1 million liquid nodes (~ 700MB worth of ram) 
and although the GC slows down a lot after 400MB, it does not crash, 
until  you start missing real RAM.

(its possible the 400MB GC slow-down is system specific, and people 
with newer/better machine with more ram will get the bottleneck further 
away.

Ok, but how does the stylize loop look ? For example:
	forever [
		stylize/master [button: button "hello"]
	]

I am doing something similar, but have not reproduced the actual 
leak yet.

I am hoping I'll find an example which will.

this *might* have been fixed in v1.3.2  although my tests are simple, 
no stylesheet creation is now leaking even one byte!