Summary of grievances
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
**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
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
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
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
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
**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?!
First public release! New-look website! Hooray! http://www.pyglet.org/
to the first proposal for pyglet, with Richard asking where he buys one.
Windows permissions woes
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).
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
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
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
But I love locate. What to do?