Archive for May, 2009

Convert GPS .loc files to .gpx files with PHP

Monday, May 25th, 2009

This is a simple PHP5 script I wrote to convert LOC files from geocaching.com into GPX files.  You have to be a paid member to get GPX files from geocaching.com, but both LOC and GPX files are xml, and are fairly trivial to convert.  I tested that the GPX files produced from this script correctly load into my Garmin desktop software as well as into the GPS.  The script is hard coded to set them to be geocache-type waypoints, but you could always change that as needed.  Of course, I provide no warranty of any sort, but it worked for me. I called this file loc2gpx.php, but you can download the source and call it whatever you like. The example command below assumes you agree with my name for it.

Usage:
Pass the script a folder full of .loc files and it will create a single .gpx file for each one.

[~]$ php loc2gpx.php /path/to/.loc files

Download loc2gpx.php

Posted in PHP | 1 Comment »

PHP is not a DSL

Sunday, May 24th, 2009

EDIT (5/25/09): Some how my Wikipedia link to Domain Specific Languages got lost in a draft somehwere, thanks Supermike for noticing it was missing.  http://en.wikipedia.org/wiki/Domain-specific_programming_language

Disclaimer: I’m going to try my best to keep this post from turning into a rant comparing PHP to other trendy scripting languages.  Also, If you came here with a pre-disposed opinion that PHP sucks, I’m not likely to convince you otherwise, so I’ll concede now; that’s not the point anyway.

There’s been more and more activity on the blogosphere about DSL’s lately, and I’m not buying into it (partially because some of them are well-crafted trolls).  I believe that there’s not many domain-specific languages out there, at least not “main stream” ones.  When I think DSL, I think Lego LOGO and BASH; languages that literally solve one problem.  There are many other languages available that happen to be particularly good at doing one thing or the other, however that’s not to say they couldn’t do some other thing, albeit very poorly.

There’s a mile-long spectrum of language functionality to consider here.  You have C/C++ that can be made to do damn near anything from programming your refrigerator to serving web pages.  On the short end of that spectrum are DSL’s.  So where does PHP fit into a scheme like this?  I’m going to say it sits squarely in the middle, and that’s why the internet has such a love-hate relationship with it.  PHP is good at many things, great at a few things, and terrible at a few as well.  People who don’t solve problems with PHP all day every day aren’t fully aware of it’s extensive capabilities, and have been shown most likely to start flame wars about PHP’s inferiority to (Ruby|Python|Java|C#) by an incomprehensive study I just conducted in my head.

PHP, in it’s early stages, could definitely have been considered a DSL.  It existed solely to solve one problem: the web problem.  (I’ll also argue that the folks over on 4Chan maybe creating the “web problem” as we speak.) What is the web problem?  It’s the “D” in DSL.  The domain.  How do we create web pages programmatically?  That’s the web problem, and PHP came around and started solving it.  Really damn easily.

With PHP4 and especially PHP5, times have changed.  PHP’s runtime, if you include the vast extension library, is full-featured almost to a fault these days.  Now PHP solves lots of problems, from raw-socket TCP/IP problems, to XML parsing problems, to Database problems, and more.  I’ve even heard of someone writing a software compiler in PHP (purely acadamic, of course).  So is PHP great at solving these new and more complicated problems that the Internet has brought upon us?  Nah, it’s not great at them.  But it’s pretty good, and that’s good enough, especially considering that you can tackle almost any internet-related problem without a context swith to another language (because you’re already building web pages in PHP to start with right?).

So what does PHP suck at?  Well, there are some things it just can’t, in fact probably never will, do.  PHP can’t do threads.  In fact, it’s not happy when other things that touch it are doing threads.  If you must have threads, you should probably use (Ruby|Python|Java|C#).  PHP also sucks at running for a long time.  PHP scripts just aren’t meant to run for 10 days at a time.  Somehwere along the line they’re probably going to develop a memory leak and do something nasty.  That’s OK though.  PHP wasn’t design to run for a long time or to spin up multiple threads.  And this my friends, is where the gray area comes in.  I spent the last paragraph telling you about how PHP wasn’t a DSL because it could solve all these disparate problems (or at least implying it…spoiler alert), but now we have a problem.  I just told you two of PHP’s shortcomings were language design issues.  And why were they designed that way? Well, PHP is meant to be created and torn down in the context of a web request, because PHP was meant to solve the web problem.

So no, PHP isn’t a DSL, but it used to be.  Ironically though, what makes it so popular, is that it’s really good at that one thing:  it’s damn good at creating web pages.

Posted in PHP | No Comments »

Keeping track of merges in SVN 1.5

Sunday, May 17th, 2009

I’ve finally migrated to Subversion 1.5 hoping to be completely wowed by the new merge tracking features.  While they may be great on paper, the Subversive/SVNKit connectors that come with Eclipse (rather, Zend Studio for Eclipse) are less than exciting.  If you’re expecting, “wow, new interface and features”, don’t be, it’s a mild change at best.  However, the merge tracking definitely works and it works automagically.  The issue that I’ve run into with it is that while it may track what has been merged where just fine, someone still has to track all the things have haven’t been merged.  This especially true if you have a “stable” branch in your code.  As you bring features and updates from the trunk into that branch, SVN will happily track the revision numbers that you’ve merged.  But, what about all those ones that haven’t been merged yet?

Up until today, I’ve been going through a tedious process of reading the svn:mergeinfo field and comparing that against the commit logs from WebSVN or Fisheye, and then using the “whiteboard” method to keep tracking of that still needs to be looked at.  To solve this problem, I wrote a quickie PHP script that will read the svn:mergeinfo property as well as another property I’ve created called “minmerge” and spit out a list of revisions to look over.  The minmerge property is basically a number I set by hand that denotes how far back in to look.  Anything lower than that revision number is assumed to have already been processed and either merged or decided not to be merged.

<?
$mergedcmd = "svnlook pg /svn/testrepo svn:mergeinfo /branches/stable";
$minmergecmd = "svnlook pg /svn/testrepo minmerge /branches/stable";
$mergemsgcmd = "";
$merged = exec($mergedcmd);
$minmerge = exec($minmergecmd);
 
$merged = str_replace("/trunk:", "", $merged);
 
$revs = explode(",", $merged);
 
echo "found " . count($revs) . " merges \n";
 
foreach ($revs as $rev)
{
	if (strpos($rev, '-'))
	{
		$bounds = explode("-", $rev);
		for ($c = $bounds[0]; $c &lt;= $bounds[1]; $c++)
		{
			$realrevs[] = $c;
		}
	} else {
		$realrevs[] = $rev;
	}
}
sort($realrevs);
 
$min = min($realrevs);
$max = max($realrevs);
echo "found " . count($realrevs) . " revisions from $min to $max\n";
echo "ignoring revs above $minmerge\n";
 
for ($c = $min; $c &lt;= $max; $c++)
{
	if (!in_array($c, $realrevs) &amp;&amp; $c &gt; $minmerge)
	{
		$unmerged[] = $c;
	}
}
 
sort($unmerged);
echo "found " . count($unmerged) . " unmerged revisions:\n";
foreach ($unmerged as $rev)
{
	echo "$rev\n";
}
?>

Posted in PHP, Software Development | No Comments »