Very good ones. My taste.
25 September 2011
04 September 2011
04 June 2011
linux drop cache
Thing that is rarely used but very useful when needed. How do drop cache's in Linux:
free pagecache
echo 1 > /proc/sys/vm/drop_caches
free dentries and inodes
echo 2 > /proc/sys/vm/drop_caches
pagecache, dentries and inodes
echo 3 > /proc/sys/vm/drop_caches
free pagecache
echo 1 > /proc/sys/vm/drop_caches
free dentries and inodes
echo 2 > /proc/sys/vm/drop_caches
pagecache, dentries and inodes
echo 3 > /proc/sys/vm/drop_caches
26 May 2011
22 May 2011
How to unpack rpm
I rarely use this one but it's handy sometimes:
(taken from this blog)
edit:
sometimes it doesn't work because of this:
but it seems that cpio is broken and it can be fixed with:
(taken from another blog)
rpm2cpio rpmname.rpm | cpio -idv
(taken from this blog)
edit:
sometimes it doesn't work because of this:
cpio: Malformed number
but it seems that cpio is broken and it can be fixed with:
rpm2cpio rpmnamerpm | lzma -d | cpio -id
(taken from another blog)
28 January 2011
GPU-GEMS
GPU GEMS has arrived! It contains chapter of mine (as a co-author) about fact Smith-Waterman algorithm implementation on NVIDIA GPUs. I host code of it on http://code.google.com/p/sw-gpu/.
18 October 2010
How I Learned To Stop Worrying And Love The Setuptools
This is mainly note for myself if I ever forgot how to use it.
For most of the time my projects lived each in it's own directory and I resolved importing issues with sys.path manipulation. That works for low number of simple programs/libraries. Using distribute (setuptools) seems to be a natural step forward.
I'd like to stay with this approach (no setuptools) for a little bit longer because I'm easily distracted and I need to get used to setuptools boilerplate ;)
Steps to make life less painful (use setuptools) and to preserve old ways:
Step 1. install virtualenv
Step 2. virtualenv $SOME_PATH_TO_NEW_ENVIRONMENT
Step 3. source $SOME_PATH_TO_NEW_ENVIRONMENT/bin/activate
Then we've got cloned python installation that will work with python setup.py install or whatever. But we're only halfway done and need to setup our package.
Step 1. mkdir $PACKAGE_INSTALLER
Step 2. cd $PACKAGE_INSTALLER
Step 3. ln -s $REAL_PACKAGE_DIR .
Step 4. write setup.py as advertised in documentation
Thats all. I can hide package installers so I don't get distracted but still I get all power of setuptools.
edit:
Main benefit is that when using setup.py develop I can edit my package as always in $REAL_PACKAGE_DIR.
For most of the time my projects lived each in it's own directory and I resolved importing issues with sys.path manipulation. That works for low number of simple programs/libraries. Using distribute (setuptools) seems to be a natural step forward.
I'd like to stay with this approach (no setuptools) for a little bit longer because I'm easily distracted and I need to get used to setuptools boilerplate ;)
Steps to make life less painful (use setuptools) and to preserve old ways:
Step 1. install virtualenv
Step 2. virtualenv $SOME_PATH_TO_NEW_ENVIRONMENT
Step 3. source $SOME_PATH_TO_NEW_ENVIRONMENT/bin/activate
Then we've got cloned python installation that will work with python setup.py install or whatever. But we're only halfway done and need to setup our package.
Step 1. mkdir $PACKAGE_INSTALLER
Step 2. cd $PACKAGE_INSTALLER
Step 3. ln -s $REAL_PACKAGE_DIR .
Step 4. write setup.py as advertised in documentation
Thats all. I can hide package installers so I don't get distracted but still I get all power of setuptools.
edit:
Main benefit is that when using setup.py develop I can edit my package as always in $REAL_PACKAGE_DIR.
Subscribe to:
Posts (Atom)