From mark at microenh.com Sat Apr 11 20:28:50 2009 From: mark at microenh.com (Mark Erbaugh) Date: Sat, 11 Apr 2009 14:28:50 -0400 Subject: [CentralOH] pysqlite2 Message-ID: <1239474530.18520.21.camel@quad> I'm trying to build pysqlite2 against a version of sqlite3 that is not installed as the default version. Basically, I built a web app on my local machine against sqlite 3.4.2 and went to install it on my web server. They have sqlite 3.2.1 installed. I discovered that there were some changes between 3.2.1 and 3.4.2 that are important to my app. Rather than change my app, I thought I'd upgrade pysqlite2. I'm just a customer of the web server and don't have superuser access. First, my understanding is that all the database access code is built into pysqlite2, there is no "server" required. It's just a matter of getting _sqlite.so (part of pysqlite2) built with the proper code. I downloaded and built the latest sqlite 3.6.12, using ./configure --prefix=/home/mark/Projects/sqlite/install, make and make install (where install is a local user writeable directory). If I go into the install directory and launch the command-line sqlite3, it indicates the correct version 3.6.12. pysqlite2 (version 2.5.5) is built using distutils and has a setup.cfg file that is supposed to be modifiable for my situation. Here's the original: [build_ext] #define= #include_dirs=/usr/local/include #library_dirs=/usr/local/lib libraries=sqlite3 define=SQLITE_OMIT_LOAD_EXTENSION I modified it to: [build_ext] #define= include_dirs=/home/mark/Projects/sqlite/install/include library_dirs=/home/mark/Projects/sqlite/install/lib libraries=???? define=SQLITE_OMIT_LOAD_EXTENSION I assume that # are comments, so I removed them when I edited the include_dirs and library_dirs. It appears that the correct -I and -L parameters are passed to gcc. The problem, I think is the libraries command. If I leave it at libraries=sqlite3 (the default) pysqlite2 builds, but includes the versions of installed version of sqlite3. I haven't been able to figure what to do with the libraries line. If I change it to anything other than sqlite3, the build process complains for example with libraries=libsqlite3 there is an error message: /usr/bin/ld: cannot find -llibsqlite3 I changed it to libraries = /home/mark/Projects/sqlite/install/lib/libsqlite3 and gcc complained warning: no library file corresponding to '/home/mark/Projects/sqlite/install/lib/libsqlite3' found (skipping) There are several other files in the install/lib directory, but I get similar errors with them all. FWIW, there is no sqlite3 file. The only sqlite3 file in the install tree is an executable which runs the sqlite command line program (which indicates the proper version). Obviously, I'm in over my head in understanding what's going on. Any help would be appreciated. Thanks, Mark From mark at microenh.com Tue Apr 14 20:47:19 2009 From: mark at microenh.com (Mark Erbaugh) Date: Tue, 14 Apr 2009 14:47:19 -0400 Subject: [CentralOH] web.py anyone Message-ID: <1239734839.7591.8.camel@quad> I've started using web.py (www.webpy.org) for creating web based apps. Is anyone else using it. I'd like to find some folks to discuss things or see what others have done with it. Thanks, Mark From wam at cisco.com Wed Apr 15 00:16:42 2009 From: wam at cisco.com (William McVey) Date: Tue, 14 Apr 2009 18:16:42 -0400 Subject: [CentralOH] pysqlite2 In-Reply-To: <1239474530.18520.21.camel@quad> References: <1239474530.18520.21.camel@quad> Message-ID: <1239747402.8234.40.camel@talyn.cisco.com> On Sat, 2009-04-11 at 14:28 -0400, Mark Erbaugh wrote: > I'm trying to build pysqlite2 against a version of sqlite3 that is not > installed as the default version. Basically, I built a web app on my > local machine against sqlite 3.4.2 and went to install it on my web > server. They have sqlite 3.2.1 installed. I discovered that there were > some changes between 3.2.1 and 3.4.2 that are important to my app. > Rather than change my app, I thought I'd upgrade pysqlite2. Well, if all you need is an updated sqlite3 backend, you should be able to just upgrade it and continue to use the same python interface but utilizing a different shared library. > pysqlite2 builds, but includes the versions of installed version of > sqlite3. If gcc is getting passed in the right -I and -L options the pysqlite2 library should be getting linked in correctly. The problem is mostly likely due to sqlite3 being a shared library. At runtime, the runtime linker is resolving the external reference by pulling in libsqlite3.so.0 from your system. This behavior can be modified on a system-wide basis by updating your /etc/ld.so.conf config file (or on some linux distributions, this is delegated to config files with /etc/ld.so.conf.d/ Of course, that requires system privileges. If you don't have system privileges (or just don't want to update the system for your particular application), you can set the LD_LIBRARY_PATH environment variable to point to the directory which contains your shared library. Once that is done, you should be able to run 'ldd _sqlite3.so' and see libsqlite3.so.0 getting resolved with your custom project version of the shared library and not the system one. > I haven't been able to figure what to do with the libraries line. If I > change it to anything other than sqlite3, the build process complains That value is passed on to the -l option of gcc, which needs the library name without the lib prefix. Leaving it with the default value should work. > There are several other files in the install/lib directory, but I get > similar errors with them all. FWIW, there is no sqlite3 file. The > only > sqlite3 file in the install tree is an executable which runs the > sqlite > command line program (which indicates the proper version). > > Obviously, I'm in over my head in understanding what's going on. Any > help would be appreciated. Really though, you probably don't need to reinstall pysqlite2. The version that is already installed on your system should be just Here is how I was able to install the latest SQLite library and access it from Python without having to reinstall the pysqlite2 package: * I pulled down the sqlite-amalgamation-3.6.13.tar.gz package from SQLite.org. $ cd /tmp $ curl -O http://www.sqlite.org/sqlite-amalgamation-3.6.13.tar.gz $ tar xzf sqlite-amalgamation-3.6.13.tar.gz $ cd sqlite-3.6.13 * Configured, built and installed package into a project directory $ configure --prefix=/tmp/scratch-project $ make all install $ find /tmp/scratch-project/ -print /tmp/scratch-project/ /tmp/scratch-project/lib /tmp/scratch-project/lib/libsqlite3.a /tmp/scratch-project/lib/libsqlite3.so /tmp/scratch-project/lib/pkgconfig /tmp/scratch-project/lib/pkgconfig/sqlite3.pc /tmp/scratch-project/lib/libsqlite3.la /tmp/scratch-project/lib/libsqlite3.so.0.8.6 /tmp/scratch-project/lib/libsqlite3.so.0 /tmp/scratch-project/include /tmp/scratch-project/include/sqlite3.h /tmp/scratch-project/include/sqlite3ext.h /tmp/scratch-project/bin /tmp/scratch-project/bin/sqlite3 * Once installed, I set my LD_LIBRARY_PATH and confirmed that the python library of sqlite module was used $ LD_LIBRARY_PATH=/tmp/scratch-project/lib $ export LD_LIBRARY_PATH $ ldd /usr/lib/python2.5/lib-dynload/_sqlite3.so | grep libsqlite3 libsqlite3.so.0 => /tmp/scratch-project/lib/libsqlite3.so.0 * Test with the native sqlite3 python module: $ python >>> import sqlite3 >>> sqlite3 >>> sqlite3.sqlite_version '3.6.13' * Test the negative condition (without the LD_LIBRARY_PATH) to make sure there is a difference in SQLite version: $ unset LD_LIBRARY_PATH $ ldd /usr/lib/python2.5/lib-dynload/_sqlite3.so | grep libsqlite3 libsqlite3.so.0 => /usr/lib/libsqlite3.so.0 $ python >>> import sqlite3 >>> sqlite3.sqlite_version '3.5.9' That looks like it accomplished what we needed it to. An updated version of the SQLite database library utilizing the same python bindings that come shipped with python. -- William From eric at intellovations.com Thu Apr 16 18:44:33 2009 From: eric at intellovations.com (Eric Floehr) Date: Thu, 16 Apr 2009 12:44:33 -0400 Subject: [CentralOH] PyOhio: Call for Proposals In-Reply-To: <34f468870904160419m19ae6d9bw3f28b94ba9d7808b@mail.gmail.com> References: <6523e39a0904091354m4f2ec721ke0ca8e50a5f74208@mail.gmail.com> <34f468870904130542l106aaff2ida71733ff69bd101@mail.gmail.com> <34f468870904160419m19ae6d9bw3f28b94ba9d7808b@mail.gmail.com> Message-ID: <34f468870904160944h6d7b03d7ge9d328c9616fe041@mail.gmail.com> Hi, PyOhio, the Python conference for Ohio, will be at OSU Saturday and Sunday, July 25-26, 2009.? The call for speaking proposals just went out, see below for details. Also, if you are interested in Python, and would attend a Central Ohio Python User's Group, I'm thinking about starting one.? Please send me a note if you would be interested. Best Regards, Eric ----------------- PyOhio: Call for Proposals PyOhio 2009, the second annual Python programming mini-conference for Ohio and surrounding areas, will take place Saturday-Sunday, July 25-26, 2009 at the Ohio State University in Columbus, Ohio. A variety of activities are planned, including tutorials, scheduled talks, Lightning Talks, and Open Spaces. PyOhio invites all interested people to submit proposals for scheduled talks and tutorials. PyOhio will accept abstracts on any topics of interest to Python programmers. Standard presentations are expected to last 40 minutes with a 10 minute question-and-answer period. Other talk formats will also be considered, however; please indicate your preferred format in your proposal. Hands-on tutorial sessions are also welcomed. Tutorial instructors should indicate the expected length PyOhio is especially interested in hosting a Beginners' Track for those new to Python or new to programming in general. If your proposal would be suitable for inclusion in the Beginners' Track, please indicate so. Organizers will work with speakers and instructors in the Beginners' Track to help them coordinate their talks/tutorials into a smooth, coherent learning curve for new Python users. All proposals should include abstracts no longer than 500 words in length. Abstracts must include the title, summary of the presentation, the expertise level targeted, and a brief description of the area of Python programming it relates to. All proposals should be emailed to cfp at pyohio.org for review. Please submit proposals by May 15, 2009. Accepted speakers will be notified by June 1. You can read more about the conference at http://pyohio.org If you have questions about proposals, please email cfp at pyohio.org. You can also contact the PyOhio organizers at pyohio-organizers at python.org. From harrisbw at notes.udayton.edu Sat Apr 18 19:28:44 2009 From: harrisbw at notes.udayton.edu (Bryan Harris) Date: Sat, 18 Apr 2009 13:28:44 -0400 Subject: [CentralOH] Neat little tool to visualize binary data Message-ID: <16d1d1250904181028q4312cbb7uc31a66b610462f2e@mail.gmail.com> Hi all, I wrote this little tool to visualize binary data. It doesn't have to be binary, but it treats all files as binary. Text files come out looking grey. Here for instance is an image of my master boot record. Warning! This is faithfully reproducing the binary input, so I wouldn't spread around your /etc/passwd or anything else secret... Bye, Bryan Bryan Harris Research Engineer Structures and Materials Evaluation Group harrisbw at notes.udayton.edu http://www.udri.udayton.edu/ (937) 229-5561 -------------- next part -------------- A non-text attachment was scrubbed... Name: bin2bmp.py Type: text/x-python Size: 1646 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: more.com-XP.bmp Type: image/bmp Size: 17334 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: more-obsd.bmp Type: image/bmp Size: 87222 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: more-ubuntu.bmp Type: image/bmp Size: 30390 bytes Desc: not available URL: From harrisbw at notes.udayton.edu Sat Apr 18 20:01:33 2009 From: harrisbw at notes.udayton.edu (Bryan Harris) Date: Sat, 18 Apr 2009 14:01:33 -0400 Subject: [CentralOH] Binary images of three file systems with the debian logo icon Message-ID: <16d1d1250904181101x63bdf7dbm88381e2eabb4f28f@mail.gmail.com> I just wanted to play with my new tool. I created 3 100 kB filesystems, mounted them with 'mount -o loop' and stuck the debian logo on all three filesystem images. (Actually I tried ntfs, reiserfs, and ext4, but they didn't work for various reasons.) The results are interesting to a geek like me. You can clearly see the file itself on all three fs images, and the stuff at the top is what makes the file system different. This is neat! Bryan Bryan Harris Research Engineer Structures and Materials Evaluation Group harrisbw at notes.udayton.edu http://www.udri.udayton.edu/ (937) 229-5561 -------------- next part -------------- A non-text attachment was scrubbed... Name: ext2.img.bmp Type: image/bmp Size: 102582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ext3.img.bmp Type: image/bmp Size: 102582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: vfat.img.bmp Type: image/bmp Size: 102582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debian-logo.png.bmp Type: image/bmp Size: 1974 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debian-logo.png Type: image/png Size: 1718 bytes Desc: not available URL: From pythondevdang at lazytwinacres.net Tue Apr 21 04:28:13 2009 From: pythondevdang at lazytwinacres.net (Daniel 'Dang' Griffith) Date: Mon, 20 Apr 2009 22:28:13 -0400 Subject: [CentralOH] pyparsing W00t! for centraloh In-Reply-To: References: Message-ID: <6.2.3.4.2.20090420222444.0230ee68@mail.lazytwinacres.net> An HTML attachment was scrubbed... URL: