Laziness, impatience and hubris

Righteous rant

2008-10-18T00:55:00.000-07:00

/*
 Sybase does an awful job of this stuff, non null ints of size 1 2
and 4 have there own codes but nullable ints are lumped into INTN
sheesh! 
*/

- From comments in tds.h from FreeTDS

Java-to-Python converter

2007-03-30T18:34:00.000-07:00

"Anything that can be done, could be done 'meta'" (© Charles Simonyi) is right up there with "Laziness, impatience and hubris" (© Larry Wall) as pithy description of my development philosophy. Also, unfortunately, there's another one: "Once it's clear how to proceed, why bother to proceed" (or something like that). So, with that in mind...

I wanted a Python client library for GData (thankfully, they released one last week, so this is moot -- good!), so I thought of automagically converting the Java library to Python. I tried Java2Python, but it's based on ANTLR grammar for Java 1.4, and the library, of course, is in Java 5. As I was relearning ANTLR and writing all these actions by hand (the pain!), I took a break and found Java 1.5 parser with AST generation and visitor suport by Julio Gesser (no relation, I presume?) and Sreenivasa Viswanadha, based on JavaCC. Aha! Much easier... But then, of course, Google releases the Python version of the library I needed in the first place, so I don't bother wrapping this project up... Here it is for whoever wants it: http://code.google.com/p/j2p/.

py-cover task is now in the main pyAntTasks project

2007-03-19T01:09:00.000-07:00

The py-cover task is now integrated into the project tree.

Poor Man's Tracepoints and a call sequence of a C program

2007-02-27T09:31:00.000-08:00

My C is quite rusty, so to help me figure out the flow of a program, I thought I'd do with gdb what Tony Loton did with JPDA. Quickly giving myself a refresher on gdb, I thought tracepoints are the easiest way to go. Except that they are available only for remote targets, and

There's no gdbserver on my host platform (Cygwin)
The target platform does have it (good news!), but it doesn't support tracepoints (and some say, that few if any stubs even support it...

So I wrote a silly Perl script to read ctags information, create breakpoints on every function entry, print the arguments and resume. I haven't bothered to figure out where to use pure MI vs. CLI commands, and in general I have no clue...

Now, what I think would be interesting is making this an add-on, using CDT (or, more generically, via Eclipse Debug Framework) and GEF... I envision something like a call graph (with exclusions of course, because it will become too big), which grows as you step through, displaying arguments. Could be a quick way to get a picture of how a program works before just reading the code and keeping stuff in your head...

In related news, upgrading to Eclipse 3.2.2 I lost the "Remote debugging" launch configuration. (Ironically, the reason for the attempted upgrade was to see whether a bug with hardcoded remote port has been fixed (it appeared that it's always 4305, no matter what you put in; while the default one is 1234, which is the kind of thing an idiot would have on his luggage.). Which brings me to the "Zero information content" of various blogs/articles out there (which this blog is trying not to be). Thank you, Bill Graham, for pointing out that "the 'vanilla' CDT from www.eclipse.org [...] doesn't support remote target debugging", thus leading me in my Google search to your article which doesn't tell me how to fix it, nor does it tell me much of anything... There, I vented. (The answer, BTW, is to get Target Management, who knew...)

Stalin and high tech

2007-02-25T23:38:00.000-08:00

Since Overstream embedding is now fixed, here...

Continuous integration with code coverage in Python

2007-02-13T16:22:00.000-08:00

Update
This code has been integrated into the main tree.

I decided it would be good to have a coverage report of our Python code, with nice visualization like Clover. So I took Ron Smith's PyAntTasks, and added py-cover task to them. This will run coverage for every test, and a cumulative one. In other words, you can see what code a particular test exercises, and what code all the tests in your tree exercise.

This also modifies py-test task to include packagedtests attribute - see below.

The newly added py-cover task runs Ned Batchelder's coverage.py (download it separately), and is specified as follows in your build.xml:

<py-cover
packagedtests="false"
pythonpath="${pythonpath}"
reportsDir="${reports}"
coverage="${tools}/coverage.py">
 
<tests dir=".">
    <include name="**Test.py">
      </tests>

<src dir="${quickRoot}">
     <include name="**/*.py">
     <include name="*.py">
</src>
</py-cover>

Here, <tests> is a FileSet specifying tests to run, <src;> is a FileSet specifying source code to cover. The attributes are:

reportsDir - where the coverage reports go
packagedtests - this idiosyncrasy is prompted by our tree setup. If this attribute is true it means that the test files reside in Python packages, false otherwise. (In our case, they do not; they are in the tree but are not packages. Note that the original py-test task assumed they are in packages, I ahve changed this too).
coverage - path to coverage.py on your system (which you downloaded separately, right?)

P.S. I know about the colorize.py thingie, but I rolled my own (uglier, of course) for this one.

XmlRpc for AS 3.0 HOWTO

2007-02-12T19:01:00.001-08:00

Since people ask (in emails, at the short-lived MT version of this blog and on flexcoders@yahoo), here is how I use it. (DISCLAIMER: as I've mentioned, I hacked this from the original when I was just starting with Flex 2, so I gutted some code before I knew what the hell I was doing, but in this state it works for me...)

I use Flex Builder. I have the contents of the zip file right in my Flex Builder project. (NOTE: This was before I read that flex should not be a part of a package name per Adobe's license; change it, willya?)

Then I choose have a simple facade like so:

package com.qbf.flex.ct {
  // Insert correct imports here, of course...

  public class Utils {
    public static function serverCall(method:String, 
                                          params:Array,    
                                          handler:Function): void {
        SERVER_CALL.call(method, 
                         params, 
                         handler, 
                         DisplayObject(Application.application));
    }

    public static const SERVER_CALL:XmlRpcService = 
   new XmlRpcService("http://localhost:8081/", 
                        Application.application.url.indexOf("http://") == 0? null :
   null :
   // This is explained further below... 
   QbfFakeResponse.SINGLETON); 
}

And from everywhere else in the code I use Utils.serverCall() as follows:

var params:Array = [{value : resdefDataToServer, type: "struct"}, 
uri, server];
Utils.serverCall("doStuff", params,
        // This callback will be executed when the server 
        // call returns
 function(result:Object):void {
           process(result);
        });

Notice that you only need to specify types for parameters if it's not a string. If all your parameters are string, you can just pass an array of their values to the serverCall() -- a little sugar...

Now about this QbfFakeResponse.SINGLETON business (it's not necessary, just use null in its place if you don't need it). The definition of SERVER_CALL checks whether the application URL starts with http:// -- in my case, it means that it's running "for real". If it is running in Flex Builder's debugger, the URL will start with file://, and so I will use "fake" responses to simulate server calls (this is sometimes useful for debugging, so that I don't have to run a server). This fake response class is an implementation of com.qbf.flex.util.xmlrpc.FakeResponse interface. All you need to do is implement getResponse() method and return whatever you need by checking the method name and parameters provided.

The King, the Jedi and the Prodigal Son walk into a bar...

2007-01-11T20:51:00.000-08:00

So, earlier I tried to switch to Blogger briefly, because my LiveJournal was messing up javablogs feeds (and I wanted something trackback-like). But then I missed this tag/label/category functionality thingie, so I had a brief affair with Movable Type, but then, voila -- The New Version of Blogger. Good, I don't have to host the stupid thing then...

Peter Kriens has been working too much: "Today an interesting project proposal drew my attention: Corona. Ok, the name is a bad start. The Apache model of names without a cause is becoming a trend." Eh? I was with you until the last sentence -- but it's not an Apache model of names without a cause, it's a model of -- aw, geez, there must be a pithier term for it -- names for things associated with main product that are in some ways puns on the original name (JavaBeans, Jakarta, etc.) Get it? Sun - Eclipse, Eclipse - Corona? (Things will really get out of hand -- with horses! -- when a Corona-associated product will be called Dos Equis).

Dbdb - a JPDA-based single-stack debugger for mixed-language programming

2006-11-26T23:23:00.000-08:00

Dbdb project is officially up for adoption, because I have no plans for working on it (I am sick of it). Dbdb is a proof-of-concept of a JPDA-based single-stack debugger for mixed-language programming, done as an Eclipse plugin (but doesn't have to be). It is based on Java 6 ("Mustang"). The proof-of-concept is allowing a developer to debug Java code that calls a PL/SQL stored procedure. The debugging session in Java proceeds normally, nothing to write home about. When a Statement.execute() (or similar) statement is executed, however, the debugger connects to the Oracle's VM and shows a combined call stack, from Java down into PL/SQL. (See screenshot). The idea, of course, that it can be done with other combinations, but Java-into-Oracle-stored-proc is a very common scenario. P.S. This is a rehash of an older post. I am trying to see what Blogger is like vs. LJ (for instance, LJ breaks javablogs feeds).