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

World: r3wp

[Core] Discuss core issues

Steeve
16-Apr-2010
[16352]
See that weird one :)


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple skip to-binary (shift -1 32 - bits) 4
    mask and address xor network = .0.
]
BrianH
16-Apr-2010
[16353]
Andreas, I'm sure my function is flawed - I just came up with it 
right then. Thanks for the fix :)
Steeve
16-Apr-2010
[16354]
rather optimized...


cidr-match?: funct [address [tuple!] network [tuple!] bits [integer!]] 
[
    mask: to-tuple to-binary shift -1 64 - bits
    mask and address xor network = .0.
]
Andreas
16-Apr-2010
[16355]
Heh, that's great Steeve. Esp the ".0."
Steeve
16-Apr-2010
[16356]
yeah,
.0. = 0.0.0 = 0.0.0.0.0 ...
Andreas
16-Apr-2010
[16357]
Yeah :)
BrianH
16-Apr-2010
[16358x2]
Yeah, silly me, forgot about SHIFT :)
That should work on R2 with 32 instead of 64.
Steeve
16-Apr-2010
[16360]
Yup
Andreas
16-Apr-2010
[16361]
Nope. You'd need shift/left on R2
Steeve
16-Apr-2010
[16362]
He knew... :)
Andreas
16-Apr-2010
[16363]
Just a reminder :)
BrianH
16-Apr-2010
[16364x2]
The last time I did IP calculations in REBOL was before 2.7.6 came 
out, so the reminder is appreciated :)
Though your functions do indicate the value of using REBOL's datatypes 
properly. Take note, Pekr, no strings :)
Pekr
17-Apr-2010
[16366x2]
wow, what a bunch of reactions :-) BrianH - I used strings, because 
of original Mikrotik format. They use 10.10.10.10/24 format for IP, 
so it was easier for me to carry around in a string form, then parse 
it later when needed ....


IP arithmetics, and ranges would be 2 nice new datatypes for REBOL 
imo :-)
Steeve - your optimised version for R2 does not work correctly:

>> cidr-match? 10.10.10.10 10.10.10.0 24
== false
Steeve
17-Apr-2010
[16368]
Because it was for R3 only, try this for R2:


cidr-match?: func [address [tuple!] network [tuple!] bits [integer!]] 
[

    address xor network and (to-tuple debase/base to-hex shift/left -1 
    32 - bits 16) = .0.
]

Don't know if it's faster than Andreas's, though
ChristianE
17-Apr-2010
[16369]
(-:-:- = -:0:-) = (0:-:0 = 0:0:0)
Steeve
17-Apr-2010
[16370x2]
-:-
and so:
+:+
Henrik
18-Apr-2010
[16372]
I'm trying to figure out which index comes earlier in two different 
references to the same block and was trying with MIN and MAX, because 
I didn't want to resort to LESSER? INDEX? things.


The result with MIN/MAX doesn't seem to be particularly useful. What 
is the basis of comparison of two blocks when using MIN and MAX?
BrianH
18-Apr-2010
[16373]
Their contents, not their indexes.
Henrik
18-Apr-2010
[16374]
yes, I figure that, but what's the basis for comparison?
Steeve
18-Apr-2010
[16375]
...
ChristianE
18-Apr-2010
[16376]
Their first elements, as in
>> max [0 9 9] [2]
== [2]
Henrik
18-Apr-2010
[16377x2]
are you sure?

>> min [b 1] [b b 2]
== [b b 2]
also because MIN and MAX don't compare on words, so there must be 
a different base of comparison.
ChristianE
18-Apr-2010
[16379]
>> min reduce [word! integer!] reduce [word! word! integer!]
== [word! word! integer!]
BrianH
18-Apr-2010
[16380x2]
MIN and MAX compare the spelling of words in blocks in R3.
And it's not just the first element:
>> min [b b] [b a]
== [b a]
ChristianE
18-Apr-2010
[16382]
Henrik just showed that.
BrianH
18-Apr-2010
[16383]
If the types aren't the same the datatypes are compared, by the arbitrary 
ordering they have in the type list (the datatype number).
Gabriele
19-Apr-2010
[16384]
Henrik: it's the same as SORT
Pekr
19-Apr-2010
[16385x2]
would it be possible to have more operators? In !Mikrotik group, 
I am trying do some stuff for MT routerOS API. Thanks to Anton, I 
can now proceed. When "studying" Python code, I found segment like:

elif l < 0x4000:
     l |= 0x8000


1) they can directly compare 'l of integer type to binary value. 
But I might make wrong conclusion here. But 'l is really result of 
len('string here') operation. But - even if so, I don't miss such 
an automation, as I can always write if l = to-integer #{8000}


2) Second line is more interesting - I did not find precisely |=, 
but found e.g. /= ... and it translates like do some operation, and 
assign. In this regard, the only comparable operator of REBOL is 
++ or --, but in R2 this is just mezzanine, in R3 native. But if 
I am right, their code:

l |=0x8000

R3:
l: (to-binary l) or #{8000}


So, if I would assume 'l being of correct type already (binary here), 
would it be possible to have?:

l |= #{8000}


Hmm, that is not probably compatible with REBOL parser and REBOL's 
assigment operator, which is :
If I am completly wrong, then please ignore me, I am not that much 
into the language design stuff :-) But why don't we at least have 
& for 'and, and | for 'or shortcuts?
Steeve
19-Apr-2010
[16387x2]
What's the gain ?
Anyway, you can create your own alias.
In R3 >
|: :or
&: :and

In R2 >
alias 'and "&"
alias 'or "|"
Pekr
19-Apr-2010
[16389x2]
you could use the same (R3 way) aliasing aproach in R2 too, no?
& and | are easy to add. The gain is to have apply & modify operation. 
Maybe there is no gain ... Simply instead of a = a + 10, you can 
write in python a += 10 in Python.
BrianH
19-Apr-2010
[16391x2]
User-defined operators are planned for R3, but for now you have to 
use one of the existing operators, possibly renamed. If you can switch 
to prefix ordering you are less limited.
If R2 the built-in operators are special-cased in the DO function, 
so you can't do the renaming trick.
Pekr
19-Apr-2010
[16393]
Is there any bits converter in REBOL? Or not even in rebol? I mean 
- how do I get from 255 or FF to "11111111"? :-)
BrianH
19-Apr-2010
[16394]
In R3:
>> to-binary 255
== #{00000000000000FF}
>> enbase/base to-binary 255 2

== {0000000000000000000000000000000000000000000000000000000011111111}
>> enbase/base take/part/last to-binary 255 1 2
== "11111111"


The to-binary part gets more difficult in R2 because of the aforementioned 
bugs in the semantic model.
Steeve
19-Apr-2010
[16395]
R2:
>> enbase/base #{FF} 2
== "11111111"
BrianH
19-Apr-2010
[16396]
Steeve, the enbase isn't the problem in R2, it's the to-binary.
Steeve
19-Apr-2010
[16397]
debase/base to-hex 255 16
BrianH
19-Apr-2010
[16398x2]
To do proper integer to binary conversions in R2 you can convert 
the individual octets of the integer to char and then convert them 
to binary. I'm sure Steeve has more solutions for that though.
As he proved while I was waiting for the post to arrive :)
Pekr
19-Apr-2010
[16400]
thanks .... will try to mess with it. The bug in R3 preventing to 
join binarries is really bad ...
BrianH
19-Apr-2010
[16401]
I just mentioned it in the a98 call for fixes blog.