World: r3wp

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

do you find it a bug or a feature?

mmm... more of a bug, I think.

I think bug, when other datatypes throw false.

Looks like a bug in same -- it comes up even if you add a copy
a: charset ""
b: charset ""
same? a b ; == true
But insert something into one of them, and the same is now false.

thanks, I personally tend to think it *is* a bug, because they are 
only equal

Nice catch, by the way!
That should have been:
a: copy charset ""
b: copy charset ""
same? a b ; == true

of course, it fits integer! handling ...
>> a: 1
== 1
>> b: 1
== 1
>> same? a b
== true

why do you think copy is necessary?

i was just testimg how far the (at the time alleged) bug went

in the  middle. Tried a bit. Same charsets  are compacted.