It would be nice to have a single jlm.version number (used to name .jar file during the build process but also present in the jlm.properties file included in the distribution).

As the title says, if you type some java code in, then it gets used even if the chosen language is python. Annoying since you have to erase your Java code to do the lesson in Python

Currently, the interface is very slow to boot up because we need to run all entities in answer worlds to compute the desired state of the world. This can take up to a dozen of seconds when all lessons are enabled, and this limits the amount and size of test cases that we are adding to the exercises. For example, several nice turmites were not added because of the very large amount of steps mandatory to compute them.

Lazy loading was a try to fix this, by post-poning the computation of these solutions, but the best solution would be to serialize these worlds in the jar file so that we don't have to recompute them.

For that, the jar building process would be decomposed as follows:

• build the basic jar
• run the jar with the specific argument --serialize
• rebuild the jar and include the result of the serialization

This way should make sure that we don't have any serialization stale issue.

It would be great to add many shortcuts to be able to use JLM without a mouse. For instance:

• Ctrl+ PageUp or PageDown to switch tab in an exercise
• Up / Down arrows to scroll a lesson
• Ctrl + W to close the lessons window (with the tree view)
• tab or arrows to move in the lessons tree, and Enter to validate ("let' s go")
• few shortcuts for each button :
  • F1 for help
  • F2 to compile & run
  • F3 for step
  • F11 to reset
  • F12 for the demo

It is not complete, but it would be a good first try :)

Having more than one view per world, as it is the case for sorting worlds, is not the good idea that it seemed to be at the first glance. Instead, it makes the interface cumbersome.

So I think that we should merge both views into the same class / graphical area. Then, a right-click menu could allow to switch between them. Alternatively, a radio button group in the interactive panel could allow to give that setting too.

They are not translated to english, and could benefit from a little lifting somehow.

If you type some code and switch the exercise (w/o running it), your code gets lost. That's quite easy to fix, but it should be done.

The first reason is that some people may not like writing html directly, but the real one is that it would allow to greatly simplify the filtering depending on the class. The current solution based on the class is hackish because the support for CSS is very limited in swing, so we kill the text manually without using the CSS.

Help should contains all boolean operators (for instance, there is no indication that XOR is ^)

Some characters (e.g. quote character) must be escaped from tabname when generating source file to compile. Otherwise we get an invalid character exception when generating the URI to the file.

JLM does not have any automatic testing, which makes the hacking dangerous since you have to rerun all the lessons to check that you didn't break anything.

DrJava do have unit testing, and could constitute a nice souce of inspiration.

For example, we should try to compile and run the solution code of all lessons. Also, we should try to extract the student template for each exercise and check that it compiles nicely.

Students reported that left and right are mixed up in text. Because when we follow instructions it does not produce the same graphics.

While demoing the hanoi exercice, I got the following exception:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at jlm.universe.hanoi.HanoiWorldView.drawSlot(HanoiWorldView.java:57)
at jlm.universe.hanoi.HanoiWorldView.paintComponent(HanoiWorldView.java:42)
at javax.swing.JComponent.paint(JComponent.java:1029)
at javax.swing.JComponent.paintChildren(JComponent.java:862)
at javax.swing.JComponent.paint(JComponent.java:1038)
at javax.swing.JComponent.paintChildren(JComponent.java:862)
at javax.swing.JComponent.paint(JComponent.java:1038)
at javax.swing.JComponent.paintToOffscreen(JComponent.java:5124)
at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:278)
at javax.swing.RepaintManager.paint(RepaintManager.java:1224)
at javax.swing.JComponent._paintImmediately(JComponent.java:5072)
at javax.swing.JComponent.paintImmediately(JComponent.java:4882)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:785)
at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:713)
at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:693)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:125)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:641)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:602)
at java.awt.EventQueue$1.run(EventQueue.java:600)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:611)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)

As the title says, there is some execution paths where the step-by-step execution gets broken. It's something like the sequence "step" "step" "demo" "change exercise" "run". I'm not quite sure anymore.

The symptoms afterward are that the buttons think you are in regular run while the threads still try to acquire the semaphore.

Sorry for the fuzzy report, I guess that the first step would be to reproduce it.

For now, exercises are sorted per lesson, and are linear in each lesson. Although this schema allow nice pedagogical progressions, it is quite lame to have only this way of ordering.

Another solution would be to introduce tags and difficulty level to let the student pick what they want to do now. That would be good for smaller self-contained set of exercises. This can be connected to pedagogical objectives, as displayed in the "about this lesson" of the welcome lesson.

We can also explicit some dependencies between exercises and build automatically a DAG which could be represented nicely as in http://pingus.seul.org/images/screen_0.7.0-3.jpg Actually, our version would probably be less fancy so that we can rebuild it automatically when the set of exercises changes. JUNG would probably get used to display those DAGs.

As it stands, it is near to impossible to debug for the students with the amount of information that they get.

To reproduce the error, try for example to write some code in AltPairs that fail when the input string is of length <4. Since it is only tested in hidden tests, that's unpleasant.

For now, all output from all entities get mixed into the console. It would be better to have one tab for system messages and one tab per entity. This would greatly ease the possibility to debug using System.out.println() in the entity code (without having all the lines mixed).

Since all lines are put on one line only, // comments do very bad results. This comments should be removed altogether before concatenating the lines.

It happens in jlm.core.model.lesson.ExerciseTemplated.newSourceFromFile().

Object Oriented Programming is a classical way of code organisation that is often teached to the students in the beginning of their curriculum. But there is no lesson on OOP in JLM yet. In 2010, two students were asked to think about it, and the result of their reflexion is here:
http://webloria.loria.fr/~quinson/Research/Students/2010_toni_vourch-rapport.pdf
http://webloria.loria.fr/~quinson/Research/Students/2010_toni_vourch-slides.pdf

Now, two other students are asked to revive this work, and bring it to its termination. This bug repport aims at constituting a simple way to centralize the work on this front.

Etienne, Marion, remember, we want international individuals to participate to the project, so everything should be in english (as usual in science). No matter if your english is not perfect, we simply need others to understand what you write. Please create an account on github, and comment this bug report regularly to indicate your progress and difficulties.

Now that the linearity is gone, we are free to add more and more exercises to the welcome lesson. Ideally, they would show interesting constructions to arose the student curiosity. Since we want to populate the welcome lesson, sorting and recursion are not an option (simple exercise mandating these notions should be moved to the right lesson).

Here are some ideas:* Spirolaterals in LOGO (see THE ART OF SPIROLATERAL REVERSALS by Robert J. Krawczyk)

• L-systems in LOGO (see The Algorithmic Beauty of Plants http://algorithmicbotany.org/papers/#abop)
• LOGO allows to draw a whole lot of beautiful graphs, such as euler spiral (see http://jsxgraph.uni-bayreuth.de/wiki/index.php/Category:Curves)

Other ideas can be stolen from JavaScool http://javascool.gforge.inria.fr/

The exercises of this lesson have only one world each. This makes it possible to hardcode a solution like "forward(); turnLeft(); forward(2);" etc.

If we had several worlds (several different mazes with the same caracteristics) for each, this would become impossible, or at least very harder.

This should be quite easy with the Buggle World editor, which is hidden somewhere in the source tree.

Three words are used for « baggle » :

• « baggle »
• « baggel »
• « biscuit » (in french version of PledgeMaze for instance)

Wouldn't it be better to use one and only one name ? (whatever the chosen language) I would vote for « baggle » as in the function names (pickUpBaggle(), etc.)

The idea behind interactive controls is that they should allow the student to experiment with the code before running it for real. But unfortunately, it is too limited for now to be really efficient.

First, most world don't have interactive controls at all, and the one which have one do not give control to all functionnalities of the world.

Then, interactive controls get disabled when running step by step where they would really enhance the debugging experience. Of course, you shouldn't be allowed to pass an exercise by fixing some bugs in your code interactively and then running step by step.

Finally, some special reward should be given if you solve the exercise interactively. Mayby not a gold medal, but at least a silver one. There is an issue if you solve only one of the several worlds this way. I'm not sure of what to do in this case.

For now, there is no server for JLM and each instance is completely independent. Having a server would allow much more possibilities, such as leaderboards allowing the students to compare themselves to their friends, or the ability for the teachers to follow the progress of their students.

Indeed the twitter mode is interesting to see who's progressing, but as a teacher, you need to identify who's stuck in order to help them. A server seems mandatory for that.

A related idea would be to allow the level designers to see which exercises require much time and atempts to get solved (and thus require some more explanation and/or hints) and which exercises are solved very easily (and thus should be merged and or placed elsewhere in the progression).

Exercise description is is not very precise. We don't know what is exactly a junction.
Anyway, if mouse's movement are completely random then exercise is much more simpler.
Just a loop until it finds the baggle, then take a random3() direction. At the beginning, this solution was not enough performant. But now, since we can change the stepUI delay, it is sufficient.

We need a little button to the prev/next exercises in the lesson. Since there may be more than one such exercise, we would need to open a little popup dialog to ask the user which exercise s/he wants.

Then, that functionnality should be given a keybord shortcut, but there is already another bug report about it.

We should add a new exercise introducing the notion of Strings in Java. It would be placed after the arrays in the main track. So far, I have no good idea of what this exercise should be about.

We could ask the students to play with the messages on the ground, such as following a track marked not with color as in the snail exercise, but with textual hints. The hints to follow could be the string itself, to test with equals(), or a substring (like "follow the track of messages where the third letter is a 'A') or something else.

We could adapt the goAndGet exercise where the students have to read the messages on each cells of the row, and put them all concatenated on the bottom line.

Well, these ideas are not perfect, but that could constitute a good start (string, string equality, substring madness, any other notion maybe?).

Once these introduction exercises are setup, we could integrate the String Bat exercises in the welcome lesson.

For now, it makes no difference whether you solve the exo in Java or Python or whatever. The used language should be noted in the core, and displayed in the interface. Instead of the little star, you could get a cup for java success, a snake for python one and so on. And if you success in every language, you'd then get the star.

Also, solving the exercise through the interactive control should be detected and granted an extra kind of star. This would encourage people using the interactive controls to explore the exercises.

There is a specific lesson on arrays, introducing easy concepts such as finding the minimum in an array and so on, but it could be polished further and integrated in the welcome lesson.

Also, a 2D version with matrices would be nice. It would allow to do the last exercices of the Welcome lesson (on traversal) in good settings instead of perverting the buggle world for that.

Another idea with matrices is to introduce some imaging algorithms. See for example http://www.aracknea-core.net/wiki/Teaching/CuisinerLesPixels for inspiration (in french, sorry).

The demo of this exercise enters an infinite loop, failing to find the way out. That's really anoying since there is no way to stop it afterward, beside killing the JLM and starting it new.

There should be a little red box around the current exercise when openning the leesson navigator. I fail to understand why it's not the case:
vv.getPickedVertexState().pick(selectedLect, false);
vv.getPickedVertexState().pick(selectedLect, true);

(I tried to set it to false before switching to true in order to force a recompute, but it didn't work, obviously)

For now, one navigator gets openned each time you clic on ^E. This is not consistent with the help navigator and other external windows, where only one instance gets created, and it register to the right listener list to recompute its content when the lesson/exercise/whatever changes.

the lesson navigator should be made consistant.

It seems impossble to activate it right now... demo effect....

The remaining bat lesson was not integrated yet since it contains several exercises based on strings, which are not part of the welcome lesson yet. But it would be interesting to sort out the exercises that only depend on integer arrays, and move them in a specific new track in the welcome lesson.

There is a meta-lesson in the git, which aims at teaching how to write your own world and exercises, but it is far from being finished so far.

At time of writting, there is only the first exercise, about writing a new world is kinda working, but the exercise about writing entities for that world is not working at all. This should be fixed, as writing new exercises is something that the teachers really want to.

The first step may be to simplify a bit the way entities are written. For now, we have to write a large bunch of constructors simply passing the arguments to their super, and we may find a way to reduce that number, maybe.

For now, when the student edit their code, they have no way to move back to an older version of their code. It would be nice if we could have a sort of VCS in the session manager. It would allow the students to feel confident at testing new ideas, since their working solution would not get lost in the process.

A pure java implementation of subversion or something else would be needed, but it shouldn't be too hard to find something like this. Of course, integrating it properly in the interface to keep newbies friendly is a bit more challenging, but still feasible.

The world 'MonkeyTrouble' differs:
MonkeyTrouble(true,false) returned truewhile false were expected.

For now, the interface takes several seconds to start because it solves all the exercises to compute the solutions. It would be better to show the interface as soon as the first lesson is loaded, and load the other ones only on need.

There is some support code for this in the tree already, but it does not mix well with the session manager since the student code for lessons not loaded yet get lost on save. Maybe one session manager per lesson is the way to go? Or we could instruct the session managerS to reuse any student code they found that refer to an exercise they don't know about. Not sure.

In the french version, a capital letter is missing in the documentation : « pickupBaggle() » instead of « pickUpBaggle() ».

Each world class have a specific icon in the lesson navigator. When the exercise is passed, the icon is supposed to be starred. But right now, passed exercises always have a starred invader as icon, as if they were BuggleWorlds. That's problematic when the world is a BatWorld or something else.

It should be possible to switch from the current tabbed pane view to a split pane one. This is about the mission/code tabs, and also about the current/objective one.

If you click really quickly on the run button while visiting an exercise that is a bit long to load (lot of entities or need to load a scripting engine such as python while it was not loaded previously), you can easily manage to get an exception such as the following. For exemple, double-clicking on the run button of the Conditions exercise.

java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.remove(AbstractList.java:357)
at jlm.core.model.LessonRunner.run(LessonRunner.java:58)

I think that it comes from the fact that the Game locking (disabling the buttons) is done in the runner thread, allowing the AWT thread to issue a second command before the first one locks the door. This should be done in the action handler, which should itself be synchronized, and double check that the door is not locked before proceeding.

There is a Transformer in the code to fit the world size to the size of the available visualisation area, but the code seems to be adapted to square worlds. When the world is not a square (as it is the case for turmites worlds), a blue unused area appears at the top and bottom.

That should be fixed to maximize the usage of the screen space.

robozzle is a little programming game in the same spirit than lightbot. http://www.robozzle.com/

It would be nice to allow these worlds to be played from within JLM. It's not quite hard:

• we have to allow black parts in the world (with an exception raised if the robot get into it). This could be encoded as height=0 or -1
• We have to give a color attibute to each cell in the world
• we have to add some new commands such as "turn if red", "turn if green" and so on.
• we have to create automatic lights, which get lighted up automatically when the bot goes into the cell
• worlds should specify the world size, function amount and sizes from there construction.

Each javascript page of robozzle have all the information we need in clear text:
For example, http://www.robozzle.com/js/play.aspx?puzzle=644 contains:
var puzzles = [{
id:644,
title:"Right on red",
about:"",
robotCol:7,
robotRow:6,
robotDir:0,
subs:[5,4,0,0,0],
allowedCommands:0,
board:" gbbbbbbg b b b b b bbbbbg b B grg b b gbbg "
}];

That should be quite easy to take it out and reuse.

Alternatively, JLM could download the boards from the robozzle directly and allow you to play with all the boards of their set. That would be nice, but a bit of editorial work over their boards would be welcomed, maybe.

According to students (I didn't check), there is a mistake in the description of the lesson named "Courbe du dragon(2)".

Dans l'énoncé vous donnez des formules pour calculer les coordonnées de (u, v), cependant vous donnez deux fois les mêmes, alors que dans la méthode dragonInverse() deux signes sont opposés, et on devrait avoir :

u = (x + z)/2 - (t - y)/2
v = (y + t)/2 + (z - x)/2

Au lieu de :

u = (x + z)/2 + (t - y)/2

v = (y + t)/2 - (z - x)/2

As the title says, if you don't take the exercises in the normal order in the maze part, you have this error message.

It prevents the JLMfrom loading the .html file corresponding to the selected exercise but it still loads the good panels for the world view and the "code panel".

If you click on the button "Let's go" a second time, the .html file will be loaded, but the Exercise Selection Window still won't disappear.

Some padding (or a better solution) should be used to get correct line numbers in error messages

For now, we use the ZIP session manager by default to save the student code. It is nice to move their code from one machine to another, but it's a pain in regular settings since it's near to impossible to hack it from outside JLM.

A better solution would be to use the file session manager by default and have the zip session manager used whe, you import/export the session.

To implement this, we need an upgrade path where the existing code currently saved in the zip session manager do not get lost on upgrade. Testing for the presence of a zip file to import before creating the file session is the way to go.