Monday, January 07, 2013
Saturday, October 18, 2008
Righteous rant
/*- From comments in tds.h from FreeTDSSybase 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! */
Posted by
debedb
at
12:55 AM
0
comments
Labels: code comment, code rant, freetds, sybase, tds
Friday, March 30, 2007
Java-to-Python converter
"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/.
Posted by
debedb
at
6:34 PM
0
comments
Labels: converter, grammar, java, javacc, python, translator, visitor
Monday, March 19, 2007
py-cover task is now in the main pyAntTasks project
The py-cover task is now integrated into the
project tree.
Posted by
debedb
at
1:09 AM
1 comments
Labels: ant, code coverage, continous integration, pyanttasks, python, testing
Tuesday, February 27, 2007
Poor Man's Tracepoints and a call sequence of a C program
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
gdbserveron 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...
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...)
Posted by
debedb
at
9:31 AM
3
comments
Labels: c, cdt, debugging, eclipse, gdb, perl, reverse engineering, snippets, tools, visualization
Sunday, February 25, 2007
Stalin and high tech
Since Overstream embedding is now fixed, here...
Posted by
debedb
at
11:38 PM
0
comments
Labels: overstream
Tuesday, February 13, 2007
Continuous integration with code coverage in Python
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 addedUpdate
This code has been integrated into the main tree.
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 istrueit means that the test files reside in Python packages,falseotherwise. (In our case, they do not; they are in the tree but are not packages. Note that the originalpy-testtask assumed they are in packages, I ahve changed this too). -
coverage- path tocoverage.pyon 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.
Posted by
debedb
at
4:22 PM
0
comments
Labels: ant, code coverage, continous integration, continuum, python, tools
Monday, February 12, 2007
XmlRpc for AS 3.0 HOWTO
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 thatflex 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.
Posted by
debedb
at
7:01 PM
2
comments
Labels: actionscript, contrib, flex, xmlrpc
Thursday, January 11, 2007
The King, the Jedi and the Prodigal Son walk into a bar...
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).
Posted by
debedb
at
8:51 PM
0
comments
Sunday, November 26, 2006
Dbdb - a JPDA-based single-stack debugger for mixed-language programming
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).
Posted by
debedb
at
11:23 PM
0
comments
Labels: dbdb, debugging, eclipse, sourceforge, tools