[Edu-sig] Crunchy Frog 0.3 released
andre.roberge at gmail.com
Wed May 24 20:53:11 CEST 2006
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
On 5/24/06, Andrew Harrington <aharrin at 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
> return 2_other.html
> elif first error on test 3:
> if ValueError:
> return ve3.html
> return 3_other.html
> 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
> 3. I just checked, you illustrate several "evaluate" windows per page.
However only one full interpreter seems to work per page or maybe per
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.
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.
> Andre Roberge wrote:
> >Version 0.3 of "Crunchy Frog" has been released. It can be found at
> >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
> >*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
> >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. :-)
> >Edu-sig mailing list
> >Edu-sig at python.org
> 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 at luc.edu
> Chicago, Illinois 60611
> Edu-sig mailing list
> Edu-sig at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Edu-sig