Compiling linux kernel 2.6.34.1 with ICC (Intel Compiler) Version 12.0.0 without wrapper!

First Download Intel Compiler  its free for individuals to download and use for non-commercial type.
Second Source the compiler for x86_64 or x64 (64bit) architectures:

source /opt/intel/bin/iccvars.sh intel64

For x86 32bit architectures you will need other patch!

Step Third : Download and Patch the kernel 2.6.34.1

patch -p1 < dna-2.6.33-intel64.patch

Now you are ready to make oldconfig or make menuconfig , then :

make  AR=xiar LD=xild

Note :  AR=xiar LD=xil  is for use ICC’s built in LD and AR linking


if you get the error : /usr/lib/libirc_s.a: No such file or directory       

cd /usr/lib/
sudo ln -sf /opt/intel/lib/intel64/libirc_s.a libirc_s.a  

TUTORIAL : migrate mysql to GAE (Google App Engine)

This post is based upon Nick's Blog Advanced Bulk Loading, part 3: Alternate datasources , Migration to a Better Datastore and Google app engine Uploading data

From Nicks Blog : The bulkloader automatically supports loading data from CSV files, but it's not restricted to that.

The key to this is the generate_records method. This method accepts a filename, and is expected to yield a list of strings for each entity to be uploaded. By overriding this method, we can load from any datasource we wish

This is an example (algo taken from Nicks blog :P) but with some fixes I had to add

import MySQLdb
from google.appengine.tools import bulkloader
from google.appengine.ext import db

class MySQLLoader(bulkloader.Loader):
  def __init__(self, kind_name, query, converters):
    self.query = query
    bulkloader.Loader.__init__(kind_name, converters)

  def initialize(self, filename, loader_opts)
    self.connect_args = dict(urlparse.parse_qsl(loader_opts))

  def generate_records(self, filename):
    """Generates records from a MySQL database."""
    db = MySQLdb.connect(self.connect_args)
    cursor = db.cursor()
    cursor.execute(self.query)
    return iter(cursor.fetchone, None)

class BlogPost(db.Model):
  title = db.TextProperty(required=True)
  date = db.DateProperty(required=True, auto_now_add=True)
  body = db.TextProperty(required=True)

class BlogPostLoader(MySQLLoader):
  def __init__(self):
    MySQLLoader.__init__('BlogPost',
                         'SELECT title, date, body FROM posts',
                         [('title', str),
                          ('date', custom_date('%m/%d/%Y')),
                          ('body', str)
                         ])

laoders = [BlogPostLoader]

And here how to use it.

appcfg.py upload_data --config_file=blogpost_loader.py --filename=sarasa --loader_opts="passwd=passwd&db;=things" --kind=BlogPost

If you want to put the data to the developtment :

appcfg.py upload_data --config_file=blogpost_loader.py --filename=sarasa --loader_opts="passwd=passwd&db;=things" --kind=BlogPost --url=http://localhost:8080/remote_api 

Dont forget to add the remote_api in handlers :

-- url: /loadusers
 script: myloader.py
 login: admin

Also go to http://localhost:8000/remote_api and signin with a mail checking the box signin as administrator with your browser.
-

Tutorial : Running django under GAE (Google App engine)

1. Install the appengine SDK 
2. In your project folder create a sym link to the GAE SDK :
   

   ln -s /opt/google_appengine google_appengine
   

   /opt/google_appengine should be your SDK directory
   
3. download an unzip the following NOT in your project folder :
Download the following zip files:
• django-nonrel (or clone it)
• djangoappengine (or clone it)
• djangotoolbox (or clone it)
• django-dbindexer (or clone it)
• django-testapp (or clone it)
4. Copy folders in your project like this : Copy the following folders into your project (e.g., django-testapp):
   
   django-nonrel/django => /django
   djangotoolbox/djangotoolbox => /djangotoolbox
   django-dbindexer/dbindexer => /dbindexer
   djangoappengine => /djangoappengine
5. Configure your app.yml and ready to go as a normal django project!

Important :Many advanced Django features are not supported at the moment. A few of them are:

• JOINs
• many-to-many relations
• aggregates
• transactions (but you can use run_in_transaction() from App Engine's SDK)
• QuerySet.select_related()

Superimpose text over an image by using CSS-styled text

Idea : superimposed over an image by using CSS-styled text and a background image in a

tag.

The div with the image

.imagediv {
    background-image:  url(/images/backgroundimage.JPG);
    background-repeat: no-repeat;
    height: 500px;
    width: 380px;
}

Put the text in a div with class "textoverimage"

.textoverimage {
    position: relative;
    height: auto;
    width: auto;
    left: 25px;
    top: 200px;
}

Design Patterns in python : Singleton

Singleton design pattern provides a mechanism to limit the number of the instances of the class to one. Typically such classes are used to manage resources that by their very nature can only exist once.

There are different approaches to singleton pattern in python.

Singleton

class Singleton(object):
  def __init__(cls,*a,**k):
    if not hasattr(cls,'_inst'):
      cls,_inst = super(Singleton,cls).__new__(cls,*a,**k)
    return cls._inst

Problems with subclassing.

Monostate (Borg Pattern by Alex Martelli). Idea : instead of forcing all instances to have the same identity they share state.

class Borg(object):
  _shared_state = {}
  def __new__(cls, *a, **k):
    obj = super(Borg, cls).__new__(cls, *a, **k)
    obj.__dict__ = cls._shared_state
  return obj

No problems with subclassing.

Things to know about python

Why python? Python has become very popular among developers, who are attracted to its clean syntax and reputation for productivity.

Python is weakly typed lenguage. In a strongly typed language, each variable has a type that's known at compile time. If I attempt to invoke a method on a variable whose type doesn't declare that method, the compiler of a strongly typed language tells me of the error. That's one difference between a strongly typed and weakly typed language.

 In a strongly typed language, a variable's type implies the object it references will have a particular interface. That interface doesn't just tell me at compile time what method signatures exist, it also tells me what those methods mean. It tells me what the methods promise to do.

Checking the type of an object in python at runtime is rarely done, you invoke the method without guarantee.

In Python, there is a contract, but the contract is implicit. The contract isn't specified by an interface.

Python objects is that they are not merely instances of their classes; their structures can change in runtime. This level of flexibility combined with the ability of the instance to trap attribute access lays a foundation for various Python idioms. On the other hand it also requires some restraint from the programmer, because overly ``dynamic'' code can be very difficult to understand and maintain.

Python is dynamically but strongly typed. The fact that the two halves of that statement fit together can confuse those who come from a static language type background. In Python it is perfectly legal to do this :


Duck typing :

If it walks like a duck and quacks like a duck, I would call it a duck.

In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself. For example, in a non-duck-typed language, one can create a function that takes an object of type Duck and calls that object's walk and quack methods. In a duck-typed language, the equivalent function would take an object of any type and call that object's walk and quack methods. If the object does not have the methods that are called then the function signals a run-time error.

Multiple Inheritance

Python supports a limited form of multiple inheritance as well. A class definition with multiple base classes looks as follows:

class DerivedClassName(Base1, Base2, Base3):
    
    .
    .
    .
    

The only rule necessary to explain the semantics is the resolution rule used for class attribute references. This is depth-first, left-to-right. Thus, if an attribute is not found in DerivedClassName, it is searched in Base1, then (recursively) in the base classes of Base1, and only if it is not found there, it is searched in Base2, and so on.
(To some people breadth first -- searching Base2 and Base3 before the base classes of Base1 -- looks more natural. However, this would require you to know whether a particular attribute of Base1 is actually defined inBase1 or in one of its base classes before you can figure out the consequences of a name conflict with an attribute of Base2. The depth-first rule makes no differences between direct and inherited attributes of Base1.)
It is clear that indiscriminate use of multiple inheritance is a maintenance nightmare, given the reliance in Python on conventions to avoid accidental name conflicts. A well-known problem with multiple inheritance is a class derived from two classes that happen to have a common base class. While it is easy enough to figure out what happens in this case (the instance will have a single copy of ``instance variables'' or data attributes used by the common base class), it is not clear that these semantics are in any way useful.

Predefined Class Attributes

Classes have five predefined attributes:

Attribute	Type	Read/Write	Description
__dict__	dictionary	R/W	The class name space.
__name__	string	R/O	The name of the class.
__bases__	tuple of classes	R/O	The classes from which this class inherits.
__doc__	string OR None	R/W	The class documentation string.
__module__	string	R/W	The name of the module in which this class was defined.

Django : projects versus applications

Projects versus applications

Understanding the distinction Django draws between a “project” and an “application” is a big part of good code layout.

• application : tries to provide a single, relatively self-contained set of related functions.

• project  : collection of applications, installed into the same database, and all using the same settings file.

Examples 

A project may correspond to a single web site.

Observations 

The project is also responsible for the root URL configuration.

An application is allowed to define a set of models.

Conventions (nothing official) or check list 

Generally there’s no need to require standardized layouts or locations for certain functions, but it can be helpful to adhere to a few conventions.

Stuffing logic and huge amounts of code into models.py sounds like a

terrible idea

Each "application" should be small -- a single reusable entity plus a few associated tables. We have about 5 plus/minus 2 tables per application model. Most of our half-dozen applications are smaller than 5 tables. One has zero tables in the model.

It's okay to have applications depend on each other. However, the dependency has to be limited to the obvious things like "models" and "forms".

Each application should be designed to be one reusable concept. In our case, each application is a piece of the overall site; the applications could be removed and replaced separately.

This is something I’m still in the process of developing, but I also like to have an easy way to test the dependencies my applications have, and to make sure everything is configured properly. The easiest way to do this, in my experience, is to put some code in the application’s __init__.py which checks for everything the application will need. 

Bad examples

A bad example of a Django app would be one that implemented authentication, openid support, helpdesk, and project tracking. Why would that be bad? Because now if you want to reuse your authentication app you have to extricate some models, some views, some templates from your all-encompassing app. If you decide that OpenId support is a must for your next project, you will have to go through the code of this behemoth of an app and find out what parts are relevant.

FPGA :Researchers Claim 1,000 Core Chip Created

Remember a few months ago when the feasibility was discussed of a thousand core processor? By using FPGAs, Glasgow University researchers have claimed a proof of concept 1,000 core chip that they demonstrated running an MPEG algorithm at a speed of 5Gbps. From one of the researchers, 'This is very early proof-of-concept work where we're trying to demonstrate a convenient way to program FPGAs so that their potential to provide very fast processing power could be used much more widely in future computing and electronics. While many existing technologies currently make use of FPGAs, including plasma and LCD televisions and computer network routers, their use in standard desk-top computers is limited. However, we are already seeing some microchips which combine traditional CPUs with FPGA chips being announced by developers, including Intel and ARM. I believe these kinds of processors will only become more common and help to speed up computers even further over the next few years.

The guy behind IMDb

The founder of one of the most successful websites in the world
has been unveiled as a self-confessed technology geek who still runs
the website from his former family home in Bristol.

A chance e-mail encounter in 1989 with a film fan in California prompted Mr Needham to publish his own personal database online.
The list was published once a month and fellow fans could log on and download it to their own computers. The first set of software was published in October 1990 and IMDb was born.

Led Cube of 512 LEDs

The led cube 8x8x8 at first glance this project might seem like an overly complex and daunting task. However, we are dealing with digital electronics here, so everything is either on or off!