World: r3wp

Good news!
So you have a few days to fix the recycle problem for real :-)

actually I'm going to look at a printerserver, which deadlocks, if 
two people are trying to print too close to eachother.

it's quite simple, I think it was based on some cookbook code. moving 
to ports for that...

this is an annoyance ... but 'to-local-file drops the trailing slash 
for directories

confirmed under OSX

Rambo it ??

yep

Ok

it's not a problem the other way around, so yes, it's inconsistent.

Done.

Henrik, I see regular "Crash Should not happen" on one of my scripts, 
so you are not alone.

anyone willing to find a way to reproduce it?

I don't have anything trivial that will trigger the bug. It's a big 
application that can run for a while before crashing....And the code 
has been tweaked to minimise the occurrence of the problem.

i feel the pain - same problem i had with chord.

but at this point (focused on R3) RT does not have enough resources 
to debug a big app.

well, if it's about memory allocation and clean up, would there not 
be a way to torture it? What's the worst possible way to stress the 
garbage collector?

recycle/torture

but i guess it won't show in that case...

something that randomly creates a large amount of blocks, inserts, 
deletes, manipulates, copies and does various other things.

just found, that youtube do not respect HTTP1.0 protocol => sends 
HTTP1.1 303 response even if client require HTTP1.0 (which is Rebol 
case). As there is no response specified for 303 in Rebol's http 
handler, it can be fixed using:

use [tmp][

 tmp: select second get in system/schemes/http/handler 'open to-set-word 
 'response-actions
	if none? find tmp 303
	insert tmp reduce [303 select tmp 302]
]

whith the patch above you should be able to do for example:

trace/net on

p: open/direct http://www.youtube.com/get_video?video_id=FVbf9tOGwno&t=OEgsToPDskKR0Ng6kANs3Z4VNG81T2tZ
error? try [close p]

(Reichard: will be fixed the Altme bug which cripples text with long 
links?)

it should be easy imho

there is a silly bug in my patch, it should be:
use [tmp][

 tmp: select second get in system/schemes/http/handler 'open to-set-word 
 'response-actions
	if none? find tmp 303 [ insert tmp reduce [303 select tmp 302] ]
]

Oldes, note that you can do this, which looks clearer to me:

select second get in system/schemes/http/handler 'open [response-actions:]

Oldes, how do you classify this patch ? Is it simply improving Rebol's 
HTTP 1.0 scheme, or is it half-way sliding towards HTTP 1.1 ?
(ie. does the official HTTP 1.0 spec contain a 303 response ?)

(if not, then this should be called a "workaround patch" or "temporary 
migration patch")

it's patch for buggy foreign servers... as server should not return 
HTTP1.1 response if client requires HTTP1.0

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.