Five Open Tools for 2D Structure Layout (aka Structure Diagram Generation)

Five Open Tools for 2D Structure Layout (aka Structure Diagram Generation)

Good summary of several alternatives. I've been using CDK of late, but am partial to tools written for CPython. I wonder if any of the alternatives make it as easy to extract coordinates as does CDK?

TUAW Terminal Tip: Safari 3.1 brings true one-window mode

Terminal Tip: Safari 3.1 brings true one-window mode:

...true one-window mode is finally, finally, here for Safari. All you need to enter is the command below into Terminal, hit enter, and you're sorted.

defaults write com.apple.Safari TargetedClicksCreateTabs -bool true

Yay!

Functest

Writing Functests:

"This is where functest really shines. When you run functest against any directory or file the collector actually compiles a dependency chain which includes any valid python modules in all the parent directories..."

Hm. So functest would let me dispense with this nonsense boilerplate in my test modules?

import sys
import os
thisdir = os.path.abspath(os.path.dirname(__file__))
def relpath(p):
return os.path.abspath(os.path.join(thisdir, p))
sys.path.insert(relpath("../"))

I wonder if nose does/will provide similar facilities? It's pretty nice in other respects...

Twill, CherryPy 3 and testing with internal servers

Twill can test CherryPy web servers "in process", without having to run them as servers. I've used twill this way with CherryPy 2, but when I recently tried to do the same thing with a CherryPy 3 server everything broke.

I had based my code on an old CherryPy 2 tutorial by Titus Brown, and was trying to grep through the CherryPy 3 code tree to figure out how to patch it up. Bad idea :)

Yesterday Google finally turned up a solution, from a talk Titus gave at PyCon 2007.

The upshot: don't use cherrypy._cpwsgi.CPWSGIApp. In CherryPy 3, your application itself is already a WSGIApp. What's more, I think cherrypy._cpwsgi.CPWSGIApp may be broken. For sure, it and twill have incompatible ideas about the correct type of the 2nd constructor argument.

Anyway, thanks to Titus, here's an example of how to connect twill to a CherryPy 3 application for in-process testing:

import twill
import cherrypy
...
wsgi_app = cherrypy.tree.mount(myApp, "/", myConfig)
cherrypy.engine.start(blocking=False)
twill.add_wsgi_intercept('localhost', 8080, lambda: wsgi_app)

[Update 2008/03/24] Ditched the cherrypy.server.quickstart() invocation, per fumanchu's comment. Reported as Ticket #801.

waf build errors

I'm evaluating waf to see if it's easier to use than SCons (especially for Qt projects). So far the results are encouraging. In particular, waf reports many kinds of problems using straightforward (color-coded!) error messages, rather than Python tracebacks.

target 'build_info' does not exist

Sometimes waf does spew an unintelligible Python traceback reminiscent of SCons. For me, these typically end with a KeyError:

File "/path/to/.waf-1.3.2-blah/wafadmin/Task.py", line 290, in must_run
    prev_sig = tree.m_sig_cache[key][0]
KeyError: -214303645

This error always translates to "you are trying to build a file which is part of your source tree."

My SConscripts work in situ, creating object files etc. in the same directories where the source code resides. waf prefers to put build products in a separate build/ subdirectory. When waf is instructed to generate an output file in its build tree, and when that file already exists in the source tree, waf fails with the KeyError traceback.

I'd bet this problem is most common in software projects which started life using build systems like Make or SCons -- tools which default to building in situ.

For example, I'm trying to use waf in a subversion workspace where I've been doing SCons builds for years. To make matters worse, one of the build products is a header file, containing revision number and date for the current build. This looks like a source file, so it's likely that I never checked whether it was properly removed by scons -u -c.

In retrospect, I should have started with a clean check-out...

Rogue Amoeba: Code Signing and You

Code Signing and You:

"Code signing itself is a neutral technology, but it gives incredible power to the system vendor, and that power is just waiting to be exercised and abused."

It's possible that Apple intends to close off the OS X platform. If that happens, I'll go back to Linux.

DailyTech - Researcher: Basic Greenhouse Equations "Totally Wrong"

From DailyTech:

"NASA refused to release the results.  Miskolczi believes their motivation is simple.  'Money', he tells DailyTech.  Research that contradicts the view of an impending crisis jeopardizes funding, not only for his own atmosphere-monitoring project, but all climate-change research.  Currently, funding for climate research tops $5 billion per year.
"

"The equations also answer thorny problems raised by current theory, which doesn't explain why "runaway" greenhouse warming hasn't happened in the Earth's past. The new theory predicts that greenhouse gas increases should result in small, but very rapid temperature spikes, followed by much longer, slower periods of cooling -- exactly what the paleoclimatic record demonstrates."

"Miskowlczi has used his theory to model not only Earth, but the Martian atmosphere as well, showing what he claims is an extremely good fit with observational results."

Hey, at least we still have peak oil.

Intermittent Pickle Problems in Jython

The previous post mentioned "integrating" Jython and CPython by transmitting a stream of pickles between the two. I encountered one intermittent problem with this approach, and I'm unsure of its cause. (Hm, and I should probably post this to a Jython mailing list...)

Problem

In Jython I'd pickled the str() of a java.io.StringWriter, into which I'd just written the SD representation of a CDK molecule. Jython could create the pickle alright. But when I tried to unpickle it in CPython, sometimes, for some molecules, I got a traceback:

File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/pickle.py", line 970, in load_string
    raise ValueError, "insecure string pickle"
ValueError: insecure string pickle

The error occurred consistently in my application code, always on the same input structure. But I couldn't derive a simple test script to demonstrate the problem.

Investigation

Examination of the problematic pickle data showed that a Python unicode string literal marker had somehow been inserted, and the type code for the item was somehow S (for string) rather than V (for unicode):

...
sS'sdf'
p3
Su'ZINC00000181\n  CDK...
 ^ What the... ?

Workaround

Google turned up a usable workaround: encode the offending string as utf-8 before trying to pickle it.

import codecs
enc = codecs.getencoder('utf8')
...
sdf = enc(sdf)
...

Ted Leung: The Sun is going to shine on Python

Congratulations to Ted Leung (and to Frank Wierzbicki):
The Sun is going to shine on Python.

Their work at Sun will extend well beyond Jython, but Ted's post reminded me of my recent experiences. Jython 2.2 sure made it pleasant and easy[1] to get what I needed out of CDK, and to integrate the results into a CPython app via pickle and subprocess.

I did miss some language features such as yield which have appeared in CPython since 2.2. Maybe at some point Ted and/or Frank will have time to re-sync Jython with CPython?

[1] I had one intermittent problem with this approach. See the next post.