r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

Graham
23-Jan-2007
[2515]
perhaps you could fix mine at the same time :)
Pekr
24-Jan-2007
[2516]
Graham - is that correct to open other than 21 port? Maybe so, but 
I never saw that ...
Graham
24-Jan-2007
[2517]
Yes, I've installed Hylafax which uses a modifed ftp protocol on 
port 4559.
sqlab
25-Jan-2007
[2518]
I used 
read ftp://user:[pass-:-host]:22
and
read ftp://user:[pass-:-host]:4567
in fresh instances
and it worked
Graham
25-Jan-2007
[2519x2]
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
Gabriele
26-Jan-2007
[2521x2]
ah... graham, now i see the problem... it's port-id, not port!
port-id: 4559
Graham
26-Jan-2007
[2523x3]
port id ??
oh dear ..
would you delete my ticket then?
Gabriele
26-Jan-2007
[2526x2]
done
:)
Graham
26-Jan-2007
[2528]
thanks
Ladislav
26-Jan-2007
[2529x3]
User poll:
a: charset ""
b: charset ""
same? a b ; == true
do you find it a bug or a feature?
Anton
26-Jan-2007
[2532]
mmm... more of a bug, I think.
Rebolek
26-Jan-2007
[2533]
I think bug, when other datatypes throw false.
Sunanda
26-Jan-2007
[2534]
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.
Ladislav
26-Jan-2007
[2535]
thanks, I personally tend to think it *is* a bug, because they are 
only equal
Sunanda
26-Jan-2007
[2536]
Nice catch, by the way!
That should have been:
a: copy charset ""
b: copy charset ""
same? a b ; == true
Ingo
26-Jan-2007
[2537]
of course, it fits integer! handling ...
>> a: 1
== 1
>> b: 1
== 1
>> same? a b
== true
Ladislav
26-Jan-2007
[2538]
why do you think copy is necessary?
Sunanda
26-Jan-2007
[2539]
i was just testimg how far the (at the time alleged) bug went
Volker
26-Jan-2007
[2540x3]
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.
Sunanda
26-Jan-2007
[2543]
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
Pekr
26-Jan-2007
[2544]
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?
Volker
26-Jan-2007
[2545x2]
>> 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.
Pekr
26-Jan-2007
[2547]
uh, even when  using copy charset "" still 'same? returns 'true? 
Now I am lost ....
Ladislav
26-Jan-2007
[2548x2]
I show you something from my article:

a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical?: func [
    {are the values identical?}
    a [any-type!]
    b [any-type!]
    /local var var2
] [
    ; compare types

    if not-equal? type? get/any 'a type? get/any 'b [return false]
    ; there is only one #[unset!] value
    unless value? 'a [return true]
    ; errors can be disarmed and compared afterwards
    if error? :a [a: disarm :a b: disarm :b]
    ; we need to be transitive for decimals and money
    if any [decimal? :a money? :a] [
        return found? all [same? a b zero? a - b]
    ]
    ; we need to be transitive for dates

    if date? :a [return found? all [same? a b same? a/time b/time]]
    ; we need to be able to compare even the closed ports
    if port? :a [return equal? reduce [a] reduce [b]]
    ; our function has to work for structs
    if struct? :a [return same? third a third b]
    ; we can have something stronger than SAME? for bitsets
    if bitset? :a [
        unless same? a b [return false]
        if 0 = length? a [return true]
        unless equal? var: find a 0 find b 0 [return false]
        either var [
            remove/part a 0
            var2: find b 0
            insert a 0
        ] [
            insert a 0
            var2: find b 0
            remove/part a 0
        ]
        return var <> var2 
    ]
    same? :a :b
]
identical? a b ; == true
identical? a c ; == false
identical? a copy a ; == false
Pekr
26-Jan-2007
[2550]
the question probably is, what we consider being "identical"? Is 
5 in memory slot 1234 identical to 5 in memory slot 4321? It could 
be. But I can also imagine that 'same serves the purpose of finding 
out, if two words reference the same slot?
Ladislav
26-Jan-2007
[2551]
your question is answered in http://www.fm.tul.cz/~ladislav/rebol/identity.html
Pekr
26-Jan-2007
[2552]
ok, thanks, will read it ...
Volker
26-Jan-2007
[2553]
Expected behavior: things  which are modified  when one thing is 
 modified should be same.

Expected Reason for  current behavior:  bitsets with the  same data 
 share the  same data automatically  to save  space.

Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
Expected Fix: comare something else :)
Pekr
26-Jan-2007
[2554]
:-)
Ladislav
26-Jan-2007
[2555x2]
Expected Reason for  current behavior:  bitsets with the  same data 
 share the  same data automatically  to save  space.
 proven wrong above
Expected Reason for bug: 'same? compares the  pointer to  the data, 
which is automatically made same with equal data.
 proven wrong above
Anton
26-Jan-2007
[2557]
Yep, I think SAME? was just quickly implemented using the existing 
equality function.
Pekr
26-Jan-2007
[2558]
then it needs to be fixed, and we need precise definition, of what 
actually 'same compares and decides upon
Volker
26-Jan-2007
[2559x2]
can you make a simpler example, so i can analyze code? My tests say 
 yes, what  do i miss?
The the explanation with equal? makes sensse too.
Ladislav
26-Jan-2007
[2561]
I have proven, that there is a function (IDENTICAL?), which has got 
the following property:
a: b: charset [#"a" #"b"] c: insert charset [#"a"] #"b
identical? a b ; == true
identical? a c ; == false
identical? a copy a ; == false
Volker
26-Jan-2007
[2562]
but  how does itdecide that? If  it is by modifying the data, that 
would be re-samed when you change  the data  back
Ladislav
26-Jan-2007
[2563]
nothing is re-samed, if it were, IDENTICAL? a b would have to yield 
FALSE
Volker
26-Jan-2007
[2564]
hu? a and b have the equal content. so  they would point to  the 
same  data. so  'same? would return true.