What I'm subsequently doing further "down" in the code is a recursive
matching in order to get at the pieces I want, on the same list, I'll
give you an example:
(dm twitter> (L)
(use (@A @X @E @Z)
(make
(while (match '(@A "<" "s" "t" "a" "t" "u" "s" ">" @E "<" "/"
"s" "t" "a" "t" "u" "s" ">" @Z) L)
(let R (twitterEntry> This @E)
(when R (link R)))
(setq L @Z)))))
L is here the very same list called Lst in the earlier example that
segfaults. So even if I should use an argument in (till) in the first
type test the above algorithm will segfault anyway as it is matching
on the same long list.
A "trick" you yourself showed me once. But yeah if there are quicker
ways of getting at the data...
/Henrik
On Fri, Oct 30, 2009 at 4:51 PM, Alexander Burger <a...@software-lab.de> wro=
te:
> Hi Henrik,
>
>> segfault. Hope this helps.
>
> Thanks. Unfortunately, I cannot reproduce it. I even checked with my
> special GC check setup, where a garbage collection is performed before
> each 'cons'. This usually shows errors in the data handling (though such
> a test runs for hours).
>
>
> Could it be a stack overflow, because of that long argument? What says
>
> =A0 $ ulimit -s
>
> in your case? Does it work if you set it to 'unlimited'?
>
> If so, I would reconsider the design of that function. 'match'ing such
> large lists is not very efficient. Can't you step through the data with
> 'from' and 'till', extracting individual tokens, instead of reading them
> into a huge list?
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
