gpoesia / loopye Goto Github PK

The UI should have a way of quickly visualizing the commands and goals of each lesson. As discussed, this can be put on the right side of the canvas, as a slim panel which basically lists all commands and important information for that lesson.

This is an umbrella issue for changes to Robolang, which were discussed offline, such as:

• Changing the commands to Portuguese (e.g. "E" instead of "L" for turning/moving left)
• Changing the syntax of the "if-else" statement to be more readable and similar to existing languages
• Changing the keyword and syntax for while loops

In Lesson 01, the first step that uses the "D" (right) command doesn't have its description on the reference panel. It should be there already.

One issue that confuses students is that the Code Editor loses focus when they advance to the next step. Then, many times they start typing and only then realise they need to click the editor first. Focusing the editor by default when a new step begins would solve this problem.

The implementation would be basically to give focus to CodeEditor's <textarea> element whenever it is rendered. This would involve the following:

• Set a "ref" callback to CodeEditor's <textarea> element, so that it can be accessed after rendering is done (https://facebook.github.io/react/docs/more-about-refs.html)
• In that callback, call the element's focus method (https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/focus)

There's a chance this will not work because of the pop-up we show in the beginning of the step. If so, we'll probably need to call focus when the pop-up is closed. By looking at react-popup's code, it seems this can be done using popup.addCloseListener(callback) (https://github.com/minutemailer/react-popup/blob/master/src/index.js). Then, this callback would need to indirectly call textarea.focus().

I've observed this with two children: when they forget what each button means, they often click the wrong one. We should probably differentiate them in some way.

If the player runs a correct code, and after it has been accepted runs it again and advances while it runs, the animation continues and the new step is not rendered.

This may be closely linked to #45

This is an umbrella issue for visual enhancements like:

• Adding backgrounds to lessons.
• Making the lesson environment interface more appealing and intuitive.
• Enhancing sprites and animations.

It's common to observe a single small pause during animations in lessons (does not occur in the test animation). It could be due to a GC pass, some interaction with React, or something else.

The intention of ResourceLoader was to pre-load resources to the browser's cache before something that depends on those resources. However, it's not guaranteed that the browser will cache e.g. images and have them instantly loaded the second time we load it.

How to reproduce the bug: in lesson 2, by the time you reach the first leaking battery, it will probably not show up unless you press the "reset" button (it's intermittent, though, as it depends on a race condition).

ResourceLoader eargerly waits for resources to load, and only proceeds when they were loaded for the first time. We should store these resources somewhere and then, instead of creating them again, loading them from the ResourceLoader.

We're using a stormtrooper in the place of a robot, and not using actual asteroids. The sprites should be changed, which also requires updating the functions that create them in util/animator/element_factories.js.

If a player presses "Play" and then "Reset", the "Reset" action is basically ignored. It is expected to work, since sometimes errors are detected before the program finishes (or even gets close to finishing) and the player wants to stop the erroneous.

There should be an explanation of the "senao" (or "else") behavior in the following places:

• the instructions message of the first level where it is needed (marked with a TODO in the code)
• the command reference, starting from the same level as in the previous item

If you try to play the same wrong code multiple times, the error messages stack up on top of the editor. This eventually makes it impossible to see the code and the canvas at the same time. It's also undesirable since the code can be modified from one click to another, but the error messages from the first will still show up.

The fix would be to simply clear the error messages when the Play button is pressed.

Especially in lesson 3, the robot can take very long (sometimes more than 3 minutes) to execute a single step.

As discussed offline, a fix would be to add a button that speeds-up the animation (say, by 8x). Then, the player can watch in normal speed until some point (e.g. until she checks correctness in the first iterations of a long loop), and then skip the rest.

The implementation for this would involve adding a new state variable to the animator, storing the time at which the speed-up started (if it did at all). Then, time after that point is counted as multiplied by some factor. This would need to be integrated with the UI: another button would be added to the ButtonBar, which should trigger the action of setting the speed-up beginning in the animator (if it's not already set).

How to reproduce: Run something like "100000{R}" on any lesson.

Because we run all steps and render the animation in advance (and JavaScript is single-threaded), this hangs the browser (or at least our tab in the best case). Even if we allowed it run, it doesn't seem like a good idea.

The fix would be to simply set a limit on the number of iterations of bounded loops. For what we have now, 10 would be enough for all existing levels.

In lesson 3, if the robot is already holding a component and it executes another G command, execution halts with an empty error message. It should show a message related to what happened: the robot can only hold one component at a time.

This is probably just a typo in the message's constant name:

• The constant is defined here: https://github.com/gpoesia/comp4kids/blob/master/src/constants.js#L34
• And referenced here: https://github.com/gpoesia/comp4kids/blob/master/src/lesson/lesson03.js#L530

With the current animation framework, it's possible that an animation to change a property from 0 to 10, for example, actually ends when the property is at 9.8, and leaves it that way. It may happen because during the update loop we simply check to see if an animation is active and if so update the property. However, it may happen that one update leaves the property at 9.8 and the next update happens at a time later than the end of the animation, whereupon it's ignored, and the property never reaches 10.

This can be fixed by ensuring that all finished animations receive an update at its final state.

In some lessons, there is a code size limit. With the old editor, it was not possible to type more characters than the limit. The new editor allows to type more than the limit. However, when hit the Play button, only the number of steps up to the limit is executed anyway.

As reported by @vrod, steps to reproduce:

1- Open lesson 2 (not necessarily)
2- Run code with a loop without the block_end token. Example: "9{F"
3- Try to fix the code (you won't be able to).

The effect is that the editor will keep resetting the code to its previous state, in which it doesn't work. Also, no message is shown.

The bug is probably that TokenStream.consumeToken (https://github.com/gpoesia/comp4kids/blob/master/src/language/robolang/lexer.js#L41) does not check that there are tokens left to consume. This breaks because some ASTBlockNodeParser will expect an "}" after all tokens have been consumed.

The newly introduced reset button resets the position of the obstacles in lesson 01, but the robot remains where it was.

Right now, compilation errors are simply written at the top of the code editor. Which part the message refers to should be clear.

This is an open-ended project. It will probably involve several modifications to the CodeEditor, and also keeping track of source code locations in the parser, besides making the link between both modules.

Umbrella issue: #67

Right now, when the code is modified, the game is reset to its initial state. Some students prefer to write code incrementally (which is good), and this hinders them, since they cannot see in which state the existing code ends and build upon that. Modifying the code should probably not immediately reset the game. There's already a reset button if the student wants that.

The modification involved would probably be to simply not call _reset() in LessonEnvironment.componentDidUpdate() (https://github.com/gpoesia/comp4kids/blob/master/src/view/lesson_environment.js#L164)

This is an umbrella issue for all issues related to rewriting our CodeEditor, which right now is a simple HTML textarea.

Right now, there's only a plain <textarea> for the user to write code. This is an umbrella issue for enhancements like:

• Implementing automatic indentation
• Closing brackets automatically
• Syntax highlighting
• Highlight the part of the code being executed

This happens because the image may load after the canvas has been drawn. A fix would be to only start the lesson after all resources load.

This sometimes also used to happen to the "Play" button.

While the code is running, we could highlight what part of the code is being executed. This would create a strong visual link between the code and what it is doing, and ease debugging.

Umbrella issue: #67

grid_cell_size is currently not optimal when multiple puzzles are used in a lesson step (Lesson01ExerciseStepPlayerMulti).

For instance, when n_cols is too small, a lot of space is left unused (since grid_cell_size is currently computed as stepPlayer.game.gridCellSize() / nPlayers). See step 11 for an example.

On the other hand, when n_cols is too large, there is no distinction about where the grid for the n-th puzzle ends and the n+1-th puzzle begins. See step 13 for an example.

The ideal is to compute grid_cell_size, as well as the elements' positions, in a way that both problems stated above are not present.

Code: src/lesson/lesson01.js

The animation framework uses the CPU after the whole animation finishes because it still checks for active animations even when they all finished. This can be simply fixed by avoiding window.requestAnimationFrame calls when the whole animation has ended.

As of now, the optimum grid size is 10x10. That means when a grid smaller than 10x10 is created, it occupies less space than made available in canvas. It is more critical for grids greater than 10x10, that end up rendered out of canvas.