Since getting back from our trip to the Rocky Bioinformatics conference I’ve been working on fixing up some code. There were a number of bugs that I had back-burned in favor of working on my presentation for the conference. The graphing proof-of-concept for Subsystems that I had been working on was first to hit the burner. I stopped work on that in order to get the json saves to the new server working.
The json saves were close, but not perfect when I left for Colorado. Daniel and I actually discovered a couple more weird little problems when I got back. (Luckily, he made quick work of his own OpenSocial portion of the saves, so I had a reliable place to get correct output to check against). Click the read more to hear my bug-squashing tale in all its glory!I sat down to work on the bugs in order of most recent to least. The first problem was that Daniel and I had values that matched for some annotations, and others that didn’t. Eventually I tracked this down to the fact that the Hash I was using to create my json data was overwriting itself. I did a little more investigation and found that in the past we (intentionally or not, I can’t recall) had MM display results which came in after the first chunk as separate entities.
That is, if “Bob” is reported to MM from the server as having “value: 14” in results chunk one, we write that to our list. If “Bob” is later reported with “value: 6” in results chunk 2 or 3, we write that to our list. When we re-alphabetize, we see “Bob value: 14” on one line, and “Bob value: 6” on the next. When we create our hash, we insert Bob with value 14, and then insert Bob with value 6 overwriting the previous value. What we really want to do, to correctly mimic Rob’s RTMg and Daniel’s OpenSocial implementations, is notice that we have a pair of Bobs, sum their values, and attribute their combined value to the key “Bob”. MM does this now, and as a result, results lists are shorter and the json saves seem to be accurate. (I’ve yet to hop on a linux machine to do some kind of diff on a pair of files, but from my spot checks, the old problem areas now give good values.)
Interestingly, after solving this problem I recalled that we had an issue with the graph proof of concept that involved duplicate keys being displayed as separate objects instead of a combined entity. The graph code is heavily based in MM’s own code, so it seemed pretty likely that the code I had just written to fix the json saves would directly fix the graph issue as well. A bit of copy and paste later and…. GraphPOC crashed. To be fair, the copy-paste was not at fault (this time..), rather, I had a few other issues I had been working on fixing when I dropped the project. After fixing up some weird odds and ends, the code ran flawlessly, and now properly combines repeat keys.
The next step is to integrate the graph into MM such that the options button actually does something, and then work on the other hierarchy views.