FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid RSS feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

line 3, column 25: description should not contain HTML: a [help]

feeds as well.)&lt;/p&gt;</description><link>http://www.thok.org/intranet/py ...
                         ^

line 84, column 0: description should not contain relative URL references: usbscale.py (10 occurrences) [help]
```
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/u ...
```

line 681, column 178: Missing atom:link with rel="self" [help]

... Jun 2004 10:00:00 -0000</pubDate></item></channel></rss>
                                             ^

Source: http://www.thok.org/intranet/python/aggregation.rss

<rss version="2.0"><channel><title>THOK Python Projects Aggregation</title><description>All projects under <a href="http://www.thok.org/intranet/python">http://www.thok.org/intranet/python</a> unified into a
single common feed. (Individual projects all have their own distinct
feeds as well.)</description><link>http://www.thok.org/intranet/python/aggregation.rss</link><item><title>exif: Tue Dec 2 22:22:00 2014</title><description>Just noticed an actual "stuttering" repeat upload caused by the <code>flickr</code>/<code>flickd</code> processing mishandling duplicated file (one md5sum, 3 "file" names and it would re-upload the last one but tag the first one as <code>flickd</code>...) After fixing the immediate problem by hand (deleting the duplicates on Flickr itself, then moving the <code>flickd</code> tags around with emacs) I tried to measure the scope of the problem:
<div class="codehilite"><pre><code>import kimdaba_album
album = kimdaba_album.parse(kimdaba_album.kimdaba_default_album())
km = {}
for img in album.findall("images/image"):
mm = img.get("md5sum")
ff = img.get("file")
km[mm] = km.get(mm, []) + [ff]
print len([k for k,v in km.items() if len(v) &gt; 1])
</code></pre></div>
Turns out there are 289 distinct images that each have multiple paths - one of which is the less-surprising 18 zero-length files, primarily from old cellphones, one is the 3-way that caused the problem, and the rest are duplicates of various kinds. Not much of a mess given that there are 131446 entries total, but it still caused a visible problem and needs fixing.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/exif/readme_1417594920.html</guid><pubDate>Wed, 03 Dec 2014 08:22:00 -0000</pubDate></item><item><title>Yay, youtube takes care of this now</title><description>In 2012, Google
<a href="http://googleresearch.blogspot.com/2012/05/video-stabilization-on-youtube.html">added video stabilization to youtube</a>
under <code>Edit -&gt; Enhancements</code> so I fed it the hawk video and applied it;
<a href="http://www.youtube.com/watch?v=0B-A_EA93yc">http://www.youtube.com/watch?v=0B-A_EA93yc</a> shows that it works quite
nicely, and saves me the effort of doing any packaging work on this
code. (They've also included much more advanced techniques like
<a href="http://research.google.com/pubs/pub37744.html">Rolling Shutter removal</a>
which I hadn't even considered as a solvable problem.)
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/hawk/readme_1392650820.html</guid><pubDate>Mon, 17 Feb 2014 15:27:00 -0000</pubDate></item><item><title>newthing: Mon Aug 5 12:34:00 2013</title><description>A year later and that clearly worked well. Let's try again, maybe with something simple like
<ul>
<li>
<code>Makefile</code>s (gnu is fine, esp. with guile support :-)</li>
<li>split <code>README.md</code> into snippets</li>
<li>basic styling, even if not bootstrap...</li>
</ul>
(In practice, it turns out that getting the existing tools running again under Raring has taken a couple of evenings, but at least it is producing output, so maybe I shouldn't be even that ambitious :-)
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/newthing/readme_1375738440.html</guid><pubDate>Mon, 05 Aug 2013 21:34:00 -0000</pubDate></item><item><title>zephyr_page: Sat Oct 15 01:47:00 2011</title><description><code>zgather.py</code> has been vaguely useful, but the web interface didn't really go anywhere, and I mostly use <code>barnowl</code> as a backlog reader (along with my traditional logger.) Recent thoughts inspired a new architecture:
<ul>
<li>
<code>couchdb</code> holding zephyrgrams<ul>
<li>so split out the subscribing part of <code>zgather.py</code> into a "<code>tzc</code> with JSON instead of S-expressions"</li>
<li>then we can run multiple subscribers, letting couchdb eliminate duplicates</li>
<li>then a <code>barnowl</code> backend can be a couchdb client</li>
<li>continuity over upgrades is handled by extra <code>couchdb</code> instances, and extra subscribers</li>
<li>same db can hold "read this" and "liked/saved this" info</li>
<li>an IMAP interface can work with all that, allowing K-9 to be a mobile client...</li>
<li>a JSON interface to the couchdb can be the "remote" part, either by getting a backlog stream from the dbs, or looking at a freshly-instantiated local mirror</li>
</ul>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/zephyr_page/readme_1318675620.html</guid><pubDate>Sat, 15 Oct 2011 10:47:00 -0000</pubDate></item><item><title>toodledo: Sat Jan 29 02:22:00 2011</title><description>While I still have hundreds of personal todo items filed in <code>hiveminder</code>, the exposed-perl-guts API has kept me from getting very far with my own client code - and the limited number of other non-web clients suggests that I'm not alone in this. Looking for other apps that I can cleanly use on my (Android) phone, and after some failures with <code>RememberTheMilk</code> (in particular, somehow tasks filed from clients were only visible to other clients, not on the website) and some uninspired efforts at writing my own, I came across ToodleDo; there were multiple iOS and Android clients, several of which took the approach of doing their own "model" for tasks, but also pushing them to ToodleDo, rather than being specifically ToodleDo clients. ToodleDo's API docs seem to encourage this some by talking explicitly about synchronization.
Turns out that once you get past the slightly odd (and not particularly secure) ToodleDo authentication step, you can write commandline apps for it using <code>curl</code> and <code>xmlstarlet</code> - I don't recommend it, but 
<div class="codehilite"><pre><code>curl -s "&lt;http://api.toodledo.com/api.php?method=getContexts;key=$short_term_key"&gt; | xmlstarlet sel -T -t -m contexts/context -s T:-:- '*' -v 'text()' -n
</code></pre></div>
did actually work. Of course I went from there directly to python, again getting distracted with messing around with the authentication steps... finally I took another look and found <code>poodledo</code>, a simple python API wrapper that is unmaintained but functional, and since one of my left-over resolutions from 2009 was to put more effort into using other people's code instead of writing it from scratch, I took a shot at it.
This turns out to work just fine, at least for various filtered versions of <code>getTasks</code>. A simple task-adder is next, probably similar to my hiveminder <code>todo.py</code> tool. Turns out I went a little overboard with a class that stashes key-value-expiration into a sqlite db in one's homedir, for things like remembering the username, password, and short-term api key (4 hour expiration) - that's something that is common enough that there should be some existing version to use, but I'm not sure what to actually call it so I can search for it :-) I suppose the right answer is to store the password with <code>python-keyring</code> but that still leaves a host of other user-specific data to store, so it doesn't actually simplify the code at all to use it.
(Not actually posting the code here until I implement a few more features and actually use them for a bit, but since I was checking it in, I figured I'd blog about it a bit too.)
<ul>
<li>hiveminder <a href="http://task.hm">http://task.hm</a>
</li>
<li>iMinder <a href="http://iminder.worldairmaillinks.com/">http://iminder.worldairmaillinks.com/</a> (but note that with 700+ tasks, it falls over pretty quickly on the iPad)</li>
<li>RememberTheMilk <a href="http://www.rememberthemilk.com/">http://www.rememberthemilk.com/</a>
</li>
<li>ToodleDo <a href="http://www.toodledo.com/">http://www.toodledo.com/</a>
</li>
<li>ToodleDo API <a href="http://api.toodledo.com/2/index.php">http://api.toodledo.com/2/index.php</a>
</li>
<li>poodledo python wrapper <a href="http://code.google.com/p/poodledo/">http://code.google.com/p/poodledo/</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/toodledo/readme_1296303720.html</guid><pubDate>Sat, 29 Jan 2011 12:22:00 -0000</pubDate></item><item><title>usb: Thu Oct 8 00:42:00 2009</title><description>A few years back I picked up a Radio Shack USB Electronic Scale, on clearance, on the theory that it might work someday - or else I'd get at least that much value out of taking it apart...
I found it on a shelf today, plugged it in, did a google search for the USB id, and found user-space code that talked to <code>hiddev0</code> and turned the events into weights. As much for the practice as anything, I converted it to python - handling <code>ioctl</code>s isn't particularly tricky, but it took some poking to determine that the event values were sign-extended bytes, and the multiple reassignments to different variables in the C code actually mattered.
<ul>
<li>forum thread about the scale <a href="http://www.linuxquestions.org/questions/linux-hardware-18/installing-a-usb-scale-503125/page2.html">http://www.linuxquestions.org/questions/linux-hardware-18/installing-a-usb-scale-503125/page2.html</a>
</li>
<li>bkubes C code <a href="http://kubes.org/src/usbscale.c">http://kubes.org/src/usbscale.c</a>
</li>
<li>my python version <a href="usbscale.py">usbscale.py</a>
</li>
</ul>
The python code probably needs to run as <code>root</code> unless you do some <code>udev</code> tweaking; fire it up with the scale empty, when you get the prompt, put something on it, hit enter, and read the weight in grams. Not terribly exciting... but the next step might be to keep reading until the new value stabilizes. Ultimately I'd like to put this in the kitchen, maybe hooked to a chumby, with code that lets you set a target weight, then beeps in one tone when you get close, and another when you hit the actual value (or something more sophisticated.) Basically to let me look at what I'm pouring rather than at the display... could also do multiple targets for mixing, have it even "speak" the next item to add (or for things that are strictly proportional, adjust later measurements based on the initial one, though that seems like it might not be that useful compared to just being accurate.)
note added 20140224 I wonder if the app attached to the <a href="adaptics.co">Adaptics</a> "Drop" connected-scale will include that, it at least does <a href="http://gigaom.com/2014/02/24/drop-gets-into-the-kitchen-with-a-connected-scale-for-bakers/">sophisticated recipe integration...</a>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/usb/readme_1254994920.html</guid><pubDate>Thu, 08 Oct 2009 09:42:00 -0000</pubDate></item><item><title>ztwit: Wed Dec 10 00:15:00 2008</title><description>Got one negative comment about the flickr updates, decided to interpret it as "make them more interesting" rather than actually stopping them (after all, playing with the tools is more than half of what this is about - I'm not trying to find strangers here, or anything...)
The flickr updates now include as many tags as they can, sorted by popularity and length, so the latest one says <code>[Concord,Great Meadows National Wildlife Refuge,Massachusetts,ice,sunshine,winter,marsh...]</code> which perhaps gives the reader an idea of what pictures they'll find. (Granted, most of my readers are local, so knowing me and knowing the weather is probably sufficient to guess :-) Not realizing that python's sort is stable in 2.4 and later, I counted tags and used a key of <code>tag_popularity[tag] - 1/float(len(tag))</code> (the value itself is the major key, putting everything into integer buckets, and the tag length reduces that - the shorter the tag, the more it reduces, so the closer to the start of the list of tags that length, but bounded between 1/1 and 1/longest-tag-len, approaching zero, so the values fit. Of course we want high popularity first, so this is a reverse sort, so we're actually favoring longer tags, based on them likely having more inherent detail.) This is what we call "excessively clever" - given a stable sort, we could just sort the list twice:
<div class="codehilite"><pre><code>tags = sorted(tag_popularity, key=len)
tags = sorted(tags, key=tag_popularity.__getitem__)
</code></pre></div>
and then <code>reverse</code> the whole thing. (Notice that sort-stability is the place where <code>sorted(reverse=True)</code> is different from <code>reversed(sorted())</code> - the former reverses the direction of the current key, but preserves the order of things that were equal; the later reverses everything.)
Future directions could include
<ul>
<li>saving 18 characters by shortening the reference (oh, I can save 11 of those just by using flickr's own shortcuts, done)</li>
<li>keeping track of all tags and using global popularity (to support expressing both "what this set is mostly about" and "what distinct cool things are in here" at the same time, chopping out the middle...) This may have to wait until I re-unify all of my photo data sets into one master gallery, though. (Cheap storage scaling may make that happen sooner than later, even if I do take over 20G/year of pictures now...)</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/ztwit/readme_1228904100.html</guid><pubDate>Wed, 10 Dec 2008 10:15:00 -0000</pubDate></item><item><title>blogthing: Wed Dec 10 00:02:00 2008</title><description>I've gone another year without significant change to the blogging
software; I did just add <a href="http://rpc.weblogs.com">http://rpc.weblogs.com</a> pinging to go along
with the year-old google-pinging support (embarassingly, the only
difference between the two is the noise they return on success, and I
just print that anyway; I was just reminded because it showed up on
<a href="http://scripting.com">http://scripting.com</a> recently.)
I have been putting a little time into using Sphinx to build one of my
documentation/ranting sites, though, because Sphinx sites actually
look pretty nice as-is, and maybe it's time to clean up the look
around here a bit (especially code display.) It looks like I'll be
able to use the existing parsers to do at least a rough draft
automatic conversion to RST, which is nice - though I'm seriously
considering WikiCreole as well, it looks like RST still wins on tools.
Footnotes:
<ul>
<li>google api <a href="http://www.google.com/help/blogsearch/pinging_API.html">http://www.google.com/help/blogsearch/pinging_API.html</a>
</li>
<li>verisign/weblogs.com api <a href="http://www.weblogs.com/api.html">http://www.weblogs.com/api.html</a>
</li>
<li>sphinx <a href="http://sphinx.pocoo.org/">http://sphinx.pocoo.org/</a>
</li>
<li>RST - reStructured Text - <a href="http://docutils.sourceforge.net/rst.html">http://docutils.sourceforge.net/rst.html</a>
</li>
<li>WikiCreole <a href="http://www.wikicreole.org/wiki/Creole1.0">http://www.wikicreole.org/wiki/Creole1.0</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/blogthing/readme_1228903320.html</guid><pubDate>Wed, 10 Dec 2008 10:02:00 -0000</pubDate></item><item><title>local_tasks: Wed Dec 3 02:03:00 2008</title><description>Need a local task manager, to handle work-paranoia about external data leaks. It should still have cheap external inputs, as long as reading it requires "internal" access.
Hiveminder of course provides a lot of inspiration; key differences are
<ul>
<li>should tie directly in to existing intranet systems (RT, viewsvn, moinmoin, news) via links</li>
<li>should be faster in the face of large numbers of items</li>
</ul>
Strictly speaking it doesn't need a web interface, though that'll make it easier to spread it to other people.
I considered just making it a roundup instance, but I'm not sure that actually buys us anything - <code>local_task</code> doesn't even need to be multi-user, so much of the infrastructure goes away; it probably doesn't need more than basic locking...
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/local_tasks/readme_1228305780.html</guid><pubDate>Wed, 03 Dec 2008 12:03:00 -0000</pubDate></item><item><title>thokalbum: Sun Sep 14 23:46:00 2008</title><description>Realized when half-awake this morning that the album-search cache was wrong at an entirely different level - reloading the album needs to invalidate all prior searches, where instead the code was just reloading the one that was in progress when we noticed the base album was stale. This is also the first hint that, at 900 lines of code, I already need bugtracking; given my offline working mode, I should probably look at SD - having a bug list that can be checked in with the code makes a lot of sense, especially if it still supports real management tools and isn't just a free form list.
Pushed the change out as 0.2a after testing. (Still needs to be made "pure functional with caching" to eliminate some other rarely-seen problems. Also need to think about adding this album to nagaina monitoring...)
Footnotes: 
<ul>
<li>sd syncable bug tracking <a href="http://syncwith.us/sd/using">http://syncwith.us/sd/using</a>
</li>
<li>nagaina <a href="http://www.thok.org/intranet/python/nagaina/index.html">http://www.thok.org/intranet/python/nagaina/index.html</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/thokalbum/readme_1221468360.html</guid><pubDate>Mon, 15 Sep 2008 08:46:00 -0000</pubDate></item><item><title>vernier: Sat Mar 29 00:31:00 2008</title><description>Thanks to Federico Grau (for going back and forth with Vernier) for
finding a calibration mechanism, but also for noting that Greg Kroah
Hartman's tutorial and example code (in particular, the user-space
<code>get_temp</code> wrapper) actually multiplies by the cryptic-looking
value 0.0078125 to get Celsius values.
Thanks also to <code>johnl</code> for pointing out that his device was
calibrated in units of 128ths of a degree, instead of 100ths; when he
pointed that out, I went back and looked at the cryptic-looking
number, and realized that my "computational numerology" skills had
failed me - 0.0078125 is 1/128 (my original 1/100 was an entirely
unjustified guess.)
(Also, thanks to Dave Vernier for his feedback, which hasn't yet been
incorporated into the code - that's right, Vernier isn't just a clever
name for a measurement company, it's an actual person :-)
Footnotes:
<ul>
<li>"Stainless Steel Temperature Probe (Order Code TMP-BTA)" <a href="http://www2.vernier.com/booklets/tmp-bta.pdf">http://www2.vernier.com/booklets/tmp-bta.pdf</a>
</li>
<li>Greg Kroah-Hartman's driver tutorial <a href="http://tree.celinuxforum.org/CelfPubWiki/ELC2006Presentations?action=AttachFile&amp;do=get&amp;target=celf_2006_tutorial.pdf">http://tree.celinuxforum.org/CelfPubWiki/ELC2006Presentations?action=AttachFile&amp;do=get&amp;target=celf_2006_tutorial.pdf</a>
</li>
<li>ldusb reader with the (now-obvious) correction <a href="gotemp-ldusb.py">gotemp-ldusb.py</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/vernier/readme_1206783060.html</guid><pubDate>Sat, 29 Mar 2008 09:31:00 -0000</pubDate></item><item><title>pyfox: Wed Mar 26 22:46:00 2008</title><description>Footnotes:
<ul>
<li>
<a href="http://developer.mozilla.org/en/docs/Creating_a_Python_XPCOM_component">http://developer.mozilla.org/en/docs/Creating_a_Python_XPCOM_component</a><ul>
<li>assumes you've read <a href="http://books.mozdev.org/html/mozilla-chp-8-sect-2.html">http://books.mozdev.org/html/mozilla-chp-8-sect-2.html</a>
</li>
</ul>
</li>
<li>all of the book reviews point to <a href="http://www.xulplanet.com/">http://www.xulplanet.com/</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/pyfox/readme_1206603960.html</guid><pubDate>Thu, 27 Mar 2008 07:46:00 -0000</pubDate></item><item><title>usgs: Thu Mar 20 00:33:00 2008</title><description>As part of the <code>libremap</code> project, the entire 24k scale USGS quads were
acquired and made available on <code>archive.org</code> (by gathering donations for
a complete set of media.)
The top level "collection page" (<code>maps_usgs</code>) has links to individual
states (like <code>usgs_ma</code>.) These then have "this just in" links (like
<code>usgs_drg_ma_41070_e8</code>) which are detail pages, with text metadata, xml
metadata, <code>tfw</code> files (georeferences) and the actual tif files.
<ul>
<li>the project <a href="http://libremap.org/">http://libremap.org/</a>
</li>
<li>the published collection page <a href="http://www.archive.org/details/maps_usgs">http://www.archive.org/details/maps_usgs</a>
</li>
<li>MA <a href="http://www.archive.org/details/usgs_ma">http://www.archive.org/details/usgs_ma</a>
</li>
<li>selected MA map <a href="http://www.archive.org/details/usgs_drg_ma_41070_e8">http://www.archive.org/details/usgs_drg_ma_41070_e8</a>
</li>
</ul>
It may be more useful to use a collection search, and walk the "next"
links, once we have the list of collection names.
<ul>
<li><a href="http://www.archive.org/search.php?query=collection%3A%22usgs_ma%22">http://www.archive.org/search.php?query=collection%3A%22usgs_ma%22</a></li>
<li><a href="http://www.archive.org/search.php?query=collection%3A%22maps_usgs%22">http://www.archive.org/search.php?query=collection%3A%22maps_usgs%22</a></li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/usgs/readme_1206005580.html</guid><pubDate>Thu, 20 Mar 2008 09:33:00 -0000</pubDate></item><item><title>toys: Tue Feb 26 01:20:00 2008</title><description><a href="t9.py">t9.py</a> is an exploration of words with ambiguous T9 (phone
text interface) encodings. The interesting bit is the scaling
issue... or lack of one: it handled a 230K wordlist, producing 10k
result sets, in about 30 seconds... on an EEEpc. Completely naive
implementation, no optimization (and thus no wasted optimization :-)
I did use <code>string.maketrans</code> and <code>string.translate</code> but that
was more because I'd used them before and they're actually a pretty
natural fit for this task. (I did switch from lists to sets, but that
wasn't performance-related either - the wordlist I was working from
had a variety of entries that weren't unique when downcased, and it
didn't occur to me to just use <code>sort -fu</code> on it.)
Footnotes:
<ul>
<li>T9 appears to be a trademark of Nuance Communications, Inc. <a href="http://www.t9.com">http://www.t9.com</a>
</li>
<li>The specific EEEpc tested is a 900mhz celeron M with 1G of useful RAM.</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/toys/readme_1204024800.html</guid><pubDate>Tue, 26 Feb 2008 11:20:00 -0000</pubDate></item><item><title>hm: Sun Feb 24 20:46:00 2008</title><description>Minor fixes to <a href="todo.py">todo.py</a> today;
<ul>
<li>broken return-value handling in <code>but_first</code>
</li>
<li>
<code>list</code> didn't report errors (<code>todo.pl</code> has the same bug, patch sent upstream)</li>
<li>improved <code>sid</code>-cookie handling</li>
</ul>
(I'm using defer-until-task enough that I should make it an actual subcommand :-)
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/hm/readme_1203921960.html</guid><pubDate>Mon, 25 Feb 2008 06:46:00 -0000</pubDate></item><item><title>calendar: Tue Jan 29 02:36:00 2008</title><description><code>gcalcli.py</code> might be a better answer to all of this. See also <code>stfl</code>.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/calendar/readme_1201610160.html</guid><pubDate>Tue, 29 Jan 2008 12:36:00 -0000</pubDate></item><item><title>xscreensaver: Mon Jan 21 00:40:00 2008</title><description>New project space for xscreensaver modules in python. The most recent
experiments have been in the area of vector text;
<a href="xss_vector_text.py">xss_vector_text.py</a> isn't much to look at, and fairly retro,
but it has a compact notation for pseudo-multi-segment characters and
can draw a randomly selected word across the top of the screen. Not
exciting, just another piece (and I may replace it with real text with
fonts later.)
One interesting note: the version of python-xlib I have has a typo, a
call to <code>PolSegment</code> instead of <code>PolySegment</code>. Fixed on
sourceforge... back in 2003 :-) but the one in Debian didn't get
updated until April 2007 (post-etch.) If you have 0.12-5.1, read the
comments in <a href="xss_vector_text.py">xss_vector_text.py</a> for details, or just make the
obvious change.
Footnotes:
<ul>
<li>debian update to <code>python-xlib</code> <a href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421594">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421594</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/xscreensaver/readme_1200912000.html</guid><pubDate>Mon, 21 Jan 2008 10:40:00 -0000</pubDate></item><item><title>Mon Jan 14 22:47:00 2008</title><description>
The README-blog has enough content that it is starting to pick up
traffic about random topics, even with only email and zephyr
backchannels. femtocomment got sidetracked into being an OpenID
playground, which made sense a year ago, but looking at
<a href="http://openid.net/">http://openid.net/</a> today, it's a lot more real, and I should start
focusing on the comment side of the story again.
(I'll probably start with something that works off of a simple
hand-set cookie just to get it off the ground, but that's not
inconsistent with having an OpenID interface, it's just a shortcut
path.)
<h3>Inputs:</h3>
<ul><li> the comment itself</li><li> the authentication metadata</li><li> the context of the comment</li><ul><li> replying to what posting</li><li> (later) replying to what comment</li><li> when</li></ul></ul>

<h3>Outputs:</h3>
<ul><li> rendering of comments (threads) on each topic page</li><li> global comment-review page</li><ul><li> site-wide, for the administrator (me)</li><li> comment deletion</li><li> cookie revocation / (later) id blocking</li></ul><li> (later) RSS feeds for comment threads you're in</li><li> (later) email for comments</li></ul>

<h3>Constraints:</h3>
<ul><li> Can't be generated offline the way the blog is</li><ul><li> README-blog can insert a "talk to the service" bit, though</li><li> maybe README-blog can pull static copies of threads, so the service bit is only the freshest stuff?</li></ul></ul>

This is probably enough to start slinging bits around and see what it
looks like :-)
<h3>Footnotes:</h3>
<ul><li> OpenID DevCamp <a href="http://barcamp.org/OpenIDDevCamp">http://barcamp.org/OpenIDDevCamp</a></li><li> OpenID standards <a href="http://openid.net">http://openid.net</a></li></ul></description><guid isPermaLink="true">http://www.thok.org/intranet/python/blogthing/femtocomment/README.html#Mon_Jan_14_22:47:00_2008</guid><pubDate>Tue, 15 Jan 2008 03:47:00 GMT</pubDate></item><item><title>meterstone: Mon Dec 3 03:16:00 2007</title><description>Codemonth is over, and while I didn't get as much done as I'd hoped, I
did make some real progress... and while stuffing more software into
the EEEpc and configuring it has been a major distraction, it just now
gave something back - turns out that there is a useful outline
editor in debian after all, called <code>treeline</code> (found during a
mis-aimed <code>apt-cache search</code> for "python doc".) It's an outline
editor that can make a fair guess at arbitrary XML files; it loaded
meterstone's one sample file immediately - and was able to "export" it
back (as "Generic" XML) to a file that meterstone could read
(treeline's save format is somewhat different, though.)
A related search also turned up <code>tcm</code>, the "Toolkit for Conceptual
Modeling", which looks like it's trying to cover what would be the
overall task breakdown part problem in more detail, without actually
looking at estimation at all. It's also a very retro-looking
<code>lesstif</code> app, which apparently hasn't been touched since 2003, so
I'm not sure it will actually help, but it seemed worth noting.
Footnotes:
<ul>
<li>codemonth <a href="http://www.codemonth.org/">http://www.codemonth.org/</a>
</li>
<li>treeline <a href="http://www.bellz.org/treeline/">http://www.bellz.org/treeline/</a>
</li>
<li>tcm <a href="http://wwwhome.cs.utwente.nl/~tcm/">http://wwwhome.cs.utwente.nl/~tcm/</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/meterstone/readme_1196687760.html</guid><pubDate>Mon, 03 Dec 2007 13:16:00 -0000</pubDate></item><item><title>krbvert: Sat Nov 3 23:55:00 2007</title><description>I gave in and built my own <code>SLAB</code> kernel and modules; I'm not too
happy with the result (suspend works but I've had some lockups that
I'm blaming the video driver for for now) but I'm going to move
forward with it anyway.
Had a near miss with noticing that Gutsy's <code>ssh</code> supports setting
<code>GSSAPITrustDns=no</code> but the documentation points out that this
just means passing the value to GSSAPI... which then goes back out
to DNS to (mis)canonicalize it anyway, which misses the point, and
lets me get back to work on this project :-)
A bunch of grinding, and discovering the need to copy the <code>struct
addrinfo</code> and the contained <code>ai_addr</code> in the cache, and I've got a
successful, if crude, tool...
Given <code>strdup</code> I'm sort of surprised not to find a corresponding
<code>memdup</code>, so I put one in. (The code would be more readable with
a gnu-style <code>xstrdup</code> and <code>xmemdup</code> so maybe I'll add those
later; for now the debugging code still gets in the way...)
Current state: grabs the IPv4 address that the first <code>getaddrinfo</code>
call returns, as it goes by, and saves it; when <code>getnameinfo</code> is
called with that address, stuff the originally-supplied name in the
result, over the result that actually came back.
Future enhancements:
<ul>
<li>build a map from all <code>getaddrinfo</code> calls</li>
<li>handle IPv4 and IPv6 addresses</li>
<li>for that matter, handle all addresses that come back</li>
<li>package it for Debian</li>
<li>package it for FreeBSD (whatever that means)</li>
<li>investigate <code>getnameinfo</code> flags more carefully</li>
<li>don't assume that <code>getnameinfo</code> gets any valid answer - if we get a match, return it directly without even calling the upstream function</li>
</ul>
However, those can wait until I get some feedback - it now
accomplishes the primary goal, which was to let me drop my
hack-and-slash patches to ssh and just maintain a separate module.
Think of it as "Aspect Oriented Programming... in C" :-)
<ul>
<li>Aspect Oriented Programming <a href="http://aosd.net/">http://aosd.net/</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/krbvert/readme_1194166500.html</guid><pubDate>Sun, 04 Nov 2007 08:55:00 -0000</pubDate></item><item><title>firefox: Tue Jul 24 01:50:00 2007</title><description>I did try the search-through-HTML approach to strip the Conkeror
link-numbers (since I have the cut&amp;paste selection with contamination,
and the raw HTML of the page, I can search for one to find the other.)
My results were fuzzier than I liked, and refining the effort didn't
really hold my attention.
I found something simpler:
<div class="codehilite"><pre><code>function strip_numbers_hard()
{
 removeExisting(document.commandDispatcher.focusedWindow.document);
}
</code></pre></div>
If I run that before the cut&amp;paste, I lose the numbered-links
entirely, and the existing code should just work...
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/firefox/readme_1185274200.html</guid><pubDate>Tue, 24 Jul 2007 10:50:00 -0000</pubDate></item><item><title>globe: Sun Jul 1 16:06:00 2007</title><description>More experimentation in the past week leads me to believe that
<code>GL_POLYGON</code> and <code>GL_QUAD_STRIP</code> and the like do triangular
decomposition... and get it wrong, somehow, because only some parts
of various polygons go away with <code>GL_CULL_FACE</code> but some obvious
triangles remain that clearly shouldn't. This seems to be consistent
with accelerated and non-accelerated OpenGL in the server (discovered
the latter when rolling back from a 2.6.22 kernel to 2.6.20, and
forgetting to roll back the <code>xorg-driver-fglrx</code> package.) I'll
have to try newer libraries.
The approach I'm taking for the moment is to simply draw a unit radius
blue sphere, and then draw the continents over it; using
<code>GL_CULL_FACE</code> to cull polygons with backwards winding was
supposed to make this do the right thing.
An alternate approach is suggested by some of the "NeHe" tutorial/demo
programs - create a texture out of the polygons, and then map it on to
the sphere. This should make the rotation and other navigation
stunningly fast, but departs rather a lot from the original program's
concept...
Footnotes:
<ul>
<li>NeHe tutorials <a href="http://nehe.gamedev.net">http://nehe.gamedev.net</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/globe/readme_1183316760.html</guid><pubDate>Sun, 01 Jul 2007 19:06:00 -0000</pubDate></item><item><title>contacts: Thu Jun 21 22:04:00 2007</title><description>Found a better vcard parser, in <code>pycocumalib/vcard.py</code> - PyCoCuMa
(Pythonic Contact and Customer Management) is a somewhat dated-looking
(Tk and XML-RPC based) pure-vcf contact manager. Produced a simple
<code>vcard_to_pma.py</code> script that does a "good" match... fills in a
<code>&lt;Contact&gt;</code> with the obvious mapping from vcard fields. Not
attempting to sync, this is a one-way translation, and doesn't yet
flag data that gets lost; AddressBook has a fair number of fields that
aren't reflected in RFC 2426, like <code>Profession</code>, <code>Spouse</code>, and
<code>Pronunciation</code> fields; likewise vcard has <code>TZ</code>, <code>GEO</code>, <code>LOGO</code>, and <code>X-*</code>
extension fields that aren't mapped. The next version of this should
probably report any "leftover" data that doesn't get sent over, but I
think this is a good start.
Footnotes:
<ul>
<li>PyCoCuMa upstream <a href="http://www.srcco.de/pycocuma/index.html">http://www.srcco.de/pycocuma/index.html</a> 0.4.5-6 (2005-09-13 23:25 CET) is the latest upstream</li>
<li>
<a href="vcard_to_pma.py">vcard_to_pma.py</a> </li>
<li>RFC 2426 <a href="http://www.ietf.org/rfc/rfc2426.txt">http://www.ietf.org/rfc/rfc2426.txt</a>
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/contacts/readme_1182474240.html</guid><pubDate>Fri, 22 Jun 2007 01:04:00 -0000</pubDate></item><item><title>distributed-photography: Thu Apr 26 21:11:00 2007</title><description>So many people have digital cameras, pretty much everywhere... but
there's no infrastructure to harness that. Flickr Maps
<a href="http://www.flickr.com/map/">http://www.flickr.com/map/</a> can be used to find pictures in many
places, but only those that have already been taken and geolocated
(often manually.) (Flickr claims 15 million geolocated pictures, out
of around 450 million.)
That gives us a standard set of Web 2.0 ingredients:
<ul>
<li>geography/locality</li>
<li>social/community</li>
<li>photos</li>
<li>realtime</li>
<li>subvert mainstream media</li>
<li>user developed content</li>
<li>mashup</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/distributed-photography/readme_1177654260.html</guid><pubDate>Fri, 27 Apr 2007 06:11:00 -0000</pubDate></item><item><title>distractme: Sun Apr 15 13:01:00 2007</title><description>I did a little more hacking here - a simple python script to figure
out what's the top window and log it, using <code>subprocess.Popen</code> to
call <code>xwininfo</code> and <code>xprop</code>.
This turned up some interesting tidbits:
<ul>
<li>
<code>xterm</code> already has <code>WM_NAME</code> set via an old <code>$PS1</code> setting</li>
<li>
<code>emacs</code> only puts the buffer in the title for multiple frames; <code>(setq frame-title-format "%b")</code> fixes this.</li>
<li>
<code>firefox</code> (using the <code>conkeror</code> extension) puts the "buffer" (page/tab) name in the title; it turned out to be easy to change this to the URL with a scattering of <code>document.title = document.commandDispatcher.focusedWindow.location.href;</code> statements.</li>
</ul>
Since I was having some reliability issues with figuring out the "top
window", I tried using <code>ratpoison -c 'windows %s%i'</code> but something
about running that 3 times/second (or possibly about using c-c to
interrupt it) crashed ratpoison (1.4.0-beta4 ubuntu) which I'll try
and diagnose later.
In the meantime, a discussion about some of my old perl code (the fact
that I still set my X desktop with code that uses my pure-perl Xlib
implementation,
<a href="http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0010.html">http://www.foo.be/docs/tpj/issues/vol2_1/tpj0201-0010.html</a> was pointed
out as one of the last chunks of perl in my life, since my
"conversion" to python) inspired me to look at <code>python-xlib</code> again.
Turns out that <code>python-xlib</code> has a nicely rich interface (windows
as objects with methods, rather than a thin mapping to the C bindings,
while still being appropriately close to the wire.) <code>python-xlib</code>
gave me a number of advantages:
<ul>
<li>X errors (due to the transient nature of these particular windows) turn into <code>Xlib.error.BadWindow</code> exceptions, which I can handle cleanly</li>
<li>it takes less code to ask for the particular property via <code>topwin.get_wm_name()</code> than to parse them out of <code>xprop</code> output</li>
<li>once I lost the extra baggage of parsing code, it was easier to see simpler ways to look at the overall structure</li>
<li>using the interactive python interpreter to poke at window state directly made it much easier to decide that <code>child.get_attributes().override_redirect</code> was worth checking (turns out that were override-redirect windows which were higher on the list, but still not the "real" top window.)</li>
</ul>
The current version <a href="on_top.py">on_top.py</a> still has a little debugging
info, and only covers the logging and data-gathering parts of the
effort. It doesn't cover actually mapping this information to what
project I'm actually working on; I want to start out by collecting
evidence, and after a few days of that will come back and figure out
how to analyze it.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/distractme/readme_1176674460.html</guid><pubDate>Sun, 15 Apr 2007 22:01:00 -0000</pubDate></item><item><title>Thu Feb 22 21:28:00 2007</title><description>
Another random item.
<tt>*</tt> should be just a star...</description><guid isPermaLink="true">http://www.thok.org/intranet/python/blogthing/testing/_TEST_INPUT.html#Thu_Feb_22_21:28:00_2007</guid><pubDate>Fri, 23 Feb 2007 02:28:00 GMT</pubDate></item><item><title>nagaina: Fri Feb 9 02:19:00 2007</title><description>Still running multihomed, clearly need to do at least some tests in a
channel-specific manner. The easy thing to start with is <code>probe_ping</code>,
since it has a <code>-S</code> option for source address, which should do the right
thing when combined with our iprules. However, since this is testing
the interface, not the remote resource, it isn't an option to
<code>probe_ping</code>, but a new <code>probe_interface</code> or something like that.
Later versions should probably do similar tests with TCP.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/nagaina/notes_1171023540.html</guid><pubDate>Fri, 09 Feb 2007 12:19:00 -0000</pubDate></item><item><title>bluetooth: Sun Dec 17 19:23:00 2006</title><description>Inspired by <a href="http://www.librarything.com/">http://www.librarything.com/</a> I dug out the Flic Cordless
bluetooth scanner again. I have notes from a coworker who borrowed it
and figured out how to talk to it; there's a registration-required SDK
that I will probably grab if I have any trouble (I thought I had a
copy already, but I haven't found it.)
<div class="codehilite"><pre><code>sudo rfcomm connect hci0 "00:A0:96:04:D2:B2" 1 &amp;
screen /dev/rfcomm0
it sends:
79013400800202FD
sent 02fd^f
09736154967502FE
send 02fe^f
got 3-tone downwards sequence (for "done"...)
W&lt;RET&gt;
Microvision® Flic® Barcode Scanner, ID: 4117271B, FW: 2.8.0, BT: 1.20M
W0000000000000000590000004117271BFFFF020800
T1&lt;RET&gt; just beeps
T9&lt;RET&gt; low-beeps
</code></pre></div>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/bluetooth/readme_1166419380.html</guid><pubDate>Mon, 18 Dec 2006 05:23:00 -0000</pubDate></item><item><title>bookstuff: Thu Dec 14 01:06:00 2006</title><description>Tried uploading Delicious Library's xml file directly to library
thing. Seems like it was a little too aggressive in that I got 900+
books, many of which I clearly don't own; I think it doesn't know
about the recommendations field. But that's what <code>cElementTree</code> is for...
Ah, much better: "LibraryThing found 161 unique ISBNs. 138 of them are
new (not already in your library)." (I entered a small pile of books
by looking around the room, and then clicking through suggestions and
authors and going "oh, I have that one" :-)
<a href="delicious_asin.py">delicious_asin.py</a> is the (entirely trivial) extractor.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/bookstuff/readme_1166094360.html</guid><pubDate>Thu, 14 Dec 2006 11:06:00 -0000</pubDate></item><item><title>todont: Wed Nov 22 01:41:00 2006</title><description>Requirements, probably conflicting:
<ul>
<li>fast UI<ul>
<li>ie. faster than the hiveminder web ui; probably faster than any web UI, start with curses and emacs</li>
</ul>
</li>
<li>widely accessible UI<ul>
<li>for me that means it needs a palm app</li>
<li>and probably a web app even if it is slow</li>
</ul>
</li>
<li>rich UI<ul>
<li>while "review" and "only current doable" are useful pages, I clearly also need</li>
<li>show everything</li>
<li>show tree of dependencies (somehow, but especially in the form "what can I do to unsnarl the most")</li>
<li>What should I do next is quite reasonably based more on what it unlocks, not just what I can see</li>
<li>effort vs. payoff</li>
</ul>
</li>
<li>dependencies<ul>
<li>and-then/but-first are a good simplification</li>
<li>at the same time, it needs to be easy to find existing tasks to attach</li>
<li>"any of" or "choose among" is another path</li>
</ul>
</li>
<li>time/size recognition<ul>
<li>sometimes I really am looking for "what's a 1/2 hour task I can do now"</li>
<li>making estimates and recording the results later is good training</li>
<li>picking highest payoff tasks is sometimes the right strategy</li>
</ul>
</li>
</ul>
That's certainly enough; it may be too much to do up front, but it's a
description of the show-off point at least.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/todont/readme_1164195660.html</guid><pubDate>Wed, 22 Nov 2006 11:41:00 -0000</pubDate></item><item><title>zephyr: Thu Nov 16 03:07:00 2006</title><description>After ignoring the zephyr code for a while (the logger has Just Worked
for rather a while, barring network outages, and it restarts well
enough after those) I took another look at <code>ctypes</code>. One key difference
is that pyrex imports the abstract (as much as C ever is) structure
definitions... so you can define fields by name based on what's
visible and part of the API... because under the covers it is
compiling against the header files; with <code>ctypes</code>, you have to duplicate
the physical C structure, because it isn't compiling at all, just
building up the same thing in memory.
Given that, it still only took 95 lines of code to cook up the notice
type, initialize one, and send it (unauthenticated). I still need to
wrap it up in a more useful interface, but this convinces me that it
works for a library like this... next step is authentication, and then
maybe gssapi...
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/zephyr/readme_1163682420.html</guid><pubDate>Thu, 16 Nov 2006 13:07:00 -0000</pubDate></item><item><title>openafs: Wed Nov 1 01:53:00 2006</title><description>Wrapup:
These were an interesting exercise - but it turned out that my
appetite for disk space was, after all, satiable; all of the volumes
have been moved to a single Dell PE830 with mirrored 500G SATA drives.
At this time the database servers still need moving, but the clever
volume management issue no longer matters at this scale.
(The desktop minitowers are trailing-edge enough that it may be
harmful to donate them; the martian box is now a wireless print server
running Ubuntu Edgy Eft, and the HushPC is now a dvd-only MythTV
box... so both still have life due to their specialized nature, namely
"quiet enough (and small enough) to share space with humans in a
civilized manner".)
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/openafs/readme_1162381980.html</guid><pubDate>Wed, 01 Nov 2006 11:53:00 -0000</pubDate></item><item><title>backup: Tue Oct 17 16:27:00 2006</title><description>Hmm. The commandline (exclusion) args should probably get stashed in
<code>.backup_metadata</code>. For now put them here:
<div class="codehilite"><pre><code>time ./splitbackups.py --path /home/eichin --prep --exclude tmp --exclude metacarta --exclude acid --exclude bigdig --exclude .svk --exclude PIX --exclude .kde/share/apps/akregator/Archive --exclude .mozilla/firefox/x2mkyrlv.default/Cache --exclude .snownews/cache
</code></pre></div>
<code>akgregator</code> and <code>snownews</code> are excluded because of Joliet issues.
<code>firefox</code> is excluded because it's running and expiring live.
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/backup/readme_1161134820.html</guid><pubDate>Wed, 18 Oct 2006 01:27:00 -0000</pubDate></item><item><title>vnc: Thu Oct 12 04:39:00 2006</title><description>While looking for a Mac OS X VNC Server (to remote-sysadmin a Eudora
problem that seemed impervious to ssh) I stumbled across "eggplant
purple", a visually oriented, rather polished, GUI test harness based
on VNC (so, while a Mac product, it can test pretty much anything.)
The primary takeaway from the video demo was that GUI testing could be
broken down into two simple abstractions:
<ul>
<li>find things to push</li>
<li>script how to push them</li>
</ul>
They had a nice script-building GUI for this; basically a pass-through
overlay on a VNC client where you could simply run the app under test
(or even start with a blank desktop and find it), making you break
down "just click on that icon" into "trace the icon, optionally adjust
the hotspot, click" which then became a saved TIFF off the icon, and a
line of script "click name-of-tiff".
This made simple things look simple, and you could also see how to do
more complex stuff from there. An interesting bit that took a while
to sink in was that failures automatically saved a screen shot of the
last thing attempted - so it could be used to set up scripted
screenshot generation simply as a side effect of tests with impossible
end conditions. 
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/vnc/readme_1160660340.html</guid><pubDate>Thu, 12 Oct 2006 13:39:00 -0000</pubDate></item><item><title>boston-massacre: Mon Jan 9 17:37:00 2006</title><description>A friend suggested a scheme that he uses to more effectively identify
and contain spam sourced mail; some searching/riffing on his name lead
me to
<a href="http://www.law.umkc.edu/faculty/projects/ftrials/bostonmassacre/keyfigures.html">http://www.law.umkc.edu/faculty/projects/ftrials/bostonmassacre/keyfigures.html</a>
and thus the name of this project.
Basic concept: mechanically generate reply addresses. When spam
starts arriving by one, drop it.
Uses:
<ul>
<li>
personal mail: people mostly reply anyway, so that works; or they can
add one particular one to their address book, and as long as they
don't end up getting leaked, they keep working.
</li>
<li>
list mail: doesn't work for mailman, membership-post-only addresses,
without some further kludging. Perhaps always post from a bucket
address or a list-specific address in those cases.
</li>
<li>
strangers: they come in via a generic address, and maybe don't get
in.
</li>
<li>
existing correspondants: hunt them down and get them to update.
</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/boston-massacre/readme_1136864220.html</guid><pubDate>Tue, 10 Jan 2006 03:37:00 -0000</pubDate></item><item><title>sheetwork: Thu Dec 29 00:29:00 2005</title><description><dl>
<dt>sheetwork</dt>
<dd>A term used in edition binding for the binding operations
of folding, tipping, gathering, endsheeting, sewing, and smashing.
-- <a href="http://palimpsest.stanford.edu/don/dt/dt3078.html">http://palimpsest.stanford.edu/don/dt/dt3078.html</a>
</dd>
</dl>
sheetwork is a tool for producing web pages. Not an entire blog, but
a single page article, possibly for inclusion in an outer framework
which is a blog or album structure. A page, an article, a journal
day.... Not, perhaps, a good match for the term.
<ul>
<li>needs to work well with emacs</li>
<li>
<code>bzero</code> provides some possible inspirations...</li>
<li>an external tool for adding notation for objects, like images</li>
<li>commandline cooking tools (like tex, too)</li>
<li>scribe's <code>@documentstyle</code> was a good idea</li>
<li>nroff's command notation isn't bad for commands, but is bad for flow
in text</li>
<li>we've already got lots of wiki stuff, why not use it?</li>
<li>"kid" is cool, if we end up with anything template-like</li>
<li>rfc822 isn't bad as a low-end representation, at least for leading
metadata, but doesn't handle body stuff</li>
<li>must end up with an emacs mode, but not be doomed without it</li>
</ul>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/sheetwork/readme_1135852140.html</guid><pubDate>Thu, 29 Dec 2005 10:29:00 -0000</pubDate></item><item><title>deli: Mon Dec 12 00:41:00 2005</title><description><a href="http://delicious-py.berlios.de/">http://delicious-py.berlios.de/</a>
needs a new maintainer... but might be a better thing to leverage
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/deli/readme_1134384060.html</guid><pubDate>Mon, 12 Dec 2005 10:41:00 -0000</pubDate></item><item><title>rss: Sun Nov 27 01:02:00 2005</title><description>I need a better reader than snownews, more text-oriented (and
linux-friendly) than nnw. (Though images in messages were nice; it
might suffice to use w3m as a renderer and hack w3m img...)
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/rss/readme_1133089320.html</guid><pubDate>Sun, 27 Nov 2005 11:02:00 -0000</pubDate></item><item><title>comics: Sun Nov 27 00:16:00 2005</title><description>Most recently, switched to conkeror+firefox, and now hit c-c c-n in
the web browser to get the next comic. The same queue is fed by a
one-liner in <code>~/.snownews/browser</code>:
<div class="codehilite"><pre><code>curl -Hurl:\ %s -d "" &lt;http://localhost:3383/push_url&gt;
</code></pre></div>
so urls from that are queued up the same way (see ../firefox.)
Still should do some kind of auto-training; the simplest algorithm is
to fetch the whole page, then fetch it small-T (an hour? 5m?) later,
and see what changed, and ignore it. Keep a record (vector?) of the
whittling, and use that instead of <code>check_maybe</code>. Possibly pick a
threshold of change and display it to me - and let me vote on same
vs. different...
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/comics/readme_1133086560.html</guid><pubDate>Sun, 27 Nov 2005 10:16:00 -0000</pubDate></item><item><title>todo-prodder: Wed Nov 3 03:08:00 2004</title><description>higher level stuff
<div class="codehilite"><pre><code>- produce list of whole-items, with date + subitems
- filter out [done]s or at least identify them
</code></pre></div>
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/todo-prodder/readme_1099487280.html</guid><pubDate>Wed, 03 Nov 2004 13:08:00 -0000</pubDate></item><item><title>topicmaster: Sat Sep 11 03:03:00 2004</title><description>Another one - "virtual topic" of "all stufflogs mentioning chocolate
or cocoa in the clip itself"
Then a metaproject of "chocolate printing"
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/topicmaster/readme_1094904180.html</guid><pubDate>Sat, 11 Sep 2004 12:03:00 -0000</pubDate></item><item><title>filthy-assistant: Wed Jun 30 00:00:00 2004</title><description>I need to get back to the collection-of-interest-topics model, so that
short lived things like "getting passport" get pulled in, bigger
things like "accepted advertiser mail" do too...
</description><guid isPermaLink="true">http://www.thok.org/intranet/python/filthy-assistant/readme_1088589600.html</guid><pubDate>Wed, 30 Jun 2004 10:00:00 -0000</pubDate></item></channel></rss>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//www.thok.org/intranet/python/aggregation.rss"><img src="valid-rss-rogers.png" alt="[Valid RSS]" title="Validate my RSS feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//www.thok.org/intranet/python/aggregation.rss

Home · About · News · Docs · Terms