Extension with jme function that returns a promise

[jhoobergs]

@christianp I am trying to develop an extension to evaluate SQL knowledge op students. The (initial version of the) code can be found at https://github.com/jhoobergs/numbas-extension-sqlite

My main issue is situated at https://github.com/jhoobergs/numbas-extension-sqlite/blob/5024b57e0ffce3a565fba81833e71128f571e26a/extension.js#L296 were I have a Promise (which yields a TBool) instead of a TBool. Do you know of a way to solve this? If not I will need to do the operations with sql.js in a synchronous way but I would rather not.

EDIT: For now I changed the design so the correct resultset is calculated on creation of the SQL editor and every time a query is executed, that resultset is saved. When the user clicks submit, the last saved resultset is compared with the correct resultset.

PS: Maybe it is an idea to add the 'hacktoberfest' topic to the Numbas repo's? (see https://hacktoberfest.digitalocean.com/)

[christianp]

@chrismgraham and @georgestagg have written a very similar extension for their programming courses, with the same problem. We've tried a few different ways of getting round the fact that the code has to run asynchronously.

The way we've got it at the moment is that we have a custom part type whose input widget is a code editor. We override the part's submit and mark_answer methods to do the following:

• Initialise a list of promises that must be fulfilled before the part can be properly marked.
• Submit once, to find all the places that mark_answer would be called.
• Whenever mark_answer is called, send the code off to be evaluated, producing a Promise, and add that promise to the list. Return an error state.
• Reset the part's feedback, because it'll be full of errors. Add a warning "Waiting for code to be evaluated" to the part, so the student knows what's going on.
• After each promise resolves, it saves its result to an attribute on the part that created it.
• Once all the promises have resolved, submit again. This time, mark_answer can put the results of the promise in the marking_parameters, and run the marking algorithm as normal.

This is still a bit flakey, but it looks OK to students when it's used properly.

There are two ways of improving this: make it possible for JME functions to evaluate to a promise, or have a built-in method for registering a promise that must be resolved before a part can be marked. I think that the second option is the one to go for: making the marking process promise-aware will lead to far fewer breaking changes than making jme.evaluate return a promise!

I'd like to release our coding extension as open source, but at the moment it relies on a backend that is specific to Newcastle. George and I are looking into making it use Jupyter kernels instead, which would be much easier to replicate elsewhere.

[christianp]

The pre-submit tasks feature handles this now.