TypeError: character mapping must return integer, None or unicode

This is pretty unhelpful error message also occurs if you try any method that indirectly use altchars. For example:

base64.urlsafe_b64decode(unicode('aass'))
base64.b64decode(unicode('aass'),'-_')

both fail while the following works:

base64.urlsafe_b64decode('aass')
base64.b64decode(unicode('aass'))

While it’s not complicated to fix it (just convert any unicode string to ascii string), it’s still annoying.

modprobe -r nvidia

before restarting the X server.

 \lyxframeend
                 {}\lyxframe{Outline}
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.

After comparing my document to example (working) beamer documents I’ve found out that you must have an EndFrame command after your last frame.Too bad it wasn’t documented anywhere I’ve found as this little thing drove me crazy.

acpid: can't open /proc/acpi/event: No such file or directory

Apparently acpid requires you to enable ACPI_PROC_EVENT, which in it’s labels states “Deprecated /proc/acpi/event support”. I really wonder why such tool only support the deprecated way to receive the ACPI events.

LaTeX Error: Command \textquotedbl unavailable in encoding HE8

This could be solved by adding the following line to your LaTeX preamble:

\let\textquotedbl="

This line will define the \textquotedb to be the double quotation mark, and the document will compile look the same as it looked in older versions of LyX.

convert openyahtzee16.png openyahtzee32.png openyahtzee64.png openyahtzee.ico

resulted in the alpha channel being reversed. I’ve used ImageMagick 6.4.0, and I didn’t remember this misbehavior happening in the previous versions.

While this annoyed, and was due to no apparent reason, it could be easily solved using the ImageMagick switches to reverse the alpha channel:

-channel Alpha -negate

So the command that produces a correct .ico file was:

convert openyahtzee16.png openyahtzee32.png openyahtzee64.png -channel Alpha -negate openyahtzee.ico

I decided to change the aperture size. To do so I entered the bios and pressed Ctrl+F1. This shows up some more advanced configuration options. The aperture size option was under “Advanced Chipset Options”, I changed it to 64MB and I rebooted the computer.

Now everything seems to work properly, I just hope it was really solved and no just accidentally work like at the past. The good thing I can’t see any errors from the NVIDIA driver in dmesg anymore.

usb 1-4: device descriptor read/64, error -71

and the device recognition fails. The player’s battery gets reloaded but I can’t mount it and transfer songs.

The solution that worked for me was runnig as root

echo Y > /sys/module/usbcore/parameters/old_scheme_first

The general idea behind the solution is that there are two way to enumerate USB devices according to the standard. The method that is currently used by default in the usbcore module is similar to the one found in Windows. Apparently There are devices, and the Sansa Clip is among them, that require the other method to function properly. See Linux USB FAQ for more info.

Package amsmath Error: \begin{split} won't work here.

I was using LyX, so I’ve assumed that it would generate the correct syntax for this environment. But the error clearly said that the \begin{split} was used wrong. I’ve went through the user’s guide for the amsmath package and rechecked the syntax. The document has a very handy section that contain common error messages and explanations. I was happy to find out that the error I got was documented there. Unfortunately, the explanation only confirmed that LyX generated the appropriated code for the split environment.

At this point, I’ve decided to export the document to a LaTeX file and manually tweak it till I find a solution. I’ve removed everything from the document apart from some Hebrew text and the split formula. I’ve suspected this error had to do with the Hebrew, as nobody else reported errors using split to the LyX mailing list. I’ve remembered that someone mentioned to me once that LaTex is very sensitive to the order the packages are added. So I’ve started to play with the order and moved the \usepackage statements around. When I’ve put the \usepackage{babel} above the \usepackage{amsmath} the document suddenly compiled fine.

Some further testing showed that in order for the split environment to work properly in an Hebrew document the babel package must be included before amsmath and any other package that depends on it (like mathtools).

Getting things to work back in LyX was a bit more tricky. LyX automatically adds the babel package after the LaTeX preamble, and by default it adds the amsmath when needed, but it does so before the LaTeX preamble. This, as you can see, results in the \usepackage{amsmath} appearing before the \usepackage{babel}. The solution had to override the placements of both statements.

The first step is to go to Document->Settings->Math Options and uncheck both “Use the AMS math package automatically” and “Use the AMS math package”. This won’t prevent you from using any to the amsmath package feature if you include it manually (like we will do). The next step is to go to Documents->Settings->LaTeX Preamble, and insert directly at the top of the preamble the following two lines:

\usepackage{babel}
\usepackage{amsmath}

Now the Hebrew document will compile fine even if you use the amsmath’s split environment. Note that LyX will add \usepackage statement for for babel after the preamble despite the fact you already have one. But don’t worry, LaTeX will ignore that second statement and no harm will be done.

The clock() function returns an approximation of processor time used by the program.

I thought that the word approximation was there because that the CLOCKS_PER_SEC should always be set to 1,000,000 according to the POSIX standard, and modern CPU tick on a much higher frequency so here goes the approximation, as the number of actual ticks needs to be adjusted, as the tick rate of clock() is a one million in a second ticks and not the actual hardware rate.

But the word “approximation” is there for different reason. clock() just can’t register very short processor times. Let’s examine the following program:

#include <stdio.h>
#include <time.h>
 
int main()
{
        clock_t start, end;
        int temp,i;
        start = clock();
        for (i = 0; i<2500000 ; i++)
                temp+=temp;
        end = clock();
        printf("%i\n",end-start);
        return 0;
}

If I compile and run this program it prints 1000 that means that the clock() has done 1000 ticks, if we divide it by CLOCKS_PER_SEC we get that the processor time for computing the loop in the program was 0.01 seconds.

Now if I change a bit the loop and make it a bit shorter by changing the top limit from 2,500,000 to 2,000,000 and compile and run it, the output is 0. Suddenly the loop doesn’t take any processor time!

That means that also CLOCKS_PER_SEC is set for 1,000,000 the actual resolution that one can depend on is less than 1000 ticks per second, which is pretty low. This disqualifies clock() from being used in any task that demands precision.

Possible alternatives for clock() that have higher resolution include clock_gettime and gettimeofday() (despite its name). Both functions provide high-resolution clocks that should give back the time in microseconds, which allows to use them in a much similar way (but hopefully more accurate) than clock()