Crunchy Frog 0.3 released
Version 0.3 of "Crunchy Frog" has been released. It can be found at https://sourceforge.net/project/showfiles.php?group_id=125834 Crunchy Frog transforms a "traditional" Python tutorial into an interactive session within your favourite web browser. Four modes of interaction are currently possible: 1. One-liner, similar to the typical instruction at the Python interpreter. *NEW* 2. Embedded Python shell, within an html page. This is a bit similar to Ian Bicking's HTConsole. 3. Multi-line Python code, as entered in a traditional editor, and executed by Python. 4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig. Even though it is an early release, Crunchy Frog could probably already be useful in a classroom situation. To use it, you will also need to have installed Elementtree and CherryPy. Suggestion: read the 6 page long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in approximately 15 minutes (20 for Kirby, according to a previous message ;-) ... if you don't spend too much time playing with the new interpreter. :-) André
Dear Andre, Wish list for Crunchy Frog: 1. Fitting in with my previous brainstorming, the most important thing is allowing differential branching based on test or evaluate results. The most obvious is an alternate place to go when there is a test failure. With the possibly helpful Python error messages, a learner may well be able to go back and fix an error directly, so the suggested place to get specific help on the error should be connect to a "Help on the error" button, which the learner can choose to press after giving up on further editing of the code and further evaluation of the code. 2. A fancier version of reacting to testing would allow parsing of the error output and doing different things based on the error, for instance how many tests were passed before the first failure, or even based on the particular response to the test that triggered the error. basically encode logic like if no error: return topic23.html if first error on test 1: return e1.html elif first error on test 2: if output == '5': return t2_5.html elif output == '17': return t2_17.html else: return 2_other.html elif first error on test 3: if ValueError: return ve3.html else: return 3_other.html else: return other.html To allow arbitrary choice, one approach would be to actually allow Python code to be specified. I do not really like that idea: I would prefer not to have to worry about submitted lessons being able to execute Trojan code. Another alternative would be a list, in the order of the tests, with a URL for each location the first error could occur. In place of a URL there might be a list of pairs of output string and URL. I would have the final option be taken if none apply. The above logic would translate into something like the following where ... mean skip to the last line, and * is a wildcard topic23.html, e1.html, ["5":t2_5.html, "17":t2_17.html, *:2_other.html], [..."ValueError"*:ve3.html, *:3_other.html], other.html 3. I just checked, you illustrate several "evaluate" windows per page. However only one full interpreter seems to work per page or maybe per session. When I want cumulative results, with interspersed lesson details, it would be nice to give a response to the last typing, and then expect the user to type more into the same environment. For this we would want to copy the history from the last page, insert a new comment above the text box to the same interpreter, and then whatever buttons or other new stuff is due. Most flexibly, allow a next page to include a reference to insert the body of the last page at the top of the current one, followed by current page, with a text box for the interpreter continuing with the state for the same interpreter as before. Ideally allow logic something like 2 above to choose what to do next based on what the user types or the response. You should also be able to get a newly initialized interpreter if you do not want to continue using the old one. 4. I got Crunchy Frog hanging on my Windows XP machine when I clicked to start the tutorial. This was after I had run the tutorial multiple times with no problem and terminated normally. Sorry I do not remember what happened to give you a better idea at this point. I'll try to note the error environment more completely if it happens again. 5. It looks like you can see previous pages with the Firefox back arrow, but things get messed up if you try to interact with an old page. It would be lovely if the program would deal gracefully with that -- at least keeping a page ID and noting if an old page is submitted, and ignoring it and ?? jumping back to the last page in the sequence ?? I am not sure how to respond and not lose the sequence completely. I have further interests in adding and handling meta data. I will post those ideas separately. Andy Andre Roberge wrote:
Version 0.3 of "Crunchy Frog" has been released. It can be found at https://sourceforge.net/project/showfiles.php?group_id=125834
Crunchy Frog transforms a "traditional" Python tutorial into an interactive session within your favourite web browser. Four modes of interaction are currently possible: 1. One-liner, similar to the typical instruction at the Python interpreter. *NEW* 2. Embedded Python shell, within an html page. This is a bit similar to Ian Bicking's HTConsole. 3. Multi-line Python code, as entered in a traditional editor, and executed by Python. 4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig.
Even though it is an early release, Crunchy Frog could probably already be useful in a classroom situation. To use it, you will also need to have installed Elementtree and CherryPy.
Suggestion: read the 6 page long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in approximately 15 minutes (20 for Kirby, according to a previous message ;-) ... if you don't spend too much time playing with the new interpreter. :-)
André _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
Dear Andrew, Thanks for your message. There is lots of food for thought in there. I'll have to think some more about these issues, and I'm sure that Johannes Woolard will too. :-) I'll just give you (and other readers) a few quick first-impression comments. On 5/24/06, Andrew Harrington <aharrin@luc.edu> wrote:
Dear Andre,
Wish list for Crunchy Frog:
1. Fitting in with my previous brainstorming, the most important thing is allowing differential branching based on test or evaluate results. The most obvious is an alternate place to go when there is a test failure. With the possibly helpful Python error messages, a learner may well be able to go back and fix an error directly, so the suggested place to get specific help on the error should be connect to a "Help on the error" button, which the learner can choose to press after giving up on further editing of the code and further evaluation of the code.
Branching depending on test results: a) In terms of programming flexibility, it should be possible to implement a way to do this. b) In terms of curriculum design ... this is a lot more difficult to do. There are two possibilities I see: i) Identify the type of conceptual error that lead to a wrong answer. One needs to be prescient and figure out all possible wrong possibilities.... ii) Have a series of exercises by topic and, given a high failure rate in a given topic, redirect to simpler, more basic exercises on prerequisite topics to be understood. Again, I think it is more a curriculum design ('content') than a programming issue ('framework'). Crunchy Frog is intended to be a flexible framework. Perhaps I am missing something deep here... 2. A fancier version of reacting to testing would allow parsing of the
error output and doing different things based on the error, for instance how many tests were passed before the first failure, or even based on the particular response to the test that triggered the error.
basically encode logic like if no error: return topic23.html if first error on test 1: return e1.html elif first error on test 2: if output == '5': return t2_5.html elif output == '17': return t2_17.html else: return 2_other.html elif first error on test 3: if ValueError: return ve3.html else: return 3_other.html else: return other.html
Again, I see the framework to be design in a way that this could be accommodated... but the real challenge is coming up with the detailed course content. [snip]
3. I just checked, you illustrate several "evaluate" windows per page.
Yes. However only one full interpreter seems to work per page or maybe per
session.
True... at the moment. This is something I want to take care of. When I want cumulative results, with interspersed lesson details, it
would be nice to give a response to the last typing, and then expect the user to type more into the same environment.
Yes, I am planning to have this flexibility built-in. For this we would want to
copy the history from the last page, insert a new comment above the text box to the same interpreter, and then whatever buttons or other new stuff is due. Most flexibly, allow a next page to include a reference to insert the body of the last page at the top of the current one, followed by current page, with a text box for the interpreter continuing with the state for the same interpreter as before.
Actually, I see the interpreter as an environment for "quick and dirty" tests. I see the editor (which will need to be improved) as the place to do some more serious tests - with the possibility of "remembering" the input from editor on page N, after successful result (say of running a doctest) and putting it as an initial value in the editor on page N+1. Ideally allow logic
something like 2 above to choose what to do next based on what the user types or the response.
You should also be able to get a newly initialized interpreter if you do not want to continue using the old one.
Yes, there should be a way to restart the interpreter. (Right now, you simply need to reload the page :-) 4. I got Crunchy Frog hanging on my Windows XP machine when I clicked
to start the tutorial. This was after I had run the tutorial multiple times with no problem and terminated normally. Sorry I do not remember what happened to give you a better idea at this point. I'll try to note the error environment more completely if it happens again.
ok 5. It looks like you can see previous pages with the Firefox back
arrow, but things get messed up if you try to interact with an old page. It would be lovely if the program would deal gracefully with that -- at least keeping a page ID and noting if an old page is submitted, and ignoring it and ?? jumping back to the last page in the sequence ?? I am not sure how to respond and not lose the sequence completely.
I've started to look at that. Right now, it does not work for the interpreter .... and I am not sure it's worth trying to implement. I have further interests in adding and handling meta data. I will post
those ideas separately.
Andy
Andre Roberge wrote:
Version 0.3 of "Crunchy Frog" has been released. It can be found at https://sourceforge.net/project/showfiles.php?group_id=125834
Crunchy Frog transforms a "traditional" Python tutorial into an interactive session within your favourite web browser. Four modes of interaction are currently possible: 1. One-liner, similar to the typical instruction at the Python interpreter. *NEW* 2. Embedded Python shell, within an html page. This is a bit similar to Ian Bicking's HTConsole. 3. Multi-line Python code, as entered in a traditional editor, and executed by Python. 4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig.
Even though it is an early release, Crunchy Frog could probably already be useful in a classroom situation. To use it, you will also need to have installed Elementtree and CherryPy.
Suggestion: read the 6 page long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in approximately 15 minutes (20 for Kirby, according to a previous message ;-) ... if you don't spend too much time playing with the new interpreter. :-)
André _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin@luc.edu Chicago, Illinois 60611
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
participants (2)
-
Andre Roberge -
Andrew Harrington