feeling like this needs to happen.
2 Likes
Hey Sleepdeficit, thanks for your interest! There actually is some existing effort in this area going on, which will probably be covered in more detail in a blog post whenever I get the chance to write it, but here’s an overview:
Eterna has been aiming to move away from Flash and to open sourcing their software for quite a while, which was kicked off with the new data browser. Vineet has started the groundwork for an app by building an iOS app for chat in objective C. We’re planning on changing this to instead be built on Cordova, with the chat functionality being provided by the new HTML chat client I wrote which is going to be launched on the website soon. Cordova will both allow existing HTML/CSS/JS parts of the codebase to be integrated into the app, as well as allow for ports to iOS, Android, desktop, etc without (much, if any) additional code. From there, the app can be expanded to contain more features, such as integration with the forums, wiki, and yes - the actual puzzle solving.
The main issue left here is the actual puzzle solving interface. This past summer I put together an HTML prototype to show that it’s feasible, and I was able to build out a fair amount of the core UI. Rhiju later asked me to write a blog post “call to arms” to start collectively working on this problem. Needles to say, that hasn’t happened yet, particularly due to schoolwork and my work on the new HTML chat client. Once that is finally up and running, it’ll be easier to start getting people organized to work on this. However, there is one caveat to this. The energy models that actually predict the shape and properties of sequences (IE, “natural mode”, free energy, etc) is all written in C. This means that either the energy models need to run server-side, or using Emscripten/WebAssembly/Google Native Client (with varying amounts of browser support). Probably, initial work will simply load the Flash applet on the page just to be used for the energy models, but this will need to change for mobile to be a possibility.
I have set up a Slack server for player-driven development which a number of people have already been invited to as there’s been specific reason to (essentially to test the waters before opening it up further). This is probably where we’ll concentrate discussion of the puzzle UI development at least for the time being. I’m planning on opening up the Slack officially with the same blog post I’m going to be posting, but if anyone wants to jump in now, feel free to shoot me a PM.
1 Like
@LFP6, thank you for the excellent summary!
As I was reading it, something occurred to me that I don’t remember discussing before. On mobile devices, where you’re planning on wrapping up the HTML into a native app, is using the NUPACK C code directly, without major transformation, an option?
It appears to be possible from an initial search, but to be honest I have little experience in the area. Were you thinking of having the energy model in Flash on web, and directly in C on mobile? I could see this working for the short term, but we do want to ditch Flash completely, and it would be best to have a single codebase between web and mobile where we can.
There’s no question we want to ditch Flash as soon as we can. But it certainly seems that using C code for the folding in a native app is something we could do today. So yes, having the energy model in Flash on the web, and directly in C on mobile devices seems like a feasible path to consider.
If we can just run the C code using Emscripten (essentially transpiling to JS), I feel like that would be the best route. Is there any reason why this would be any worse than what you propose?
I can’t say anything definitive; I’ve never used Emscripten. But when the devs discussed the possible paths to getting rid of flash (6 - 9 months ago), Emscripten came up. My memory is hazy, but I believe @nando said that, based on his experience, he wouldn’t recommend it – too finicky I think, but I don’t remember the details. What I do remember for sure is going away with the feeling that at that time, we really didn’t have a good plan for replacing the folding engine.