linuxbutler

I recently worked on some c code on an embedded platform with this declaration:

__attribute__((critical)) void somefunc (void) {
    function body ...
}

I’d never seen anything like that.

It turns out that “critical” (and “atomic” and a few other keywords) are part of the open mp spec, where multiprocessing support is being built in to compilers. This has been moving into gcc since 2005 (at least, that’s when I see the mention of “omp” in the changelogs).

Dunno when it will be available on x86 though … it didn’t work on my desktop:

bjb@blueeyes:~/junk/foo$ gcc try1.c -o try1
try1.c:12: warning: 'critical' attribute directive ignored
try1.c:23: warning: 'critical' attribute directive ignored
bjb@blueeyes:~/junk/foo$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

bjb@blueeyes:~/junk/foo$

There was no warning on the customer platform, but it’s presence did not produce a different executable than source code without it.

The next “activation date” came and went, with no DSL service. The reason given is that my address did not exactly match the address on my phone bill. I said the address as it should be into the phone when I ordered the service, but the customer service rep(s) on the other end insisted on putting the letter after the number as a “unit” number or “suite” number. I said I don’t write 999 unit A, I write 999A. But they didn’t know how to enter that into their (or their supplier’s) system.

I wonder why that is, when I had DSL service through NCF, which uses TekSavvy for it’s upstream, and that worked first try?

Why is TekSavvy so certain this time that the activation will work, when it failed the last two times?

Why did TekSavvy decline my offer to fax my phone bill (with address) to their office?

If they’ve done something to ensure that it will work this time — why didn’t they do that the first time?

I’m having a rocky start with TekSavvy. In spite of ordering DSL service a while ago, the order got messed up and I’ve had to call a few times to try to sort it out. Today, NCF cutoff day, I find that the order has been so badly mangled that I have to start over from scratch and be internetless for a week.

I have spoken to 2 newbie customer service reps out of the three calls I’ve made (they volunteered the info). One insisted that the only way to switch between payment types was to start over (but he didn’t tell me that it would delay the start date). He didn’t cancel the first order … that confused TekSavvy no end, I even got a call from them asking about it. But the person who called didn’t make it better so that when I spoke to the next newbie (today), we had to start over - again.

I’ve ordered a new DSL supplier and have cancelled the old one — the transfer date is June 24. So if I go offline June 24, that might be why. I’ll be back.

I haven’t got my new static IP address yet, nor my new IPv6 subnet. Stay tuned! Hopefully I’ll find out what they are before June 24 (so I can put them in DNS on time).

NCF (National Capital FreeNet) has been great — but I wanted a native IPv6 supplier. So, I’m trying out TekSavvy. TekSavvy is NCF’s upstream, as it happens.

I will try to stay in touch with NCF by visiting the fora and asking/answering questions there, if I see anything I can respond to.

The ways that psql can be configured to connect to a different port:

1. compiled in default
2. PGPORT environment variable
3. —port or -p option
4. .pgpass setting

If you are running more than one version of PostgreSQL, you might wonder which one the psql client will talk to by default.

(DJANGO-1-3)bjb@spidy:~$ bash
bjb@spidy:~$ echo $PGPORT

bjb@spidy:~$ unset PGPORT
bjb@spidy:~$ ls -la ~/.pgpass
-rw------- 1 bjb bjb 0 May 20 17:33 /home/bjb/.pgpass
bjb@spidy:~$ locate psql | egrep bin
/usr/bin/psql
/usr/lib/postgresql/8.4/bin/psql
bjb@spidy:~$ /usr/lib/postgresql/8.4/bin/psql template1
psql (8.4.8)
Type "help" for help.

template1=> \echo :PORT
5432
template1=> \q
bjb@spidy:~$ exit
(DJANGO-1-3)bjb@spidy:~$ 

Voila. The psql in /usr/bin is a perl script wrapper for the real psql. To find the “compiled-in” default port number, you can run the real psql without the command-line arg to change the port number, --port 5555 or -p 5555, and you also need to unset PGPORT (if it’s set). I have a .pgpass, but it’s empty so I didn’t have to do anything special for that. If you have a non-empty .pgpass, you might copy it aside before running psql if you want to try this test. Don’t forget to put it back when you’re done.

On my work machine, I had two versions of PostgreSQL running: 8.4 and 8.3. 8.3 was listening on 5432 and 8.4 was listening on 5433. psql was configured to go to port 5432 by default (and therefore PostgreSQL 8.3).

I found this very helpful. It worked great with Django 1.3, PostgreSQL 8.3 in 2011/06:

And the penultimate step (filling in the primary key in existing rows) took around half a minute for almost 200,000 records on a not-particularly well-endowed laptop.

Summary:

CREATE SEQUENCE rcvh7_id_seq;
ALTER TABLE rcvh7 ADD id INT UNIQUE;
ALTER TABLE rcvh7 ALTER COLUMN id SET DEFAULT NEXTVAL('rcvh7_id_seq');
UPDATE rcvh7 SET id = NEXTVAL('rcvh7_id_seq');
ALTER TABLE rcvh7 ALTER COLUMN id SET NOT NULL;

I have a database full of strings where the accented characters have been replaced by their non-accented equivalents, and a spreadsheet full of strings with accents in them. I’m supposed to look up the info in the database given the info in the spreadsheet.

I found this great stackoverflow post that helped me out:

title = u"some string with accented characters in it like b\xe9cancour"
import unicodedata
unicodedata.normalize('NFKD', title).encode('ascii', 'ignore')
'some string with accented characters in it like becancour'

Normalize with ‘NFKD’ will decompose each character in the string into its composing characters. For example, if there was an e with acute accent, it separates it into an e and an acute accent. The K part of NFKD ensures the ‘e’ is the simplest possible e (presumably if there is an ‘e’ in ASCII, it will prefer that one). Then the encode ('ascii', 'ignore') will drop all the non-ASCII characters, which by now are just the accents which have been separated from the rest of the letter.

Awesome. And it works in python 2.5.

Today is the day (starting from midnight GMT).

Some test sites:

• ipv6-test
• test-ipv6

identd provides the “auth” service (see /etc/services). On Debian, it can be provided by any of several packages, including ident2, nullidentd and oidentd.

If you want to have an identd that can talk IPv6, you can choose oidentd.

If you are running it from inetd, you should configure your inetd to respond to IPv6 as well. I’m using openbsd-inetd, and the lines in /etc/inetd.conf to make it listen on both IPv4 and IPv6 for the auth service are:

auth stream tcp4 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I
auth stream tcp6 nowait root /usr/sbin/tcpd /usr/sbin/oidentd -I

Note the protocol, which specifies IPv4 or IPv6. Also note the -I option to oidentd, to make it read from stdin and write to stdout and to exit after answering one request (needed for inetd operation).

I briefly considered nullidentd, but the description made it sound like it would only ever return one static string. Not quite what I was looking for, and I didn’t investigate further.

I was looking at django sessions and was a bit confused until I read the source code.

django/contrib/sessions/models.py
django/contrib/sessions/backends/base.py
django/contrib/sessions/backends/db.py
django/contrib/sessions/backends/cache.py
django/contrib/sessions/backends/cached_db.py
django/contrib/sessions/backends/file.py

You might think the interesting file to look at is django/contrib/sessions/models.py, but really the “toplevel” session object is defined in base.py. The object in base.py SessionBase. It is a base class for the various session implementations.

If you’re using a database-backed SessionStore, then you’ll be using base.py, db.py and session.py. db.py uses session.py for the database model and database interaction. In a view, the session object in the request object that is supplied by the session middleware is actually a SessionStore object. That is the object that has the methods get_expiry_age, etc.

I wanted to get some info out of every session in a batch mode including expiry age, so I needed to traverse SessionStore.objects.all(), not Session.objects.all().