Python - CSV to sqllite
Nice Python CSV to sqlite conversion...
# toSqlite.py - Imports humod06.txt to sqlite.
import csv
import sqlite3
conn = sqlite3.connect('humod.sqlite')
c = conn.cursor()
c.execute('''DROP TABLE IF EXISTS skl_desc''')
c.execute('''CREATE TABLE skl_desc (
id INTEGER PRIMARY KEY AUTOINCREMENT,
parent INTEGER,
mod INTEGER,
desc TEXT,
abr TEXT,
r INTEGER)
''')
insertSql = '''
INSERT INTO skl_desc
VALUES (null, ?, ?, ?, ?, ?)
'''
reader = csv.reader(open('humod06.txt', 'rb'), delimiter='\t')
rownum = 0
for row in reader:
if rownum == 0: pass
else:
parent = 0
rValue = 0
if row[5] == 'R':
rValue = 1
t = (parent,
row[1],
unicode(row[4].strip(), 'utf8'),
unicode(row[2].strip(), 'utf8'),
rValue)
c.execute(insertSql, t)
rownum += 1
print('rows: %s' % rownum)
conn.commit()
c.close()
Export this post to PDF document
Python - CSV to XML
# toXml.py - Imports humod06.txt to XML.
import csv
from xml.dom.minidom import parseString
doc = parseString('<skill_descriptors lvl="0"/>')
reader = csv.reader(open('humod06.txt', 'rb'), delimiter='\t')
rownum = 0
elm = doc.documentElement
for row in reader:
if rownum == 0:
header = row
else:
sd = doc.createElement('skill_descriptor')
colnum = 0
for col in row:
#print '%-8s: %s' % (header[colnum], col)
sd.setAttribute(header[colnum].lower(), unicode(col.strip(), 'utf8'))
colnum += 1
while row[3] <= elm.getAttribute('lvl'):
elm = elm.parentNode
elm.appendChild(sd)
elm = sd
rownum += 1
print(doc.toxml())
print('rows: %s' % rownum)
doc.unlink()
Export this post to PDF document
Egregious IE Bug
After nearly a decade of battling Internet explorer, you would have thought I knew all of IE's quirks, but today I stumbled across a "feature" (read bug) which absolutely astounded me. Running the code below in IE 7 or 8 shows their implementation of innerHTML strips leading spaces from the DOM. This wreaks havoc on HTML editors such as TinyMCE
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>XHTML Page</title>
</head>
<body>
<div id="baseDiv">
<a id="link" href="#" onclick="helloWorld()">Say hi...</a>
</div>
<script type="text/javascript">
//<!--<![CDATA[
function helloWorld() {
var newSpan = document.createElement('span');
newSpan.innerHTML = ' hello world ';
prompt('', newSpan.outerHTML);
}
//]]>-->
</script>
</body>
</html>
Export this post to PDF document
SVN - parse tlsext Work-Around
UPDATE (Apr 2, 2010): Version 2.2.15 does seem to have fixed this issue - I'd recommend upgrading if possible.
It took me so long to find the solution to this problem that I just had to share... Ever since last August, after upgrading Apache HTTPD from version 2.2.11 to version 2.2.13 I have had a nagging issue with my Subversion server and "parse tlsext" errors during large commits and other SVN operations (it seems I skipped version 2.2.12 for no apparent reason, but that version had the problem too).
SSL negotiation failed: SSL error: parse tlsext
According to comments on this page, "This issue is most propably because of using multiple SSL enabled VirtualHosts in Apache httpd 2.2.12 - 2.2.14 and OpenSSL 0.9.8f - 0.9.8l". They do link to a mod_ssl patch which they claim works. I did not try the patch myself, though - my SVN server is on Windows and I am not about to start building Apache on Windows, I will wait for the binaries to come! The patch is from November, so hopefully it will make its way into 2.2.15, whenever it is released.
Work Around:
After a bit of Googling I found several forum/mailing-list posts which pointed to disabling Transport Layer Security (TLS) Extensions by adding the following to the VirtualHost entry in httpd-ssl.conf file
SSLProtocol -ALL +SSLv3
The critical part I had been missing was that this needs to be added to EACH VirtualHost using SSL on the same port. Since I have multiple named VirtualHosts running on port 443, even though I had disabled TLS for the affected VirtualHost, TLS was still enabled on the port. Once I applied this to all VirtualHosts on port 443 everything worked as it should.
Hope it helps someone...
Export this post to PDF document
