This happens even when there are no changes in the patches. Initial profiling suggests that it's just modelruns checking for differences. I'll have to talk to @nicolaspayette about this.

if something causes a LogoException, the server becomes unresponsive to further commands

I mentioned the need to do with on this comment on issue 46.

Dropdown or autocomplete or something. I think autocomplete would be best.

Requested by Uri.

Discovered while testing with the names "Derp" and "Derptown".

NetLogo.jar has hooks for this, we'd just need to translate the java.awt.Colors we get back into HTML colors

Currently, Ace just looks at a static list of keywords in order to do the syntax highlighting.

In order to add this functionality, I think something needs to dynamically be done on code change to reach inside the Ace mode's tokenizer's syntax highlighter and change the keyword mapper to include keywords relevant to the current model (namely, the procedures).

so that we're not relying merely on Jason's keen eyes to catch stuff like 87018f5

fine shades of colors don't seem to be preserved, so e.g. with Climate Change note the increased banding in the sky:

Teletortoise should read the button widgets from the loaded model, display them, and react accordingly when they are pressed. This is the first step in supporting widgets in general.

even when nothing's happening, an endless stream of this is being sent over the websocket:

{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
{"turtles":{},"patches":{}}
...

I've seen it over and over again where people think that to join the room they might need some special username, instead of just being fine to type any name

Play 2.1.1 is out. We should upgrade sometime.

...while chatter should be in the regular sans serif font. this will help a lot with the usability problem where it's easy to lose track of whether you're chattering or commandcentering.

if the font distinction could show up in both the input field and in the output log, so much the better.

NetLogo already knows how to convert Markdown to HTML, so this could happen server-side and the client would just see the HTML

on the "stability" branch,

[error] application - 

! @6epf0mna9 - Internal server error, for (GET) [/model/list.json] ->

play.api.Application$$anon$1: Execution exception[[NullPointerException: null]]
        at play.api.Application$class.handleError(Application.scala:289) ~[play_2.10.jar:2.1.1]
        at play.api.DefaultApplication.handleError(Application.scala:383) [play_2.10.jar:2.1.1]
        at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$17$$anonfun$apply$24.apply(PlayDefaultUpstreamHandler.scala:326) [play_2.10.jar:2.1.1]
        at play.core.server.netty.PlayDefaultUpstreamHandler$$anonfun$17$$anonfun$apply$24.apply(PlayDefaultUpstreamHandler.scala:324) [play_2.10.jar:2.1.1]
        at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10.jar:2.1.1]
        at play.api.libs.concurrent.PlayPromise$$anonfun$extend1$1.apply(Promise.scala:113) [play_2.10.jar:2.1.1]
java.lang.NullPointerException: null
        at scala.collection.mutable.ArrayOps$ofRef$.newBuilder$extension(ArrayOps.scala:109) ~[scala-library.jar:na]
        at scala.collection.mutable.ArrayOps$ofRef.newBuilder(ArrayOps.scala:105) ~[scala-library.jar:na]
        at scala.collection.TraversableLike$class.filter(TraversableLike.scala:262) ~[scala-library.jar:na]
        at scala.collection.mutable.ArrayOps$ofRef.filter(ArrayOps.scala:105) ~[scala-library.jar:na]
        at controllers.Application$$anonfun$modelList$1.controllers$Application$$anonfun$$recursiveListFiles$1(Application.scala:29) ~[na:na]
        at controllers.Application$$anonfun$modelList$1$$anonfun$1.apply(Application.scala:33) ~[na:na]

eventually I figured out I needed to git submodule --init, but it'd be nice if I got a reasonable error, and/or if the "building/running" instructions included the necessary extra step

Currently, the protocol consists of sending a command to the server. You then get a response that contains either the output that would've been printed to the command center printed or an error. This response is not traceable back to the original request.

The protocol should support:

• Support for reporters.
• Tracing responses back to their original request. It should be the actual, unique request. So, it should be done on a unique id, not just the request contents. This is absolutely necessary for reporters.
• Distinct "error" and "success" response. Success responses should contain the reporter result / command output.
• Possibly separate "success" response types for reporters and commands. I don't think so though. I was originally envisioning this, so I don't want to discard it completely.
• Responses for print "" and crt 5 should be distinguishable. I'm happy to use null for this, since we literally want to say "there was no output", but I could be persuaded otherwise (leave out the key entirely?). Some equivalent of Option would be cool, but seems like overkill.

see branch gcc in this fork:

stepheneb/Teletortoise@master...gcc

I'm getting a blank (black) display and no error messages

It would be very useful to me to have an alternate view that just shows the NetLogo model and supports a JavaScript API for communicating with the model.

I'd like to see if I can create a prototype where I can embed the result of this in an iframe on another page. Then I'd like to experiment with a postMessage API to communicate with the Teletortise model running in the iframe.

We have recently experimented with this in the Lab repo by embedding an html5 NextGen MW Interactive into a Khan exercise.

See demo here showing the Khan "Check Answer" button using a postMessage-based API in the Khan exercise to find out the "Pressure" from the embedded html5 NextGen MW model running in the iframe.

http://concord-consortium.github.com/khan-exercises/exercises/volume_pressure_relationship.html

More details on how we are experimenting with a postMessage API:

email list: lab-models
thread: Lab + Khan exercise demo
https://groups.google.com/group/lab-models/browse_thread/thread/90c6ea2d1d72d14c

This is the the only file added/changes made in the Khan exercise framework to support this:

https://github.com/concord-consortium/khan-exercises/blob/concord-demo/exercises/volume_pressure_relationship.html

These are the two new files added to Lab to support this level of communication:

The more generic controller for supporting the postMessage API:

https://github.com/concord-consortium/lab/blob/master/src/lab/md2d/controllers/parent-message-api.js

And a more specific one that is used to specifically support the 2D Molecular Dynamics model:
https://github.com/concord-consortium/lab/blob/master/src/lab/common/parent-message-controller.js

Testing with the Global Climate model running:

observer: setup
observer: loop [ go ]
observer: add-cloud
observer: add-cloud
observer: add-cloud

No clouds appear.

chatter: /halt

Clouds have appeared.

Perhaps the following is the same issue:

observer: setup
observer: loop [ go ]

At this point some of the "sunlight" is being reflected from the Earth

observer: set albedo 0

The model continues as before -- I expected no sunlight to be reflected.

chatter: /halt
observer: loop [ go ]

Now view is updated.

Link shapes determine how directed links are shown, thus I have combined these two features into one issue.

It might be best to do this in stages:

1. Support direction indicator
2. Support curviness
3. Support multi-line links

the menu shouldn't even be there if it doesn't do anything

the colors are more neon than the actual NetLogo colors

we seem to be using the right RGB values, so I don't know if this is because the browser is doing some kind of gamma correction or what.

Safari, Firefox, Chrome, all same. this is on Mac OS X

no hypotheses why, yet, that I know of

Some wise-ass decided to do /go and then leave the room without stopping it. This left the server running at full CPU usage for over three hours, and, is, thus, not cool. /go should automatically turn itself off if no one—barring BizzleBot—is in the room.

in NetLogo/Teletortoise@83701ed I did a janky version of this where we render a rectangle instead of a line, which was enough for Climate Change to look sort of reasonable, but of course isn't right at all

before resorting to the rectangle thing, I did try using various combinations of lineTo and stuff but nothing ever got drawn

That is, changing the context with the Tab key changes fonts properly, but using Ctrl+Shift+1 et. all doesn't cause the font to change.

Something in the fix for #2 clearly didn't pan out correctly....

To be honest, I think I broke this when I converted Philip's JS to CoffeeScript and tried to do the throttling through underscore.js.

like jQuery and underscore

in conf/application.conf

Now that we have syntax highlighting in the input box, it might seem desirable to have coloring in the command center output. There are two things that complicate that at the moment:

• The input box and the chat outputs are (purposely) styled very differently. Currently, the black (default) text color looks fine in the (white) input box, but would be very difficult to read against the (dark gray) background of the Command Center output entries.
• As far as I've been able to tell, getting the Ace-highlighted HTML requires creating an HTML element, turning it into an Ace element through JavaScript, and making it visible at least for a brief moment in order to force the initialization of the Ace element.

Some planning of how to circumvent these problems should be done before attempting to syntax color output code.

I think it would be helpful, for a lot of reasons, to have a record of all commands that were entered, all chat comments made, etc

we already have a binary format that model runs uses for storing runs, both in memory and on disk.

or, if we want to stick with JSON, we could compress and decompress it on the fly, perhaps using Snappy: http://code.google.com/p/snappy/

If you're in any context but Chatter and try selecting text with your mouse, you're gonna have a bad time.

Not sure what's going on there....

It would be useful to expose a selection list in the UI for a user to select from the NetLogo models in the ./public/models dir:

https://github.com/NetLogo/Teletortoise/tree/master/public/models

Currently "Wolf Sheep Predation" is hard-coded into NetLogoController.scala:

https://github.com/NetLogo/Teletortoise/blob/master/app/models/NetLogoController.scala#L17

I would like to demo the Global Climate model running in Teletortise to remote collaborators so being able to do this on deployed demo server would be useful:

http://li425-91.members.linode.com:9000/

Add a simple text editor that shows the code of the current model and that, when edited, sends the code back to the server to either be compiled and sent back as js (tortoise), or compiled and incorporated in the workspace (teletortoise).

I'm going to use Ace for now as we have working syntax highlighting for that. Swapping out text editors would be trivial in the future though.

I'm on Teletortoise on Linode, running the Life model, and /halt isn't halting the model. BizzleBot says "@seth, halting" but it doesn't. (even after several minutes and multiple attempts)

I shouldn't be able to do stuff like file-open "/etc/passwd" repeat 100 [ print file-read-line ] and so forth.

maybe install a SecurityManager?

I think this would be fun/useful to have for testing/demo purposes. I'd type the same command once in the shared command center and then it would run in both T and TT and could eyeball whether the results were the same on both sides.

I might do a Swing version of this for doing similar Tortoise/NetLogo comparisons

(Jason suggested I open a ticket)

Right now, links don't take advantage of wrapping. They should follow the wrapped path if that happens to be the shortest path.

ctrl+shift+1 used to put you into the "chatter" context. It now puts you into "turtles". I suspect that this is the result of someone tinkering with LinkedHashSet.

but the tests in TestTortoise seem to show that the correct JSON is being generated when turtles die, so unless there's something wrong with the testing framework, this seems like a bug in the Tortoise/Teletortoise front end

To reproduce:

• Go to Tortoise
• Type setup into the Command Center
• Observe as nothing happens, rendering Tortoise entirely useless

The above causes an error to be thrown by this line (in JavaScript):

shape = this.drawer.shapes[shapeName] || defaultShape;

as a result of shapes being undefined.

git bisect incriminates 26c83cc as the culprit.

Note: In the future, please test on both Teletortoise and Tortoise before checking in significant changes to core systems.

Uri requested this in a meeting. Now that Teletortoise can at least sensibly display something for every model (that doesn't use the drawing layer), it might make sense to just put them all in.