World: r3wp

not -> note

Don't want to add too much, but with parse you can really build up 
a vocubulary based on the patterns you know:


 section: [integer! ["." | 1 4 ["." integer!]]] ; -- or whatever rule 
 covers all permutations
	chars-sp: charset " " space: [some chars-sp]

	parse/all [copy sn section space [to newline | to end]]


Vocabularies are easy to wrap in their own context too.  Note also 
that [integer!] is a shorthand for [some digit] -- very useful : 
)

Oldes, thanks for your suggestion. It works when I do a simple one 
line rule as you suggested but when I try to use multiple rules it 
fails.

Example of what I'm trying to do:
Example of the text document:

3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS


3.1 Aluminum ladders are divided into two basic types of construction, 
viz:, solid beam and truss.


3.1.1  Solid Beam Aluminum Construction- This type of ladder has 
a solid side rail construction with aluminum rungs connecting with 
the side rails at fourteen inch intervals. The connection is generally 
either by a welded joint between rung and side rails, or by an expansion 
plug pinching the rung tightly to the side rails and internal backup 
plates. (Figure 2 A)


3.1.2  Aluminum Truss Construction- In the aluminum truss design, 
the top and bottom rails are connected to rung assemblies or rung 
blocks by rivets. The rungs are either welded or expansion plugged 
to the rung plate assemblies, which are supported by the top and 
bottom rails. (Figure 2B)
	

3.2 The base of the portable aluminum ladder is provided with either 
steel spikes or swiveling rubber safety shoes and aluminum spikes. 
For ladders equipped with the swiveling device, the rubber pads should 
be utilized when the ladder is to be raised and used on hard surfaces. 
(Figure 2A, 2B)
 3. CONSTRUCTION OF PORTABLE ALUMINUM LADDERS

space: charset " ^-"
spaces: [some space]
chars: complement charset " ^-^/"
digit: charset "0123456789"
digits: [some digit]
section: [digits "." some space]
sub-sec: [digits "." digits spaces]
sub-sub-sec: [digits "." digits "." digits spaces]


rules: [heading some parts done] (where heading is the first line 
of the text file]

parts: [newline | section format_section | sub-section | sub-sub-section]


format_section:   copy sec section copy rest to newline (print reduce 
[sec rest])

If I use format_section code directly with parse it works but  i 
get nothing when I redirect it to another line.


THe above code is similar to what Carl used in his text to html script.

Any reason that the headings with one number have a trailing period 
and the rest don't?

BrianH, sorry BRian the text above is just from a random and simpler 
section of the document.

if I copied the from the begining the first line would not have a 
number at all.

Actually, the inconsistency affects the parse rules. I ask again...

I thought you ment the document heading...

No reason but my rules account for it. The rules work in simpler 
tests..

Are you creating the documents or are others doing so? For that matter, 
does it just go to 3 levels of numbers?

THE docs come from pdf's that I have converted to text and tried 
to reformat by hand to hte similest form whilepreserving the structure 
of the doc. In addition to sections, sub-sections and sub-sub-seections 
there are nubered lists, letter lists, photos/diagrams, and tables 
to deal with. I thought I start with sorting out the sections and 
tackle the rest later.

Well, first of all you need to put the longer matches first in your 
alternates, so they will be tested first.

in the above code the following will work:
format_section:   [copy rest to newline (print reduce [rest ])

but this fails: 

format_section:   [copy sec section copy rest to newline (print reduce 
[sec rest])

longer matches...

This is where I get lost in parse.

What do you mean?

It checks the alternates (sections separated by | ) in order. If 
there is ambiguity, the way to get it to go for the longest match 
is to check for that match first.

so check sub-sub-sections then sub-section then sections in that 
order?

Yes, or combine them (which I will demonstrate).

How does parse evaluate the rule and document?


does it check each rule through the whle doc or line first then goes 
back and checks with hte next alternate? and so on?

section: [some digits (level: 1) ["." some digits (level: level + 
1) | "."]]

Note that I did the longer alternate first.

But I made a mistake.

section: [some digits (level: 1) [some ["." some digits (level: level 
+ 1)] | "."]]

This will give me a hit on any section or sub or sub sub?


I may want to do something different depending on each. does this 
allow me to ?

sorry that is the level:?

Yup.

I'll play with this . Thanks

If you are making your decisions on a per-line basis, you might consider 
doing a read/lines and parsing each line individually, maintaining 
your own state to tell you where you are in the greater document. 
It's the only way to parse documents greater than memory in size.

Well, at least the only way that doesn't rely on deep magic :)

Reminder: [integer!] is shorthand for [some digit] : )

..but only for values between -2**31 to 2**31 -1

>> parse [1] [integer!]
== true

>> parse reduce [2147483647] [integer!]
== true

>> parse reduce [2147483648] [integer!]
== false

String parsing too: parse "1234" [integer!] == true

BrianH, eh? read/lines would still try to read the whole document 
wouldn't it ?

Or are you just suggesting that as a way which is then easily modified 
to allow larger than memory documents?

I think the string parsing behavior might go away in R3 Chris. Without 
support for other types as well, not many people seem to use it.

That would suck -- I use it.  Seems like a common enough scenario....

I mean you can do open/lines/direct and stream - then you would only 
need the memory for one line and a state machine.

Right, that makes sense.

I'm finally digging into parse now, but I have a question about HTML. 
  Big idea:  pulling the data out of an HTML table (made in Word--ugh!). 
 Where I am stuck:  Is there a way to create a rule for opening tags 
such as <tr> that include a lot of formatting:  i.e. <tr style="mso........> 
?   I want to pull the info inbetween the opening and closing tags.

Here is some data:

<tr style='mso-yfti-irow:6;mso-row-margin-left:.18%;mso-row-margin-right:20.4%'>

  <td style='mso-cell-special:placeholder;border:none;padding:0in 0in 
  0in 0in'
  width="0%"><p class='MsoNormal'>&nbsp;</td>

  <td width="23%" colspan=2 style='width:23.6%;padding:0in 0in 0in 
  0in'>

  <p class=MsoNormal><span style='font-family:"Lucida Sans Unicode"'>&nbsp;MNDLDA09Mar03a_e<o:p></o:p></span></p>
  </td>

with the </tr> at the end

I came up with a rule:  [some [thru "<td" thru ">" y: to "</td>" 
(a: remove-each tag load/markup y [tag? tag])]]  but it seems to 
not be as efficient as it could be.

wouldn't you use "copy y " instead of "y:"?

Josh, if you do a load/markup on the whole string, you get a block 
with tags and strings. You can then pick the string from the block, 
maybe doing TRIM on them to sort out newlines and spaces. Like:

blk: load/markup your-data
foreach f blk [if all [string? f "" <> trim f] [print f]]

If you wanna use PARSE, you can do something like:


parse your-data [some ["<" thru ">" | copy y to "<" (if "" <> trim 
y [print y])]]

I've been toying with this to obtain a very parsable "dialect" -- 
my goal being to scrape live game updates from a certain sports web 
site (for personal use, natch).  It's reliant on 'parse-xml though, 
so ymmv....

do http://www.ross-gill.com/r/scrape.r
probe load-xml some-xml

Result is a little like:

	from -- <tag attr="attribute">Content</tag>
	to -- <tag> /attr attribute "Content"

Josh, using the REMOVE-EACH very often is what makes your parse slow. 
A remove operation in the middle of a large string is slow, and you 
are doing many removes. That's why the others suggested using copy.

Thanks for the input.  I will have to play around with those later 
as I am trying to get this finished up and then I can go back and 
clean up the code. The data is minimal enough for the script to finish 
in under a second anyway.   Parse is pretty sweet.   Makes this much 
neater than the alternative

No worries.