World: r3wp

I'm studying memory usage and recycle for a bit. Whenever I'm adding 
a block or doing an operation, REBOL might consume small chunks of 
memory continuously, like 16-32 kb per second. whenever recycle is 
applied, it just stops. Why is that?

I don't know, but I've seen similar allocations that continue over 
time and then seem to stop.

I must point out that recycle specifically was turned off and so 
the number would just keep growing for hours eating up 100s of MB. 
Recycle is probably normally invoked, if you don't specify that it 
has to be turned off. The fact that the memory usage just keeps growing 
in an idle situation seems just like a memory leak to me.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlPSTK
<--- I can't find this old bug in RAMBO, and it still crashes REBOL.

a: [ append a [+ 1] 1]

loop 1000 [ print [ do a newline ] print [ "Block length: " length? 
a "Bytes used: " ((length? a) * 16) ] ]

henrik, with recycle/off, no memory is ever reused, and obviously 
rebol is constantly allocating memory for temporary values and so 
on. so used memory grows. when you do a recycle, the gc will collect 
all the garbage and start reusing it for later allocations, so that 
memory used stops to grow until you get to the same point as before 
and rebol needs more memory.

recycle never releases memory to the system (afaik) because that's 
usually inefficient, better to keep it for future usage.

Thanks for the explanation

never? maybe it would be good to have some way how to force rebol 
to release what does not require from time-to-time. That's probably 
the reason why my nonstop running server requires 5MB instead of 
3MB when was started.

I just think there should be better clarity on what are do's and 
don'ts in terms of how to preserve memory and have a stable application 
at the same time. Some apps of mine never eat more than 3-5 MB RAM, 
while others eat 250 MB RAM, and I don't know what causes it.

Oldes, unless the OS is really broken there is no need to release 
memory, because unused memory just gets paged out.

Gabriele, could you please add this note to #3867:

Update: I now understand that the events trickle down in a dynamic 
fashion and it cannot be known (for certain) at the beginning whether 
an event will arrive at a particular face, as DETECT functions along 
the way to the face can alter the route. -Anton

And I think the Importance should be lowered from Critical.

i think there was a reason for it being critical... hmm.

anyway - you're right, but even though the target face may never 
be reached, if it is known already it would be good to have it there 
for many reasons.

why couldn't 4275 be fixed?  Should be easy enough!

because the ticket was created much after the list for 2.7.6 was 
created :-)

oh :(

Why can't we get a directory requestor?

system ...

maybe we should follow reichart's bug fixing rules... but i can't 
redo the list ten times...

when is the next bug fix cycle?

dir req.......... R3.

who gets to see R3 on the first of Jun ?

next bug fix - no idea. depends on Carl's time.

i don't think there's a fixed list that has been written yet.

Ahh.. the Carl bottleneck problem.

(personally i want it to be dynamic. like adding people when i have 
some vid stuff to show.)

So, is chord ready for R3 ? :)

i actually want to  try that out before july... but not sure i'll 
have the time.

Shall I create a R3 list here then ?  :(

:)

R3 list initial release - BrianH, Anton, Volker, Henrik, Ashley, 
Graham, Gregg, Dockimbel, Sunanda, btiffin ... simply ppl who are 
skilled, and/or actively use Rebol with own projects ...

sorry if I forgot someone :-)

ah, wait, I forgot myself :-)

hmm, well, I can wait till late release. But - I don't like the attitude 
already - "like adding people when i have some vid stuff to show" 
... that simply sucks

we are going thru the same attitude over and over again, for many 
years. First RT blogs, asks, debates, then closes the door and comes 
up with something,not asking if we like it or not ... then complaining, 
that we complain ;-)

IIRC, there should be VID+ group, which was supposed to discuss what 
direction new VID should go. There is many talented ppl with various 
povs here, who could influence some decision in a good way imo ...

All right.  Two Brians...We win.

But Pekr;  RT has to be careful with this.  Giving it out to too 
many will just generate

too much noise...  I'd gladly take my name off the list and wait, 
as to not overwhelm

those in more appropriate positions...I'd rather get handed Government 
Reject Unfit

for Normal Training work.  Not that it isn't a nice shiny carrot 
dangling ever so close

to the nose.  And, being a little schizoid, I also agree with you.

I surely hope you allow us to nominate you for Secretary of the (proposed) 

REBOL User Group. The (proposed) Executive Summary could definitely 
use your
candor.  :)

petr, remember the open view 1.3 project? the problem it didn't get 
anywhere (despite producing a lot of good code) is that Carl does 
not work that way. we can only aknowledge it.

r3 will be open enough that people will be able to work on it without 
Carl's intervention. but for things that require Carl's intervention 
we follow Carl's rules.

btiffin - only if group takes some sensible name :-) all those RUGs 
etc. remind me of linux or amiga groups, noone can depict the acronym 
and it sounds ugly, actually nothing I would like to wear on my T-shirt 
:-)

Gabriele - you talk about two distinctive things, but we shold probably 
move from this group.

Gabriele,
Can you please take a look at these 2 submissions:

http://www.rebol.net/cgi-bin/rambo.r?id=4274&
http://www.rebol.net/cgi-bin/rambo.r?id=4161&


I am desperate because center and left aligned text can not be edited.

Ca you please help?

I convinced myself and 2 others to go REBOL with a small but important 
app I need, but simple stuff like this kills the idea.

Have to agree with Pekr about naming issues!! Let find something 
sexier that anyone would be attracted to 8-).

You meant, center and *right* aligned text can not be edited.

But yes, this is a long-standing bug, and it's annoyed me a few times.
Actually, this is something that *could* be worked around.

We just need to figure out how caret-to-offset and offset-to-caret 
work, then write mezzanines to replace them. I've been meaning to 
do this for a while.

Dear Anton,

A mezzanine, that's it. 
I can not tell you how frustrated I am.

See my response to Gabriele below:
Thanks for the info.


It is so sad to see that "little" things are not fixed in a reasonable 
fashion.

Here I am, 99% of my stuff is Center aligned and I find myself "regretting" 
that I go for a "not so established" language.
(never thought that entering text in a box will be a problem)


I have to actually ask 1000 people to klick 4 times more often, just 
to overcome a stupid bug.
So I ask them to:

Change to left align
Edit
Go back to Center align

Repeat as long as needed and pardon, I used "REBOL"

Best regards


So, what is needed to fix this, please let's include Ashley

Thanks a ton for the shimmer of light I see at the end of the tunnel
Peter

Forgot to include Gabriele's response.
The short form is 
Yes, known for ages
No will not be fixed (in 2.7 there is)
Yes the glorious R3 will (probably) fix it

Known for ages and won't be fixed .... :(

;Not perfect, but less clicky
view layout [
    style cfield field center feel [
        redraw: func [face act pos] bind [
            if all [in face 'colors block? face/colors] [
                face/color: pick face/colors face <> focal-face
            ]
            foc?: same? face system/view/focal-face
            face/font/align: either foc? ['left] ['center]
        ] system/view
    ]
    cfield "hello" with [focus self]
    cfield "cflied2"
    cfield "cfield3"
]