World: r3wp

Ok, so let me restate the situation:

Due to a buggy foreign server, we are patching our HTTP scheme, which 
declares itself as HTTP1.0, with a part from HTTP1.1.
(I just want to clarify that HTTP 1.0 does not contain 303.)

official HTTP1.0 spec doesn't know 303 response. And there are also 
missing 305 and 307 forward responses.

http://tools.ietf.org/html/rfc2616#section-10.3.4

Note: Many pre-HTTP/1.1 user agents do not understand the 303

      status. When interoperability with such clients is a concern, the

      302 status code may be used instead, since most user agents react
      to a 302 response as described here for 303.

Excellent, that's what I wanted to know, thankyou.

Gab .. are you submitting and then replying to your own tickets?

Graham - actually it might be educative :-)

or pathological :-)

lol - Carl does submit tickets too. it's just to remember about the 
bugs we find.

Copy/part can't use a path! as its RANGE argument

>> path: 'svvc/color
== svvc/color

>> copy/part path back tail path
** Script Error: Invalid /part count: color
** Near: copy/part path back tail path

This is interesting because a path is a series, supposedly very similar 
to a block.

Same with paren!

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 ...