World: r3wp

Gabrielle, the 307 redirection solved the problem partially, if you 
try to read the url that I put above, you'll realize the problem..

when you try to read the redirected url.. it sends back a forbidden 
message.. it is common with the 307 that returns back also a 401 
message

I think that http scheme should behave as a browser in all aspects.. 
you know..  the http scheme is not complete to simulate all the browser 
functions.. :-( I mean, cookies, redirections etc

Came across this at work today ....

REBOL/View 1.3.1.3.1 17-Jun-2005 Core 2.6.0

>> to integer! ""
== 0
>> to decimal! ""
** Script Error: Invalid argument:
** Near: to decimal! ""


Shouldnt that return 0 like to integer!   ??

Cant see anything in Rambo for it though ...

Must have crept in amongst  View 1.3 changes.

REBOL/Core 2.5.8.3.1

>> to integer! ""
** Script Error: Invalid argument:
** Near: to integer! ""

You would have thought RT's automated tests would have trapped such 
a change.

oh, I just submited bug with the forall and just now found that the 
same bug was already submited

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

if I would like to just skip from the loop, I would use break, not 
return, but understand that carl made the cahnge for the propper 
report on errors.

Gabriele: I submitted a "Read beyond network port" crash ticket. 
(see Recycle bug group discussion)

dont have access to rambo could someone submit an error in the word 
brower for me.  in the find box a down arrow errors with: ** Script 
Error: index? expected series argument
 of type: series port
** Where: pick-next
** Near: sync-funcs-list index? f
show-word first

This is a known and already corrected bug. The new version has not 
been uploaded yet, waiting for other changes pending.

RAMBO 3939: In response to your question, I propose an alternative. 
Instead of changing to-dec and to-int to handle decimal and integer 
(respectively) source values correctly (slowing down the common case), 
add as-dec and as-int opcodes that act as assignments when given 
source values already of the corresponding type, letting those opcodes 
have the overhead when you can't be sure the source is of the opposite 
type. Also, change to-int to assign 0 instead of 1 for invalid source 
values, to be consistent with to-dec assigning 0.0 then.

I don't have an account on RAMBO, so there is no other way for me 
to reply to the question asked of my submission.

For that matter, I just submitted another rebcode proposal to RAMBO, 
and then noticed some code in the fix section that I wanted to change. 
The submitted code still works, but I would still like to clean it 
up a little. If I had an account on RAMBO, would I be able to fix 
my own submissions?

Rambo needs "add comment" section ... I am not sure Carl checks regularry 
here ....

Send it to RAMBO :)

ah, I should read first ... dunno if Rambo allows you to edit your 
submissions ...

You need edit permissions, and that applies to ALL tickets, not just 
yours, AFAIK. So I guess the answer is no.

Gabriele, that's what I thought :(

RAMBO 3939 still has a status of "Waiting".

On RAMBO 3942 in the fix code, in the either statement please change 
the test to empty? labels and swap the code blocks, thanks. It'll 
work the same but will be cleaner. Like this:
        either empty? labels [rule: opcode-rule] [
            label-rule: make block! length? labels

            foreach [key val] labels [insert insert tail label-rule to-lit-word 
            key '|]
            clear back tail label-rule

            label-fixup-rule: [there: label-rule (there/1: 2 + select labels 
            there/1)]

            label-error-rule: [label-rule (error/with here "Cannot use label 
            here:")]
            rule: fixup-rule
        ]

Submitted my proposed alternate to 3939 as a new RAMBO entry. Maybe 
that will work.

actually, it's possible that 3939 will be implemented. to-dec and 
to-int are unlikely to be used in loops, so their speed is not necessarily 
an issue.

this hasn't been decided yet anyway.

What about an AS-INC AS-DEC instead, as proposed above (BrianH) ?

looks like Carl's changing to-int and to-dec instead.

Yay! "Generic" math here we come!

Thanks for the change to 3942 as well. A braino, I forgot about empty? 
for a moment :(

Should I make RAMBO entries for the other rebcode enhancements we 
came up with in the Rebol Enhancements group?

should not be needed.

if you want to summarize the suggestions anyway, i can pass the summary 
on.

There were a couple categories - give me a moment.

i think i passed all of them along, but just to be sure...

Integer operations:
- conversions between integers and binary and back
- bswap opcode for endian conversion

- picki and pokei, like pick and poke but for bytewise access to 
integers

- perhaps allow tuples to be treated like integers for opcode purposes, 
or to-tup/to-int for conversions between them
Word operations:
- set indirect for things like forall, 'a parameters, other uses

- for objects/contexts:  bind ["Bind a variable to a context" word! 
word!]
Struct operations:
- sets ["Set a field value of a struct" word! word! word!]
- gets ["Get a field value of a struct" word! word! word!]
- copys/changes or picks/pokes (see other group for details)

There was also some mention of a lack of orthogonality with get/set 
and copy/change (see group for details), but that may not be as important.

(note: not yet released)
-bswap already there
-tuples and pair access available (pick/poke)
-indirect words already there (setw/getw)
-change will probably take a lenght

What about picki/pokei? I can see putting off struct access until 
structs are put into /Core independent of libraries, but since that 
has been promised it might be better to get support for them in while 
we can.

(sorry, those two sentences were seperate questions)

(I'll be back later)

picki/pokei: dunno. seems related to int/binary conversion to me 
though. i have reposted requests anyway.

Well yes, they could be used for that, but there are other cases 
where integers are used to store packed byte values in binary data, 
and these operations can be translated to single machine instructions 
instead of the 3+ required by their arithmetic equivalents. Carl 
will of course use his own judgement.

is this a known bug??: 

>> a-list: make list! 30'000
>> repeat n 200 [insert a-list n]
>> a-list: head a-list   ;;;  without this line no error is threw
>> clear a-list
>> repeat n 200 [insert a-list n]
** Script Error: Out of range or past end
** Near: insert a-list n

The error isn't threw with hash! nor block! datatypes

ok, I saw Jaime has reported the bug....

so... it seems some spammer has found his way into the bug database 
:-(

yep. but luckily we need to approve each post. :)

Bug 3486 has status PENDING but seems to be already fixed. Maybe 
other bugs are fixed too, but RAMBO says otherwise. Adding comments 
to RAMBO should be really great.

Yep, looks like that one was fixed, i don't know exactly in what 
version though.

regarding #3912

The newest Rebol version displays a different error message

***Panic (should not happen) -Invalid series width 1 was 16 (type 
44)

How near is RT to a fix ?

Try this:

view/new layout [button 233x233]

load read-net http://www.userfriendly.org/cartoons/archives/97nov/uf13b471.gif

Now try this...:

view/new layout [button 233x232]

load read-net http://www.userfriendly.org/cartoons/archives/97nov/uf13b471.gif