Patrick Mueller elsewhere:,

Friday, January 05, 2007

Xdebug support for Eclipse PDT

'Time to debug' by Henri Bergius

A colleague of mine from the UK, Dave Kelsey, has just uploaded a bit of nifty new functionality for the Eclipse PDT Project. PDT stands for PHP Development Tool, the new name of the PHP IDE project at Eclipse.

The new functionality enables you to use the PHP XDebug extension. As shipped, the PDT project ships support for the Zend Debugger. For any of a number of reasons, you might want to be able to use XDebug instead of the Zend Debugger extension. Now you can!

Brief information available here, code and doco available here.

Dave hangs out on the newsgroup on the NNTP server, if you have any questions, bugs to report, etc. Note that you need to be registered to the news server; if you don't already have a userid, you can get one from here.

Also note that Ben Ramsey just posted a blog entry about how to set up the Zend Debugger in Eclipse.

Photo 'Time to debug' with a nice CC license, by Henri Bergius. Found using the Flickr's Create Commons Search.

Thursday, January 04, 2007

interop not

'Keep 'em separated' by Mark and Allegra Jaroski-Biava

I've previously written about scripting languages in Java and some of the interop issues with them. My basic thoughts haven't changed, though I also haven't been playing with any of these lately. But I have some additional thoughts.

My DEmentor, John Duimovich (he's an IBM Distinguished Engineer), found me on Google Talk last night, and we ended up chatting about all kinds of stuff, and one topic was scripting language / Java interop. John threw out all the usual pro's that come with this sort of interop nirvana:

  • You can write your (non-time-critical) business logic in a scripting language, which will be smaller and more readable than in Java, but more importantly, you can write it quicker.
  • Your scripting language can make use of all the great Java class libraries available.
  • You can probably make use of at least some class/function libraries in your scripting language from Java.

Sounds wonderful.

I think most people, when they hear interop stories, get afraid of performance. Ignore that one for now; consider that you could at least prototype your Java code in a scripting language, then convert to Java later. Interop would still be a huge benefit.

But performance isn't the issue. There are bigger issues. Let me recap, quickly. Read my previous blog post for more details.

  • debug
  • code completion on the Java you are 'writing' in your scripting language (I can't live without Java code completion)
  • impedence mismatches between languages; especially typed Java arrays

My experience is that the complete story isn't really all that easy with these interop stories. Which is probably the best reason you would want to do this anyway. That takes care of the first pro.

For the second and third pro, I'll just ask: what libraries are you wanting to use in the 'other' language (be it Java or scripting language)? Is there really that much of a difference, these days, between the functionality of, say, Java, PHP, and Ruby? Functionality from 10K feet, because you obviously use Rails when using standard Ruby, and are using Servlets in Java (or worse); think holistically here. The answer is ... not really.

Is all hope lost? For language interop ... yes.

Does that mean implementations of scripting languages on Java is pointless? No.

IronPython performance is on par with python-c. So there's no reason why implementing a scripting language in Java isn't a reasonable option, though you probably want to factor in things like a need for invokedynamic and making Java a better C (more on that last one in a future blog post).

The question is, do you really need user-level language interop, or do you just need your scripting language and it's typical libraries? I say the typical libraries, because at some point you are certainly dealing with Java objects in your interpreter / runtime, but they don't necessarily need to be visible to the end user; the programmer in this case. And you could certainly invent a mechanism to allow scripting language functions / classes to be implemented in Java for those non-mortals amongst us that implement core libraries. Back in the early VisualAge for Java days, the Java natives were implemented in Smalltalk (boy, was that sweet!). Who used it? Not many people (well, we didn't advertise it), but not many people would have needed it anyway. Not many people write the core libraries.

Taking the burden off of the scripting language implementor to add an 'interop facility' is also a huge benefit. At least, an interop facility that you have to make available as public API.

End users (programmers) win, to some extent, because they don't have two languages/class libraries to deal with. They lose the theoretical interop benefits, but they never really had them anyway.

In the end, what's the real benefit to doing this? That we get to implement our scripting languages and their extensions in Java. And not C. Or worse. With the recent GPL-ization of Java, I'm hoping that we're going to see Java available much more widely than it had been before. Time to take advantage of this situation.

I've made all sorts of crazy assumptions here; please attempt to prove me wrong.

Photo 'Keep 'em separated' with a nice CC license, by Mark and Allegra Jaroski-Biava. Found using the Flickr's Create Commons Search.

Update: So one assumption I got wrong was that John was arguing for the level of Java interop that I'm suggesting is pointless. He wasn't. He's on the same page as me (well, closer than I thought). The problem is the term interop was used, and it clearly means different things to different people.

Useful interop are things like JNI, the Zend API, etc. Useful because I can interoperate with C, that can do anything it wants to on a machine. Useful, but difficult to use. Who wants to program in C? Especially with these rather arcane 'extension' libraries. That's not just C, that's complicated C.

When I hear interop, I hear the "end user programmers can talk to Java directly from language-X". When John hears it, he's thinking JNI. I think this is good material for a future blog post - "defining interop".

Mea culpa John. Gotta go find me a little chocolate.

Wednesday, January 03, 2007

my new ruby slippers

Ruby Slippers

I certainly hope no one mistakes me for some kind of Ruby fan-boy because of my brand spankin' new Picante Chuck Taylors. Or was that Cayenne? I swear, my wife got them for me for Christmas, I didn't even pick the color!

I do love 'em.

And to be honest, I am becoming a bit of a Ruby fan-boy.

Time to do a little photoshopping of that picture at the top of my blog page.

Tuesday, January 02, 2007

nc state parks mashup

Raven Rock State Park

I just completed my first 'mashup', of sorts. After I wrote my blog post on Raven Rock NC State Park, I realized the NC State Park system was fertile ground for a map-based mashup.

So I wrote one.

What I did:

  • Collected a bunch of information about the parks. Obviously the most painful part of this project. The format of the file is a bit odd, but that's because the URLs of the parks and names were easy to lift out of the html on the 'park chooser' page. The longitudes, latitudes took the longest to gather; I had a little Google Maps 'app' I had written that would dump the coordinates of map locations based on mouse clicks, just pasted that into the data file.

  • Started working on a small HTML + JS app using the Google Maps API. My thinking was that I'd have a program I'd run on the server to read the input text file, and generate JSON data, that the HTML + JS app I was going to write would then read, to populate the map. I had some problem with that:

    • Making the map 'widget' automagically resizeable was not immediately obvious, and I didn't really have a way to test whether the method I ended up using would work anywhere but Firefox 1.5. (Note I found this page from the Google Maps discussion group).

    • Getting additional content on the page, with the resizing map widget, seemed like it was going to be a royal pain. Apparently I'm lost without Motif form attachments. I'm pretty handy with CSS, but never really mastered the layout bits.

    • Curiously, the map data from maps displayed with the Google Maps API, and with the Google Maps page, are from different companies. TeleAtlas and NAVTEQ, respectively. According to the legend at the bottom of the maps. I could have sworn the maps were a little different, somehow, but then when I found Lake Norman State Park on the NAVTEQ map, and saw it was called Duke Power State Park on the TeleAtlas map, it was ... pretty obvious they were different. Other differences seemed to be that the TeleAtlas map seemed to show more rivers, and fewer streets.

    • Google Mapplications are missing some features found on traditional Google Maps, like, oh, all the trimmings around the map (email, print, directions, search nearby, etc). At one point during prototying, I included a link to Google Maps in the Mapplication popup windows for each park. Which is obviously kinda dumb.

    • I discovered KML, and after that, the HTML + JS was too much work.

  • I had already written a small Ruby program to generate the JSON based on on the park data file; I just swizzled it a bit to generate KML instead.

  • Added some code to get weather data and add it to the 'description' of the park, from Yahoo! Weather.

  • Put it up on on the ncParksMap project page at my web site.

  • Set up a cron job to rebuild the .kml file every so often.


Note that KML was originally designed for Google Earth, so you can open the .kml file in there,, and specify how often to refresh the file and what-not.

Note that Google Maps has been sometimes complaining that it can't find the .kml file. Not sure what's going on. Try refreshing the page if you see this.

Next mapplication: show surf reports at the beach, on a map.