Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Clone this wiki locally
Jason’s input: Work is already in progress on this on Tortoise’s
wip-inspection-windowbranches. Mostly, it’s just UI stuff that needs to be implemented in Galapagos, at this point.
- Jason’s input: Work is already in progress on this on Tortoise’s
Jason’s input: I took a shot at this. It didn’t go well. There’s no real easy way to write a DOM element to an image. There are libraries to do it, but, in my experience (as of August 2017), they’re pretty janky. I managed to use a popular library—maybe even two? I’ve forgotten...—to try and export interfaces. It succeeded. With the exception that things didn’t look right. Namely, sliders’ labels were shifted down, such that half or more of each letter was cut off. This rendered those labels mostly illegible. And, since I’ve got to assume that the whole reason you want to see the interface, rather than just using
export-view, is because you want to see what all of the widgets are set to, that sort of bug largely negates the purpose of the primitive. Maybe the technology for this will get better with time. Or maybe people will become comfortable with just using their computer’s “Print Screen” button.
- Jason’s input: I took a shot at this. It didn’t go well. There’s no real easy way to write a DOM element to an image. There are libraries to do it, but, in my experience (as of August 2017), they’re pretty janky. I managed to use a popular library—maybe even two? I’ve forgotten...—to try and export interfaces. It succeeded. With the exception that things didn’t look right. Namely, sliders’ labels were shifted down, such that half or more of each letter was cut off. This rendered those labels mostly illegible. And, since I’ve got to assume that the whole reason you want to see the interface, rather than just using
- Jason’s input: Another pretty pointless primitive. Don’t bother. Even Uri and the people on the NetLogo development team were surprised to learn that it existed
- Difficulty: Hard
- Description: These prims are used in HubNet models. Implementing HubNet—a networked version on NetLogo—is no small feat. It's on our radar, but it will be quite a while before this functionality is ready.
- Jason’s Suggested Solution: Spend a lot of time and implement it
- Difficulty: Hard
no-displayonly makes sense in the presence of
user-*prims), but not one for this use case. We could build our own dialog, but only natively-implemented ones can be synchronous.
- Jason’s Suggested Solution: We explored the idea of running the engine inside of a Web Worker, so we could allow the UI to “breathe” freely, and also simulate blocking threads when needed. This didn’t work out. The engine, when run inside of a Web Worker, was massively slower than when it ran in the UI thread (check out some single-worker benchmarks to see for yourself). As a result, it seems that Web Workers aren’t the solution. The only other reasonable solution that comes to mind to me to try using ES6 generators. It might be a bit yucky, but I expect that all of these prims would be expressible in terms of generators in some non-terrifying way.
- user-one-of (does not have a JS equivalent)
- Difficulty: Hard
without-interruptioncan only be used with
ask-concurrentis usually not very useful or intuitive. Since the introduction of
ask-concurrenthas been highly recommended against. And implementing it with the correct semantics in NetLogo Web would be a pretty unpleasant, code-complicating task.
- Jason’s Suggested Solution: Just don’t ever implement these
- Difficulty: Daunting, if not impossible
- Jason’s Suggested Solution: It would be easier, probably, to just have things function differently and do reading/writing through HTTP GET/POST
- Difficulty: Probably not too tough
- Description: BehaviorSpace. It manages these values under the hood. It can expose them through the primitives mentioned below.
- Jason’s Suggested Solution: You could probably just have Baby BehaviorSpace pass these values into the engine when it starts a run. Or you could pass in a prim config that just defers to a closure around a mutable variable that lives in Baby BehaviorSpace and gets altered as necessary.