World: r3wp

how do you call the last part of the data, isn't it the same part 
that may repeat more than once?

(divided by comma, of course)

one more thing we need to make agreement on: do we want to rely on 
the default whitespace handling or be more specific and say exactly 
where whitespace may be?

well, it looks, that I will have to run soon

mhinson... If I can encourage you... once you will "get" it... it 
will all become <really> simple.  you mind is just adapting to maping 
rules and seeing the inherent stack of what they imply.  

Don't give up, it will all become clear.  I think we all feel the 
same anxiety at first.  Most don't follow through, its a good thing 
that you persevere.  :-)

the white space is not present in the intresting part of the data 
so would that suggest the default handleing would be ok?

you mean not using /all?

probably yes

yes

the rule

line: [random-part repeated-part any ["," repeated-part]]


just means, that at the start there is a special random-part, and 
then we have more repeated-part's separated by comma

notice, that the comma isn't at the end!

I dont understand why we need the repeated-part in twice?

we didn't specify what exactly is in the repeated-part, so we can 
continue:

repeated-part: [one-to-thirteen "/" a-range]

repeated-part twice: good question. we stated it so, to describe 
the situation, when the quantity of repeated-part's is one less than 
the quantity of commas

because of the comma (",")

sorry, "one more"

there is no comma before the first repeated-part, basically.

ok, bye, it's yours

Probably that would be enough:
line: [random-part any [repeated-part opt #","]]
But it can failed, dependening what is in repeated-part

well, that does not exactly describe what mhinson said

steeve, that means it will not require a comma, which means the repeated 
part can match some wrong pattern

agree, but if repeated part begins and ends with digits, it will 
not failed

hehe its hard not to help new users here.

but it WONT fail when they are missing, in which case your parse 
rules can wreak havoc.

the question there is, can the comma be missing ?

real test data
     3/1-2,3/4,3/7,3/26-30,3/34-38,3/48

3    4/1-2,4/4-13,4/15-17,4/19-21,4/23-25,4/27-28,4/30-33,4/35,4/40,4/48
4/36-39,4/41-47
35   4/29
40   4/18,4/22,4/26,4/34
999  4/3,4/14
disable     4/3,4/5,4/9,4/14,4/19,4/26,4/28,4/34,4/47

but i agree that Ladislav''s rule is more secure

I suppose any data can get damaged, so it is better for the rules 
to crash & burn than hide the fact that the data is damaged

digit: charset "0123456789"
alpha: charset [#"a" - #"z" #"A" - #"Z"]

prefix: [1 2 digit]
sufix: [some digit opt ["-" some digit]]
range: [copy range! [prefix #"/" sufix] (prin ["range:" range!])]

rand: [copy rand! [1 4 digit | some alpha] (prin [newline "random:" 
rand!])] 

target: [rand range any [#"," range]]

parse/all inp [some [target | skip]]

is that ok ?

hmm, random is optionnal, so it should be:

target: [opt rand range any [#"," range]]

/all has to be removed i guess

I think this is what Ladislav has given us so far:
alpha: charset [#"a" - #"z" #"A" - #"Z"]
a-word:  [some alpha]
one-to-two: [#"1" - #"2"]
digit: [#"0" - #"9"]
non-zero-digit: [#"1" - #"9"]
a-number: [one-to-two 3 digit | non-zero-digit 0 2 digit]
random-part: [a-word | a-number | none]


record: [random-part whitespace repeated-part any ["," repeated-part]]


I understand how it relates to the data, but not how to use it to 
extract the bit I want....

what is the data you want? (comming in late on this discussion)

the data is structured with a key words or a vlan number followed 
by ports & ranges of ports. (like 2/2,2/4-6)
I want to restructure this data so I end up with
port 2/2 vlan55 disabled name3
port 2/4 vlan55 disabled name4
port 2/5 vlan88  named somthing else

the generall concept: 

   Once you match data, you add a parens, in which you add rebol code 
   to execute.

first I am extracting the ports & ranges from the data. after that 
I need to recreate the actual ports and key information & do that 
for several types of input & colate it.

if you need parts of the data in your parens, the you add pointers 
to the data within the rules (use copy or here:) and se those within 
the processing parens.

Do you know where Ladislav was heading with his suggestions? I understood 
what he was saying, but not what he was going to do with the structures 
he recomended.

I understand his rules... look at steeve's rules, they already include 
parens, where he lists the data.

that is where you execute stuff.

so you'd just create a block before the parse, and dump the data 
which you want in there, using your new structure.

Am I making sense?

So do you think Ladislav thought he had described everything he needed 
to? because he had a rule that would match part of the data & could 
be skipped on finding each match in turn somehow...

it looks complete for a single record

but steeve's might actually be simpler and already includes the basis 
for what you want to do... it you try his rules on your data?

it = did

I tried Peters rules & Steves first rules, then Ladislav gave me 
some more structure to it which seemed like a good idea when things 
get more complex. But I cant quite fit it all together.

This AltME client is hard work too, why dosn't the group have a web 
based forum, then I could access it on the PC where my development 
is being done too. AltME is a NoNo for corperate use.

reboltalk.com would be a possibility if it wasnt so embarassingly 
full of spam

I think one of the most confusing things about leaning Parse, is 
the occurance of  some & any & | , and the use of [ ]  

the constructs are quite straight forward, but the need for [ ]  
etc is a raw mystery to me.