World: r3wp
[RAMBO] The REBOL bug and enhancement database
older newer | first last |
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. |
older newer | first last |