how to get rid of duplicate solutions

[Wolfram Diestel]

Hello,

I often face the problem, that some predicate (tree) is creating duplicate solutions. Normally it is because of some logical weakness, e.g. missing join condition, but it is really hard to find the reason by debugging/tracing the code and often takes more time then crafting the code itself. I know the duplicates somehow spread out from choice points. I'm still looking for some straight forward method to systematically identifying the locations where such duplicates spread from. Do you have some experience how to do it? I had a look on get_prolog_backtrace and trace/leash predicate, but did not get a clue if they could be used the for that specific purpose. 

Regards,

  Wolfram.

[Jan Wielemaker]

In general, getting rid of duplicate answers is hard. Sometimes you
can add additional conditions to avoid that a subsequent clause generates
predicates that were already generated by a previous clause. Roughly, the
choices are:

- Additional conditions to avoid them. Sometimes trivial, sometimes
not. Cuts can achieve the same. Be careful to avoid loosing answers
though.
- Use distinct/1 or distinct/2. The price is that every new answer is
compared to a maintained (hash) table of answers. That costs time
and space.
- Use setof/3 + member. Same problem as above. Worse, answers only
become available after computing all of them. More traditional and
portable.
- Use tabling (7.3.21 or later). Similar problem as setof/3+member.
Less portable, but solves more issues.
- Don't worry. Duplicates are not always a serious problem for
subsequent processing steps.

Cheers --- Jan


>
> Regards,
> Wolfram.
>
> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swi-prolog+...@googlegroups.com
> <mailto:swi-prolog+...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/swi-prolog.
> For more options, visit https://groups.google.com/d/optout.

[Markus Triska]

Hi Wolfram,

that's an excellent question, and one that can be easily answered with appropriate tools by applying declarative debugging.

I know one powerful system that makes this possible: GUPU by Ulrich Neumerkel. It currently depends on SICStus Prolog, and I hope that one day more of its (GUPU's) source code will become publicly available.

In essence, your case can be solved in GUPU by first claiming that there is no solution at all; as this is the opposite of what is actually the case, GUPU will disprove this claim and show you all program fragments that contradict your claim.

The syntax to state the claim "no solution exists", for example "the predicate solution/1 has no solution" in GUPU is:

:/- solution(S).

and you can specialize this for example to:

:/- solution(concrete_solution).

where concrete_solution/0 is one of the duplicates.

GUPU will then show you the contradicting fragments, and this will reveal the different branches that lead to solutions.

This powerful technique is applicable for the pure and monotonic subset of Prolog, which I highly recommend staying in to make such analyses possible.

Until such tools are more widely available, debugging such issues is quite procedural and cumbersome. gtrace/0 may be of some help if you feel like jumping around and all over the place in your code and all kinds of libraries.

All the best,
Markus

[Wolfram Diestel]

Well, I know that I can remove duplicates afterwards, but I feel not well with this approach, because duplicates in the solution often means, that the logic is not clean, and this may mean that e.g. there could be also wrong solutions in the results.

I'm looking for some approach like: show me all redos in the path which led to a concrete solution. Comparing them with a duplicate solution I could identify the weak location in the code more easily. The GUPU feature that Markus describes is quite close to this. I wonder if such feature could be coded with SWI's builtin predicates.

In the concrete case after tracing, "distinct" (thank you, I had not remarked this handy predicate before) helped me to get rid of one source of duplicates coming from a fact base which I looked up with some free variables leading to duplicates. But I still could not find another source of duplicates.

[Jan Wielemaker]

On 31/05/16 22:03, Wolfram Diestel wrote:
>
> Well, I know that I can remove duplicates afterwards, but I feel not
> well with this approach, because duplicates in the solution often means,
> that the logic is not clean, and this may mean that e.g. there could be
> also wrong solutions in the results.

I'm not sure about that claim in general. Results may follow from
multiple rules. For example, in RDF a resource is of a type if it has
an rdf:type property, but also if it appears as an object in a triple
for which the property has a specified range. Two completely sane rules
that may (and often do) produce the result. So you get

typeof(R, T) :-
rdf(R, rdf:type, T).
typeof(R, T) :-
rdf(_, P, R),
rdf(P, rdfs:range, T).

Now, if you want to avoid duplicates, you get:

typeof(R, T) :-
rdf(R, rdf:type, T).
typeof(R, T) :-
rdf(_, P, R),
rdf(P, rdfs:range, T),
\+ rdf(R, rdf:type, T).

I can't really call this an improvement from the logical point of view.
We can't cut either of the rules either as all triples may appear
multiple times. The real RDF case is so complicated that it is hard
to get right using backward reasoning.

> I'm looking for some approach like: show me all redos in the path which
> led to a concrete solution. Comparing them with a duplicate solution I
> could identify the weak location in the code more easily. The GUPU
> feature that Markus describes is quite close to this. I wonder if such
> feature could be coded with SWI's builtin predicates.

Surely. For this case you could write a meta interpreter that, in
addition to the answer, returns a proof. If you sre interested in
pruning choices, the graphical debugger does a good job.

> In the concrete case after tracing, "distinct" (thank you, I had not
> remarked this handy predicate before) helped me to get rid of one source
> of duplicates coming from a fact base which I looked up with some free
> variables leading to duplicates. But I still could not find another
> source of duplicates.

Success :)

Cheers --- Jan

[Boris Vassilev]

Hello Wolfram,

Is it at all useful to approach your problem differently, namely: make sure that your proof tree does not contain choice points that _you_ did not intend to have there?

The rationale for me was as follows. I write a predicate that I expect to have exactly one solution: so, succeed without choice points. Instead, due to a programming error, somewhere down the proof tree a predicate leaves a choice point behind (an argument was not ground? I overlooked a possible solution?) which leads to backtracking.

The solution as suggested by Jan was:

==
call_is_det(Goal, IsDet) :-
        call_cleanup(Goal, Det=true),
        (   Det == true
        ->  IsDet = true
        ;   !,
            IsDet = false
        ).
==

This will unify IsDet with false if you get a solution and a choice point is left behind. The choice point itself is discarded.

==
?- call_is_det(between(1,1,1), true).
true.

?- call_is_det(between(1,1,2), true).
false.

?- call_is_det(between(1,1,X), true).
X = 1.

?- call_is_det(between(1,2,X), true).
false.

?- call_is_det(between(1,2,1), IsDet).
IsDet = true.

?- call_is_det(between(1,2,X), IsDet).
X = 1,
IsDet = false.
==

I used this to throw an error when IsDet was indeed false.

This might be relevant to your original problem if your duplicate answers come from choice points that you didn't know are there. There are also a few relevant questions and answers on Stackoverflow, see:

http://stackoverflow.com/questions/29823117/making-deterministic-success-of-prolog-goals-explicit

http://stackoverflow.com/questions/35140363/ensuring-that-a-predicate-succeeds-deterministically

Cheers,

Boris

Currently in the EEST time zone: This is UTC +3:00
Save our in-boxes! http://emailcharter.org

--

You received this message because you are subscribed to the Google Groups "SWI-Prolog" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swi-prolog+...@googlegroups.com.

[Jan Burse]

Anything to do that these Prolog systems are all incompatible?

Mostlikely not a real issue, but more a border case, but even
parsing is different among SWI-Prolog and SICStus Prolog:

SICStus Prolog: first test case not greedy,
second test case greedy

    ?- X = (+ ; +), write_canonical(X), nl.
    ;(+,+)
    X = ((+);(+)) ?

    ?- X = (+ ; + !), write_canonical(X), nl.
    +(+(;),!)
    X = + (;)+! ?

SWI-Prolog: Both not greedy

    ?- X = (+ ; +), write_canonical(X), nl.
    ;(+,+)
    X =  ((+); (+)).

    X = (+ ; + !), write_canonical(X), nl.
    ;(+,+(!))
    X =  ((+);+!).

Jekejeke Prolog: Both greedy

    ?- X = (+;+), write_canonical(X), nl.
    Error: Term missing.
    X = (+;+), write_canonical(X), nl.
            ^
    ?- X = (+ ; + !), write_canonical(X), nl.
    +(+(;),!)
    X = +;+!

[Jan Wielemaker]

Please do not reply to messages while changing the topic
completely.

On 06/02/2016 02:07 PM, Jan Burse wrote:
> Anything to do that these Prolog systems are all incompatible?
>
> Mostlikely not a real issue, but more a border case, but even
> parsing is different among SWI-Prolog and SICStus Prolog:

Most systems had their parser established when there was no standard and
while the syntax had all sorts of small (and large) variations. Most
people just did something sensible with the <l>f<r> notation. As it
mostly concerns corner cases that are better written with explicit
brackets anyway, it isn't really high priority to be solved.

Writing a parser from scratch to implement a specification is a lot
easier than adjusting an existing parser to a specification. Also, any
modification to the parser will make some existing users unhappy.

Even in my porting experience (a couple of million lines), this was
hardly ever a problem. Operators being scoped globally or by module is a
more common problem. Another issue is formed by quoted atoms.

Cheers --- Jan

P.s. Probably GNU-Prolog has the most standard compliant parser.
Certainly, SWI-Prolog should not be your system of choice
to test ISO compliance.

> SICStus Prolog: first test case not greedy,
> second test case greedy
>
> ?- X = (+ ; +), write_canonical(X), nl.
> ;(+,+)
> X = ((+);(+)) ?
>
> ?- X = (+ ; + !), write_canonical(X), nl.
> +(+(;),!)
> X = + (;)+! ?
>
> SWI-Prolog: Both not greedy
>
> ?- X = (+ ; +), write_canonical(X), nl.
> ;(+,+)
> X = ((+); (+)).
>
> X = (+ ; + !), write_canonical(X), nl.
> ;(+,+(!))
> X = ((+);+!).
>
> Jekejeke Prolog: Both greedy
>
> ?- X = (+;+), write_canonical(X), nl.
> Error: Term missing.
> X = (+;+), write_canonical(X), nl.
> ^
> ?- X = (+ ; + !), write_canonical(X), nl.
> +(+(;),!)
> X = +;+!
>
> Am Dienstag, 31. Mai 2016 20:49:23 UTC+2 schrieb Markus Triska:
>

> I know one powerful system that makes this possible: *GUPU* by

> Ulrich Neumerkel. It currently
>
> depends on SICStus Prolog, and I hope that one day more of its
> (GUPU's) source code will
>
> become publicly available.
>

> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swi-prolog+...@googlegroups.com

> <mailto:swi-prolog+...@googlegroups.com>.

[Jan Burse]

GNU Refuses to parse both of them. Probably missing
definition for prefix (+)/1 operator. Dunno yet.

Problem is not so much the parsing, but the pretty printing.
If these parser incompatibilities force you to overcautiously
place parenthesis then the code gets ugly.

I am currently trying a strategy that writes the fewest
parenthesis in the pretty printer. With the disadvantage that
the output is differently re-read by different Prolog system
sometimes.

Here is (overly-)cautious output (SWI-Prolog):

   ?- X = (+,+,+).
   X = ((+), (+), (+)).

   ?- X = (+ ; + !).
   X = ((+);+!).

   ?- X = ((+) + +).
   X = (+)+ (+)

And here is some non-(overly-)cautious output (Jekejeke Preview):

    ?- X = (+,+,+).
    X = (+,+,+)

    ?- X = (+ ; + !).
    X = +;+!
   
    ?- X = ((+) + +)
    X = (+)+ +

Bye

[Jan Wielemaker]

On 06/02/2016 09:53 PM, Jan Burse wrote:
> GNU Refuses to parse both of them. Probably missing
> definition for prefix (+)/1 operator. Dunno yet.

| ?- current_op(A,B,+).

A = 200
B = fy ? ;

A = 500
B = yfx

> Problem is not so much the parsing, but the pretty printing.
> If these parser incompatibilities force you to overcautiously
> place parenthesis then the code gets ugly.

Surely, SWI-Prolog accepts things it should not according to
the standard. A few are deliberate. Most are not.

> I am currently trying a strategy that writes the fewest
> parenthesis in the pretty printer. With the disadvantage that
> the output is differently re-read by different Prolog system
> sometimes.

I guess the aim should be to minimise quoting and parenthesis
and provide standard compliant output. That is a far from
trivial task. In addition, SWI-Prolog does a half-baked
attempt to maintain symmetry for the two arguments of
infix operators. It is really half-baked :(

Cheers --- Jan

>
> Here is (overly-)cautious output (SWI-Prolog):
>
> ?- X = (+,+,+).
> X = ((+), (+), (+)).
>
> ?- X = (+ ; + !).
> X = ((+);+!).
>
> ?- X = ((+) + +).
> X = (+)+ (+)
>
> And here is some non-(overly-)cautious output (Jekejeke Preview):
>
> ?- X = (+,+,+).
> X = (+,+,+)
>
> ?- X = (+ ; + !).
> X = +;+!
>
> ?- X = ((+) + +)
> X = (+)+ +
>
> Bye
>
> Am Donnerstag, 2. Juni 2016 14:42:19 UTC+2 schrieb Jan Wielemaker:
>
> P.s. Probably GNU-Prolog has the most standard compliant parser.
> Certainly, SWI-Prolog should not be your system of choice
> to test ISO compliance.
>

[Markus Triska]

Hi Jan,

On Thursday, June 2, 2016 at 2:07:15 PM UTC+2, Jan Burse wrote:

Anything to do that these Prolog systems are all incompatible?

 
Yes! Believe it or not: The syntax differences are the most important reason why all attempts to port GUPU to other systems have failed so far.

This may sound almost too trivial to believe! After all, why not simply change the GUPU source and adapt the syntax? The reason is that this is not sufficient, since the GUPU source code itself, although spanning 60.000 LOC, is only a tiny fragment of the Prolog source we want to read. Everything in GUPU is a Prolog term: All user input, all examples, the change history, the log files etc. Millions and millions of Prolog terms were collected over the decades from past courses. So far, SWI-Prolog unfortunately cannot correctly read this collection of terms, although for a time Jan has made very significant improvements to the parser, for example regarding ISO Latin 1 which is used in GUPU.

In isolation, the small syntax discrepancies between systems often sound trivial and are easily dismissed. Put in proper context though, they are unfortunately a huge impediment to porting larger existing collections of terms as they arise in GUPU.

I am grateful that you are now considering such discrepancies. I think it would be a great contribution to have an ISO-conformant parser for Prolog that is itself written in a subset of Prolog that many different systems execute correctly. This way, we could for example easily check, in different systems, whether any given source is syntactically conformant.

All the best!
Markus

[Jan Wielemaker]

On 06/03/2016 08:25 AM, Markus Triska wrote:
> Hi Jan,
>
> On Thursday, June 2, 2016 at 2:07:15 PM UTC+2, Jan Burse wrote:
>
> Anything to do that these Prolog systems are all incompatible?
>
>
> Yes! Believe it or not: The syntax differences are the most important
> reason why all attempts to port GUPU to other systems have failed so far.
>
> This may sound almost too trivial to believe! After all, why not simply
> change the GUPU source and adapt the syntax? The reason is that this is
> not sufficient, since the GUPU source code itself, although spanning
> 60.000 LOC, is only a tiny fragment of the Prolog source we want to
> read. Everything in GUPU is a Prolog term: All user input, all examples,
> the change history, the log files etc. Millions and millions of Prolog
> terms were collected over the decades from past courses. So far,
> SWI-Prolog unfortunately cannot correctly read this collection of terms,
> although for a time Jan has made very significant improvements to the
> parser, for example regarding ISO Latin 1 which is used in GUPU.
>
> In isolation, the small syntax discrepancies between systems often sound
> trivial and are easily dismissed. Put in proper context though, they are
> unfortunately a huge impediment to porting larger existing collections
> of terms as they arise in GUPU.

It shouldn't be that hard to deal with a collection of terms. SICStus
has written them and I assume it can read them (although SICStus' closer
ISO compliance may be a problem). Dump them using write_canonical. Have
SWI-Prolog read both the canonical version and the raw version and
compare the two. See what the problems are and decide on what to do
with them.

Good cross-platform exchange of terms is indeed not really trivial for
various reasons. Here are a few.

- write_canonical/1 should do the trick, but deeply nested lists easily
cause resource issues in the parser. It is also horrible to read by
a human.
- Quoted text depends on the character set. Using \xxx\ escape sequences
is not defined (that is, the sequence is defined, but the character
not).
Systems have different/no length limit, may or may not allow for
\000\ characters and may or may not allow for certain character sets.
- There may or may not be arity limits.
- If you use operators for readability, you need to fix the set. Some
systems can do that as their operators are module local. Others
can not.

Still, going from SICStus to SWI should be fairly trivial as SWI has
fewer limits (no arity limit, no length limit on atoms or strings, can
embed \000\, full Unicode character support).

> I am grateful that you are now considering such discrepancies. I think
> it would be a great contribution to have an ISO-conformant parser for
> Prolog that is itself written in a subset of Prolog that many different
> systems execute correctly. This way, we could for example easily check,
> in different systems, whether any given source is syntactically conformant.

A conformant parser may help isolating issues. Otherwise it should not
be necessary.

Cheers --- Jan

[Wouter Beek]

Hi Markus, others,

On Fri, Jun 3, 2016 at 9:25 AM, Markus Triska <tri...@logic.at> wrote:

In isolation, the small syntax discrepancies between systems often sound trivial and are easily dismissed. Put in proper context though, they are unfortunately a huge impediment to porting larger existing collections of terms as they arise in GUPU.

Is it not possible to automatically clean huge quantities of Prolog code?  We've done something similar for Semantic Web data, where reasoning would normally be impossible because of the many syntactic deviations and errors.

---

Cheers,

Wouter.

[Markus Triska]

Hi Wouter,

Is it not possible to automatically clean huge quantities of Prolog code?

This is likely what everyone who first hears about such issues would think and even start doing. It is certainly what I first thought when hearing about these problems. However, it unfortunately breaks the foremost principle of any archiving to retrospectively change the collected data, and for this reason the Prolog system or a compatibility layer should instead be made to work with the original, unchanged data, which is stored in an ISO conformant way.

Note that even if this elementary constraint were removed and we decided to arbitrarily change the hitherto collected data to accomodate syntax quirks of other systems, suppose there are mistakes in the conversion: This would with certainty only complicate and execerbate the situation further, since it may subtly destroy internal properties of the data, and create further difficulties in later testing and debugging. If some mistakes are later found, is it time to recheck the conversion process, or maybe time to debug some completely different functionality?

The situation may be simpler in other Prolog applications, for example if the stored terms do not touch many corner cases of the ISO standard. In GUPU though, we see the collected works of thousands of people who start learning Prolog, and you would be surprised of the huge number of corner cases these examples trigger in the underlying Prolog system's parser.

For such reasons, a strong requirement for a complete GUPU port to a different Prolog system is that system's ability to correctly parse the hithereto collected vast number of (sometimes very strange) Prolog terms. In fact, for Ulrich, correctly parsing the existing data is a prerequesite to even start working on the port. Until then, I hope that we will still see at least small fragments of GUPU and related programs also in freely available Prolog systems. library(diadem) is such an example, though alas it does not help much in the use case cited by Wolfram.

All the best,
Markus

[Wolfram Diestel]

I agree, that the claim is not a general one. It depends on the underlying data model. When the datamodel is expected to be normalized relational as in my case redundancy should not happen. If the data model is hierarchical like in the pre-RDBMS mainframe era and now again in the post-RDMBS era with the ontologies having class hierarchies, or weakly structured distributed (big) data collections (alias statistical data models), redundancies cannot be avoided. 

Am Mittwoch, 1. Juni 2016 09:56:28 UTC+2 schrieb Jan Wielemaker:

On 31/05/16 22:03, Wolfram Diestel wrote:
>
> Well, I know that I can remove duplicates afterwards, but I feel not
> well with this approach, because duplicates in the solution often means,
> that the logic is not clean, and this may mean that e.g. there could be
> also wrong solutions in the results.

I'm not sure about that claim in general.  Results may follow from
multiple rules.  For example, in RDF a resource is of a type if it has
an rdf:type property, but also if it appears as an object in a triple
for which the property has a specified range.  Two completely sane rules

that may (and often do) produce the result.  [...]

[Jan Wielemaker]

On 06/03/2016 03:34 PM, Markus Triska wrote:
> Hi Wouter,
>
> Is it not possible to automatically clean huge quantities of Prolog
> code?
>
>
> This is likely what everyone who first hears about such issues would
> think and even start doing. It is certainly what I first thought when
> hearing about these problems. However, it unfortunately breaks the
> foremost principle of any archiving to retrospectively change the
> collected data, and for this reason the Prolog system or a compatibility
> layer should instead be made to work with the original, unchanged data,
> which is stored in an ISO conformant way.
>
> Note that even if this elementary constraint were removed and we decided
> to arbitrarily change the hitherto collected data to accomodate syntax
> quirks of other systems, suppose there are mistakes in the conversion:
> This would with certainty only complicate and execerbate the situation
> further, since it may subtly destroy internal properties of the data,
> and create further difficulties in later testing and debugging. If some
> mistakes are later found, is it time to recheck the conversion process,
> or maybe time to debug some completely different functionality?

You are exaggerating. If you have a Prolog system A that is guaranteed
to read the terms correctly (I doubt any system can guarantee that unless
you never upgraded this system; also SICStus started with what was
common in the late 80s and moved to ISO in several steps) and a system
B that must read the same data consistently it is easy enough to setup
a validation chain:

- A reads a term and writes it using write_canonical, possibly
with some tweaks. Another format might do as well.
- B reads the same term and the one in the secondary format and
calls variant/2 on them.

I think this is sufficient to make sure B can read the term and that the
structure is unchanged. You may have problems with quoted atoms that are
consistently misrepresented, but it shouldn't be too hard to extend the
scheme to get this right too. For example by changing all atoms into a
list of character codes and do the same trick.

That creates a setting where you can reliably change the representation
as well.

> The situation may be simpler in other Prolog applications, for example
> if the stored terms do not touch many corner cases of the ISO standard.

Normal production programs are generally less weird indeed.

> In GUPU though, we see the collected works of thousands of people who
> start learning Prolog, and you would be surprised of the huge number of
> corner cases these examples trigger in the underlying Prolog system's
> parser.

I don't really see why a ported GUPU should be able to read all work
done by all past students in the first place, let alone with 100%
reliability. The above scheme will do the trick however.

> For such reasons, a strong requirement for a complete GUPU port to a
> different Prolog system is that system's ability to correctly parse the
> hithereto collected vast number of (sometimes very strange) Prolog
> terms. In fact, for Ulrich, correctly parsing the existing data is a
> prerequesite to even start working on the port. Until then, I hope that

I'll stick with correct language ... Ulrich's only purpose of this is to
enforce strict conformance with the ISO standard. If this is fixed he
makes up a story why he can't start because of some other mostly
irrelevant issue is the problem.

Getting Prolog to round trip write/read using operators is really hard.
Running SWISH/Pengines has found several issues with that. Fixed one
today, where a.(;) was written as a. (;). Without using operators it
should be much easier.

SWISH/Pengines became in part realistic due to Ulrich's zillion bug
reports targeting stability issues for code no sane person would write,
and which I deemed often unimportant back then. It was not a big
priority, but it was great to have at the moment Torbjörn Lager came
along with his Pengines idea.

Cheers --- Jan

[Markus Triska]

Hi Jan,

On Friday, June 3, 2016 at 5:22:07 PM UTC+2, Jan Wielemaker wrote:

SWISH/Pengines became in part realistic due to Ulrich's zillion bug
reports targeting stability issues for code no sane person would write,
and which I deemed often unimportant back then. It was not a big
priority, but it was great to have at the moment Torbjörn Lager came
along with his Pengines idea.

Indeed! And one thing I know for certain is this: If there were a way to run GUPU with SWI-Prolog, and to really run a beginner's class with SWI+GUPU as the underlying system, we would, very quickly, find many, many more opportunities for improvement. Beginners are very good at throwing completely unexpected queries and terms at the system, and I think handling such issues would provide a further gigantic stability boost for SWI-Prolog because GUPU internally does a lot of complex further processing.

Hundreds of improvements in SICStus Prolog are the direct result of such courses and the issues that arose due to unexpected student input combined with GUPU's processing. I am certain that if you fixed the remaining syntax issues and we could run GUPU with SWI for only a few months, you would say exactly the same thing that you are now saying about previous bug reports by Ulrich, which may often seem nonsensical and irrelevant without proper context.

I know that this is very unrealistic for now. But, as the saying goes: dum spiro spero...

All the best,
Markus

[Jan Wielemaker]

On 06/03/2016 07:09 PM, Markus Triska wrote:
> Hi Jan,
>
> On Friday, June 3, 2016 at 5:22:07 PM UTC+2, Jan Wielemaker wrote:
>
>
> SWISH/Pengines became in part realistic due to Ulrich's zillion bug
> reports targeting stability issues for code no sane person would write,
> and which I deemed often unimportant back then. It was not a big
> priority, but it was great to have at the moment Torbjörn Lager came
> along with his Pengines idea.
>
>
> Indeed! And one thing I know for certain is this: If there were a way to
> run GUPU with SWI-Prolog, and to really run a beginner's class with
> SWI+GUPU as the underlying system, we would, very quickly, find many,
> many more opportunities for improvement. Beginners are very good at
> throwing completely unexpected queries and terms at the system, and I
> think handling such issues would provide a further gigantic stability
> boost for SWI-Prolog because GUPU internally does a lot of complex
> further processing.

SWI-Prolog is already handling tens of thousands of often weird queries
each day. There are indeed still some stability issues. Most seem
unrelated to the queries themselves. There is likely still an issue in
the semantic highlighting server support code and possibly in the
Pengine/HTTP connection.

Cheers --- Jan