Author Archives: Marc

OS X Homebrew: Build FreeTDS from HEAD (gitorious)

Posted on by
1

Here’s a pull request I just submitted to homebrew to make it possible to build FreeTDS from master on its gitorious repo:

https://github.com/mxcl/homebrew/pull/21309

Example of using it:

$ brew install freetds --HEAD --universal
==> Cloning https://git.gitorious.org/freetds/freetds.git
Updating /Library/Caches/Homebrew/freetds--git
==> autoreconf -i
==> ./configure --prefix=/usr/local/Cellar/freetds/HEAD --with-openssl=/usr/bin --with-tdsver=7.1 --mandir=/usr/local/Cellar/freetds/HEAD/share/man
==> make
==> make install
🍺  /usr/local/Cellar/freetds/HEAD: 63 files, 3.6M, built in 67 seconds

$ brew test freetds --HEAD -v
Testing freetds
==> /usr/local/Cellar/freetds/HEAD/bin/tsql -C
/usr/local/Cellar/freetds/HEAD/bin/tsql -C
Compile-time settings (established with the "configure" script)
                            Version: freetds v0.92.dev.20130718
             freetds.conf directory: /usr/local/Cellar/freetds/HEAD/etc
     MS db-lib source compatibility: no
        Sybase binary compatibility: no
                      Thread safety: yes
                      iconv library: yes
                        TDS version: 7.1
                              iODBC: yes
                           unixodbc: no
              SSPI "trusted" logins: no
                           Kerberos: no

Pretty simple:

commit 3d786f23bc2ff5d73a22474f9256330a17f01e23
Author: Marc Abramowitz 
Date:   Thu Jul 18 09:10:33 2013 -0700

    freetds.rb: Enable support for building FreeTDS from HEAD (gitorious)

diff --git a/Library/Formula/freetds.rb b/Library/Formula/freetds.rb
index 0a700e6..362b411 100644
--- a/Library/Formula/freetds.rb
+++ b/Library/Formula/freetds.rb
@@ -5,10 +5,19 @@ class Freetds < Formula
   url 'http://mirrors.ibiblio.org/freetds/stable/freetds-0.91.tar.gz'
   sha1 '3ab06c8e208e82197dc25d09ae353d9f3be7db52'

+  head 'https://git.gitorious.org/freetds/freetds.git'
+
   depends_on "pkg-config" => :build
   depends_on "unixodbc" => :optional

+  if build.head?
+    depends_on :automake
+    depends_on :libtool
+  end
+
   def install
+    system "autoreconf -i" if build.head?
+
     args = %W[--prefix=#{prefix}
               --with-openssl=/usr/bin
               --with-tdsver=7.1

Here’s the commit on GitHub.

I also added support for a test and for doing a universal build.

Compiling a universal library

Posted on by
Reply

A note for my future self on how to compile a library as universal binary in Mac OS X.

For a while, I’ve been getting warnings like these when building pymssql:

ld: warning: ignoring file /usr/local/lib/libsybdb.dylib, 
file was built for unsupported file format 
( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) 
which is not the architecture being linked (i386): 
/usr/local/lib/libsybdb.dylib
ld: warning: ignoring file /usr/local/lib/libct.dylib, 
file was built for unsupported file format 
( 0xcf 0xfa 0xed 0xfe 0x 7 0x 0 0x 0 0x 1 0x 3 0x 0 0x 0 0x 0 0x 6 0x 0 0x 0 0x 0 ) 
which is not the architecture being linked (i386): 
/usr/local/lib/libct.dylib

I finally decided to do something about them. I rebuilt FreeTDS from source as follows:

./configure \
    CFLAGS="-arch i386 -arch x86_64" \
    CXXFLAGS="-arch i386 -arch x86_64" \
    LDFLAGS="-arch i386 -arch x86_64" \
    --disable-dependency-tracking
make
make install

Goodbye warnings!

This Stack Overflow post was helpful: Stack Overflow: How to compile universal libraries on Mac OS X?

Back to setuptools

Posted on by
Reply

Browsing PyPI yesterday, I was surprised to see a new version of setuptools. I almost thought it was a bug. For years, I’ve been drinking the distribute Kool-Aid

pip/distribute Public Service Announcement

and automatically using distribute instead of setuptools. Well, I guess that things have changed and now distribute has been merged into setuptools and distribute is deprecated and setuptools is the thing to use. It may take me a little while to unlearn my old habits and it might make explaining Python packaging a little bit more difficult (not that it was easy :-)).

Getting double-tap to drag working again in OS X Lion and Mountain Lion

Posted on by
1

Finally fixed one little thing that was annoying me on my work laptop with OS X 10.8.4. I couldn’t double-tap to drag files or make selections.

The fix is dead simple and it’s from this CNET article:

If you want to reactivate the classic double-tap-and-drag gesture, it’s possible, but the option is well-hidden. Instead of being in System Preferences under Trackpad, it’s actually under System Preferences > Universal Access > Mouse and Trackpad > Trackpad Options. Click the check box that says “Dragging” and you should be all set.

In Mountain Lion, it seems that “Universal Access” was renamed to “Accessibility”.

How to bring back "double tap to drag" in newer versions of OS X

How to bring back “double tap to drag” in newer versions of OS X

Note to self: Don’t name my git branches “tests”

Posted on by
Reply

I have sometimes had a git branch called “tests” because I was adding tests or working on tests. The problem is that many projects have a “tests” directory so if you have a “test” branch, you get this:

$ git diff tests
fatal: ambiguous argument 'tests': both revision and filename
Use '--' to separate paths from revisions, like this:
'git  [...] -- [...]'

You can of course use git diff -- tests and it will work, but it’s easier to just not name a branch “tests” in the first place.

Plone and Zope time

Posted on by
1

Doing my yearly ritual of looking at Plone & Zope and making sure I still don’t grok them. Check.

In this year’s installment, I set up a little Plone site and actually got as far as creating a custom content type. I started down the road of thinking I would create the content type manually with code in Archetypes. Then I looked at tutorials and saw that it looked like it involved a lot of repetitive code and configuration voodoo. I ended up using ZopeSkel to create a really, really simple Archetypes content type, which actually didn’t take too long to figure out (to my pleasant surprise).

It still feels like too much work and it’s difficult to find good documentation on what’s the current recommended way to do things, because the recommended way of doing things seems to change every couple of years and there is a lot of old, outdated documentation out there. A search on Archetypes for instance yielded all kinds of pages referring to practices that seem to be outdated now, like manually creating the directory structure for an Archetypes product (i.e.: no ZopeSkel) and copying the product into the Zope 2 “Products” directory (which seems to be deprecated in favor of buildout)

In comparison, creating a model in Django is very simple, Pythonic, and well-documented.

Continuation of mod_wsgi setup

Posted on by
2

My previous setup worked until I wanted to add another Django instance and then it didn’t work, because I had two WSGIScriptAlias entries under different URLs but it would launch whichever app it wanted to regardless of the URL. A little searching suggested that it had to do with mod_wsgi process pools. I eventually ended up with something like this:

WSGIPythonHome /www/python/pypi.venv
WSGIPythonPath /www/python/django
WSGIPassAuthorization On
WSGISocketPrefix /var/run/wsgi

<VirtualHost *:80>

    ...

    DocumentRoot /www/python

        WSGIDaemonProcess djangoplayground_wsgi user=apache python-path=/www/python/django
        WSGIScriptAlias /djangoplayground /www/python/django/djangoplayground/wsgi.py
        <Location /djangoplayground>
            WSGIProcessGroup djangoplayground_wsgi
        </Location>

        WSGIDaemonProcess djangopypi_wsgi user=apache python-path=/www/python/django
        WSGIScriptAlias /djangopypi /www/python/django/djangopypisite/wsgi.py
        <Location /djangopypi>
            WSGIProcessGroup djangopypi_wsgi
        </Location>
</VirtualHost>