gpoesia / loopye Goto Github PK
View Code? Open in Web Editor NEWA playful CS 101 course designed for children with a novel approach
License: GNU General Public License v3.0
A playful CS 101 course designed for children with a novel approach
License: GNU General Public License v3.0
There should be an explanation of the "senao" (or "else") behavior in the following places:
TODO
in the code)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.
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.
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.
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 changes to Robolang, which were discussed offline, such as:
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.
This is an umbrella issue for visual enhancements like:
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.
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
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
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.
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.
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:
Right now, there's only a plain <textarea> for the user to write code. This is an umbrella issue for enhancements like:
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 all issues related to rewriting our CodeEditor, which right now is a simple HTML textarea
.
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.
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
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).
The newly introduced reset button resets the position of the obstacles in lesson 01, but the robot remains where it was.
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.
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:
<textarea>
element, so that it can be accessed after rendering is done (https://facebook.github.io/react/docs/more-about-refs.html)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()
.
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.
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.
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.
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 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.