-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Bad plan description"? #65
Comments
There is a lot to be frustrated about in the syntax error reporting from VAL, I fear. The plan syntax is fairly permissive, so I suspect that is not going to be the problem - more likely types. You can try the parser (which is a standalone build target from the same source) which will output the syntax tree as it parses. That can help to isolate any parsing errors. If it is a typing error - hmm.
The line you highlighted is checking that the pointer from the parser (to the parse tree for the plan) is non-zero and that the plan typechecks. You can try reducing the problem with a binary chop on the plan (it will not be a valid plan, of course, but it should parse and typecheck, so that would allow you to nail down which action is the problem).
Failing all else, if it is content you are happy to share, you can mail me the lot and I will look at it.
…________________________________
From: rpgoldman ***@***.***>
Sent: 06 March 2025 16:38
To: KCL-Planning/VAL ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [KCL-Planning/VAL] "Bad plan description"? (Issue #65)
Any suggestions for debugging plans rejected by Validate with "Bad plan description!"
Looking at the source code, it looks like this could be either a failure in type checking or because the system has not been able to read the plan:
(!the_plan || !tc.typecheckPlan(the_plan))
the first disjunct comes from:
the_plan = dynamic_cast< plan * >(top_thing);
Which I'm afraid I don't follow. Am I right in assuming that this means that the format of the plan is incorrect?
If so, any reason why these two failures are conflated?
Also, looking at the type-checking, I see this:
bool TypeChecker::typecheckPlan(const plan *p) {
if (!isTyped) return true;
return p->end() == std::find_if(p->begin(), p->end(), badchecker(this));
};
Does the above miss an opportunity to tell the user what step of the plan is ill-typed?
—
Reply to this email directly, view it on GitHub<#65>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB2KOVGFP6UD2NJRUWEG7KD2TB2WZAVCNFSM6AAAAABYPEWDDOVHI2DSMVQWIX3LMV43ASLTON2WKOZSHEYDAOJQGEZTONQ>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
[rpgoldman]rpgoldman created an issue (KCL-Planning/VAL#65)<#65>
Any suggestions for debugging plans rejected by Validate with "Bad plan description!"
Looking at the source code, it looks like this could be either a failure in type checking or because the system has not been able to read the plan:
(!the_plan || !tc.typecheckPlan(the_plan))
the first disjunct comes from:
the_plan = dynamic_cast< plan * >(top_thing);
Which I'm afraid I don't follow. Am I right in assuming that this means that the format of the plan is incorrect?
If so, any reason why these two failures are conflated?
Also, looking at the type-checking, I see this:
bool TypeChecker::typecheckPlan(const plan *p) {
if (!isTyped) return true;
return p->end() == std::find_if(p->begin(), p->end(), badchecker(this));
};
Does the above miss an opportunity to tell the user what step of the plan is ill-typed?
—
Reply to this email directly, view it on GitHub<#65>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AB2KOVGFP6UD2NJRUWEG7KD2TB2WZAVCNFSM6AAAAABYPEWDDOVHI2DSMVQWIX3LMV43ASLTON2WKOZSHEYDAOJQGEZTONQ>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
The particular case I'm working with seems trivial, so I won't bother you with the example. But I was wondering: it looks like the type-checker iterates over the plan until it finds an error or reaches the end. Right now, the type checking function just checks to see if the latter case holds, returning a boolean. But if the result of the |
@DerekLong101 -- As I've said, I am not a C++ programmer. By sheer bluff I got as far as the following: std::string TypeChecker::planTypecheckFlaw(const plan *p) {
std::ostringstream oss;
oss << "Type error in:\n";
oss << *(std::find_if(p->begin(), p->end(), badchecker(this)));
oss << "\n";
return oss.str();
}; Which I think almost works, but it looks like it's printing the address of the happening, instead of the happening:
If anyone could tell me what I'm doing wrong trying to print the value returned by |
OK, more information: I think this is actually a problem with checking the domain. It turns out that there's a syntax error in the domain definition, but So ... does Validate not check the results of parsing its input files? |
The underlying error was me treating |
See #67 for proposed fix |
Here's the check in Validate's if (!an_analysis.the_domain) {
cerr << "Problem in domain definition!\n";
if (LaTeX)
*report << "\\section{Error!} Problem in domain definition! \n "
"\\end{document}\n";
exit(-1);
}; Is this too permissive? Should we be checking |
Any suggestions for debugging plans rejected by Validate with "Bad plan description!"
Looking at the source code, it looks like this could be either a failure in type checking or because the system has not been able to read the plan:
the first disjunct comes from:
Which I'm afraid I don't follow. Am I right in assuming that this means that the format of the plan is incorrect?
If so, any reason why these two failures are conflated?
Also, looking at the type-checking, I see this:
Does the above miss an opportunity to tell the user what step of the plan is ill-typed?
The text was updated successfully, but these errors were encountered: