Older blog entries for ingvar (starting at number 298)

So, upgrades happened at home and, as occasionally happens, X stopped working. X stopping working varies from "trivial" to "annoyingly painful" to troubleshoot, especially as there was NOTHING in the xorg.N.log file to indicate what the issue was and it wedged the console to the point where "shutdown, reload" was the only way to get it back (thankfully, I could log on from another machine to do that).

In the end, it was a surprisingly simple fix, after "startx 2>&1 > trace-file" gave me the crucial bits of info. An expected symbol was not around in a dynamic linking stage and chasing that down gave a simple(ish) fix. All I had to do, in the end, was to uninstall the fglrx driver (something I installed in the first place to get working accelerated 3D primitives and direct rendering).

But, it did made me wonder, if the Xorg server can write to stderr, why can't it log the lack of a symbol to the og file? Maybe, I don't know, because that writing happens in a non-X library? I should probably have a poke at that, at some point.

As Pierre Mai so eloquently writes, the evaluation order corner case is explicitly covered as "it depends" by the Standard, so any code that depended on it is, well, relying on implementation-specific details.</a>

Intriguing. I have found an interesting corner case, where I believe the Common Lisp standard doesn't have an opinion. I don't think it's really any critical corner case, as I (right now) can't see any legitimate use of the difference, but...

Basically, in the case of the following:

(defun frob (x) (format t "Frob: ~a~%" x))
(frob (defun frob (x) (format t "New frob: ~a~%" x))

does the printed line say "Frob" or "New frob"?

It is, I believe, fully specified what will happen when you do either of (funcall #'frob ...) or (funcall 'frob ...), but out of the two implementations I have tried (SBCL and CLisp), I have two different behaviours. SBCL prints "New frob" and CLisp prints "Frob".

I shall have to ponder this, for a bit, I think.

Been a while since the last post. Work has been hectic, what with having to battle through the amendments to my pre- takeover contract into my new post-takeover contract. Mostly it seemed to be down to the legal department just not getting FOSS and once the whole "he's doing this for fun?" clicked, they didn't seem to have a problem anymore.

Two papers finished off, both declined to Conference #1, but now submitted for the consideration of Conference #2.

Two essays, on data structures and time complexity and electronic fora finished off.

OK, as an addendum to my previous post, I ended up screen- scraping what I needed, parsed the data I wanted out of it and generated SQL statements to (later) populate a database with. It would probably have been more elegant to connect to the database and insert the data directly, but a FORMAT call is quite convenient, as it were.

The screen-scraper was constructed by using DRAKMA to fetch the pages and then some substring functions to extract the data I needed. Estimated 30 minutes of coding lisp and testing, then a further "lots" of actual scraping.

But, my main musing for today is something I've noticed recently, in my Apache logs. It seems as if there's an active business in "referring page" spam. I haven't run the numbers, but from eyeballing the logs, I am seeing at least a couple of page fetches per day, where the "referring page" field is several URLs that trigger my wetware "this is spam" detection. I wonder what the reasoning behind it is? Maybe they're banking on sites publishing their stats publicly?

Border-line silly question. Is there an easily-navigated (or searchable) repository of vulnerability reports that can list things in a time-span? Last time, I ended up going through the BugTraq mailing list archive, but if someone has already collated specific vulnerabilities by "first reported date", it'd make things slightly easier for me.

Looks as if SecurityFocus have the raw data, but (alas) no obvious navigational features to let me do what I want.

Yes, it's that time, again. Snooper Annual Report! MUCH less than a year since last, but probably about a year before the next time it gets done. This time, it also spans exactly one calendar year and overlaps slightly with the tail end of the last report's interval.

Recently (as in the last couple of years, not as in the last few weeks), publicly available Common Lisp libraries have undergone not only an explosion in numbers, but a rather bizarre change in release model. More and more libraries are essentially only available as "check out the latest version from VersionControlSystemOfChoice".

Since I am a writer of assorted nonsense, I wrote a short piece on this, trying to articulate why I find this less than ideal and how it could, possibly, be turned from less-than- ideal to much better.

Personally, I try to release my own stuff in versioned tarballs, with an ASDF system definition having a matching version number. I suspect I should modify my release packager script to actually modify a list of stuff available, instead of having a couple of static pages I almost never edit (note: the packaging script makes some rather rash assumptions on the organisation of your source code and relies on a couple of magic files being up-to- date; your source code is probably not organised like mine is)

It seems as if NOCtool keeps spawning side projects. I'm currently in the early stages of another support library for it (more details when the code is closer to "usable").

In other news, twitter syndication makes me unhappy. Especially when it goes Twitter, to LiveJournal, then on to Advogato. If I wanted to read them, I would've been on Twitter already.

Useless text-coding idea #n (but a sit is cute, I shall ignore this and pretend it actually has some use).

Imagine a text, where each word is viewed as an integer. By, for example, splitting the text at whitespaces (this would leave punctuation as being parts of words, but this is not a critical problem). We can then convert each word to an octet vector (by, say, using UTF-8 encoding, since that seems so popular, these days). This octet vector, in turn, can be viewed as either a big-endian or little-endian 8n-bit unsigned integer.

Being an integer, it can be decomposed into its prime factors and these can them be emitted in some suitable order, using some simple framing protocol (using, say, 16- bit "prime ordinal", using 0 as a delimiter).

Obvsiouly, this restricts you from expressing words that happen to be prime, unless they're within the first 65535 primes and I haven't actually run any tests on this, to see how it seems to work out on actual test data. But other than being useless, I think it has cuteness potential.

Seems as if the lates addition to the spam-controls has done something for the comments section. Out of 128 attempts to post, only 10 resulted in a user-visible comment. Unfortunately, all 10 of those were spam and I have no idea how many of the others weren't. Currently doodling on a mod-queue system, so I can actually observe these things in a bit more "what gets trapped, what doesn't" fashion and actually allow me to experiment and tune the predictors.