Parson's Problems

Re: Parson's Problems

by Richard Lobb -
Number of replies: 8

I've figured out how to use Moodle's jquery and jquery-ui, rather than include the source for both within the Parson's problem prototype. This reduces the HTML size from around 300k to 14k! It also removes potential conflicts between the two different versions.

I've also fixed the bug that allowed you to lose lines by dragging them off to the right of the window.

The updated prototype can be downloaded from github: https://github.com/trampgeek/ucquestiontypes.

In reply to Richard Lobb

Re: Parson's Problems

by Jon Witts -
Hi Richard and Paul,

I am trying to add the CodeRunner prototype to my Moodle install and use the examples in the Question Type details to set up my first Parson's Puzzle with Code Runner... However I must be missing something!

I have the following fields filled in for my first question:
Question Type: python3_parsons_problem
Template params: 
    
import json, random
code = '''
    print("Guess the word")
    word = input()
    while word != "Raspberry":
        print("Try again...")
        word = input()
    print(f"Well done, the word was {word}!")
'''

code_lines = [line.strip() for line in code.splitlines()]
random.shuffle(code_lines)
answer = {"CR-parsons-code": [code]}
print(json.dumps({"jumbled_code": '\n'.join(code_lines),
                  "answer": json.dumps(answer)}))
Preprocessor: Python3
Answer: {{answer}}
Global extra: {% _self.global_extra(jumbled_code) %}

With Validate on save ticked I get the following error:
Failed 1 test(s)
Got:
***Run error***
Traceback (most recent call last):
  File "__tester__.python3", line 4, in <module>
    """)["CR-parsons-code"][0]
  File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode
    obj, end = self.scan_once(s, idx)
json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

Any help gratefully received.
Jon
In reply to Jon Witts

Re: Parson's Problems

by Richard Lobb -

Sorry, I had an error in my inline documentation, plus a missing instruction.

Firstly the global extra field should be

{{ _self.global_extra(jumbled_code) }}

i.e. using '{{' and '}}' not '{%' and '%}'

Secondly I forgot to include the instruction to turn on the Twig All checkbox.

With those changes, and with a test case added, your question sort-of works. [Attached]. I say "sort-of" because the Parsons Problem question type doesn't currently include an override of the input function, so the student doesn't see the input read from the file, as happens when reading from the keyboard.

To fix this you need to insert into the code that gets executed something like:

_saved_input = input
def input(prompt=''):
    print(prompt, end='')
    s = _saved_input()
    print(s)
    return s

I attach a question with this change made to the (customised) example question. You could include that modification in the question type if you wanted.

I've updated the prototype in the uocquestiontypes repo on github.

In reply to Richard Lobb

Re: Parson's Problems

by Jon Witts -
That's great Richard; thank you so much!

I will update the prototype on my system with the one from GitHub.

I have had a look through the Template customisation you have done to allow for the input override. Should I be able to save this as a prototype called "python3_parsons_problem_w_input" to allow me to reuse it in future questions?

Thanks again,
Jon
In reply to Jon Witts

Re: Parson's Problems

by Richard Lobb -
No, you can't save that question as a prototype. All the Parsons Problem implementation is in the prototype's template parameter field, which gets merged with the 'child' question's template parameters when you run the child. Also, you don't want the test cases in the prototype.

To create a new prototype, use the 'Duplicate' option in the question bank to create a new version of the prototype, copy in the new template code, change the name to your new type, and save. Make sure you don't finish up with two prototypes with the same question-type name, however, or everything breaks.
In reply to Richard Lobb

Re: Parson's Problems

by Jon Witts -
Thanks for the clarification Richard, all done now!
In reply to Richard Lobb

Re: Parson's Problems

by Paul Powell -
Hi Richard,

I am just coming to the point of using this to set up for classes.

I have been thinking about how distractors and selectors could be handled in your new mobile friendly interface - which is better.

For selectors, it seems re-introducing something similar to the old toggle code - a span with a toggle class and and a set of options. Because the JS would re-write the innerText of the <span>, then the innerText of the code <li> would
 yield the code without modification. The main question would then be the author should type out the <span> code each time they want a toggle or if there were a more concise syntax we could use and use in codeLineToHTML. I thought we could use something like
if i=choice: #SELECT choice=[-1,0,1,2]
The idea being that a string identified in the comment is replaced with a <select> or <span> that implements the options in the list. 

Alternately I could do as above, but use a standard <select> element. This would then need a modification to getCodeString to replace a <select> element with its current value.

For distractors I was wondering about a double click/tap which would grey out the element. The double click could set a class and this could be used in getCodeString to comment out the line (not adding it would muck up line numbers for debugging)

Does that sound reasonable? - I am trying to make it as invisible as possible so that diverging versions are not needed. Perhaps a setting could turn distractors on and off?

Happy to have a go at this - but is it something you'd consider adding to the standard one you are working with?

Thanks

Paul
In reply to Paul Powell

Re: Parson's Problems

by Richard Lobb -
Sorry about the delay in replying Paul - the last two weeks of the semester are too busy for CodeRunner to get a look in.

I myself have no immediate interest in implementing selectors and distractors - in our environment (first year engineering and computer science tertiary course) Parsons Problems have only a very minor role to play and making them more sophisticated isn't a priority. But if I understand you correctly you're offering to do the development yourself, in which case I'm happy to merge your code into our ucquestiontypes repo on github, though that's not part of CodeRunner nor intended as any sort of standard. It's just supplementary stuff we make available.

I like the idea of embedding the distractor and selector specifications in comments. Your syntax of selectors looks nice but would have the disadvantage that, at least with the current implementation, the sample answer wouldn't validate on save. It would probably be better to use a syntax that doesn't damage the validity of the sample answer. Perhaps something like

if i == 2: # 2 => SELECT FROM [-1, 0, 1, 2]

This could create ambiguities so could perhaps be generalised so the text between the # and the => is a regular expression to be applied to the text to the left of the '#'? Or maybe just try the simple version first and see if ambiguities are a problem.

I like double click/tap to grey out elements. And insert a '#' in front, too, perhaps? Like code editors that offer a comment/uncomment option on a block of text.

Good luck with the implementation.