Skip to content
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

Fix debugging messages in the formatRenderedProblem method. #2662

Merged

Conversation

drgrice1
Copy link
Member

The formatRenderedProblem method of the FormatRenderedProblem module ensures that the debug_messages key of the rendered problem result is an array reference, but checks the wrong thing. It checks if the result itself is an array reference instead of the debug_messages hash key of the result. Since the result is always a hash reference and never an array reference, this means that the debugging messages from PG are always wiped out and replaced with a reference to an empty array.

This was discovered when investigating #2661. If we want to switch the PG problem editor to using the debug output format of the formatRenderedProblem method we could, but in order to get the benefit of that change we need this.

@drgrice1 drgrice1 force-pushed the bugfix/format-rendered-debug-messages branch from 1ab5a8d to 551001f Compare January 25, 2025 22:50
@drgrice1
Copy link
Member Author

One way to test this is to get the MWE that @dlglin posted in #2661, and change line 399 of htdocs/js/PGProblemEditor/pgproblemeditor.js from outputformat: 'simple' to outputformat: 'debug'. Then open the problem in the problem editor, enter an answer, and click "Check Answers". With the develop branch and the change on line 399, debugging messages still will not be shown. Of course, with this pull request they will be.

That also shows what would be needed to switch the PG problem editor to using the debug format if you want to test that out. Note that shows the debug_messages and internal_debug_messages sent from PG if there are any.

@drgrice1
Copy link
Member Author

By the way, I don't think that anything ever sets the internal_debug_messages in PG anymore. I think that is a left over relic from ages past. I don't know why there is a debug_messages facility and an internal_debug_messages facility as well.

@drgrice1 drgrice1 changed the title Fix a debugging messages in the formatRenderedProblem method. Fix debugging messages in the formatRenderedProblem method. Jan 28, 2025
The `formatRenderedProblem` method of the `FormatRenderedProblem` module
ensures that the `debug_messages` key of the rendered problem result is
an array reference, but checks the wrong thing.  It checks if the result
itself is an array reference instead of the `debug_messages` hash key of
the result.  Since the result is always a hash reference and never an
array reference, this means that the debugging messages from PG are
always wiped out and replaced with a reference to an empty array.

This was discovered when investigating openwebwork#2661.
If we want to switch the PG problem editor to using the `debug` output
format of the `formatRenderedProblem` method we could, but in order to
get the benefit of that change we need this.
@drgrice1 drgrice1 force-pushed the bugfix/format-rendered-debug-messages branch from 551001f to 313eb68 Compare February 1, 2025 23:33
@pstaabp pstaabp merged commit f1da2b1 into openwebwork:develop Feb 4, 2025
2 checks passed
@drgrice1 drgrice1 deleted the bugfix/format-rendered-debug-messages branch February 4, 2025 20:43
drgrice1 added a commit to drgrice1/webwork2 that referenced this pull request Feb 4, 2025
This is as discussed in openwebwork#2661, openwebwork#2662 and the developer meeting.  The PG
problem editor is switched to the debug format from the simple format.
The only difference for the problem editor page is that if there are
debug messages they are now shown.  Usually there aren't any such
messages, and so there isn't a difference.  But if something is enabled
like the MathObject diagnostics cmp flag, then those debug messages are
shown.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants