World: r3wp

I think the second one should also produce an overflow error, since 
a correct result is too large for an integer!

#3520 seems to work OK now (rebol/version == 1.3.2.3.1), so we should 
mark it as solved, shouldn't we?

aha, the add issue above is already in RAMBO as #3839 (by Jaime)

view layout [area mold system]

the text would include this  area the  next time, then include a 
text  which inlcudes the lastlast text and so on?

regarding #3520 once again:

to integer! -2147483647.9 ; == -2147483648
to integer! -2147483648 ; == -2147483648
to integer! -2147483648.1
** Math Error: Math or number overflow
** Near: to integer! -2147483648.1

sorry, to integer! -2147483647.9 ; == -2147483647

ladislav: yes, please mark it as built. (i think we could mark it 
as tested too, if everyone agrees)

and, Gabriele, what do you think about the to integer! -2147483648.1 
issue? (it may be related!)

...if I evaluate an expression supposed to yield -2147483648.0 but 
obtain a "slightly different" result, then the conversion may still 
not be possible due to the fact, that the overflow is a bit "premature" 
in this case, because -2147483648.1 actually *can* be converted to 
-2147483648 without any overflow

but because it cannot stored in a loaded block, should we allow it 
anyways?

do not understand your question

can you be more verbose?

hum... I didnt' think -2147483648  was a valid int value... sorry.

but it seems to be.

aha, now it makes sense to me

>> -2147483648  + -2147483648
== 0

this is a bad bug!

I understand the complement and the reason why this is returned (cause 
I've done C before...) but ask any novice and he'll just say this 
is nonsense!

it was marked as "medium" importance, I rised it to "high". It does 
not make sense when all other cases are caught.

-2147483648.1: i guess this should be fixed too.

I created a new RAMBO ticket

yes the internal type switch really is annoying, especially when 
you are parsing blocks and types are assigned specific values.

or rather specific meanings.

today I found small bug - well, did not know it is a bug, Cyphre 
just confirmed it - pre 2.7 Rebol versions require callback!, whereas 
2.7 version accepts only callback, but not callback! - the bug was 
probably introduced with string change for 2.7 ....

I have already posted it to Rambo.

just looking at it - it looks, that you inadvertently used the same 
line twice, should I edit it for you?

ah, my fault..please remove the #"!" in the second case, thanks ;)

done

#4227

Is there a bug in the ftp protocol?  I tried opening a different 
port viz 4559, but it still opens up on port 21.

Well, there is _at least_ one bug in the FTP protocol.  I haven't 
run into the one you are talking about, but I think I did solve the 
one that I was having a problem with (425 response from the server 
causing Rebol to wait infinitely).

opening a ftp port using the scheme: 'ftp and port: 4559 still opens 
up port 21 according to trace/net

Going to rambo this ...

Bo, I didn't see a rambo ticket for your bug, or the fix posted.

I'm still testing my fix.

perhaps you could fix mine at the same time :)

Graham - is that correct to open other than 21 port? Maybe so, but 
I never saw that ...

Yes, I've installed Hylafax which uses a modifed ftp protocol on 
port 4559.

I used 
read ftp://user:[pass-:-host]:22
and
read ftp://user:[pass-:-host]:4567
in fresh instances
and it worked

That's interesting .. it works that way, but not using [ scheme: 
'ftp port: 4559 host: 192.168.1.252 user: "user" pass: "password 
]

>> read ftp://Graham:[password-:-192-:-168-:-1-:-252]:4559
URL Parse: Graham password 192.168.1.252 4559 none none
Net-log: ["Opening" "tcp" "for" "FTP"]
Net-log: [none ["220" "230"]]

Net-log: {220 localhost.localdomain server (HylaFAX (tm) Version 
4.2.1) ready.}

which is working, but trying this ..


>> port: open [ scheme: 'ftp port: 4559 host: 192.168.1.252 user: 
"Graham" pass: "password" ]
Net-log: ["Opening" "tcp" "for" "ftp"]
Net-log: [none ["220" "230"]]
Net-log: "220 Microsoft FTP Service"
Net-log: [["USER" port/user] "331"]
Net-log: "331 Password required for Graham."
Net-log: [["PASS" port/pass] "230"]

doesn't because the MS ftp server at port 21 is answering instead

ah... graham, now i see the problem... it's port-id, not port!

port-id: 4559

port id ??

oh dear ..

would you delete my ticket then?

done

:)

thanks

User poll:

a: charset ""
b: charset ""
same? a b ; == true