gdb: source code location mapping on startup

When you run gdb, you usually have to add source code directories using the “dir” command. This is okay if your code lies within a single directory, but if the code you’re debugging jumps across files in various directories, you’ll end up running “dir” several times, and this can be quite cumbersome.
The solution isn’t as simple as specifying the top-level (root) directory where your source code is checked out, because gdb won’t try to find matching source files recursively in the directory tree. gdb only checks the current directory (i.e. where you launched gdb from), and other directories specified via “dir” for matching source files.
Fortunately, there’s an elegant and simple solution to this problem:
To add directories to gdb automatically, so that you don't have to point out the source code dirs manually each time you start gdb, just specify the “substitute-path” like this in your .gdbinit file:

set substitute-path 
/sandbox/builds/appframework_dev/  /data/source/branches/appframework_dev

This tells gdb that the source files that it was initially expecting at “/sandbox/builds/appframework_dev” (which is the location of the source code on the build machine, where you got the binaries that you are debugging), are mapped to the local directory (on your test machine) at “/data/source/branches/appframework_dev”

see this relevant discussion on stackoverflow for this and other approaches to this problem

EDIT: it appears that I had already blogged this little nugget of gdb goodness last year, along with a few more interesting gdb tidbits

python: calling c++ functions from python

 

Why would you want to do this? To test CPP APIs, SDKs – by consuming API/SDK code in Python. If you already have an automation test suite in Python, you can write and maintain test cases easily in Python, calling C++ functions as required, instead of writing C++ code to consume C++ libraries – which can get painful since the effort and time to write/maintain C++ is much higher than Python in my experience.

There are at least three different ways to create a python binding to a CPP library:

• SWIG
• Boost.Python
• ctypes

 

According to this discussion on stackoverflow, ctypes has a few advantages (including simplicity) over the other options:

ctypes has the advantage that you don't need to satisfy any compile time dependency on python, and your binding will work on any python that has ctypes, not just the one it was compiled against.

c++: generic pointers and void *

When a variable is declared as being a pointer to type void it is known as a generic pointer. A pointer to void can store an address to any data type. Since you cannot have a variable of type void, the pointer will not point to any data and therefore cannot be dereferenced. It is still a pointer though, to use it you just have to cast it to another kind of pointer first. Hence the term Generic pointer.
This is very useful when you want a pointer to point to data of different types at different times.
Here is some code using a void pointer:

int main()
{
    int i;
    char c;
    void *the_data;

    i = 6;
    c = 'a';

    the_data = &i;
    printf("the_data points to int %d\n", *(int*)the_data);

    the_data = &c;
    printf("the_data points to char %c\n", *(char*) the_data);

    return 0;
}

source

c++: const functions

Declaring a member function with the const keyword specifies that the function is a "read-only" function that does not modify the object for which it is called.
To declare a constant member function, place the const keyword after the closing parenthesis of the argument list. The const keyword is required in both the declaration and the definition. A constant member function cannot modify any data members or call any member functions that aren't constant.

// constant_member_function.cpp
class Date
{
 public:
   Date( int mn, int dy, int yr );
   int getMonth() const;     // A read-only function
   void setMonth( int mn );  // A write function can't be const

 private:
   int month;
};

int Date::getMonth() const
{
   return month;        // Doesn't modify anything
}

python: understanding the "with" statement/keyword

Consider some typical boilerplate code that opens a file (whose filename is passed as a command-line argument) in read-only mode, reads the file line-by-line and performs some operation on each line thus read:

fileIN = open(sys.argv[1], "r")
line = fileIN.readline()
while line:
    [do something with line]
    line = fileIN.readline()

From Python 2.5 onwards, this can be done more easily via the "with" statement:

with open(sys.argv[1], "r") as fileIN: 
    for line in fileIN: 
        [do something with line] 

The "with" statement reduces the line count from 5 to 3, and also makes the code more readable and human-friendly. It's more pythonic and intuitive.

source

HTTP: Chunked Encoding

In chunked encoding, the content is broken up into a number of chunks; each of which is prefixed by its size in bytes. A zero size chunk indicates the end of the response message. If a server is using chunked encoding it must set the Transfer-Encoding header to "chunked".

Chunked-encoding is not the same as Content-Encoding header. The Content-Encoding header is an entity-body header. since transfer-encodings are a property of the message, not of the entity-body. ("Entity-body" refers to the body or payload [e.g. a JPG image] of an HTTP request [e.g. POST or PUT request] or response).

 

Q: When is chunked encoding really useful?

A: Chunked encoding is useful when a large amount of data is being returned to the client and the total size of the response may not be known until the request has been fully processed. An example of this is generating an HTML table of results from a database query. If you wanted to use the Content-Length header you would have to buffer the whole result set before calculating the total content size. However, with chunked encoding you could just write the data one row at a time back to the client. At the end, you could write a zero-sized chunk when the end of the SQL query is reached.

This is the HTTP header that is sent by the server:

Transfer-Encoding: chunked

In the HTTP 1.1 specification, chunked is the only encoding method supported by the "Transfer-Encoding" header.

 

source

apache: what are .htaccess files typically used for?

.htaccess files allow us to make configuration changes on a per-directory basis. .htaccess files work in Apache Web Server on both Linux/Unix and Windows operating system. In Apache, the format of .htaccess is the same as the server's global configuration file.

There are several things that developers, site owners and webmasters can do with .htaccess files, for example:

• Prevent directory browsing
• Redirect visitors from one page or directory to another
• Password protection for sensitive directories
• URL-Rewriting (e.g. rewriting long, unwieldy URLs to shorter ones)
• Change the default index page of a directory
• Prevent hot-linking of images from your website
• per-directory cache control

 

 sources:

http://www.bloghash.com/2006/11/beginners-guide-to-htaccess-file-with-examples/

http://en.wikipedia.org/wiki/Htaccess