programming console widget

[GoogleCodeExporter]

From Sean's mail:

> 5. I now know at least five different people who are interested (in different 
contexts) in the idea of having a student enter stuff into a programming 
console and get interactive feedback on his/her program. Would any of you be 
interested in looking into how Oppia could more directly support this use case? 
Basically instead of trying to interpret strings and numbers we would now have 
to try and deduce things about programs (a simple example would be which test 
cases they pass).

Original issue reported on code.google.com by kash...@google.com on 12 Jul 2013 at 10:55

[GoogleCodeExporter]

I'm trying to wrap my head around this. Some design questions come to my mind:

- What should be the state of the widget? One line of program code (like an 
expression) or a bigger chunk of code, i.e. a function definition or even a 
class?

- What should be the response trigger? "Compile" and/or "Execute" button? Or 
let them compile and execute freely and have a separate "Submit my code" 
button? Or perhaps it's much smaller editor events -- e.g. so we can respond to 
syntax errors as soon as user type the code?

- Should it be a sticky widget? E.g. so user doesn't have to re-type the same 
code over? In that case the widget needs to be updated by the server response 
(e.g. new state), I think.

Probably starting with a simple model where widget is just a non-sticky text 
box (with submit button). Compile and run the code either on the client or on 
the server before server evaluates for the state transition, and the new text 
widget is rendered with the code of previous response.

I'll look at some programming tutorial materials on the net and try to come up 
with a sample exploration idea first.

Original comment by kash...@google.com on 12 Jul 2013 at 11:07

[GoogleCodeExporter]

Here are some ideas for a simple model which we can make more complicated later 
-- hope they are helpful! It may be useful to get Yana's opinion too, since I 
think she wants to build explorations that make use of this widget.

We could start with having the state of the widget be the code that's typed in 
it. Typically I think this would probably be at the level of a function 
definition, but maybe it doesn't matter -- the whole thing could be treated as 
a single file (f.py, say) and running it would amount to executing it via 
"python f.py". It may, of course, work differently in JavaScript, etc., but we 
could try this for a first attempt.

I think a reasonable response trigger would be when the user clicks 'Run code'. 
Based on the information gleaned during the run we would then give them 
feedback. I don't know whether it is better to do things on the client or the 
server -- that probably depends on the technologies we have available. If we 
run the code on the server we should try and find a way to isolate it in, e.g., 
a separate app (maybe using cloud playground?), since doing exec() on arbitrary 
code isn't safe.

I do think it should probably be sticky; the alternative is to create a new 
widget view whose contents are the code of the previous one but this seems like 
it does more work than necessary. Do we need much of a state update? I was 
thinking that the server response could be in the form of feedback that enters 
the 'conversation' in the usual way, but I don't know if this is too limited.

One particular sample idea I was thinking of was this:

    http://projecteuler.net/problem=1

You could imagine asking the user to solve this problem for general limits. 
This would need a program, and it might be possible to give feedback for things 
like "your program takes too long if the limit is 10^7", "your program gives 
the wrong answer for the limit 25", "did you consider the case when the limit 
is divisible by 5?", "are you counting multiples of 15 twice?", etc.

Here are some other sites that may be worth looking at for inspiration:

    http://cscircles.cemc.uwaterloo.ca/
    http://www.learnpython.org/
    http://tryruby.org/levels/1/challenges/0
    http://www.learnstreet.com/lessons/study/python

Original comment by s...@google.com on 13 Jul 2013 at 1:57

[GoogleCodeExporter]

Ya ok sg. Let's start with simple. Summarizing the plan:

- Sticky widget that keeps code user typed in. Response from server rendered in 
the conversation log.

- Expect runnable code snippet to be typed into the widget.

- "Run Code" button sends the code back to server. At the same time execute the 
code (either on the client or on the server) and make the result (e.g. compile 
error, runtime exception, or stdout) available to the server.

- The execution result also sent back to the client for rendering (perhaps in a 
widget custom response.html).

The projecteuler sample is intriguing. That made me realize this simple form of 
generic code widget can be used for non-programming explorations too -- e.g. we 
can ask students to compute specific numbers in a physics lesson -- the 
lesson'd be much more engaging than a lesson just explains formula and numbers, 
I think.

I'll go over the sites for ideas, but I think I have solid enough idea to get 
started.

Original comment by kash...@google.com on 16 Jul 2013 at 4:35

[GoogleCodeExporter]

I'm checking in the first iteration of the widget to master branch soon. Still 
todo after that are:

- In editor, make selection of prog languages a drop down (it's a text field 
now).
- Add an option to tell if the code is one line or multiple lines (currently it 
always shows one line, but expandable).
- Add more rules and tests for them. Rules for output, error, and evaluation.
- Write sample exploration.
- Allow the widget to be sticky (which does not clear the code in text box).

Original comment by kash...@google.com on 2 Aug 2013 at 8:09

[GoogleCodeExporter]

I'm going to file a separate issue for clarifying the parameter mechanism, but 
it looks like that is blocking the progress on the code editor. For now, can we 
disallow the programming language customization, and mandate that its value is, 
say, 'Python'? Then we can move on to the other todos and return to this one 
later.

Btw, for the second todo, you might find the TextInput widget useful:

   https://code.google.com/p/oppia/source/browse/extensions/widgets/interactive/TextInput/TextInput.html 

It allows the number of rows/columns in the textarea to be specified as a 
customization parameter.

Original comment by s...@seanlip.org on 25 Aug 2013 at 9:28

[GoogleCodeExporter]

Reviewing the current state of the widget -- we only have the last three issues 
remaining (and writing an exploration is a todo, but perhaps not an issue). 
I'll close this ticket and file new ones for the remaining tasks.

Original comment by kash...@google.com on 13 Sep 2013 at 6:33

• Changed state: Fixed