World: r3wp

Nah, my understanding of load didn't change. I can't have a string 
with double quotes across lines. But I still can't see, why my t 
get the extra hat (^).

that's too easy, Geomol. You have to find out, why 
    length? "^^" ; == 1
, as well as how the look of
    mold "^/"
is related to the look of
    "^/"

, i.e. how would you write a string containing exactly the characters 
listed on the line below

    "^/"

(four characters)

Well, as I understand MOLD, it will create a string, we can LOAD 
in again. If the original holds a newline outside any string, it 
should just be kept as a newline, shouldn't it? REBOL can LOAD newlines, 
which are seen as white space (like the space character). Maybe tab 
is better to illustrate, what I mean:

>> mold {^-}
== {"^^-"}


I get a result string holding 4 characters, while 3 is good enough. 
When I LOAD this result, the two characters #"^^" and #"-" get changed 
into one tab. Why? And why does MOLD produce 4 characters in the 
first place?

when debugging these things you should always use probe... its more 
consistent, since it always shows the "escaped" value of a string!

(just something I've come to do through the years.. never rely on 
print)

MOLD simply escapes everything so you will not end up with string 
like {^} which is not REBOL-readable.

 If the original holds a newline outside any string, it should just 
 be kept as a newline, shouldn't it? 
 - no!

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.

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"

Maybe the problem lies in the fact, that we can create strings in 
two ways, using " and {}.

(no newline char, you see?)

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 {^{^/^}}
== "^/"

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.

oki, I just wanted to know, if there was some problem in here, I 
didn't see.

The creating the strings two different ways isn't the problem in 
this case, it's double escaping.

..., and, as far as I know, the escaping of #"{" and #"}" has quirks 
in R2 (does not work well in the console)

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 "^/"
== {"^^/"}

So maybe I should ask, why do LOAD double-load?

It doesn't. It loads once (at the command line), then *you* load 
a second time explicitly.

And if this is in a script, and not at the prompt?

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, "^-" -> {"^-"}.

I think, it can be done more efficient, but I may be wrong.

It was the same in R2, though LOAD was native (and incredibly buggy) 
instead of mezzanine (and more capable).

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

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 
:(

Can I somehow get volume name?

Probably by using GetVolumeInformation from kernel32.dll

http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvb/thread/51a0c190-05d0-4d36-b679-b2ae470e622f

ok, thanks ... I thought that maybe there is some get-modes trick, 
but there is probably not :-)

FSUTIL is your friend. I have a REBOL wrapper if you want.

fsutil fsinfo volumeinfo c:\

thanx!

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 ...

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.

>> (-1 xor (to-integer 2 ** (32 - mask-range)) - 1)
same thing than:
>>shift  -1 mask-range