Add: Dynamic problems for fitb questions.

[bjones1]

This enables dynamic problems for fitb questions -- a quick, MVP pass.

[bnmnetp]

rats ☹️ only server side....

[bjones1]

That's always my preference :). Of course, this is also how WebWork operates. Especially if we want to do symbolic math, linear algebra, etc., the code base for Python / server-side programs is more mature than JS.

[bnmnetp]

I don't think we are in competition with webwork. There are things we can emulate from WebWork and there are things we can learn. My preference is always to push as much of the work as possible to the client, and for basic stuff it seems like it would be very easy to make it work in Javascript as well as Python.

That said, I really like the concept, I think we could do a lot with it.

I've not seen multi-line values for directives.unchanged before. That looks a little wonky, I assume the indentation is important there?

[bjones1]

I'm not trying to compete with Webwork, but to take ideas / design inspiration from a proven system. I agree that client-side is nice to support, and for basic problems should have all the features. However, trying to support both server-side and client-side seems hard, since the two languages (Python and JavaScript) are fundamentally different animals.

I played with multi-line values for the directive. Correct, they must be indented. More restrictively, there must be no blank lines (although a line with only a comment character can work around that). Perhaps we could also have a =================== then have the code after that, which is think is what ActiveCode uses?

[bjones1]

...but thinking about this, if the client-side code is still possible using skulpt, correct? So we could potentially send Python to the browser, then use it there to check answers? We'd also have to do template replacement (e.g. {{=a}}, but that seems do-able.

...even more, what if all question types that run either client-side or server-side do all answer checking in Python? Currently, fitb has answer checking written in both languages, which is not great...

[bnmnetp]

It could work, the sad thing about skulpt is that it was never designed so that you could have skulpt run some python and return a result to Javascript. The way skulpt and Javascript communicate (if at all) is through the DOM.

I think we need more discussion on this. The server side stuff has a lot of benefit, but the fact is that most authors do not install a full runestone server, which makes writing stuff that relies on having a full server difficult.

[bjones1]

I'd be happy to think more. To me, the core design question is: what language should dynamic problems be written in? Ideally, it would be a language that would execute in the same way on both client and server. Node.js and JavaScript are close, but these don't easily play with our Python-based server. If it is too hard to get Skulpt to talk with JS, perhaps Transcrypt?

[bjones1]

Thoughts on improvements from today's conference call:

• Allow instructors to set the seed for all students in a class, then reset it when they want. This is easy to implement. Where would this functionality be? Placing a button only the instructor sees on a given problem makes the most sense to me.
• Add a refresh button to allow students to get a new problem. This should be fairly easy. Question: can instructors "lock" this to prevent students getting another problem? If so, we need a locked field in fitb_ansers. See earlier question re: interface.
• Add a slider so students can go back in time to view past problems. A similar question applies.
• Enable multiple choice questions to be dynamic. This will take some work.
• Enable other question types to be dynamic -- Parsons, for example.
• Allow feedback to be templated. This should be fairly easy.

[bjones1]

On a side note, do we ever seed the Python RNG somewhere in our web2py code? If so, I can't find it. I assume we should be doing this...

[bjones1]

Never mind. It looks like Python does it automatically when random is imported.

[bnmnetp]

I've seen mention of things like pyv8 that provide python bindings that allow you to evaluate javascript from python rather easily. However they seem to have fallen out of fashion as many of them seem old and/or unmaintained.

I do think the disparity between the runestone serve capabilities and the runestone server are a real problem that is impacting several authors and its something we ought to look at.

[bjones1]

Hmmm. So is the goal to do dynamic problems client-side, or assume use of runestone serve? If the second, moving the code to Flask/Quart/new web2py would make it easy for authors to run a full student server (no admin tools, which I assume would stay on web2py for a while, since it's so much to port...)

[bnmnetp]

There are many goals. 😄 And, I don't mean to pick on dynamic questions, it is just the proverbial straw that broke the camels back in this case.

Both you and I want to do what we can to encourage more authors to use Runestone. I'm just trying to point out that we have unintentionally created another point of friction with several features:

1. running code in the JOBE sandbox
2. getting a CodeLens trace
3. server side grading
4. dynamic pages.
5. etc. I'm sure I'm forgetting something

All are good things, but the dynamic_pages flag in particular leaves many new authors thinking that the system is broken when it is not really broken its just that there are certain things that don't work with runestone serve

One solution would be to expand runestone serve capabilities. But I don't think I see this as ever being a server one would use in production for more than a single class. You can pip install runestone and it just works. So a minimal runestone serve that restored functionality for those things would be ideal. So maybe taking a first step in that direction would be good as it would allow us to refactor things in a way that would let you pip install rsserve in a way that worked for a minimal server as well as our production server.

[bjones1]

I agree re: runestone server -- I see it as author support/a non-production solution.

Another approach: distribute the server as a Dockerized application?

[bjones1]

Given the progress on the bookserver, I'd like to revisit this. Would you re-consider this PR given that we can currently distribute web2py in Docker with everything necessary for server-side grading, plus the new bookserver will make it easy to install and run the backend in the future?

[bjones1]

Closed in favor of #1225.