World: r3wp

ah :)

Actually, no it doesn't cause an error. It doesn't download anything 
though.

The request-download bug is a bug in read-thru. Fix the bug in read-thru 
and you fix the bug in request-download.

>> read-thru http://rebol.com
connecting to: rebol.com
** Script Error: Cannot use insert on this type port
** Where: read-thru
** Near: write/binary file data
if all

If the directory doesn't exist in the cache, it creates it, then 
throws an error. If you try again, the directory already exists and 
there is no error, but of course still nothing is downloaded.

I think the wisest thing to do when given a url without a file component 
is throw an appropriate error. I don't advise downloading anything 
because we don't know how the webserver is mapping the url to its 
filesystem (if it is in fact doing that.)

view layout [box 10x50 effect [draw [pen black white line-width 1 
line 1x1 1x50 line-pattern 5 5]]]

This line crashes Rebol/View 1.3.2 reliably under WinXP

at least it does for me. can anyone confirm?

confirmed

Yep, me too.

(crashes without line-width too)

it seems to happen if you are specifying the pen attributes and you 
accidentally include something else, like a drawing command, but 
the drawing command has to be somewhat complete to trigger the bug. 
interestingly, setting the box size to 0x0 does not trigger the bug, 
maybe because the draw block is not performed when the box is 0x0.

it seems also to be only when specifying two colors after pen. I've 
boiled it down to this:


view make face [size: 1x1 effect: [draw [pen black white box 0x0 
0x0 line-width]]]

You can even remove line-width, so:


view make face [size: 1x1 effect: [draw [pen black white box 0x0 
0x0]]]

oh... I already see it in RAMBO as #4086 :-)

won't waste more time on it then

ok :)

; mold/all/flat broken on my ubuntu. Other systems too?
o: context [a: 1] 
probe mold/all o 
probe mold/flat o 
print "pre-crash" 
probe mold/all/flat o 
print "survived"

; WindowsXP
>> mold/all/flat o
== "#[object! [^/a: 1^/]]"

Looks good there. Any other linuxes?

what do you think about #4085, are there many users that agree with 
this POV?

well, I sort of agree on that. While I haven't found any problems 
getting a decimal! returned, the datatype for the result is changed. 
There will always be overhead, if you are changing the datatype. 
I suppose it would be rather confusing to have:

>> divide 1 2
== 0

and having to remember to present one of the values as decimal

>> divide 1 2.0
== 0.5

maybe an 'intdivide could be provided?

I see some inconsistencies when checking integer arithmetic: 


1) DIVIDE automatically yields DECIMAL! when the exact integer result 
doesn't exist
2) ADD and SUBTRACT cause overflow
3) ABS "wraps over" as in: abs -2147483648 ; == -2147483648

4)  REMAINDER caused crash (see #3956), I am observing that the View 
I am using now still crashes (?)

I don't agree with #4085. REBOL gives human friendly responses. There 
are times where I wouldn't mind having an integer division *alternative*, 
but I've gotten along without it so far, and the performance concern 
is hardly a high priority IMO.

Edge cases are very important, but don't affect very many scripts.

does -2147483648 // -1 crash for you now?

Yes.

I get 0 under OSX

no crash

that may be caused by the fact that the OSX uses different C compiler

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