Skip to main content

Posts

Showing posts from 2009

Both INCLUDEPATH and DEPENDPATH are usually needed in qmake .pro project files.

qmake, the build tool provided with the Qt toolkit, converts project files written in its own mini-language to platform-specific Makefiles.

This process includes adding necessary dependencies to the Makefile, so that changes in source files trigger rebuilding of the outputs that depend on said sources.

If your project is spread across directories, you'll likely add an INCLUDEPATH line to your .pro file so that the #include directives look sane -- say #include "library/foo.h" instead of #include "../library/foo.h". This can be done by adding INCLUDEPATH += "../" to the .pro project file.

This, by itself, doesn't cause the files in include directories to be treated as dependencies. This is a sane default, since you likely don't want to rebuild your whole project if a system library changes -- assuming, of course, that the library is meant to stay binary compatible between releases!

Thus, if any of your source files references a file from somewhe…

Zultys WIP2 WiFi Phone with Asterisk

I have recently brought up an Asterisk extension on a Zultys WIP2 WiFi phone. The process had a few minor glitches, but I was able to resolve them all.



The system consists of:

Zultys WIP2 wireless phone,HP Procurve AP530 wireless access point,HP Procurve 2625PWR managed Ethernet switch,a server running CentOS 5 with asterisk-1.6.1.9-90 from atrpms.First of all, Zultys only provides manuals/firmware to their products in their knowledgebase. You have to sign up to use that. Even so, WIP2 was missing from that list. I have ~20 ZIP 4x4 phones also running off the 2625PWR switch, and their firmware/manuals are available in the KB. I emailed their support, and they quickly responded with the manual and 1.0.12 firmware. The phone had 1.0.3 installed.

I added a separate VLAN on a separate IP network just for the WIP2 phone and configured everything accordingly. Since WIP2 only supports WEP, it's not really secure, so I treat that VLAN as untrusted and only open up the SIP port on the server…

VMware Fusion 2.0.6 + Alibre Design 12 = Good News

For the early adopters who ran Alibre Design on Windows in VMware Fusion virtual machines, VMware 2.0.6 brings some very good news: the dreaded stuck-red-highlight bug is gone.

When you move the mouse cursor, Alibre's 3D views highlight the face or edge closest to the cursor. In VMware, this red highlight would be stuck -- or rather, it would only turn ON, but never OFF.

The issue was present in every VMware 2 up to and including 2.0.5, and in every version of Alibre Design starting with at least 10. I only tried it on MBP with NVidia graphics, so it might have been an NVidia-only issue.

I was very nicely surprised after updating VMware to 2.0.6 today. Not only did networked Windows startup take perhaps 25% less time (somehow), but Alibre's workspace starts up much faster (feels like 50%) and the workspace display is bug-free, as far as I can tell.

This, coupled with significant speed improvements in Alibre 12, means that a very solid parametric CAD is available for OS X on In…

PDF to PS to PDF on OS X: How to Fix Those That Cause Errors

Apple's OS X generates anti-distillation blurbs in the PostScript files generated from "encrypted" PDFs. Remember prohibition, anyone?

The "encrypted", or locked down, rather, PDFs happen to be mostly everything these days. Forms that are meant to be fillable, bank account statements where you want to mark things up to reconcile accounts, etc. My most recent run-in with this stupidity was Anthem's and CompanionLife's insurance forms. I actually wish we didn't have to fill out, um, modify those, right? And surely it's every insurance companies' dream to get the forms back with my dreadful handwriting on them...

So, the pdfs are marked as protected from modification. OS X's otherwise excellent Preview doesn't ignore such marks when you print to PostScript. Thus, the resulting postscript files throw an error when you try to distill them back into pdf, say using ps2pdf14.

Upon inspection of the postscript files, you can see the eexec blu…

Google Search Defaults To Wrong Country TLD in Opera

Opera 10.0 on OS X remembers the non-default country specific google TLD the first time Google redirects it to such a TLD. Having recently visited Australia, my Google search from the toolbar was stuck on google.com.au; clearing cookies and private data didn't help with that.

The culprit is the following line in ~/Library/Preferences/Opera Preferences:

$ cd ~/Library/Preferences/Opera\ Preferences/
$ grep -r 'TLD Default' *
[...]
operaprefs.ini:Keyboard Configuration={Resources}defaults/standard_keyboard.ini
operaprefs.ini:Mouse Configuration={Resources}defaults/standard_mouse.ini
operaprefs.ini:Show Default Browser Dialog=0
operaprefs.ini:Google TLD Default=.google.com.au

All it takes to restore the default google TLD (the US one, in my case) is to quit Opera and remove the highlighted line in operaprefs.ini. Due to this browser's cross-platform nature, it's likely that same approach will work on Windows and Linux. Hopefully it will save some traveller a bit of head …

Pascal-Style Local Functions in C (for Z8 Encore!)

When I was a kid, I used Turbo Pascal. It had one feature that I sorely miss in every embedded C compiler: local functions. Local, as in local to a block. Those become a necessity to maintain decent code performance and avoid the penalty of passing duplicate data via parameters. They also help maintain readable, decently factorized code.

A local function, were C to have it, would look like this:

void fun1(void) {
 int a;
 void fun2(void) {
   a = 0;
 }
}

I hope you see that fun2() is local to the main block of fun1(), and that the variable a is in scope within fun2().

A somewhat less clean, but equally well performing way of accomplishing this would be:

extern int a; void fun2(void) {   a = 0; } void fun1(void) { ...   fun2(); }
Now the question remains: where do we actually define the variable a, which is supposed to be local to fun1?

It becomes easy if your compiler supports static frames. Static frames are, as their name implies, allocated statically by the linker, and are overlaid according to …

Asterisk 1.4 Update Woes

I admin a CentOS 5 server with Asterisk 1.4 on it, hooked up to an XO T1 link. The repo I use for this is atrpms, which has been pretty much problem-free.

After a most recent upgrade, asterisk would fail to load the dahdi channel driver, with the following in /var/log/asterisk/messages:
WARNING[pid] loader.c: Error loading module 'chan_dahdi.so': /usr/lib/asterisk/modules/chan_dahdi.so: undefined symbol: ast_smdi_interface_unref The solution, as hinted by Chris Maciejewski, is to load the res_smdi.so module. For whatever reason, my /etc/asterisk/modules.conf had the following line:
noload => res_smdi.so Changing it to "load => ..." fixed the problem.

Zilog's Encore!: Changes for Change's Sake, and When Simple Won't Do

I have been using Zilog's Z8 Encore! chips since the first marketed silicon release of Z8F4801, Rev AA. The chip is a nice 8-bit MCU. As nice and useful as it is, its history can't but highlight concerning lack of vision and direction in Zilog's marketing and development efforts.

Let's start with a rather simple thing: the tool used to interface with the chip's one-wire DBG pin. It's nothing more than an autobauding half-duplex asynchronous port, in CMOS voltage levels. Such simplicity was reflected in Zilog's first debug "tool" sold with the early Z8F6401 development kits. It was a small board (approx 1 sq in), with a TTL-to-RS232 converter chip (MAX232, IIRC), a diode standing in for an open-drain driver, the DBG line pull-up, and some decoupling and charge pump capacitors, and two connectors -- one for the 6-pin target header, another for the serial cable.

Soon thereafter it became obvious that RS232 serial ports are being phased out from newly…

XSS Vulnerability in the Real Life: Passports

I'm traveling again. This time to Australia. I travel a few times a year, always departing from the U.S.

Each time I travel internationally, the check-in airline agent dutifully inspects my passport. The latter has acquired a sizable collection of visa labels, admittedly much flashier than the dull black-on-white photo page of the Polish passport. The visas usually occupy the whole page, look nice, and are formatted to somewhat resemble a passport page -- they have a picture, same personal data, and the two machine readable lines on the bottom.

Each and every time the airline personnel will ignore the photo page and look at the first official-enough-looking visa. Somehow it always happens to me in the U.S., and never abroad. Heck, they get angry at me for pointing out that they really should not be looking at the flashy visa labels, but at the picture page. Sigh.

Call me paranoid, but if this isn't a huge honking screaming-in-yer-face security vulnerability in the passport ins…