World: r3wp

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.

means the are same, even when created by mutiple inserts. Makes sense 
 to  do that  and  share an internal pointer.

Thought that wouldbe hard to fix. If it can be fixed easily its  
a bug.

Hmm, Volker -- maybe it is subtle undocumented behaviour:
a: charset ""
b: charset ""
same? a b
== true

insert a 1
same? a b
== false

insert b 1
same? a b
== true

I would vote for a bug too. Although charset uses the same source 
"unbound string", result of 'charset evaluation is stored to the 
same memory location, and referenced by two words?

>> a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b"  probe 
same? a c  insert a #"c"  ? a ? b ? c
true
A is a bitset of value: make bitset! #{
0000000000000000000000000E00000000000000000000000000000000000000
}
B is a bitset of value: make bitset! #{
0000000000000000000000000E00000000000000000000000000000000000000
}
C is a bitset of value: make bitset! #{
0000000000000000000000000600000000000000000000000000000000000000
}

Bug. Fix:   a and b share something which then has a pointer  to 
the bitset.  The pointer to that something should be  compared, notthe 
pointer  to the string.

uh, even when  using copy charset "" still 'same? returns 'true? 
Now I am lost ....