World: r3wp

Well, I didn't know where to ask this, so maybe here is a good place.
x: load/markup http://www.xanga.com/timwylie/588202056/item.html

then look at x/211, It's a big chunk of tags.  Why?  The only issue 
I can see is that the first tag at 211 has two quotes in a row.  
Any help in fixing this problem?

looks like the double quotes are throwing load/markup off

so it thinks the rest is a big string inside the tags

If that's the case, check RAMBO and submit it if it isn't there already.

We should try to isolate the problem first.

A huge bunch of html isn't very useful. Can you make a small example 
of the problem.

>> load/markup {<span id="xprofimg"">}
== [{span id="xprofimg"">}]

Looks like it can't load it, so just returns the whole thing, unparsed, 
as a string.

Because of the trailing open quote. Remove that and it parses.

Good Gregg. This issue came up years ago. Load/markup only accepts 
perfect input.

Well, that's what I was afraid of.  Thanks guys.  I'll just have 
to parse it another way.

I never found load/markup useful for getting data from html content... 
using just parse is faster and safer

TimW;  Haven't tried it, but check mdlparser.r in the rebol.org library. 
 It make work
round some of the problems.

Yes, you can't rely on html to be well-formed. In my web data extractors, 
I found that brutish, direct methods required less code and were 
less brittle than methods that tried to parse each html tag correctly.

Well, I guess I'll just parse the string.  I'll check out the other 
script as well.  Thanks.

One of the problems is that the format of web pages changes often. 
Web developers don't hand out any guarantee that the format of their 
data in a html page is going to be in the same place all the time. 
eg. I can' t always go to the second table inside the fourth row 
of the third outermost table to get my data, because after all that 
navigation, they might just rearrange the data into the third table 
of the second row of the second outermost table. Arg!

So I usually look for short key strings which are unlikely to change 
to jump ever closer to the data I need.

Yeah, I was actually parsing on the div class sections, but I can 
just as easily ''parse on the class names.  I just liked being able 
to get to the data by throwing the tags away like [thru <div class="x"> 
any tag! copy data string! to end].

I do the same as Anton.  Grab the smallest unique text to bracket 
the content you want using parse first.  I then use load/markup to 
get at the other bits.

I was actually thinking of building a dialect to extract the data 
that I want, but not certain how to proceed with this as each row 
of the table I need to grab although similar is always missing the 
odd element so using element /x will not always give me the same 
data.  I have found approx 10 variations in the data for the tables 
I'm trying to pull the data out of, so not sure if that is the best 
way or not.  Any advice would be great.

here's an example of the type of content I am trying to effectively 
parse.

http://www.nhl.com/nhl/app?service=page&page=Schedule

I was using the length of the returned block after the load-markup, 
but I would likely be better off defining a simple parse statement 
to grab the contents of the rows.

Oh.  that worked great.  I just read the string, found the div tag, 
then loaded it from there and i didn't have to change my code.

Brock;  Check out Daniel's rebol.org submissons...  mdlparser, quickparser 
and 
rblxelparser.  Might be a few hints and tips.

will do, thanks Brian.

I have a question.. 

What's the best way to iterate through a hash/dict! etc looking for 
values to multiple keys with the same name  ie:

n:[one "test1"  two "test2"  one "test3"]

where it returns an array of all 'one' key values?

remove-each [key item] n [not key = 'one]

Of course, you'd want a copy  :)

iirc, newer REBOLs may have other '-each' native! words.

During a Sunanda ML contest, someone came up with a parse solution 
to compacting

...it was fairly blazing in speed, but I got busy after phase one 
of the contest and didn't 
follow as close as I would have liked to.

Check http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlPCJC
for some
details...watch the entries by Romano, Peter and Christian.
The winning code ended up in

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rse-ids.r

It's not the same problem set, but parse seems to be a bit of a magic 
bullet, speed
wise.

I'm completely new to parse...haven't timed it...it probably breaks...
out: copy []
key: 'one

parse n [to key  any [thru key (insert tail out first n  insert tail 
out second n)  skip]]

Im thinking parse is not the way to go.. I'm referring to very large 
hash tables)

; This probably isn't efficient enough either:
remove-dups: func [block [any-block!] /local this-key][

    forskip block 2 [

        this-key: pick block 1
        remove-each [key val] next next block [this-key = key]
    ]
    block
]

; Parse?
remove-dups: func [block [any-block!] /locals this mk mk2][

	parse block [

		any [
			set this word! skip mk:

			any [to this mk2: (remove/part mk2 2)]

			:mk

		]

	]

	block

]

Sorry, read the problem first :)

Chris; :)  I was using the remove-each for it's nativeness.

Terry;  Parse has proven itself to be very fast.  It may be faster 
than
remove-each [key item] copy n [not key = 'one] for large sets

Otherwise foreach [key item] n [if key = 'one [insert tail out reduce 
[key item]]

But I'll bet the parse is faster (assuming it works...that is one 
of my first parse's)

; Parse, this time addressing the spec:
consolidate: func [block [any-block!] /locals key val mk dup][
	parse block [
		any [
			set key word! val: skip mk:
			opt [
				to key dup: (change/only val compose [(val/1)])
				any [to key dup: (append val/1 dup/2 remove/part dup 2)]
			]
			:mk
		]
	]
	block
]

Terry; go with Chris...He'll not lead you wrong.  :)

B: I wonder if 'parse or other loops work faster with hashes?

Hmm.  Good point.   R3 is going to have other native! '-each' words 
right?

um .. not trying to reomve dupes.. trying to collect them all (you 
know, like pokemon cards)

Terry;  Sunanda's contest was using  the parse technique on some 
very large

indexes...for skimp.  A foreach solution was actually the fastest 
for a teenie window of

time, until Romano posted the parse winner.  But...it was a different 
problem set.

It was a very informative contest in terms of efficient REBOL coding.

T: Yes, that's my last function (after I reread your post)

These don't feel right. .. looking for the equiv. of  SQL's  "select 
value where key = 'one'" .. Isn't rifling through a 100mb hash table 
using parse similar to rifling through an un-indexed SQL table?

The rse-ids.r  file seems what Im looking for .. need to have a play.

Yep.  You could sort, find first, find last and copy the range?  
But that introduces sort...

There is a blog entry about hash! but we have to wait till R3.  RSN.


Yeah, there was some high-level optimizing going on for that res-ids 
little beauty.  :)

; one more :)
select-all: func [block [any-block!] key /locals result val][
    result: copy []

    parse block [any [to key skip set val skip (append result val)]]
    result
]

That I like... :)  And Terry;  You may be surprised at the timings 
of that  to  sequence.

(thru key) would work as well, if not better, than (to key skip) 
 :)