That is why I need to vent now. I know that my blog is not important to the google-sphere, but I still need to proclaim:

Alpari sucks.

TL;DR: They are a broker that will take your money. Thats pretty much it.

They offer demo accounts, and if you (like me) are trying out algorithms, you can pretty much forget it. During the most profitable time, you cannot trade. They also disconnect you and dont let you log back in during very active moments. It is not random, it is easy to see if you look at plots of the spread they vary on a per second basis.

My verdict? As a broker, questionable. As a demo account for testing… terrible.

There don’t appear to be too many other sites like this, and certainly none that are as easy to use.  If Cuban Music is your thing, then check out cuband.com today!

(Yeah, this is a shameless plug!)

With a wee bitty script, however, you can encrypt anything you like quite easily. You have to have mcrypt installed (and also tar & bzip2, but you’ve likely got that already). Check this out:

#!/bin/bash
IFS=$’\n’
if [[ -z $3 ]]
then
echo “Use: encrypt [file/directory] [password] [outputname]“
exit
fi
echo “Encrypting $1 with password $2 into file $3″
tar -c $1 | mcrypt -p -q -k $2 > $3
echo “Done with encryption.”

Save it as “encrypt.sh” or whatever other name floats your boat, give it execute permissions, and you’re all set. It will tar, compress, and encrypt your file(s) and directories into whatever output file you specify. Just make sure you don’t forget the password you use to encrypt the file with: there isn’t any easy way to find out what it was if you lose it.

In order to decrypt your data, use this little script:

#!/bin/bash
IFS=$’\n’
if [[ -z $2 ]]
then
echo “Use: decrypt [file/directory] [password]“
exit
fi
echo “Decrypting $1 with password $2″
cat $1 | mdecrypt -q -p -k $2 | tar –x
echo “Done with decryption.”

Save it as “decrypt.sh” and give it execute permissions, and now you can easily decrypt your data as well. It can’t really get much easier than that!

There are more than just one type of WinTV USB2 device: the one I have has "Model 42014 Rev D197 Lot # 4405" on the back of it. If you do a 'lsusb', you should see this somewhere in the output:

The device ID is the problem : the driver for this particular model is looking for "2040:4200", not "2040:4201". So, you simply need to edit the driver code and add the right number. To do this, you need to have your kernel source installed and you'll have to know how to configure your kernel for your other hardware. If you're up to the task, then take your favorite editor and open the file '/usr/src/linux/drivers/media/video/em28xx/em28xx-cards.c '. At about line 249 you'll see this:

You'll want to change it to look like this:

You're simply inserting this line:

Save the changes, then go back to your '/usr/src/linux' directory, and do a normal 'make' and make 'modules_install'. As long as you're running the same kernel as the one you are compiling the modules for, you can now do a "modprobe em28xx" and you should be in business! Of course, there are other modules you'll have to load (or compile into the kernel) to get video working in general (look at the 'Video For Linux' section); but this will at least get your hardware talking.

Here's the scenario: You have two separate processes (not necessarily parent/child) and two separate FIFO's. Although a FIFO can be used for bi-directional communication, each one will be set up to be uni-directional: Process #1 will write to FIFO #1 and read from FIFO #2, while Process #2 will write to FIFO #2 and read from FIFO #1. Doing things this way allows Process #1 to pass data to Process #2 via FIFO #1, and Process #2 can pass a result back to Process #1 via FIFO #2. This provides an easy way to keep both processes synchronized, because each process will block when reading the FIFO streams.

Each process blocks when opening both FIFOs as well (during initialization, for example) until both a read and a writer are present (which is normal). Once they are opened, Process #1 writes some data (a number, for example) to FIFO #1. Process #2 should receive the data and return a value via FIFO #2. However, no matter what I tried, the data never reached Process #2, and both processes were in deadlock. But if only a single FIFO was used (where data was passed from Process #1 to Process #2 only), everything worked fine!

If you're now asking, "Just what the hell is a FIFO?", then stop reading here. If you want to know what the problem was and the solution, keep reading.

This silly problem stumped me for some hours. The internets didn't offer much help - apparently other people don't have this type of problem.

Here is the first example using a single FIFO that actually works.

The above two examples work fine. However using two FIFOs for bi-directional communication (as in the examples below) does NOT work. Why?

The solution is this:

I was using fread() and fwrite() calls in these examples. The fwrite() call uses some kind of buffering. So after every fwrite() call, you need to use the fflush() call so that the written data is actually committed. That's all! To make the server/client programs work, insert a fflush() after the fwrite() calls.

The reason that the first sample program I wrote works is because the server program writes the value to the pipe (which does not block) and then promptly ends. When the process ends, the buffer is flushed automatically - which is what I didn't realize, and which is why I took so long to figure out what the hell was going on. Geez.

Anyway, I hope someone else that runs into this same sillyness can find this post and save themselves a little bit of time!

It uses QT4, ffmpeg, and SDL to accomplish this. Probably the most useful bits of the classes are the TCAS display itself, the widget plugins (TCAS widget, the so-called "pieDisplay" widget, and a video display widget), and the video-related classes. All of the classes use QT.

The idea behind this was that it would allow a student to actually work on the detection algorithm part of the application, rather than trying to figure out how to open a video stream and grab frames from it or how to convert YUV to RGB.

Hopefully a student somewhere will end up using this for something useful!

One place to find the GPL'd version of QT for Windows is at the Vienna University of Technology. There are probably other places that host it as well. The executable pretty much does everything automatically, and the "INSTALL" file will get you going in no-time. You'll be using Trolltech's "Designer" with your C++ IDE (I am using VC++ 6) for writing applications in minutes!

I also was able to easily get the QWT plotting widgets to compile and integrated with QT designer, which means that I should be able to compile code with QT depends in Linux and on my Windows install (in VMWare, that is). Neat!