Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!ucbvax!bloom-beacon!eru!hagbard!sunic!liuida!aste16!felkl From: felkl@aste16.Berkeley.EDU (Feliks Kluzniak) Newsgroups: comp.lang.prolog Subject: Re: Can I talk about Parlog here? Message-ID: <1990Nov15.190217.21923@ida.liu.se> Date: 15 Nov 90 19:02:17 GMT References: Sender: news@ida.liu.se (News Subsystem) Reply-To: felkl@aste16.Berkeley.EDU (Feliks Kluzniak) Distribution: comp Organization: CIS Dept, Univ of Linkoping, Sweden Lines: 26 |> The question still |> stands: Is there an efficient parallel parser that works under IC |> Parlog without crashing it? Even after minor modification, Conlon's |> parser is still generating copious segmentation fault errors in IC |> Parlog when run in conjunction with my lexicon lookup routine. This |> does not surprise me, as *everything* I write in IC Parlog seems to |> generate segmentation faults and dead child processes given enough |> time or processors. If that doesn't happen, I can usually crash it |> after recompiling my code a few times. Perhaps I have some deep |> guards lurking around that are causing these problems. Why then do |> they not cause these problems consistently? Any help on these matters |> would be appreciated. Ah, I've never used IC Parlog, and I'm not particularly interested in parallel parsing. What I AM interested in is why people choose to use logic programming systems (parallel or otherwise) that ever crash with a segmentation fault. This is not an error in your program, no matter how erroneous it is: this is an inexcusable error in the implementation. The only solution is to find an implementation written by responsible professionals. No offence intended to anyone. And yes, I think I do know what I am talking about. -- Feliks Kluzniak