GSoC ’09: Mesquite

Dot language July 20, 2009

Filed under: Uncategorized — kasiahayden @ 6:22 pm

For the next part of the project, we’ll use Graphviz to visualize the annotations. The dot language behind Graphviz is really straightforward and simple.

Here are some simple examples swiped from wikipedia:

Undirected graphs versus directed graphs. First undirected:

 graph graphname {
     a -- b -- c;
     b -- d;
 }

Then, directed:

 digraph graphname {
     a -> b -> c;
     b -> d;
 }

Oh, look, different shapes and names:

 graph graphname {
     // The label attribute can be used to change the label of a node
     a [label="Foo"];
     // Here, the node shape is changed.
     b [shape=box];
     // These edges both have different line properties
     a -- b -- c [color=blue];
     b -- d [style=dotted];
 }

Why do I keep wanting to call it cute? No, no, no, it’s elegant, not cute!

Advertisements
 

Was it something I said? July 16, 2009

Filed under: Uncategorized — kasiahayden @ 9:34 pm

Ah, the melancholic musings brought on by a silent tester. The pain of seeing my code ripped apart doesn’t compare to it not being reviewed at all, oh taciturn tester.

Maybe by tomorrow you will resurface (and hopefully not be alarmed by my numerous emails)  and spare me from my misery.

 

Testing 123

Filed under: Uncategorized — kasiahayden @ 10:44 am

I solved the problems of getting columns displaying, of getting a reference to the original file location (that was lost after nexml saved the file as something new, with a .nex extension), of failing gracefully (no horrible crashes when a user tries to see the NeXML annotations on a file for which there are none). Finally, made my module’s requisite corny splash image. Does it recall 1950’s vacation advertisements?:

splash

Now I’m in the testing phase. Which is uneventful so far. All of the little problems that have come up from my mentor have been decently quick for me to fix. As for working with my student tester, I realize now how tricky it can be trying to help someone through steps necessary to get a program working when you’re not sure of their skill level and where they are in the process of getting things set up. Are they struggling with things that you could help them with or are they busy with a different project at the moment? Are they going to be vocal when they run into problems of pretend they understand things that they don’t, letting the problem snowball?

In the meantime I’m learning the dot language and working with graphviz, in prep for the next stage of my project. (Rec: if you’re going to install GraphViz, just save your time fiddling with package managers and compile from source.)

 

Eclipse’s Attempt at Sabotage and How It Was Thwarted July 13, 2009

Filed under: Uncategorized — kasiahayden @ 1:42 pm

When I started up my Eclipse recently it got as far as seeming to load properly and then hanging, displaying an incredibly helpful blank error pop-up.

Sifting through message board advice for something that seemed likely to have the least chance of unintended consequences I found this:

I ran into a problem where the Eclipse just hangs and shows a blank screen on start up. On analysis I found that its due to the perspective that its trying to open with. I could not find the problem thats causing this but I wanted to open the project and do some work on the java code base.

Since I cannot change the perspective from the eclipse workbench I looked around and found the file that can be edited to make eclipse open in the perspective you want.

It is workbench.xml file that will be under %workspace%\.metadata\.plugins\org.eclipse.ui.workbench folder. Search for perspectives element and modify it to open up in the perspective you want. For e.g. to open in java perspective you can use the following

<perspectives activePart=”org.eclipse.jdt.ui.PackageExplorer” activePerspective=”org.eclipse.jdt.ui.JavaPerspective”>

Ref: YourMitra.

The corresponding line in my workbench.xml file was <perspectives activePart=”org.eclipse.ui.console.ConsoleView” activePerspective=”org.eclipse.jdt.ui.JavaPerspective”> which, when replaced, allowed Eclipse to come to life once again.

Solved.

On a tangent, it seems like a decent portion of the solutions that work don’t work for the reasons they should. Like in the above, our activePerspective attributes were the same. The problem instead was that our activePart attributes were different. So of course that leaves me wondering if others solutions out there that target fixing the perspective actually work because they coincidentally effect the real source of the problem. And how many solutions in the world are just a fallacy of cause and effect? Can’t help but wonder

 

Post number… 3? July 12, 2009

Filed under: Uncategorized — kasiahayden @ 1:22 pm

Right, I missed the point that our student blogs can be useful for our organization to follow our progress and instead thought it was more for my own benefit (so ditched it when time became tight).

This weekend I’ve been working on figuring out how to get columns to display in imported nexml files. The code I wrote to display the nexml annotations finds which annotation to display based on the highlighted cell’s row and column, and if the column hasn’t made it to the matrix from the original xml file then my poor annotations can’t make the connection.

When testing that my nexml viewer worked correctly I simply copied and pasted a few key column names in, but I somehow don’t think that users will go for that, so it’s time to fix this problem.

It took me a little while to figure out that the nexml module probably wasn’t reinventing the wheel and calling methods to write the nexml file, much less creating it’s own methods to do so.

Then, the problem is probably wherever the main project tried to pull out character names from the project that the nexml module spit out, right? Right. (Or at least I’m mostly sure.)

In the getCharStateLabels method in ManageCategoricalCars, Mesquite is only able to get so far as to tell how many characters there are with data.getNumChars(). After that the boolean methods data.characterHasName, dData.hasStateNames(i) and foundInCharacter all return false. No good!

So now I have to figure out how the character names should be written in data so that they’re readable and then go back to nexml and fix that. Taxa are pulled from data, so I might get some hints from examining what works there.

Edit: Pretty sure that all that’s needed is for the characterNames array from CharacterData to be filled up somewhere in nexml, when it’s parsing characters. It makes sense that taxa names are pulled just fine in comparison, since what’s needed for that is guaranteed by the CharacterData constructor.

getCharStateLabels in ManageCategoricalCars