Continue_Wiggle()

[ptfrog]

One of the problems with lua – or at least the parts exposed to foldit – is that it is single-threaded. There are many scripts that get around this by doing short operations (such as wiggle) and testing between each iteration. However, a recent article made it clear that the behavior of wiggle changes over time – so doing 5 short wiggles is not the same as doing one longer one.
write
The same may be true for other functions (shake?), though this was not made clear in the article.

Ideally, one could have a separate thread watching the script and controlling its behavior. But the implementation of this might be complex. A simpler solution might be a "Continue_Wiggle()" function. All existing scripts that call wiggle would continue to function as they always have. But a new scripter could write
wiggle(1)
while (true)
if someCondition then break end
continue_wiggle(1)
end

This code could be made even simpler with the addition of a second function: init_wiggle(). That way subroutines could be written that call continue_wiggle(), leaving the calling routine to decide whether to reinitialize the wiggle algorithm.

Side note: There are a variety of other ways to implement this – such as leaving a single call to wiggle, but have its behavior changed by the state of a continue_wiggle flag. (This might also be a checkbox in the UI).

Thanks!

[tristanlbailey]

I don't know if you would consider this to be relevant or not, ptfrog, but I was wondering if perhaps the devs could allow scripters to specify the amount of time in seconds that they want various functions to run, rather than just having the existing arbitrary "iterations" (the duration of "iterations" currently changes based upon the size of the protein, and/or selected segments). I think this could be quite useful.

[ptfrog]

I agree, tristanlbailey; that would indeed be helpful – especially now that scripts will have access to a date/time. But the problem remains: if you interrupt a process to check its status, how to you resume from where you left off?

This actually goes to a deeper question, which probably deserves a separate suggestion thread: How do you script something that the best players now do manually: what gramps calls "putting the poke moves on it." They see what's happening and stop a wiggle, or change a slider…. Some of this can never be scripted, since it relies on the visual gestalt on which makes people better than computers. But some of it can.

I have an idea for this which I haven't written up because I haven't had a chance to search for similar suggestions – but here is an enhancement that would solve both of these problems: create a "monitoring thread." It might be something as simple as a subroutine that runs off an alarm (a timer, to start with – though I can envision score-based alarms as well). It might wake up every tenth of a second, see what's going on, and have limited control capabilities:
1) Change a slider
2) Change a global script variable (or perhaps one a small set of global registers)
3) Stop current wiggle/shake
and someday:
4) Pause
5) Save
6) Put up a dialog box (wouldn't that be cool?)

[tristanlbailey]

Your idea of pausing/resuming a recipe, sounds quite similar to one of my previous feedback items:
http://fold.it/portal/node/990676

Hmm… sounds like the Cookbook is going to need two separate interfaces; a Standard Interface, and an Advanced Interface. There are so many good ideas that people have come up with, but not everyone is necessarily going to be using them all.

[ptfrog]

Yes – pause is on a lot of wishlists. :-)

An advanced cookbook might be a good thing – but that's not quite the same as an API (application programmer's interface). What I am thinking about is a way to leverage the power of the community of developers who fold. If done properly, this could take some pressure off the UW coding team, and it could result in real enhancements that the entire community could benefit from. The cookbook seems a perfect place for this, since it doesn't involve the scoring algorithm or other aspects of foldit that might entice cheaters.

One possibility for sharing would be to simply open-source the cookbook. But there are gotchas here, and depending upon the current codebase this has the potential of making more work for the developers – reviewing many many code submissions, trying to decide what to incorporate.

That's why I suggested setting up an API. If the cookbook is set apart from the main body of foldit code by a simple and well-defined series of calls, such as
Calls From Foldit:
apiDisplayCookbook – call the cookbook module

Calls To Foldit:
apiLoadScript
apiSaveScript – returns info on syntax errors, if they exist
apiRunScript
apiShareScript
apiRunScript
apiExitCookbook

I'm not sure if this is the right list, but it gives the general idea. My guess is that many folks will write Lua code to create cookbooks, and that many of these will be shared with the community. Folks who use Eclipse or some other development environment may also develop really cool interfaces to foldit.

There will be those who wish to share their results, and therein lies the rub. How do you ensure the quality of these submissions? Once you open up code to the community, sharing cannot be prevented, and there is an element of danger in downloading unreviewed code. A web area where code is shared and reviewed (akin to the current recipe area) might mitigate this, along with a requirement that all source code must be submitted.

A few trusted and dedicated members of the foldit community – and I would imagine that there are dozens to choose from – might be enlisted to review and recompile Lua submissions prior to allowing them to be shared in binary form. This makes the barrier to downloading unreviewed code high enough that the bulk of the foldit community would not bother with it. And it would prevent someone from sharing a compiled version with some hidden "features" not shown in the source code.

The web page would probably need certain caveats:
1) Be careful of untested code.
2) This is a community supported web project. If your submission takes months to be reviewed, or if it never gets reviewed at all, we are sorry. But look at the bright side: you now have a recipe book of your own design, and it has made your folding life better.

[ptfrog]

Whups! This belongs in another thread. Sorry!

[tristanlbailey]

I just came up with another good idea; how about the devs re-use the existing GUI recipe screen (not the scripting version), have a button at the bottom that says "New Cookbook", and have simple "Run Recipe" and "Alarm" ingredients added to the list? These would be the simpler versions of the script functions.

Then, on the main screen, where it has the "Cookbook" tab you click to access the recipes, have that changed to "Cookbooks". When the tab is clicked, a default tab at the top appears, which could be called "Downloaded Recipes" (any recipes you download go straight to this), and have separate horizontal tabs appear for each cookbook underneath. Where there are the "Show recipe output", "Browse/download shared recipes", and "Open recipe editor" icons at the bottom left-hand side, change the "Open recipe editor" icon to read "Open editor" (as the "editor" will be supporting both cookbooks and recipes).

[ptfrog]

A good idea, though I think it belongs in another thread. It has occurred to me as well that allowing GUI recipes to run other recipes from the Cookbook would be a simple way to allow for recipe chaining. But I gather that they are addressing this in v2 – and probably more thoroughly. I guess we'll see soon enough.

[AsDawnBreaks]

This is an old one, but I think it is needed, some sort of way to gague gain/loss per iteration and to stop the command after a specific gain/loss.

[jflat06]

I believe wiggle in iterations of 2 should be 'atomic'. Meaning you should be able to run 2, do something else, then run another 2. Stopping in the middle of an iteration isn't really realistic implementation-wise.