aroberge / crunchy Goto Github PK

Crunchy needs packages for all of the target systems:

  * Windows people expect an installer - maybe we can resurrect the NSIS
installer I started (or start another along the same lines.

  * Mac users expect a .dmg file (I think).

  * Debian (and Ubuntu, Freespire etc.) users want .deb packages.

  * Fedora users want rpms.

  * True power users (and developers) want the source in simple archives
like .zip and .tar.bz2.

Currently we only support the last of these :(

What steps will reproduce the problem?
1. Try the image file example on Windows.


What is the expected output? What do you see instead?
 A traceback is created as \ characters are mishandled.
(the problem is made worse if the path has non-ascii characters in it)

The old Crunchy code can probably be adapted to take care of both problems.
I (André) should probably take care of it, especially given the issue with
non-ascii characters - I am the only one having this problem.

These were found using the functional tests.

1) Code in separate editors is not independent.
2) Interpreter to editor doesn't work, although I believe Andre is working
on this.
3) The doctest in the functional tests is broken: it generates a javascript
error.

ATM, IO handling is woefully inadequate.

Comet might be a way to fix this.

See http://ajaxpatterns.org/HTTP_Streaming for details.

Basically this would enable output to be more or less lagless and should
make input easier.

What steps will reproduce the problem?
1. Starting from a fresh copy of crunchy, but without a temp directory
running an external program will not work.

Rather than writing temp files to the crunchy distribution, they should be
written in the user default directory.

The subject line says it all. (see issue 14 for reference)

What steps will reproduce the problem?
1. Hit the "Quit Crunchy Button"


What is the expected output? What do you see instead?
It should close th current tab, but it doesn't.

A sensible fallback might be to serve up a "You may now close your browser
window" page.

Currently, crunchy has a doctest feature which could be used to run unit
tests one at a time, by having a user click on a button each time.  This
would clearly not be suitable for automated testing.

At the same time, the doctest module has a feature where a user can run
tests contained in a text file, with tests (simulated interpreter session)
can be embedded in the file together with comments.  However, these text
files are not visually interesting to read.

As a first step, it would be interesting to have a new vlam mode, perhaps
called doctest_unit_test, where tests would be kept in a Crunchy ready html
file and could be run either individually (at the click of a "local"
button) or globally (at the click of a "global" button).  The only content
of such files would be texts, simulated Python session and execution
buttons i.e. no editing facility (textarea) would be needed.

Such a feature may be seen as useful for people doing test driven
development, encouraging them to use Crunchy.  This could be later extended
to other types of unit tests.

Eventually, with a txt2html utility, a lot of the formatting issues could
be handled automatically, and existing ".txt" doctest files could be converted.

Currently, Crunchy loads "full" menus.  It would be useful to have the
ability to load customized menus, especially when geared to beginners - the
full set of references for making crunchy tutorials would not be useful.

These bugs were found using the functional tests.

1) The tool-tip isn't supported.
2) Auto-indenting doesn't work.
3) Sessions are not shared across interpreters.
3) sys.exit() can close the interpreter session.

1-3 are debatable features (1 and 2 at least we can probably do without for
now).

What steps will reproduce the problem?
1. Go to standard test pages using andre's branch.
2. Relative links are broken.

What is the expected output? What do you see instead?
See Johannes's branch for a proper working version.

The plugin system needs finalising.

See CrunchyPluginAPI in the wiki for more details.

I can (and am willing to) do this, but will need guidance/second opinions.

What steps will reproduce the problem?
1. run the colourizer test (/src/test/colourizer.html)


What is the expected output? What do you see instead?
The page doesn't even load :-(

The terminal gives the following traceback:

Exception happened during processing of request from ('127.0.0.1', 3632)
Traceback (most recent call last):
  File "SocketServer.py", line 222, in handle_request
    self.process_request(request, client_address)
  File "SocketServer.py", line 241, in process_request
    self.finish_request(request, client_address)
  File "SocketServer.py", line 254, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "SocketServer.py", line 521, in __init__
    self.handle()
  File "BaseHTTPServer.py", line 316, in handle
    self.handle_one_request()
  File "BaseHTTPServer.py", line 310, in handle_one_request
    method()
  File "/home/johan/workspace/crunchy-dev/src/crunchyrequest.py", line 47,
in do_GET
    page = crunchytute.VLAMPage(handle, 'file://' + path)
  File "/home/johan/workspace/crunchy-dev/src/crunchytute.py", line 57, in
__init__
    self.process_body()
  File "/home/johan/workspace/crunchy-dev/src/crunchytute.py", line 96, in
process_body
    self.process_pre(pre)
  File "/home/johan/workspace/crunchy-dev/src/crunchytute.py", line 178, in
process_pre
    self.substitute_editor(pre)
  File "/home/johan/workspace/crunchy-dev/src/crunchytute.py", line 217, in
substitute_editor
    elem.append(widgets.Editor(widgets.EXEC_BUTTON, text))
  File "/home/johan/workspace/crunchy-dev/src/widgets.py", line 79, in __init__
    elem.append(Code(text))
  File "/home/johan/workspace/crunchy-dev/src/widgets.py", line 116, in
__init__
    elem = parseListing(code)
  File "/home/johan/workspace/crunchy-dev/src/widgets.py", line 143, in
parseListing
    for tok in tokenize.generate_tokens(in_buf.readline):
  File "tokenize.py", line 236, in generate_tokens
    raise TokenError, ("EOF in multi-line statement", (lnum, 0))
TokenError: ('EOF in multi-line statement', (4, 0))

I think we just need to get error handling into this part of the system

Here is a suggestion for future link handling within Crunchy (very much
thoughts in progress):

Rationale:
Currently, handling of external links is adequate, but not perfect. It
would be better if Crunchy had a chance to inspect a page before the user
attempted to load it. However it would be prohibitively expensive to load
every link from a page before processing it.

Justification:
In the new COMET IO model, server->client communication is cheap and fast.
It is possible to have a much closer tie in between the python back-end and
the browser front-end.

Method:
When a user clicks on a link, instead of the browser immediately loading
the relevant page, the page sends a notification to the back-end. The
back-end can then load the page, judge if it needs VLAM processing and send
a message back to the server indicating if and where to redirect the user to.

For instance if the link points to example.com, then crunchy can download
example.com and see that this particular page wouldn't need processing.
Crunchy could then direct the page to go to example.com.

If however the link points to somevlamtutorial.com then crunchy can
download this tutorial, and direct the user to a locally cached (cached in
crunchy that is) copy of the VLAMISED tutorial. 

In this way, links in tutorials need only be analysed at "click-time" and
material could be cached locally for enhanced performance.

Further optimisations could include analysing the link and beginning to
cache the tutorial as soon as the user hovers over the link to it.

Caching is a natural progression in the current direction that crunchy is
taking.

What steps will reproduce the problem?
1. try test_run.py with some arbitrary html file

What is the expected output? What do you see instead?

The chosen html file should be displayed; instead we see the default index
page.

Currently canvas elements have to be defined explicitly in VLAM. Wouldn't
it be nice if every editor was also a canvas that only displayed the actual
drawing area when needed (ie. when init_graphics() is called).

The title says it all.  Note that this option is only on Andre's version at
the moment (December 27, 06).

Title says it all really.

I just started this as a place to log problems/progress.

I've started getting some basic VLAM handling in, doing multiple page
support right now.

What steps will reproduce the problem?
1. type in "range(" at the interpreter prompt, while running Crunchy on a Mac.

What is the expected output? What do you see instead?

A "tool tip" should appear on the right hand corner of the display, showing
the docstring for the range function.  However, nothing appears.
This is due to the fact that KeyCode events are different on the Mac.  It
can be fixed using CharCode instead (with a few other corresponding
changes).  This fix has been done locally by André on a Mac and
needs to be checked under Windows and Linux.

What steps will reproduce the problem?
1. Wait until enough tutorials exist. (see Issue 1)
2. Attempt to find a tutorial tried previously...

What is the expected output? What do you see instead?
It should be easy to find, but there's no way currently to remember
location of tutorials.  A system of bookmarks might be useful.

What steps will reproduce the problem?
1. Go to standard tests (andre's branch)
2. Try javascript interpreter

What is the expected output? What do you see instead?
Nothing is displayed.  The following error appears on the console:
[snip]crunchyfier.py", line 405, in strip_prompts
    lines = text.split('\n')
AttributeError: 'NoneType' object has no attribute 'split'
Johannes' version appears to be fixed.

What steps will reproduce the problem?
1. Have a path that contains a non ascii character, such as found in André
2. Try saving a file from the Editor

What is the expected output? What do you see instead?
We get a message that the file is not found.  Note that this may work (by
chance) on some system depending on the local encoding - so that the
problem may not be reproducible.

What steps will reproduce the problem?
1. Go to the index page for Python tutorials.
(menu Tutorials -> Python tutorials)

What is the expected output? What do you see instead?

There is no box for loading local tutorials

The cause is the introduction of the security module

With Firefox (and IE) on Windows XP displaying images doesn't work in the
SVN trunk (Comet).  Checked on Ubuntu 6.10 and Mac OS and it works.

You can check this by opening the Graphics functional test (or any tutorial
that has an image associated with it).  The
test.png file isn't shown at all.

Some further diagnostic (by andre.roberge):
* [false lead:] Looking at the html source, I noticed that a closing
</img> tag was added by Crunchy; I tried to modify the original file
to make it appear the same, but it loads the image in Firefox just
fine with the closing tag (as it should).
* Right-clicking on the broken image link to view the image gives the message:
"The image "http://127.0.0.1:8002/functional_tests/test.png" cannot be
displayed, because it contains errors."
* images loaded from external tutorials ("Links" test, with the link:
http://127.0.0.1:8002/remote?url=http%3A%2F%2Fcrunchy.sourceforge.net%2Fsrc%2Fht
ml%2Feditor.html)
work just fine.

What steps will reproduce the problem?
1. Go to standard tests
2. Try the colorizer test

What is the expected output? What do you see instead?
The warning is in bright yellow in Andre's branch (not very visible) and
bright red in Johannes (better, but could be improved.)

We need plugins for all of Crunchy's functionality not handled by the core.

As far as I can remember this can be summarised as:

  * Editor              (X)
  * Doctest             (X)
  * Interpreter         (X)
  * Local Files         (X)
  * Remote Files
  * Custom Styling
  * Menus

(Items marked with an X have at least a skeleton implementation)

and I'm sure there is more...

In order to avoid having potentially a lot of typing to do when reproducing
an interpreter session, crunchy has an option for "interpreter to editor"
where the simulated input is put into a textarea, ready for execution at
the click of a button.  While the code in that textarea can be easily
changed, the disadvantage of this using this kind of interactive elements
is that to reproduce a long session, the entire code has to be copied over
into the textarea, as each is run indendently.

By contrast, many interpreter inputs may appear on a given page, each
sharing the same interpreter backend.  Thus, and interactive session can be
reproduced, interspersed with explanations and new entry points for the
interpreter.  A complementary option might be to give the ability to
"inject" code into an interpreter.  Thus, by clicking on a button, the code
above an interpreter input could be fed to the interpreter with the result
appearing as though the user would have typed that code.  The user could
then use this as a starting point.

This type of approach would especially be useful if one has to interrupt
going through a "long" interpreter session.  Upon starting a new crunchy
session at a later time, rather than re-typing all the required code to
resume the session, one could click a few (perhaps many) different "inject
buttons" to bring the interpreter to the desired state and continuing the
learning process from that point on.

A particular, but slightly different example, might be for something like
an elementtree tutorial.  At the top of the page, one could define a string
representing an appropriate xml document which could be fairly long.  By
clicking on the "inject button", that string could be fed to the
interpreter and the tutorial as such could proceed from that point forward.

What steps will reproduce the problem?
1. Go to the index page for Python tutorials.
(menu Tutorials -> Python tutorials)

What is the expected output? What do you see instead?

There is no box for loading external tutorials

The cause is the introduction of the security module

What steps will reproduce the problem?
1. create a page with an internal link (one that stars with a #) 
2. try to follow that link


What is the expected output? What do you see instead?
The page should move to make the link visible, but it doesn't

The sf.net site desperately needs updating.

I can do it once I'm back from Germany around new year.

Ctrl+C on Windows doesn't break the main loop (in crunchy.py), whereas on
Ubuntu (Linux) and Mac OS everything works as it should.  I think this is
related to the Python socket lib, though.

What steps will reproduce the problem?
1. Select French as a language option
2. Go to menu Didacticiel -> Utiliser Crunchy
3. Select the Editor
4. Run (Evaluer) the code in the box.

What is the expected output? What do you see instead?
We should see the first error line with an à à on it.  Instead a
question mark appears.

Note that this is obtained after a line 
# -*- coding: utf-8 -*-
has been inserted in all Python files and the coding in the ".po" files has
been changed to utf-8 as well.  The html page encoding has also been set to
the same value.

However, and this is the really puzzling feature, if in translation.py,
function build_dict(), we change the line from
        line = line.decode("utf-8")
to
        line = line.decode("latin-1")
then, the labels on the buttons are showing a wrong encoding BUT the error
line is showing the à (à) properly.

What steps will reproduce the problem?
1. create a pre element with something like <pre>&gt;&gt;&gt;
1<br>1<br>&gt;&gt;&gt; 56 * 347<br>19432</pre>

What is the expected output? What do you see instead?
This displays incorrectly: because the text attribute of the ElementTree
only contains the first block of text in the element, the rest of the text
is in the tail elements of the br elements.

We need to flatten the contents pre elements intelligently - and make sure
that we handle all cases sensibly, not just br elements.

What steps will reproduce the problem?
1. Write a some style code (with html markup) inside a <pre> with no title
attribute.


What is the expected output? What do you see instead?

The code should be styled.  Instead, at least in the latest version
(andre's branch), the code does not appear.  Earlier versions may also
exhibit the same behaviour.  This can be looked at in the vlam_summary.html
page, at the end of the "Interpreter to code editor" section.

What steps will reproduce the problem?
1. In Ubuntu, start Crunchy without first starting Firefox

What is the expected output? What do you see instead?
The crunchy start page should open, but instead firefox's home page is
displayed. I'm pretty sure this is a bug in webbrowser, not Crunchy.

Here's a short overview of how it might work:

1) You give crunchy an URL for your data (which it fetches using urllib)
2) crunchy opens a page that has an editor box and some controls at
the top and a preview pane at the bottom.
3) inside the editor crunchy iterates through all the likely candidate
elements (still need to figure out exactly how to find these) and
highlights the matching section in the preview.
4) every time you hit apply or next in the editor section the preview
pane is updated
5) whenever you click next crunchy moves to the next candidate element.
6) as a backup, crunchy can display the whole source of the file,
instead of just the individual candidate elements.

What steps will reproduce the problem?
1. Use an editor (either textarea or toggled to editarea)
2. Enter enough code to trigger the vertical scrollbars.
3. Scroll the page so that the editor goes by the location of the hidden
save & load dialogs

What is the expected output? What do you see instead?

Nothing special should happen.  However, the part of the page that goes by
the dialogs appear to be frozen, and the editor scrollbars are not visible. 

Guess: the z-layer of the hidden and save dialogs is fixed to a large
number.  We should probably set it to a small number by default and only
set it to a large value when calling it and making it visible

What steps will reproduce the problem?
1. Enable the Selenium plugin
2. Load in large amount of code in editarea toggled editor

What is the expected output? What do you see instead?

Nice text with syntax colouring is expected.  Instead there appears to be a
shadow text underneath, messing up the visual display.

Solution: disable Selenium

This problem has only (so far) been noted on Mac OS.

Next step: incorporate this problem and solution in an FAQ

What steps will reproduce the problem?
1. Enter some text in a textarea in Firefox (with spell check enabled)
2. Some words (e.g. __init__) will be underline in red

What is the expected output? What do you see instead?
The red underlining can be distracting to the user; it should be turned
off.  I believe this is an option in EditArea which will need to be enabled.

What steps will reproduce the problem?
1. Run the interpreter test (/src/test/jsinterp.html)


What is the expected output? What do you see instead?
The textbox at the end is completely gaga

What steps will reproduce the problem?
1. Go to the index page for Python tutorials (menu tutorials -> Python
tutorials)
2. Load in the default remote tutorial using the button at the very bottom
3. Try to click on a link on that tutorial.

What is the expected output? What do you see instead?
We should get a valid page.  However, the page is not found.

Note that if we use the hard-coded link on that same index page for Python
tutorials, the links are working properly - but the pages are not converted
as crunchy tutorials.

What steps will reproduce the problem?
1. Create a test html file with an external style sheet (either main one,
or alternative).
2. Load the file through the browse/load local tutorial option in Crunchy.
(From the menu Tutorial -> Python tutorials)
3. Try selecting the style file in Firefox (menu: View -> Page Style)

What is the expected output? What do you see instead?

The style file does not appear as a valid choice in Firefox.  If we look at
the source, it lists the path as absolute.  For example:
===
<link href="file:///src/css/b-w.css" rel="stylesheet" title="Black and
white" type="text/css" />
<link href="file:///E|/pycon.css" rel="alternative stylesheet" title="Pycon
slides" type="text/css" />
===

Also related:

User-defined *alternative* stylesheet should probably appear last (after
Crunchy default) following processing by Crunchy.  User-defined *main*
style sheets should continue appearing first.

We should make highlighting in code elements possible (not just in pre
elements). Should be trivial in the COMET branch.

This was originally suggested by Toby Donaldson

There have been requests for a method of automatically grading student
assignments. Crunchy can already grade on a pass/fail basis - all that is
needed is a way of reporting this information to a teacher in a centralised
manner.

One way to do this would be to build a Crunchy "Grading Server" that
individual crunchy clients can connect to whenever a DocTest is run. This
server would log all the relevant details such as the student's name, the
code run and the result of the test.

The server would then be able to report a simple pass/fail to the teacher
for every student and (optionally) give more detailed statistics of what
the student did before achieving that pass/fail.

This, in my humble opinion, would be an extremely useful feature for Crunchy.

What steps will reproduce the problem?
1. Use the editor
2. Type in the textarea: print "     Hello world!"

What is the expected output? What do you see instead?
The expected output is
     Hello world!
The actual output is
Hello world!
i.e. the space at the beginning is lost.

This is likely caused by the embedding of the output in a "span" tag
instead of a "pre" tag.

What steps will reproduce the problem?
1. Go to the official Python tutorial
2. Click on a sub-section link (it will be a relative link # within a page)

What is the expected output? What do you see instead?
It displays the page from the top rather than bringing the focus to
the relative link.

To reproduce the problem:
1. go to http://www.google.com
2. search for "python tutorial"

Expected Result:
Lot's of beautiful 'crunchified' tutorials.

Actual Result:
Lot's of mundane static tutorials.

Applies to:
Currently all versions of Crunchy on all Operating Systems.

Additional Information:
Clearly this is a sub-optimal state of affairs and soemthing must be done
to remedy it! I suggest some strong evangelising throughout the Python
Community and beyond...

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

What steps will reproduce the problem?
1. A user reported that konqueror was opening when Crunchy was started, not
displaying any page - firefox had to be manually started and the link put
in explicitly. 

Proposed solution:

1. Have the possibility of registering a preferred browser in a config
file, and look for it when starting Crunchy.

What steps will reproduce the problem?
1. Create an image file by doing the matplotlib example 

What is the expected output? What do you see instead?
The code needs to be executed twice.  By "tracing" it, it appears that the
thread finishes after the GET command is issued.  We probably need a way to
communicate that such a thread is alive and do a while loop waiting to
process the GET.