They need to remove themselves from the DOM, or weird things start to happen.

Runtime-error srcloc links get red backgrounds. Parse-error srcloc links don't. This is weird.

Redirecting from pyret issue 177...

fun show(w):
  I.place-image(I.text(w, 24, "black"),
    50,
    100,
    I.square(250, "solid", "light green"))
end

used with

  W.big-bang("", [list:
  ...
      W.to-draw(show)
    ])

produces

Error: expected Color, but got "light green" definitions at 13:4 <no stack trace>

If you use a negative number on its own line, it indents as if you were mid-subtraction, e.g.:

call-some-fun(
  x,
    -1,
  y)

It should keep the -1 on the same indent level as the x and y.

The following code

fun add4(w, x, y, z): w + x + y + z end
add4(3, 4)

currently complains about an arity error on line 1, with no indication that line 2 is at fault. So does the following code:

fun add4(w, x, y, z): w + x + y + z end
add2 = add4(1, _, _)
add2(3, 4)

Part of this problem was a bug in anf-loop-compiler, now fixed in brownplt/pyret-lang@ca6e870, but the remainder appears to be a problem in guessing the probable error locations -- do we still need that heuristic for anything?

I have a a file that uses definitions obtained using the following:
import my-gdrive("streams.arr") as S

Any annotations using ::S.Stream result in an "Couldn't find the annotation named Stream in the annotations from S" error. But running the same code with a ::Stream binding in the REPL for streams.arr works just fine.

The “compute a derivative” example on CPO fails, because ‘within’ is now part of the language. https://code.pyret.org/editor#share=0B32bNEogmncOWU9OWW5MSFlHSDQ

The CM mode for pyret does a good job of tagging relevant syntax for styling, but right now all the colors (with the exception of comments) are so similar that I honestly didn't realize they were different!

The most common whiteboard marker colors (in descending order) are: black, blue, green, red, orange, purple.

I'd advocate strongly for keyword, variable, function-name, etc to be black, number literals to be blue, strings to be green and boolean literals to be dark-red. Personally, I like orange for comments (it stands out less than everything else), but purple would be fine for this as well.

The is operator ought to indent on the new line; one or both of these ought to work:

long-call-to-set-things-up([list: even, longer, args])
  is really-long-answer

or

long-call-to-set-things-up([list: even, longer, args])  is
  really-long-answer

1. open a new file, with the code:
   x=4
   x=5
2. click run

EXPECTED: error message listing both locations, separated by a line break, a comma, or something
RECIEVED: definitions: line 1, column 0definitions: line 2, column 0

When trying to left-click any of the links in the "More" menu on Horizon, nothing happens (things work fine on master). @blerner and I have narrowed the cause down to makeHoverMenu in share.js (replacing this with master's version fixes the issue), but we have yet to find the particular issue within the function.

We should at least have an onbeforeunload handler to prompt folks to save. We may also want to stash stuff in localStorage so they have something to come back to even if things crash harder.

Currently, the semantics of changing a filename is to rename the existing file.

This is consistently confusing for users. A better flow is probably:

1. Changing the name and clicking "Save" creates a new file.
2. More... has an option for explicitly renaming the file (or even the file has to be renamed in Drive, since this is much less frequently necessary)

(Extension of a conversation we've had in other contexts)

How should the string "ä" display as REPL output? There's an argument for showing the unicode value, or the character itself. IIRC, we'd decided that this would be handled much in the same way we handle rationals: toggle between both forms onclick().

Based on the most commonly used whiteboard marker colors (in descending order: black, blue, green, red, purple, orange), I propose the following for literals

cm-number: blue
cm-string: green
cm-boolean: darkred (red looks too "angry")

black should be reserved for brackets and keywords, and/or lines a teacher draws on the board. I'd suggest comments show as orange or purple, but I have much less attachment to how those are rendered. Proposals welcome.

When all tests pass, it's hard to tell because all of the tests print. If there are no failures, the REPL should just print:

Looks shipshape, all XX tests passed, mate!

with appropriate singularization/pluralization. This makes it really visually easy to tell if you're all good and should be happy, or if something failed and you need to find the failure.

This was recently added to the jsworld implementation that whalesong uses (soegaard/whalesong@0064ec2), which is virtually identical to Pyret's. This functionality is one of Bootstrap's most highly-requested features, which was recently added to WeScheme.

Every time I open the console I will see messages "Uncaught TypeError: CodeMirror.runMode is not a function". This is because runMode is a CodeMirror's add-on, and it's not loaded automatically.

And, even though we manage to load runMode, it will still not work. The third parameter to runMode must be a callback, but echo is not.

Sometimes, highlights from errors or test cases can get stuck in place, if you run and the element is lost before the mouseleave has a chance to trigger.

In general, it's probably a good idea to run clearAllMarks when the definitions window is run, just to clear any stale state that may have been floating around there.

From brownplt/pyret-lang#505:

type VertexOptions = {
  color :: I.Color,
  printer :: (Any -> String)
  }

The editor doesn't de-indent the closing }.

(I think this fits more under CPO than pyret-lang, but feel free to correct me!)

It would be useful to have a statement that prints information about a given value. This may also be a necessary step towards #60 .

Playing with rational toggling, just got the following output:

I don't really understand what's going wrong there.

When the editor page is loading vs. when it fully loads, the top-left corner UI is weird. In the loading state it shows a well-centered Program Name text field and More button, while once it loads it gets rid of the Program Name field and the centering is lost. Why is the Program Name field shown if it is to be immediately removed? And what happened to the centering?

TO REPRODUCE:

fun draw-world(current-world): 0 end  
fun next-world(current-world): 1 end

big-bang(0, [list: on-tick(next-world), to-draw(draw-world)]
)

EXPECTED:
Something vaguely readable by humans

ACTUAL:
JsworldDomError: expected a Text or an Element, received [object Object] within [object HTMLSpanElement], [object Object]

When moving the mouse over the test results, if it moves over several that are off-screen, the red "offscreen" indicator flashes many times. It ought to not re-flash if it's already in the middle of it's animation, because if you trigger a dozen flashes, it can sit there flashing even when the mouse has been moved away.

data Foo:
| foo(x:: Number)
end

fooA = foo(42)

student tries to get x out of fooA...

Foo.x

Another common error uses the lowercase foo as the object. These errors happen a lot in BS:2. Having a really good error message for them would be awesome.

This leads to buggy highlighting of e.g. arity mismatches when a function at the REPL calls a function in definitions. All of the *-ui.js modules need to take a dictionary of editors, rather than just the most recently-run editor.

css rule:

{
cursor: pointer;
}

I would make this change, but I don't have the complete list of what values are toggle-able.

Clicking on them doesn't do anything either...

Value-producing expressions at the top level should print to the Interactions Area when a program is run.

Right now, all the test cases print in the same repl output color, so it's hard to scan for the failing tests. I'd suggest that we print the passing tests in green, and the failing tests in black or red, so a quick glance can more easily discern where I should start looking for failures.

When we get a 401 response from GDrive, we should be re-authenticating silently in the background. If this fails, we need to alert the user somehow, because it causes weird behavior in saving (messages like "program saved as undefined", which isn't true).

Need to check:

1. If reauth() is actually just not working, and fixing that function would help
2. How we can gracefully handle failure, and if we'll need to get the user to click something so we can reopen a popup to authenticate

This is a little hard to test on expiration, because it takes an hour for credentials to expire!

We probably want an option to save the program to localStorage so a user can refresh without losing valuable state.

Evaluating range(0, 10000) at the REPL hangs CPO for 5-10 seconds. Evaluating range(0, 100000) hangs it for a very long time, and no output at all is shown while it's busy thinking, nor is there a way to stop the rendering. The stop button isn't active because nothing is "running"...

Originally opened at brownplt/pyret-lang#546

An example of a working Image picker can be found in WeScheme, at https://github.com/bootstrapworld/wescheme2012/blob/master/war-src/js/openEditor/editor.js#L571-L659

import world as W
W.big-bang(0,[list: ])

Gives: TypeError: Cannot read property 'firstChild' of undefined

(FWIW, this actually works in Racket, showing the number 0 in a modal window)

This test:

check:
  triangle(50, "solid", "green") is triangle(55, "solid", "green")
end

Currently prints the test output:

Reason: values not equal:
[object Object]
[object Object]

This rendering shouldn't try to tostring() the test case directly, but should extract the values and use renderPyretValue (https://github.com/brownplt/code.pyret.org/blob/master/src/web/js/output-ui.js#L704) to draw the images inline (which will automatically thumbnail them, etc).

Some new highlighting rule (maybe to do with matching keywords) seems to be making words look "fuzzy," like there's some alpha gradient to white on the edges?

Not sure what change made this happen, but it's kind of disconcerting.

(define ü 42) doesn't work, and I can guarantee you that you'll get some requests for it. Was this an explicit design decision?

I made my 100th CPO file today, and hit the pagination limit for the "files" request, and a few odd things started happening.

First, there was a naive traversal of all CPO-created files to find the "code.pyret.org" folder, which could miss (since the folder is created before all files, it's on the second page). So that got an update in 4a35cd5, because it could cause CPO to think that this was a user who didn't have a CPO folder yet, and would create a new empty one for them.

This leaves the need for an interface that can handle "next page"-type links, or at least chains through the next-page links and consolidates the whole list onto one page.

A user should be able to see all their Pyret files without opening a separate tab and being confronted with the GDrive interface. This is especially valuable for schools, where teachers may want to avoid showing students GDrive altogether.

Arity mismatches and a few other errors use a heuristic of "the top user-defined stack frame" to guess the location to report. If the stack doesn't have any frames (for whatever reason), or if the stack consists only of built-in frames, undefineds can result and break other parts of the rendering. This needs a more principled solution for what to show.

Loosely paraphrased from @shriram : "It's 2015, and we're still designing languages that can't support meme generation natively?"

Proposal: text-font should support a 9th argument (boolean), that causes the text to be rendered as white with a colored stroke. I considered overloading the "style" argument, but that seems like an uglier kludge. This change has been implemented in WeScheme (demo at http://192.wescheme.appspot.com/openEditor?publicId=fzUP5QlHU0).

When rendering the "items" view of a nested list, CPO produces the following transition:

It would be better if the inner list contents popped down, keeping everything else in a fixed position.

See my comment in 55f523d

This comes as no surprise to anyone, but I've been knee-deep in it with WeScheme for the last few days so I figured I might as well file a report. This is based on the Pyret program found at https://code.pyret.org/editor#share=0BzzMl1BJlJDkeFFTUVhURk1rd0E&v=v0.5r1428

1. Caps lock is ignored (CapsLock+k -> k, instead of K)
2. Shift modifier is ignored (Shift+k -> k, instead of K)
3. Alt/Opt modifier is ignored (Alt-c -> c, instead of ç)

I don't know how much of the old jsBigBang code Pyret inherited, but here's the issue: the only way to get modifier keys (shift, alt, etc) is to listen for keydown events, and the only [easy] way to get the modified character (ç) is to listen for keypress events.

I briefly attempted to reconstruct the typed character solely from the keydown event, but that got complicated fast. For WeScheme, I instead signed up the key-event handler for both down and press, and then had it sift through some conditions to know when to ignore one and listen for the other. It feels like a bit of a fragile solution, but I don't expect anyone to re-assign the extended ASCII character set anytime soon. :)

Hope this is helpful!

When running a program in c.p.o, the Run button is properly disabled, but the Shift+Enter hotkey is not, leading to "An unexpected error occurred: [object Object]" printed in the interactions pane, and an "Internal: run called while already running" message exception in the error console.

No matter how tall your monitor, once your program gets long, you're stuck writing at the very bottom of your screen. There doesn't seem to be an equivalent of C-l in Emacs to re-center things. Maybe this is fine by kids these days, but I find myself adding a bunch of blank lines to the file...

In case there's an option to do something about this in CodeMirror, it'd be nice to enable it. And if not, perhaps file a not-expecting-to-be-fixed-soon request.