Alex and I had a discussion on IRC regarding match and long lists,
here is a short recap and example of a string Alex can use instead of
that massive rss.xml I attached earlier.

The problem is using from in combination with till repeatedly to parse
input in order to for instance get at the contents of the <item></tem>
elements, there is a twist though, the contents can contain more
markup so a check is needed every time till encounters for instance <,
if that one is to be used as a stop char.

Anyway the following should suffice:

  <some markup><and more>
  <markup with=3D"attribute">

We need to get <some markup><and more> and <markup with=3D"attribute">
using from till, not chopping and then recursively using match which
apparently is much slower.


On Sat, Oct 31, 2009 at 12:34 PM, Alexander Burger <> wr=
> On Fri, Oct 30, 2009 at 06:12:00PM +0100, Henrik Sarvell wrote:
>> (dm twitter> (L)
>> =A0 (use (@A @X @E @Z)
>> =A0 =A0 =A0(make
>> =A0 =A0 =A0 =A0 (while (match '(@A "<" "s" "t" "a" "t" "u" "s" ">" @E "<=
" "/"
>> "s" "t" "a" "t" "u" "s" ">" @Z) L)
>> =A0 =A0 =A0 =A0 =A0 =A0(let R (twitterEntry> This @E)
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (when R (link R)))
>> =A0 =A0 =A0 =A0 =A0 =A0(setq L @Z)))))
> Wouldn't it be possible to write something along the line
> =A0 (in "rss.xml"
> =A0 =A0 =A0(while
> =A0 =A0 =A0 =A0 (from
> =A0 =A0 =A0 =A0 =A0 =A0"<status>"
> =A0 =A0 =A0 =A0 =A0 =A0"<feed>"
> =A0 =A0 =A0 =A0 =A0 =A0"<feedburner>"
> =A0 =A0 =A0 =A0 =A0 =A0"<moreTags>" )
> =A0 =A0 =A0 =A0 (case @
> =A0 =A0 =A0 =A0 =A0 =A0("<status>"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 'twitter> )
> =A0 =A0 =A0 =A0 =A0 =A0("<feed>"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
> =A0 =A0 =A0 =A0 =A0 =A0("<feedburner>"
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ...
> The individual clauses of 'case' could call 'till' (possibly several
> times in a loop) to collect the contents, and perhaps call 'match' on
> the pieces.
> A typical example for such a parser is the "lib/scrape.l" GUI scraper.
> BTW, did you try a 'ulimit -s unlimited'? Just to be sure that a stack
> overflow was the reason for the segfault, and not a 64-bit bug.
> I have to explain that while the 32-bit version calls setrlimit() to set
> an unlimited stack size, the 64-bit version does not. I think it should
> not be the business of the interpreter to set such a limit, this can be
> done more flexibly and transparently by the calling shell.
> Cheers,
> - Alex
> --

Reply via email to