World: r3wp

if you try to mimic c-structures. if you create c from rebol-structes, 
it acceptable. maybe does not really check parameter-types, IIRC. 
but not sure, i rarely need rebol<->c and more rarely make that error.

Is this wine or real windows too?
>> to-money 0.09
== $9.00
wrong with everything with leading zeros.
does not happen on linux.
to-money 1.09 works ok.

Does money string-based conversion and sees windows 9.0000000e-02?
1.09 looks like 1.09000000e+00, so fraction-part is behind ".".

is a conversion-error, $1 is greater than to-money 0.09 .

Works fine under various windows' rebol.exe on my machine.
>>  to-money 0.09
== $0.09

thanks. then wine-bug.

works fine on solaris

Hi Folks

I think that the http scheme the temporary redirection .. server 
error 307 is not at the rebol http_scheme.. the 302 is.. but not 
the 307..

if you try: page: read http://www1.folha.uol.com.br/fsp/opiniao/fz1010200501.htm

it will redirect you to another url from the browser..

but using Rebol, you can't get this new url..  as you could using 
page: open http://www1.folha.uol.com.br/fsp/opiniao/fz1010200501.htm

print page/url  or page/target

you know.. ;)

I think that the same procedure for 302 should be for the 307 server 
error

if you call from a browser it will redirect you to the following 
url: https://acesso.uol.com.br/login.html?dest=CONTENT&url=http://www1.folha.uol.com.br/fsp/opiniao/fz1010200501.htm&COD_PRODUTO=7

just for reference... http://ppewww.ph.gla.ac.uk/~flavell/www/post-redirect.html

I think 307 is not returning the alternative URL.. you know..

RFC 2616
10.3.8 307 Temporary Redirect


   The requested resource resides temporarily under a different URI.

   Since the redirection MAY be altered on occasion, the client SHOULD

   continue to use the Request-URI for future requests.  This response

   is only cacheable if indicated by a Cache-Control or Expires header
   field.

   The temporary URI SHOULD be given by the Location field in the

   response. Unless the request method was HEAD, the entity of the

   response SHOULD contain a short hypertext note with a hyperlink to
   the new URI(s) , since many pre-HTTP/1.1 user agents do not

   understand the 307 status. Therefore, the note SHOULD contain the

   information necessary for a user to repeat the original request on
   the new URI.


   If the 307 status code is received in response to a request other

   than GET or HEAD, the user agent MUST NOT automatically redirect 
   the

   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

So.. How Can I solve this Allen?

(Not tested.)

>> code: second get in system/schemes/http/handler 'open
== [
    port/locals: make object! [list: copy [] headers: none]

    generic-proxy?: all [port/proxy/type = 'generic not none? por...
>> actions: select code [response-actions:]
== [
    100 continue-post
    200 success
    201 success
    204 success
    206 success
    300 forward
    301 forward
 ...
>> insert tail actions reduce [307 select actions 300]
== []

Gabriele, regarding 
http://www.rebol.net/cgi-bin/rambo.r?id=3918&

I found my patches still cause visual artefacts in certain circumstances, 
so this report should be cancelled.
Sorry about that.

(It does demonstrate, at least, how to iterate PROGRESS style in 
a usable way, but I'll better publish that elsewhere.)

I will continue to try to understand the artefacting.

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!