Nope, it took a full system reboot. Apparently Windows had fucked itself up enough to run out of socket handles at a system-wide level.
Sounds like my experience with buggy NFS servers on Linux...
Nope, it took a full system reboot. Apparently Windows had fucked itself up enough to run out of socket handles at a system-wide level.
Sounds like my experience with buggy NFS servers on Linux...
Status: So I have a Python program which loads a C library (libclang) in order to parse a C header file and in return generate C source code to build a C library which can be loaded from a Lua script which will then be able to create objects whose memory pattern matches the C structs in the header file.My head is starting to hurt...
Status: So I eventually gave up trying to use this thing and rewrote the parts I needed from scratch. Doing this took me less time than the time I spent trying to get this framework to work.
Also, TRWTF is ctypes
doing arrays bound checks, which makes accessing a C variable-length structure quite cumbersome...
Status: I really should lose this habit of pressing Ctrl-S in LibreOffice every time I make a trivial change. Especially since the file I’m editing is on a slow NFS server and doing so makes LibreOffice freeze for 5 seconds.
An 11-deep call stack? That's nothing; in the managed world, when you take into account the unmanaged code underneath it, it's not uncommon to see call stacks 30, 40, even 50 calls deep!
That’s not the full call stack, that’s just the part in the vendor library and driver. And that’s for a quite simple operation (take a lock, put message on queue, release the lock). I don’t even want to imagine what it does for more advanced operations.
I have also found that the driver assigns a int some_func(some_type* ptr, Uint32 timeout)
function to a int ()(void*, Uint32)
function pointer by first casting the function pointer to a Uint32
and then casting it to the correct type. AFAIK, the conversion would have worked without any casts.
where's the fun in only having one thread?
Well, if you really want multiple threads, maybe I can create another one in two weeks when the DST switchover occurs here…
Status: Started meld
in a terminal, got annoyed by the debugging output
$ meld .
** (meld:20524): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-ndBY5F7jbH: Connexion refusée
(meld:20524): dconf-WARNING **: failed to commit changes to dconf: L'exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)
(meld:20524): dconf-WARNING **: failed to commit changes to dconf: L'exécution du processus fils « dbus-launch » a échoué (Aucun fichier ou dossier de ce type)
(Usual Frenglish gibberish of course...) so I tried to restart it with stderr redirected to /dev/null
:
$ meld . 2>/dev/null
Trappe pour point d'arrêt et de trace
$
... SIGTRAP
? Seriously?
Fortunately, it worked when I restarted it. Looks like it’s going to be one of those days...
Status: Investigating a latency issue. Two lines of C code which read 12 bytes and write 8 bytes sometimes take three seconds to execute in a real-time-priority, locked-in-memory process.
The accessed structure is in a mmap
ed file, so I guess a slight delay is to be expected if the mapped page is currently written to disk, but 3 seconds is a huge
Status: Investigating a latency issue. Two lines of C code which read 12 bytes and write 8 bytes sometimes take three seconds to execute in a real-time-priority, locked-in-memory process.
Status: Now trying to figure out why some I/O requests to the SD card take 300+ milliseconds to complete on the system. Looks like Linux’ I/O scheduler doesn’t handle that very well...
Status: Getting confused by the static analyzer:
I eventually realized TRWTF was me for forgetting to #include <assert.h>
.
```
$> uncompress filename.taz -c |tar -xv -C DIRor simply `tar xZf filename.taz`. Or even `tar xf filename.taz` because recent versions of tar can autodetect compressed files.
According to the documentation, foreign keys constraints need to be explicitely enabled when opening the database:
I wrote them for shits and giggles right?
You’re using a database which ignores column data types. You should probably assume that most constraint checks are nonexistent or disabled by default.
Yes, but it needs to be in CDATA IIRC
It’s fine as long as the input string is valid UTF-8 (or whatever encoding specified in the charset
attribute):
>>> import xml.etree.ElementTree as ET
>>> item = ET.fromstring('<?xml version="1.0"?><test>é</test>')
>>> print repr(item.text), item.text
u'\xe9' é
>>> item = ET.fromstring('<?xml version="1.0" encoding="macroman" ?><test>\x8e</test>')
>>> print repr(item.text), item.text
u'\xe9' é
>>>
EDIT: Hanzo’d multiple times (but I took the time to actually check...)