Kogics

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.

Thanks for the answers, filled with good news, but that's a lot of work for you! :-)
Not sure if I can help much, but I can try in some minor fields, like feeding the wiki, providing some experimentations with Kojo (as I agree with the first part of ?ukasz statement…), etc. I don't have much free time (job, wife, 3 kids…) and I have some other activities (open source, drawing…).
I start to have some experience in Java programming (and some other languages, like C and more recently JavaFX) and I just started (this week!) to learn Scala. I found that Kojo is a great way to play with the language… :-)
I am quite active in the Processing community, so I appreciate the StagingModule (impressive work!).

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.

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.

Processing: nothing ambitious, mostly little experiments in Java2D mode, and I spend quite some time helping people in the forum, learning new stuff in the process… :-)
For the curious people, you can find most of my code at Processing experiments on Launchpad. Next to my Kojo code and my Scala code, among others.

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.

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.

> 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 :)

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…

When documenting Builtins in ScalaCodeRunner, I noticed that the back command isn't actually defined in Builtins. Since Builtins mixes in SCanvas and TurtleMover, methods defined in either of those are silently defined in Builtins too.

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?

That will cause a problem, Peter.

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.

Oh, right. I don't work with multiple turtles very often, so I didn't think of that implication. I'll try to find another solution (or just try to document it anyway).

How about this, then:

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.

I like the idea a lot - especially the fact that it promotes less coupling between different parts of the codebase, and everything related to builtin commands moves to one place (which promotes good cohesion).

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.

Look at it the other way: you'll be able to add methods to TurtleMover without automatically adding them to Builtins at the same time.

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

The thing is, Builtins is a TurtleMover in the strongest sense of the term. In fact, the ideal conclusion to this line of thinking should be - the removal of Builtins!. This would help us accomplish another goal - code completion for Staging without the val S = Staging hack. Here's how that might work:
- Builtins goes away. The builtins var inside the interpreter points to Turtle0. Things continue to work like they do now for Turtle mode
- the user says use(Staging) (or something like that) to switch to Staging mode
- the builtins var inside the interpreter switches to Staging, and Staging is imported inside the interpreter
- Code completion and interpretation now work for Staging without any prefixes!
- the user says use(Turtle) (or something like that) to switch back to Turtle mode
- the builtins var inside the interpreter switches back to Turtle0, and Turtle0 is imported inside the interpreter
- things now work transparently for the Turtle

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.

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.

So, do we have a plan of action for this one? Or did I scare you off from making any changes ;)

Heavens no. While I write this, NetBeans is running tests on the rewritten Builtins. I'll push a changeset later so you can have a look at it.

ETA: pushed!

Took a quick look. Looks cool.

Refactored Builtins pulled, merged, and pushed back out. The new stuff looks great!

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.

- 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…

Incorporated.
Thanks!