childsplayosu / bogl-editor Goto Github PK

Integrate stack/npm together somehow, with a makefile or Nix. This should probably be done in the super-repo Spiel

Current syntax highlighting is haskell, which works to an extent. There was some work done in src/SpielHighlight.js, but it needs to completed so we can get proper highlighting for BoGL.

A maximum size limit should be imposed on how large of a file we are willing to send to the language server. Otherwise there is a possibility that a student could get cheeky and send a file several GBs in size that could slow things down, or max out something.

Additional options for sharing were requested, as internally we already have everything setup for sharing the prelude and gamefile code. A suggestion came along that mentioned possibly having 3 buttons (or ways) of sharing a prelude, or a gamefile, or both of them together. This would allow instructors to share just a prelude and let students code from scratch on their own, or to share both of them to give students some starter code to work with. The changes for this would be entirely frontend, as everything is already in place on the backend to support this.

For example, in ConnectFour we have:

type Input = Int

However, I can do this

> True

true
Switched back to normal mode.

Additionally, it can cause this, where null is output.

> let x = input(initialBoard) in x + 1

null

What should happen is that it should be parsed, type checked, evaluated, and then put the result in the input buffer if the type is correct. This may require some changes on the back end and in that case I can try to help.

There is some logic in the frontend in src/Repl/Repl.tsx on Line 245 that filters out duplicate boards. This is done to prevent the same board showing up multiple times as a side-effect of 1 or more place calls during a computation. In previous cases this was desirable to avoid redundant boards showing up, but it also has an unintended side-effect itself of shadowing newer boards with older previous boards; creating the appearance that new boards aren't showing up on the display.

A possible fix for this would be to simply filter the duplicate boards from Right -> Left, favoring newer boards over older duplicates, but this should be looked into further for a cleaner fix overall.

A better fix would be to utilize the frontend state to compute the diff between the last list of boards (if any) and the list provided from the current computation. There are still issues with this approach as well, including dealing with boards produced from unrelated computations, or even desired duplicates (3 places on separate boards that happen to be equivalent in their final values).

with electron, we can use the native file save/load prompt to get the location of where the user wants to save/load. with that, we can just pass it to the API

Entering in 5 (with a leading space) gives an empty prompt in the current bogl version. It's a subtle bug that's present in the terminal-in-react package we are dependent on. There is a bad check here, and the cause is further up. A slight adjustment would fix this, but the project appears to be dead.

The solution is to fork it, make the patch, and then target our fork instead of the outdated package. This will give us some flexibility for future modifications as well.

I think it's due to trying to print out the error to the CLI

Currently we do not have access to the prelude on the front end. To be clear, I don't mean a tab where it can be edited, just that the functions from the prelude are not exported.

The way it works in the parser is that it looks for a .bglp file in the directory of the executable. For me this gets placed in /home/grejuca/.local/bin:. Perhaps we should change the way this works, especially if we are going to be hosting it on an OSU server. Maybe the front end can send two files over or combine the prelude and the file to be sent? @m0deran @calgagi @bwarschauer thoughts?

Talking with the instructors who will be using this language, it's been indicated that we would like to be able to share a prelude among students in a class. This could be done by giving students the actual prelude file to copy in themselves, but since we want to hide it from the students, it's been suggested this should be done with minimal interaction on their part.

A possible solution that I've been thinking of would incorporate an ability to 'Share' a prelude. This would surreptitiously save the prelude with a random id, and then return a crafted url, like http://...?p=49108413909. Upon visiting that url, a student's environment would first read and load the prelude with the matching name as the id, and use it to populate their own prelude. In addition, there should be a reset button for the prelude, allowing students to shift back to the prelude they first loaded in (in case they change something an break it).

In addition, it may be helpful to allow this share functionality to share both the prelude and gamefile. This would allow instructors to craft and share pre-crafted complete examples for students to work with, especially custom made ones as the curriculum evolves.

The tool still has the 'Editor' link which goes to the default page that should be started with. It needs to be carefully removed since there is another page somewhere that looks the same, but has nothing on it. Once that's fixed up, that link can be removed.

Also a Help/Info/About link should be added that goes to the docs, which are at https://the-code-in-sheep-s-clothing.github.io/Spiel-Lang/ (but in the future will probably be hosted at bogl.engr.oregonstate.edu as well).

i think I'm loading the wrong page by default

README needs rewording to match the new tool usage.

We get a cool installer, but electron and react won't talk to each other on windows for some reason.
The error thrown is that window.require is not a function. This works on both mac and linux.

Electron has its own task bar. We can either use that instead of the nav-bar, or we should get rid of it. I'm in favor of using it: we can then have nice shortcuts and it will integrate with the user's OS nicely

From Martin:
Two minor change suggestions:

[✔️ ] Remove the square brackets around "BoGL says" messages (done)
[___] If possible, we should use 3-4 different text colors:
- for user input in the interpreter
- for output/responses by the system (we could further print error messages differently from ordinary output)
- for user input when BoGL is inout mode

Either write a nix derivation (guarantees build reproducibility by design) or verify via other means that other people can produce builds

The current loading of a shared prelude is a bit ad-hoc and improvised. It performs an initial load, and then afterwards reloads again to clear the link. This should be a single load, without a reload. Using some persistent data clientside can achieve the same effect without the confusing double flash.

(EDIT by @montymxb ) Adding that this issue has been partly resolved with regards to input reprompting until a valid expression has been formed. In addition, input(board) is no longer valid in the current syntax, but there is still a need to report the type expected vs. the actual type provided. Putting this here so it can be seen first, as this issue has a long string of comments.

The prompt tells me that it switched back to input mode, but this does not appear to be the case. The next time I call input it just grabs whatever is on the input buffer. Either we should not print this and require them type clear (bad interface) or actually switch.

I think the clear command is not good because then we have the situation of an undefined/nonvalue. For example if I enter let x = input(initialBoard) in x + 1 and then clear, how do we evaluate x + 1?

Anyways, here is the output of the REPL not actually leaving input mode despite what the message says.

> let x = input(initialBoard) in x + 1

Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty
Empty	Empty	Empty	Empty	Empty	Empty

Switched to input mode. Type "clear" to go back to normal mode.

> 3

4
Switched back to normal mode.

> let x = input(initialBoard) in x + 1

4

Boards of large dimensions (ex 10x10) do not display properly in the interpreter window. The layout of the board is correct, but the limited window space results in content folding over itself a bit, creating an uneven view of the board.

To rectify this, the interpreter window can be modified to allow side scrolling Left to Right. This would allow boards to be viewed in their original dimensions, but will allow other large expressions to stretch out far to the right. This could be a UI problem, as they won't be entirely visible without explicit user interaction.

The share feature has some bugs still present, in particular:

• clicking the share buttons doesn't always copy paste the result into the clipboard as expected (Kina's case)
• loading the share link doesn't always bring up the same code
  • this one seems to be in part related to the fact that first 'share' is clicked (which generates the file to share), and then the buttons to share are shown. This is a bad interface design, and it should be simplified as much as possible
  • ideally, we should reduce it back down to just 'Share', and on each click it generates a new share link, copies to the clipboard, and updates the shown link (in case the copy fails).

I have not tested this on a non-mac.

When holding "command" and clicking on multiple lines, the user can enter the same text on each line clicked. Not all text will show though unless you click to prelude and back, then the invisible code appears.

Users that frequently use "command-z" to undo may encounter this error if the click to fast directly after.

Noted an odd auto-tab bug related to how CodeMirror handles Enter on blocks.

Starting with this:

    a valid line

and hitting enter to do this

    a va
lid line

and hitting delete to go back to the prior

    a valid line

looks okay, but flipping to the prelude and back to the code tab, or reloading the page, shows this:

    a va    lid line

This issue is patched in #47 , but I wanted to document it separately here. Looks like upon enter CodeMirror was adding the space equivalent of what a tab should be to keep code indented at the same level. The problem being that the auto-added indentation did not show up in the editor until the page was reloaded, or you switched to viewing the prelude/code window and back again. This set up a really odd de-sync between what was displayed and what was actually stored, and could lead to some really nasty errors showing up without realizing what was wrong.

For example:

> command True

true

Input mode cannot be tested with the current testing setup. The existing test suite does cover other cases, but these tests should be reworked to allow for easier integration with the testing of rendered components. Once this is rectified we can run a full functional test, very close to a full UI test, for how given inputs produce certain results, and to verify their correctness. This will also help us formalize how input mode should behave in specific cases.

Adding that recent behavior has been observed where input mode can become 'stuck' after failing to resolve a given value. In particular the following example:

game HelloWorld

type Input = Int

y : Int
y = 2

x : Int
x = input + 2

With the inputs of [x,x,2,x] can get stuck after a clear and some previous runs. The full replication has been difficult to perform, and additional details should be added here as we find them.

Change input mode character (>input) - Struggling to do
LOW: Get rid of load button or make it work properly - Done
Better error/board parsing - Done
Remove input mode when not SpielPrompt - Done
Remove parse error item from command input array when error happens - Done (Implemented on backend)

I see this on Firefox 74.0 and Chrome 79.0.3945.88 on Ubuntu 18.04.4. If it is not an issue on Mac and Windows then it's not worth fixing.

During our demo with Prof. Erwig I noticed the following output for a type error:

SpielTypeError: [object Object]

This just means that the associated object was printed literally. The actual data needs to be pulled out and presented as a string instead. This could be done quickly with JSON.stringify(obj), just to verify everything is there, but could be cleaned up for students & instructors to read a bit better. Overall, just a little thing.

If a program has been shared via a link, a 'Reset' button should be present in some form. Such that if mistakes are made (or if the program does not populate properly in the window) it can be manually reset back to what it was shared as.

Here is an example of a bad parse of the line bad = 33:

SpielParseError: 37,5,game,"\"=\"\"=\"\"=\"\"=\"\":\""

Share link should have a copy button or something similar to make it a one-click setup, should work on the major browsers: Firefox, Chrome, Safari and Edge w/out issues.

This is more of an experimental idea, but it was suggested that we could put the REPL window into a 3rd tab on the UI. In this fashion, there would be 1 for code, 1 for the prelude, and 1 for the execution of both. An experimental version of this could be rolled out to see how users like it compared to the existing setup.

What we decided in the meeting is that an administrator would have the ability to write a prelude and they could provide URLs to students which load that specific prelude. The easiest way to do this would be to use filepaths in the URL. Don't know if that's the best though.

This is a little note more for myself, need to remember to add in a 'Tutorials' link at the top of the editor window.

This is best explained with a visual. Here is a short video.

The result of spiel-front should be a static website that can be built. Setting up some CI that verifies the site can build with new changes, as well as publishing that build when on the master branch would be helpful.

Static builds can be performed via: npm run build, which constructs a standalone static website under the build directory.

Currently we're running a development setup to test with that serves itself via react, but this doesn't allow properly setting up HTTPS, and has some other issues. Down the road we will be serving the statically built site via some other web service software, such as nginx or apache.

The type of the Input prompt message should match the expected type of the input. Ex:

"Enter a value of type <Type>."

It would be somewhat useful to be able to view the version number or commit hash of the front and back end that the website is running.

After typing in a number of commands I noticed that the first thing you type eventually becomes hidden by the top bar. This doesn't happen until you type enough inputs that you have to scroll through the terminal screen. This was seen on Firefox 74.0, Mac.

We decided that due to potential vulnerabilities and overhead for managing files, space usage, and accounts, the best approach would simply be to not save files and just send program contents directly to the back end.

Requested to add the ability to quickly populate the editor code window with an example, and to limit typos that students could introduce in trying to copy one by hand.