I'm currently doing development for Google App Engine. This would be an ideal environment for kojonet: scalable, flexible and we can write in scala. The free quota is pretty good, but maybe Google would support an enhanced free quota for a worthwhile educational cause.

An example game that might be simple enough for the code to be understandable might work like this: The graphical display shows a race course. Players can choose the engine size of their car. Heavier engines give better acceleration and braking in the direction of travel, but less to the left or right (so slower through the corners). The driver specifies the direction of acceleration by moving the mouse in the elliptical acceleration envelope (which would move around with the car). One can imagine competing against other players on the same course: at least remembering high scores for different age groups. Many other simple games are possible.

I think security and privacy will be important. We want to know that the people involved are real children, and perhaps know their age. On the other hand we don't want real names and other contact-relevant info to be visible to the world. We want to know who the parents or teachers are as well. Perhaps a token credit card charge through Google Checkout? These are matters that need further discussion.

- There's a small (newline related) problem with the help() command (around the point where the help for version is printed out). I have not had a chance to dig into this yet.

Ah, I know what it is. A newline is supposed to be added to the beginning of the string, but that doesn't happen now that I broke up the procedure in two parts.

I've pushed a fix for it, unfortunately my wife needs to use the computer right now, so I can't test it.

ETA: tweaked the fix a bit, looks good now, pushed it, sleep, perchance to dream…

A couple of things:
- I fixed a small issue with code completion for saveStyle and restoreStyle.
- There's a small (newline related) problem with the help() command (around the point where the help for version is printed out). I have not had a chance to dig into this yet.

ETA: pushed!

The thought that we're done and might not add stuff in that area - is not, in my mind, a good reason to remove the net

Of course not. But if there is good reason to remove it (or rather, arrange it another way) and the feature list has reached the point where further additions will be sporadic, then it becomes just an onion in the varnish.

I'll think about this and post again later (in another thread, this one really needs to get back on topic :) ).

The main thing for me here is to keep documentation truthful. It will deviate from the truth unless it is tightly coupled with either testing or declaration. It's a good thing that Scala won't accept overrides of non-existent methods.

But I digress (in a big way).

Getting back to your idea - how about if we do everything that you have suggested, but keep the TurtleMover mixin for Builtins? That way we get all the benefits of your idea, but also keep that bit of the static safety net around (it has helped me many many times during development. The thought that we're done and might not add stuff in that area - is not, in my mind, a good reason to remove the net). Builtins can then just override the aforementioned methods - to gain the benefit of localisation and proximity to the code for help and completions.

I'm all for static checks, but seriously, how many more methods do you expect to add to the turtle?

There's one drawback, though ;(

If you add a method to TurtleMover, you lose the static check that ensures that Builtins implements the new method.

Builtins does not mix in anything. Instead, every user command is declared within Builtins like this:

 val synopses = new scala.collection.mutable.StringBuilder // the forward command def forward() = println("Please provide the distance to move forward - e.g. forward(100)") def forward(n: Double) = turtle0.forward(n) synopses.append("\n forward(numSteps) - Moves the turtle forward a given number of steps") CodeCompletionUtils.MethodTemplates("forward") = "forward(${n})" // the back command def back() = println("Please provide the distance to move back - e.g. back(100)") def back(n: Double) = turtle0.back(n) synopses.append("\n back(numSteps) - Moves the turtle back a given number of steps") CodeCompletionUtils.MethodTemplates("back") = "back(${n})" def help() = { println("""You can press Ctrl-Space in the script window at any time to see available commands and functions. Here's a partial list of the available commands: """ + synopses) }

Apart from making the set of user commands easier to document, and saves the reader the trouble to compare different places to see which commands are available, it also makes it easier to synchronize commands with the help message and with command completion.

The TurtleMover trait implements the aforementioned methods in terms of other methods that it declares. Anything that mixes in TurtleMover gets these implemented methods 'for free'.

The Turtle trait also extends TurtleMover. If we move stuff out of TurtleMover into Builtins, Turtles will lose these 'free' methods.

This isn't a problem in practice, but it does make it more confusing to document. Would you mind if I moved all totally defined methods (i.e. back, right, left, setPosition, setHeading, and home) from TurtleMover to Builtins?

I'll be happy to contribute if someone starts up a few wiki stubs.

I got some stubs going on the Project home page.

Flags

Interesting!

A programming game to implement approximations of the P63-65 programs (Braking, Approach, Landing)

Even more interesting!

Looking forward to seeing this stuff…

> Maybe Peter Lewerin, which had took the dive, and isn't intimidated by the wiki, can contribute…

It would be great to have a doc like this from Peter, from the perspective of a guy who dove into the code with very little help. Peter, are you listening?

Um yes, finally noticed this. I'll be happy to contribute if someone starts up a few wiki stubs.

Also, even though I missed this thread starting, I've been working on some problems that may intersect with this:

• Flags: It's almost trivial to draw flags using Kojo or Kojo/Staging. My idea to make it more interesting is to define a DSL layer between readable flag descriptions and the actual drawing primitives. Something like

// The Tricolor Flag width 2 length 3 colors List("#0055A4", "white", "#EF4135") verticalTriband

This could be used in a challenge/exercise to use the DSL to represent different flags or extend the DSL for more unusual flag patters (e.g. Guyana).

• A programming game to implement approximations of the P63-65 programs (Braking, Approach, Landing) in the Apollo Lunar Landing Module guidance system. The game would provide physics (velocity, altitude, attitude, gravity, fuel weight and consumption) and show the LM descending towards a moving surface. The challenge/exercise is to write three programs that can achieve the basic goals within the time/distance/fuel/etc constraints and are robust to instrumentation glitches (e.g. temporary loss of range/speed radar data) and other randomness (variations in gravity due to local mass concentrations, non-nominal engine burns, etc).

Also also thank you for kind words re Staging :)

Note: if the main motivation to use NetBeans is to have the jars, we have them already with the runtime version of Kojo, haven't we?

Your installation of Netbeans will patch your build.xml file to work for you (the first time you open the project). It might be theoretically possible to build Kojo without having Netbeans installed, but I have not tried this.

Netbeans is a much improved IDE, btw. I was an Eclipse user for many years before switching to Netbeans (for my Scala development needs), and Netbeans has worked pretty well for me.

I had no problems with getting the code. I am slightly annoyed to have to download and install NetBeans to compile it, but I understand the reason. I am mostly an Eclipse user now; I tried NetBeans some years ago, found it OK, but at the time it was doing only Java so I switched to Eclipse and didn't felt the need to look back.
Oh well that's an opportunity to test is again, and take a look at the JavaFX support.

Note: if the main motivation to use NetBeans is to have the jars, we have them already with the runtime version of Kojo, haven't we?

I will take a look at the translation possibilities.

providing some experimentations with Kojo

That would be great!

feeding the wiki

That would also be helpful.

I found that Kojo is a great way to play with the language… :-)

That's good to hear.

I am quite active in the Processing community, so I appreciate the StagingModule (impressive work!).

Yup - Peter's done some great work there.
What kind of stuff have you been doing with Processing?

Good idea. A quick tour/guide of the code, and maybe pointing out where to start for each feature, might make the project less intimidating to dive in… :-)

I'll do this.

Maybe Peter Lewerin, which had took the dive, and isn't intimidated by the wiki, can contribute…

It would be great to have a doc like this from Peter, from the perspective of a guy who dove into the code with very little help. Peter, are you listening?

I am doing a local hg clone to take a quick look.

Lemme know if you run into any problems.

Is there already a possibility to translate the interface? Or is it easy to add this capability?

• You can edit Bundle.properties under net.kogics.kojo to translate most of the Kojo Menu Items
• For the remaining stuff (provided by the Netbeans Platform), this link should provide pointers: http://eppleton.sharedhost.de/blog/?p=770

Funnily, the math playground is in French! I suppose that's the GeoGebra library which is translated.

Interesting! And yes, GeoGebra ships with multiple language files…

Account creation: might I suggest to mention that in the home page of the forum?

Done.

JFugue seems nice, from a quick look at the Web site. Easy to use, well in the spirit of Kojo. Maybe also add the playing of small MP3 files, in limited number. The restrictions I mention is to avoid using a whole (big, copyrighted…) song as background of a script. ^_^ But it would allow some sound effects (bang, woosh, etc.).

Maybe I should set up a list of features that need to be developed (a backlog), and see if there are people who want to come forward and work on things.

Good idea. A quick tour/guide of the code, and maybe pointing out where to start for each feature, might make the project less intimidating to dive in… :-) Maybe Peter Lewerin, which had took the dive, and isn't intimidated by the wiki, can contribute… ^_^' Right now, I am doing a local hg clone to take a quick look.

Account creation: might I suggest to mention that in the home page of the forum? I looked for a local link for account creation, I hadn't understood that it was part of a centralized network (Processing went to Zoho, which has a similar policy).
URL: I just wrote it in lower case, but it is still stupid… I just like to rant against sloppy programming. ^_^'

Ah, a last word on Kojo itself.
Is there already a possibility to translate the interface? Or is it easy to add this capability? I am French and I would like to introduce my children to Kojo, but it might be less intimidating to make them using an application in French. Well, the language will be still English-based, but that's a limited vocabulary.
Of course, I am voluntary for the translation to French! :-)
Funnily, the math playground is in French! I suppose that's the GeoGebra library which is translated.

Sharing area and upload button: that's a very good idea, although it needs some hard work on the site side…

I'm working on it in my spare time, and it is coming along well. Don't hold me to it, but I'm confident that the Kojo Code Exchange website will be up and running by the end of September. Users will then be able to just click a button within Kojo to upload their code and a picture to the website. The site will have support for upvoting/downvoting and comments.

A 'Level 1' book on Kojo will also be out very soon, to help get kids started with Kojo.

support of sound.

That's on my todo list, using JFugue.

good support of sprites

That's also on my todo list (this would be a feature within the Staging module).

Of course, if I do everything myself, it'll take some time for things to get done. Maybe I should set up a list of features that need to be developed (a backlog), and see if there are people who want to come forward and work on things.

I saw no way to create an account here, so my first post is a guest post…

Just go on over to the main wikidot site (www.wikidot.com) to make a wikidot account if you want to.

Wikidot is stupid, it believes that http://Phi.Lho.free.fr/ isn't a valid Web site address.

Did you manage to work around this? Your name in the header of your post links correctly to this address.

Look at Scratch, a software with similar goals to Kojo, but using very different means to reach them… (visual coding, coded with Squeak, a variant of Smalltalk, exporting to Java applets): I believe that part of its tremendous success among young people comes from the social side of the site, with users having accounts to show off their work (live as applets), forums to discuss these and coding in general, scoring system and such.
One just have to click on a button in the IDE to upload the program to the site.

Other things making Scratch fun (but a bit less flexible than Kojo): support of sound (you could add JavaSound, no? Midi and MP3 playing would be nice), and even more important, good support of sprites (moving them on screen, checking collision, auto-animation with direction change, etc.). This allows to make quite good games with surprising little code.
OK, perhaps the sprite idea is a bit far for Kojo spirit. Or not. It is your judgment, I just throw ideas (against Łukasz' one of keeping the feature set small…). ^_^

PS.: I saw no way to create an account here, so my first post is a guest post…
PPS.: Wikidot is stupid, it believes that http://Phi.Lho.free.fr/ isn't a valid Web site address. Is there a too primitive regex behind that, again?

If your reference to features alludes to the Staging module - keep in mind that open source software grows with different folks scratching their own personal itches. Staging is Peter's 'itch'.

1) Have a set of tasks to complete! I believe this is a great idea and should be central point of Kojo.

We're working on this idea with an Activity based ebook. The content will be tried out at a school here this term.

2) Create sharing area. Kojo could have "upload" button that will put example on some website with a screenshot.
Importing examples to Kojo should be easy as well.

2a) To improve 2) some ranking system should be created. [maybe something like StackOverflow.com would work]

That sounds great. Please pitch in to help with this in any way you can.

3) Kojo should by injected to computer courses in some high schools to find its weakest points as learning platform.
Important: the teacher should be someone unfamiliar with Kojo, but familiar with programming

We're working on something like this here in India - starting this term. If there's a high school in your area that's interested, I'll be glad to provide any support that I can to get it rolling there.

Ideas:

1) Have a set of tasks to complete! I believe this is a great idea and should be central point of Kojo.

2) Create sharing area. Kojo could have "upload" button that will put example on some website with a screenshot.
Importing examples to Kojo should be easy as well.

2a) To improve 2) some ranking system should be created. [maybe something like StackOverflow.com would work]

3) Kojo should by injected to computer courses in some high schools to find its weakest points as learning platform.
Important: the teacher should be someone unfamiliar with Kojo, but familiar with programming

I don't see anything more important than the above for future of Kojo.