when I switch between vienna and vienna2 views then use undo(Z) the command does not work. Please validate to make sure it is not me.
2 Likes
I can confirm this. Not always, but often one looses the ability to check ones design history backwards.
To duplicate:
1- make changes to lab puzzle in vienna
2- use undo - it works
3- make a few more changes
4- switch to vienna2
5- switch back to vienna
6- use undo-- it doesnāt work.
7- or in layman terms - switching to vienna2 from vienna then back to vienna
blows out the stack that undo key uses.
This is not a bug. It is an unfortunate and necessary evil when the applet switches between the Vienna1.8.5 engine and the Vienna2.x engine that the undo stack has to be wiped. If I recall correctly, this is due to the implementation of the additional model, making it difficult to retain the information when going back and forth.
You can have Nando tell the gory details of the battles he fought to even get two models running in the applet. The are quite riveting to read.
Brourd is 100% correct. This is no bug and I had essentially no choice in the matter. Trying to maintain a compatible history would have been a computational nightmare. And as Brourd pointed out, I had plenty enough of those getting the second engine to run properly.
In essence, you need to make an early decision: which model do you want to work with, and then stick to it. Either that, or open two instances of the lab and copy/paste between them.
OK. Then we can call it a design feature. Thanks for the info. I can work around it easy enough.
Before I mark this as ānot a problemā, can I get an explanation for why the undo stack of a text string (the sequence) canāt be kept because of the energy model? Feel free to just tell me to go home because I have no clue what Iām talking about as well. 
The undo stack is everything but just a text string. For each move, everything is calculated, folds in all states, pair-types counts, constraints, etc. To preserve the functionality while allowing for engine changes, you must either do all folds in all engines, increasing time (Iām sure everybody would love to have Nupackās āspeedā everywhere and at all times) and memory consumption, or remove all folding calculations from the undo stack and be forced to re-compute everything every time you click āundoā (which will surely be āfunā, even with Vienna2, when we get to multi-states 500+ bases long puzzles in labs some day in the future)
Some may argue that Flash canāt be that slow, and yes itās true, we could in principle look into worker-threads which were implemented in Flash players quite some time ago. Unfortunately, because of the Flash CS license owned by Stanford, we canāt target players above version 10.3, and worker threads were added in Flash player 11. So we are either stuck with mono-threaded operations, or weād have to spend precious grant dollars on a license for a platform we intend to abandon very soon anyway, and have me reviewing 50ā000 lines of ActionScript code for fixing the syntactic problems introduced by the ātighteningā of the language (by itself a good thing) also introduced in newer version of the Flash development platform.
Long story short: no go.
2 Likes
Ok, the problem does make sense. What I donāt get though, is why would the calculations be such a problem for history, but not while youāre actually working? If there really is that much of an issue, Iād think that either manual control of calculation is needed (Iād imagine this to be the case for 500 count puzzles, forget about the undo stack), or it really doesnāt matter, except when making many undos for which the time in between clicks should be calculated, and the calculations donāt happen for that time.
Hope that makes some sort of sense.
Manual control is certainly something we would have to look into rather soon. But for starters, this isnāt as simple as saying āpauseā. Many implicit things depend on the calculations currently made at each mutations, in particular constraints checking and rendering, free energies, both totals and individual contributions, etc. This is not just a matter of adding a button and 5 lines of code. This is heavy development and added complexity.
Which again is troublesome to even consider at this point in time, because weāre set to abandon the current platform. Any heavy investment we make right now, could prove to be for naught in a few months timeā¦
1 Like
Makes complete sense.
Iāll keep this thread open, as eventually this would ideally change (either in a redesign or at the eventual necessity of calculation freezes).
āFlash CS license owned by Stanford, we canāt target players above version 10.3āā¦
Uhm, that sounds backwards to me. We invest so much time getting the game to work fo rthe latest Flash security patches that (my guess) >90+% of useres are using, but we cannot target players above 10.3? Should we downgrade to 10.3 to get better results (i.e. faster switches etc)?
Or could Stanford purchase a new license for Flash or would that bust the budget?
It doesnāt really matter to me, I have gotten used to having no history - I just wonder why this is an issue.