fixed a bug in the haplotype groups

Fixed a bug that was causing the haplotype data in the pop_hap array to sort incorrectly. Basically there was an extra for loop in there that was causing the pop_hap array to be jumbled an extra X times. We're now up to version 2.3.1.

missing table in IE

Help! I can't figure out why this table won't show up in Internet Explorer (v. 7, in Windows). The table (id="popsizelegendtable") is viewable in Firefox but totally disappears in IE. I have no idea what's going on. Here's the unprocessed source. Is it a CSS style issue? Or is some of my javascript overwriting some styles? The nodes and data are still there in the HTML tree, but it just isn't viewable. I feel like I've turned every display to block and zoom to 1 and am out of ideas.

Fixing svg/img bugs

So I got a bug report that said that the site didn't work in Firefox in Linux. Only one wedge was being drawn. Turns out that for some reason the call to GPolygon that usually produces svg's produces 'img' elements instead. This caused a bunch of problems. Now I've fixed it so that I check if img's or svg's are produced, then modify the event handling of those objects. I suspect that this img/svg problem may be at the heart of the app's bad behavior in Internet Explorer and Safari as well. But there are more bugs to take care of there... Just a note: Gmaps in Firefox in Windows and Mac DOES produce svgs.

By producing img's instead of svg's certain features of the site become impractical to implement. The biggest problem is that the img's must be completely redrawn each time there's a change. With svg's I can easily change the style (fill color, stroke width, etc.) of the element without having to redraw the graphic. The drawing of the pies is time consuming, so with img's I've disabled the dynamic updating of the pie wedge colors. Now the user must click the 'ok' button to submit their new color requests.

Note: I'm not sure who's 'fault' it is for not being able to use svg's on Firefox in Linux. The documentation for Firefox states that svg support is now built in to the latest release, so maybe it's Google Map API's fault for returning the wrong img datatypes when it should return svg's. In any case, img's are what's being rendered on the page.

Development environment in Linux

So getting my development environment set up in linux was no small task. I'm using Fedora 6. Here were some of the obstacles:

1) The distribution's version of Firefox doesn't come compiled with the necessary debug flags for Firebug to work properly. I downloaded a new version of Firefox directly from the website and that seemed to have solved most of the debug problems. I've heard that you may need to download the source and compile it by hand with some special flags, but luckily the downloaded tarball worked for me.

2) The php-json package was missing from my installation of php. A simple yum install fixed that problem.

another bug to fix

Fart! If you click away from the default map type on the viewer screen (say go from 'satellite' to 'map') you lose the ability to drag the pies and color them. It's bizarre, but if you resize the pies you get back some of the draggability and can recolor them....

bugs fixed -- comment console.logs out

So I was running into the problem that the program worked fine on my machine but was puking on David's. The problem turned out to be how I was debugging my programs. I've been outputting debugging info to a console log readable in the Firebug program. If you don't have Firebug installed, the console functions are not understandable and the browser barfs. So after commenting out all my console logs, the problem went away.

I also noticed the bug that if you moved a pie and zoomed the map, the pies would not be in the right location. Turns out that I had been updating the population centers twice (once on drag, then again on zoom with the same move state), so was getting erroneous placement info. Once again, turned out to be an easy fix. Just commented out the second population updater in the zoom event handler.

Does NOT work in Internet Explorer

PhyloGeoViz does NOT work in IE. But it does work in Firefox. Have no idea why it doesn't work in IE. This will be a bear to work out I think. I don't know if it's worth it. Any arguments why I should or should not take the time to fix it?

slow run time

One thing I noticed when running PhyloGeoViz with my full dataset (~85 pops and ~40 haplotypes) was that the pie generation is pretty slow. I'll have to look to ways to speed it up. In the meantime, I need to put up some sort of disclaimer to the user.

Bug fixed

Turns out php was trying to interpret the xml header declaration as php. Adding an echo statement cleared out this bug.

Thanks, Jack for pointing this out!

Bug! help!

I've got Version 0.2 up, but unfortunately the export php script fails! Oh no! Of course, the script runs fine on my machine and environment, but on the server no longer functions. Why, oh why! Here's the error:

Parse error: syntax error, unexpected T_STRING in /home/.nayla/zeppox/oenimal.net/erica/version_0.2/export.php on line 5

I thought it might be a php version issue, so updated the php version on the server, so now we're both running php 5.2.2. But the error remains. Maybe it's a security issue with php? Anyways, any ideas??