Right now, when a program runs for a long time, it will cause a crash when it returns, as the client will run out of memory. It would be better to stop running the debugger and maybe even switch to the 61A interpreter if this happens.

Ctrl+S shouldn't pop up a dialog, if you're a compulsive Ctrl+S clicker like me the dialog keeps popping up

(I noticed this issue due to the ridiculously long stack traces for KeyboardInterrupts, but it applies generally as well)

the program

(define (loop n)
  (if (zero? n) (/ 1 0) (loop (- n 1))))

(loop 300)

generates a 1204 line traceback. The Python program

def loop(n):
    if n == 0: 1/0
    return loop(n - 1)
loop(300)

generates the traceback

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in loop
  File "<stdin>", line 3, in loop
  File "<stdin>", line 3, in loop
  [Previous line repeated 297 more times]
  File "<stdin>", line 2, in loop
ZeroDivisionError: division by zero

which is 8 lines long (the [] are actually in the output). We should probably do something similar; though since we annotate with the frame, a simple string match would be insufficient. I think in practice clipping out the intermediate part of a stack trace is completely fine.

You can't select and then click Ctrl+C since it unselects immediately. Not sure how to fix.

So

scm> (define define +)
define
scm> (define f 5)
f

should work properly, rather than raising an error.

On a related note, unquote outside of quasiquotes should raise a different error.

If I run

(define (loop) (loop))
(loop)

then it uses a ridiculous amount of memory

this linearly increases, which means it ate 16% of my 8GB memory in 22s, which means it's eating 58 MB/s.

Either it should error with a max recursion depth or it should tail recurse

If you write a program involving graphics and stick in in OK and then terminate the process while it's running from the GUI, you get a segfault (!!)

Maybe related to #43 ?

Issue associated with #67

To reproduce:

• Run

(define (loop x)
  (if (= x 0)
      (/ 1 0)
      (loop (- x 1))))
(loop 2000)

in a new file

• Run (define x 5) in the console
• Open the environment viewer and hit "finish executing the program"

Expected:
The global frame should be open with x = 5

Actual:
2000 other frames are open.

Fix:
Add a client-side check to skip over frames from a previous execution that have closed. Perhaps look at their most recent assignment, and compare it to start_i of the present expr?

There's a memory leak (?) where if you run a command that eats a bunch of memory, it doesn't seem to free it when that command is terminated, or even when you hit Run again, which should reset everything in theory

So if there's lab.scm and lab_extra.scm, both should have a Test button.

To reproduce, replace hw10.scm with (/ 1 0). Then open the first test case. The output starts with:

; expect Traceback (most recent call last):
(load 'hw10)

;        0
;        (/ 1 0)
;        Error:
;        division by zero
; expect identity

which makes no sense

^ title

You are allowed to use square brackets in scheme, for readability

e.g., (define (f x) [* x (f [- x 1])])

If it's run in a terminal (like in PyCharm, at least on Macos) and PyCharm is closed, then the editor will keep running and occupy the port. It should detect when it's running in the background and terminate itself.

the buttons should work, and it should be equivalent to nothing happening in the file

If the .scm program has syntax errors or crashes when you import / load it, the OKPy window will show incorrect grading.

We should backup when they run tests, and if the backup fails, show an error message.

To reproduce this "bug":

• type some code into the editor
• click run
• modfiy the code in the editor
• type something into the console dependent on the modified code
• the old code is run instead of the new code

I see 2 ways of fixing this

1. warn you in some way that the results are stale
2. re-run the code silently on every save.

Even though they do in the tree diagram. Weird!

This is more a long-term thing, but we need to have, like, some test cases for this interpreter before deploying it to students.

Right now there are like 5 doctests, all of which fail.

Make them special forms, not just magic Symbols.

Make turtle graphics work.

Preferably before releasing hw 8, which will happen today evening at some point

There are some issues with the handling of let + define, where it isn't always clear how arguments are assigned in the env diagram. The new debugger improves this, but mimicking the behavior of scheme.pythonanywhere.com would be ideal.

Right now, if you rerun a test case, it'll open in a new window, rather than displacing the old one.

Currently, locked testcases don't behave properly when running okpy tests - this should be fixed before the first lab.

Not sure why but it takes a while for an infinitely looping test to be stopped.

Programs like

(/ 1 0)
)

run and then cause a crash in the interpreter that is not returned to the user.

Seems to be when the first expression has an exception, the second one is not parsed.

If I type ' the editor adds a ' right after my cursor. This is incorrect behavior since in scheme ' isn't a before/after thing.

This works but shouldn't

>>> '[1 2 3)
(1 2 3)

I tried opening HW10 and clicking the "Environments" button, and a console with the following tab popped up

But like it didn't have any contents? Not sure how it works

Open a console, and paste in:

; expect (quote dog) 
(apply id (quote ((quote dog))))

; expect dog 
(apply id (quote (dog)))

; expect (quote (dog)) 
(apply eval
       (quote ((quote (quote (dog))))))

; expect (dog) 
(apply eval
       (list (quote (quote (dog)))))

; expect (quote dog) 
(apply eval
       (quote ((quote (quote dog)))))

and the editor crashes. ???

Would be useful for live demos - type a command, see what happens to the visualizer. But this shouldn't screw anything up if the user is not already at the front - i.e. they should be able to stay in their present position if they so choose.

The inbuilt Scheme docs are incomplete.

Comments placed above an expressions should not be moved to the right. Example:

    ; comment
    (+ 1 2)

becomes

(+ 1 2) ; comment

when the original formatting was already correct.

Since the formatter is called many times with basically the same inputs when stepping through the debugger, it causes an unnecessary slowdown.

Right now the way factorial is formatted is literally

(define (fact x)
  (if (zero? x) 1 (* x (fact (- x 1)))))

this is hard to read. We should force block special forms define-function, if, let, ... to span multiple lines

The debugger and environment diagram views rely on the program having previously been run. It should be the case that you can hit "Debug" / "Environment" and the program should immediately rerun.

Questions:

• If the program has been run, modified, and then the user hits "debug", should the program run again?
• Should this behavior change depending on whether a debug / environment diagram view is already open?
• Should it automatically run the program, or just tell the user to hit "Run"?

Related to #9

Currently it doesn't which makes it hard to glance at your code and fix the error.

The way this software handles non-terminating programs could be better.

I suggest allowing the user to cancel programs from the run terminal within the webapp, perhaps by trapping Ctrl+C, or perhaps by adding an explicit stop button (a la IntelliJ/Eclipse)

Idk the extent to which students have this muscle memory, but when I want to modify the previous command I hit up and then left some number of times. Here that puts me at the beginning of the line, since the whole thing is selected instead of just copied.

...to like just run the current line instead of adding a newline to the current prompt.

Maybe like Ctrl+Enter?

Not sure if this is fixable, but Ctrl+W should not close the entire editor, just the current code window.

The staff interpreter has the following error

scm> . y
Traceback (most recent call last):
  0	(variadic y)
Error: Cannot evaluate variadic symbol