partiallydisassembled.net

Summary of grievances

2007-07-08 18:08:39

The last three days have been non-stop trouble for me and computing. Rather than throw the whole lot out the window (it is, after all, hard garbage week), I'll just whinge about everything in one big go here. **Grievance number 1: Gentoo** So it's my fault for using Gentoo and not falling into line with Ubuntu like the rest of you drones, but still. There's some systemic fault in my portage tree now so that any time a package is upgraded, the symlink from */usr/lib* to */usr/lib64* is lost, and all permissions on /usr/lib64 are lost. I figured this one out only moments before Ubuntising myself a few weeks ago, but the other day it manifested itself in a new way. Toby and I puzzled over why no 32-bit apps would start up... the only error message would be "command not found", and ldd wouldn't recognise them as executables. I finally figured out that the symlink from */lib/ld-linux.so.2* to */lib32/ld-linux.so.2* had been removed (again, by some package upgrade). On the plus side, I did learn lots about how executables are started up. [For example, the */lib/ld-linux.so.2* path is hardcoded into every 32 bit application. The 64 bit apps on this computer are hardcoded to look at */lib64/ld-linux-x86-64.so.2*. **Grievance number 2: setuptools** Richard found the time to address some long-standing pyglet issues on Mac OS X (issue #8 was submitted last year!). When I tried out his changes, there was no effect, and I immediately thought, "Ho ho, silly Richard, these fixes do nothing!". I then spent the next several hours trying to fix them myself, to no avail. It was *almost* as if none of my changes were being applied. Ridiculous! I had triple checked sys.path, and had printed out pyglet._ _ file _ _ from an interactive prompt. Never trust the interactive prompt. Printing pyglet._ _ file _ _ from the unit test showed that it was using an installed release of pyglet from the site-packages directory. This is despite my having a "." in PYTHONPATH. After an appalling amount of time, I traced the problem to a single function within site.py. On entry to the function, sys.path was correct, but after returning it was borked, despite the function only ever *appending* to the path (my PYTHONPATH was ending up somewhere near the middle, after site-packages). Worst implementation of anything, ever. site.py calls "exec" on any line in a package.pth file (this is supposed to be a text file) that starts with "import". Worst abuse of a bad implementation of anything, ever. easy-install.pth uses that exec to insert malicious code into site.py, reordering sys.path so that its own packages are always listed first. This in itself would not have caused a problem, except that somehow the site-packages directory itself ended up in easy-install.pth, ensuring that anything in site-packages overrides my own PYTHONPATH. Damn you to hell, setuptools. You are the spawn of something greasy. I wish many painful deaths upon you. **Grievance number 3: Safari** pyglet.org is getting some fancy new features to show off project screenshots and snippets from the mailing list. To avoid having to change the HTML on the server (risky, especially with our quota problems), it uses some simple AJAX (yes, there's even some X) to do the rendering client-side. This was a breeze (I love XML-DOM in its many incarnations) and was working in Firefox in no time. I then spent 6 hours trying to get it working in Safari. The DOM was being updated correctly (Safari has a nifty DOM viewer like Firefox), the text was being added, but nothing was being styled, and images weren't appearing. As it turns out, (though I've yet to find any related experiences on the web), Safari has a special "act like a retard" mode when content is served as XHTML. Now, I know that XHTML is tricksy and technical and it's not what you think and etc etc. BUT. There were no errors. The DOM was being updated. The XHTML after being updated was correct. It was just that Safari wasn't updating its visual model. Changing the filename to .html (the DOCTYPE is still XHTML, as IE requires this, and it still has the <?xml... prologue, because I like it) fixed everything. **Grievance number 4: Internet Explorer** Yes, this one's predictable. Actually the changes required to the same code were fairly minor (you must set the element class with *.className*, not *setAttribute*, and tables require a tbody). Thankfully there's enough suckers out there also doing IE development that Googling my problems turned up the answers pretty quickly. **Grievance number 5: Gentoo again** So I booted back from Windows into Gentoo and my fonts look weird. Um, the boldface is **really** bold, and the subpixel antialiasing looks backwards (I can see the reds and blues). I turned off subpixel antialiasing, and can live with the bold fonts; but really, why does everything happen to me?!

pyglet-1.0alpha1

2007-06-27 23:37:00

First public release! New-look website! Hooray! http://www.pyglet.org/ Linky to the first proposal for pyglet, with Richard asking where he buys one.

Windows permissions woes

2007-06-23 13:14:14

pyglet is almost ready for dress rehearsal, just dry-cleaning its jacket and organising a hair dresser for the big event. I've been having some fun writing the Windows installer for pyglet. I'm using WIX to create the MSI from an XML description, which is filled in from a template by a Python script. The installer is smart enough to detect more than one version of Python installed, and asks the user which one to install pyglet in. Unfortunately, due to limitations in the MSI model there's no way to install pyglet in more than one Python directory (as Windows will note that it's already installed once). "Power" users who need to do this will need to install from source. The big mystery that had me stumped for hours yesterday and this morning was why the generated XML would fail with error 2755 ("System cannot read from the device"), whereas my hand-written mockup worked fine. Copying and pasting the working XML over the generated XML still didn't work. In fact, copying the working MSI into the directory where the non-working one was located caused the same error in the working file. As it turns out, the directory I had been generating the MSI in was missing some permissions. You can only see these permissions by disabling "simple file sharing" (though I am not using the network). According to the "Advanced Security Settings" for the directory, my user has Full Control (inherited from its parent). It turns out that "Everyone" needs Full Control over the directory in order to install the MSI from it. These bits are set (I believe) when creating a folder from Explorer, but not when using "os.makedirs" or cygwin's "mkdir". I will admit that I've never taken the time to read up on the Windows permissions model, as I've always managed to get what I want by clicking on buttons that are shaped right; still, this seems like wrong, unexplainable behaviour (until someone explains it to me).

Syntax 2007

2007-05-27 00:45:16

So, like, 100 years ago there were these neat graphics demos you could download that pushed the processors of the day to the max. The best ones were written by Future Crew, who always won first prize at Assembly -- the biggest demo scene around. You can still run the old demos with DosBox. The demo scene is still around, but plasma effects and alpha-blending demos don't really cut it -- it's all about showing off shaders and procedural geometry. Melbourne gets a local demo party now: Syntax 2007 is on my birthday this year. Everybody come, it's free! I've (sort of) assembled my crack team of coders and we have (something of) a plan to enter the 64kb competition. This will be my first time using DirectX (excepting a short DX5 stint 50 years ago). So far we have a full-screen rendered triangle, which comes in at around 2.2kb with only a few tricks to keep the amount of static linking to a minimum.

I hate updatedb

2007-04-28 13:58:43

But I love locate. What to do?