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

World: r3wp

[Core] Discuss core issues

Oldes
13-Apr-2010
[16291]
MOLD simply escapes everything so you will not end up with string 
like {^} which is not REBOL-readable.
Ladislav
13-Apr-2010
[16292]
 If the original holds a newline outside any string, it should just 
 be kept as a newline, shouldn't it? 
 - no!
Geomol
13-Apr-2010
[16293x2]
ok :)
Should LOADing a string be the same, as if I entered the content 
of the string at the prompt? I would expect that. If I write:

>> "^^-"

I entered a string consisting of 2 chars. So loding this:

>> load {"^^-"}

should be the same, 2 characters, but it isn't.
Ladislav
13-Apr-2010
[16295x2]
As said, if the original contains a newline, then it can be written 
as

    original: "^/"


, and the MOLD ORIGINAL expression should just yield a string containing 
the above four characters following the space after the colon
, i.e. two "doublequote"s, one "hat", and one "slash"
Geomol
13-Apr-2010
[16297]
Maybe the problem lies in the fact, that we can create strings in 
two ways, using " and {}.
Ladislav
13-Apr-2010
[16298]
(no newline char, you see?)
Geomol
13-Apr-2010
[16299x3]
Or maybe there isn't a problem, and it's just me. :)
I would expect molding "^/" would produce: {^{^/^}}, 3 characters, 
not 4.
And I see no problem with my way:

>> length? {^{^/^}}
== 3
>> load {^{^/^}}
== "^/"
Ladislav
13-Apr-2010
[16302]
Certainly, that is another possibility, and if you state it that 
way, then, of course, there is a possibility to use that form, it 
is just not the one chosen in the MOLD implementation in this case.
Geomol
13-Apr-2010
[16303]
oki, I just wanted to know, if there was some problem in here, I 
didn't see.
BrianH
13-Apr-2010
[16304]
The creating the strings two different ways isn't the problem in 
this case, it's double escaping.
Ladislav
13-Apr-2010
[16305]
..., and, as far as I know, the escaping of #"{" and #"}" has quirks 
in R2 (does not work well in the console)
BrianH
13-Apr-2010
[16306x3]
When you
>> load {"^^-"}

you are loading the string twice, the first time when you are loading 
{"^^-"} and the second time when you are loading "^-". Each round 
of loading resolves another set of escaping.
When you enter something at the command line it is also loaded.
So when you mold "^/", the resulting string has a round of escaping 
added, and then *that* string is molded again for the console, with 
another round of escaping added for display. This means two ^ characters 
are apparently added, though one is taken away earlier when the initial 
command is loaded:
>> mold "^/"
== {"^^/"}
Geomol
13-Apr-2010
[16309]
So maybe I should ask, why do LOAD double-load?
BrianH
13-Apr-2010
[16310]
It doesn't. It loads once (at the command line), then *you* load 
a second time explicitly.
Geomol
13-Apr-2010
[16311]
And if this is in a script, and not at the prompt?
BrianH
13-Apr-2010
[16312x3]
Then when the script is loaded it will be loaded. And there is no 
difference in R3: Every command entered into the prompt is a separate 
script.
Keep in mind that you are already loading a script: {load {"^^-"}}. 
And then executing that script, which loads another script: "^-".
Sorry, "^-" -> {"^-"}.
Geomol
13-Apr-2010
[16315]
I think, it can be done more efficient, but I may be wrong.
BrianH
13-Apr-2010
[16316]
It was the same in R2, though LOAD was native (and incredibly buggy) 
instead of mezzanine (and more capable).
Ladislav
13-Apr-2010
[16317]
the specific case yes (3 vs. 4 chars), but the escaping of curly 
braces is broken in R2 console:

in R3:
>> {^{}
== "{"

in R2 it does not work
BrianH
13-Apr-2010
[16318x2]
All you have to remember is that every round of loading does another 
round of resolving escapes, and every round of molding does another 
round of adding escapes. And that there is one round of loading when 
you DO a script or do a command line, and one round of molding when 
the command line prints its results.
Hopefully your memory of that is less awkwardly phrased than that 
:(
Pekr
14-Apr-2010
[16320]
Can I somehow get volume name?
Oldes
14-Apr-2010
[16321]
Probably by using GetVolumeInformation from kernel32.dll

http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvb/thread/51a0c190-05d0-4d36-b679-b2ae470e622f
Pekr
14-Apr-2010
[16322]
ok, thanks ... I thought that maybe there is some get-modes trick, 
but there is probably not :-)
Gregg
14-Apr-2010
[16323]
FSUTIL is your friend. I have a REBOL wrapper if you want.

fsutil fsinfo volumeinfo c:\
Pekr
14-Apr-2010
[16324]
thanx!
Pekr
16-Apr-2010
[16325x3]
Did anyone do IP arithmetics? I need to check, if some ip is in correct 
range  :-)


I have e.g. IP 10.10.10.10, and I need to check, if it belongs to 
10.10.0.0/16. I have very primitive (but probably complicated function, 
which can't however count with cases where mask is different from 
8. 16, 24, or 32:

in-ip-range?: func [ip-fw ip-sq /local is? ip-sq-tmp ip-fw-tmp][


  ;--- turn ip-string into block of separated values- removes dots 
  and slash ["10" "10" "10" "10" "24"]
  ip-sq-tmp: parse ip-sq "./"
  ip-fw-tmp: parse ip-fw "."

  mask:  last ip-sq-tmp
  ip-sq: copy/part ip-sq-tmp 4
  ip-fw: copy/part ip-fw-tmp 4
   
  switch/default mask [

    "8"  [either (copy/part ip-fw 1) = (copy/part ip-sq 1) [is?: true][is?: 
    false]]

    "16" [either (copy/part ip-fw 2) = (copy/part ip-sq 2) [is?: true][is?: 
    false]]

    "24" [either (copy/part ip-fw 3) = (copy/part ip-sq 3) [is?: true][is?: 
    false]]

    "32" [either (copy/part ip-fw 4) = (copy/part ip-sq 4) [is?: true][is?: 
    false]]
  ][
     is?: false

     print ["Mas not found: " mask ", the result will most probably contain 
     false positives ..."]
  ]

 return is?

]
calling convetions: is-in-range? "10.10.10.10" "10.10.10.0/24"
ah, should be in-ip-range? in line above ...
BrianH
16-Apr-2010
[16328x5]
Convert to integers (through tuple then binary) and do bitwise operations.
>> ip: to-tuple "10.10.10.10"
== 10.10.10.10
>> ip-as-integer: to-integer to-binary to-tuple "10.10.10.10"
== 168430090
>> set [mask-ip mask-range] parse "10.10.10.0/24" "/"
== ["10.10.10.0" "24"]
>> mask-ip: to-tuple mask-ip
== 10.10.10.0
>> mask-range: to-integer mask-range
== 24

>> mask-integer: (to-integer to-binary mask-ip) and (-1 xor (to-integer 
2 ** (32 - mask-range)) - 1)
== 168430080
>> mask-integer = (ip-as-integer and mask-integer)
== true
That process can be converted to the algorithm for your function:

in-ip-range?: funct [ip-fw ip-sq] [
    ; Convert ip to integer
    ip-as-integer: to-integer to-binary to-tuple ip-fw
    ; Convert mask to tuple and range integer
    set [mask-ip mask-range] parse ip-sq "/"
    mask-ip: to-tuple mask-ip
    mask-range: to-integer mask-range
    ; Calculate mask as integer

    mask-integer: (to-integer to-binary mask-ip) and (-1 xor (to-integer 
    2 ** (32 - mask-range)) - 1)
    ; Is ip within mask?
    mask-integer = (ip-as-integer and mask-integer)
]
Passes testing here, R2 and R3.
Of course FUNCT was added in 2.7.7, so if you use earlier versions 
use FUNC and collect your own locals.
And this version can handle all mask ranges, not just 8, 16, 24 and 
32.
Steeve
16-Apr-2010
[16333x3]
>> (-1 xor (to-integer 2 ** (32 - mask-range)) - 1)
same thing than:
>>shift  -1 mask-range
sorry, I mean
shift  -1 32 - mask-range
not tested though...
Andreas
16-Apr-2010
[16336]
Only in R3, though, where, per default, shift == lshift, in R2 shift 
== rshift.
Steeve
16-Apr-2010
[16337]
ah yes, I forgot
Andreas
16-Apr-2010
[16338x3]
R2 needs shift/left to lshift, R3 rshifts with negative offsets.
And Brian, I fear your function is flawed.
>> in-ip-range? "10.10.10.10" "10.10.0.0/24" ; == true
Which is wrong.