Friday 31 October 2008 at 02:17 am
Ignoring files in subversion during checkout.
You can't directly ignore folders on a checkout, but you can use sparse checkouts in svn 1.5. For example:
$ svn co http://subversion/project/trunk my_checkout --depth immediates
This will check files and directories from your project trunk into 'my_checkout', but not recurse into those directories. Eg:
$ cd my_checkout && ls
bar/ baz foo xyzzy/
Then to get the contents of 'bar' down:
$ cd bar && svn update --set-depth infinity
Sunday 16 March 2008 at 09:40 am
When Rusty was here during FOSS.IN, he mentioned about utilities without which how difficult life would be.
I have been using Mercurial and really love it. It is wonderful. I always thought of spending some time with distcc and see what all it can help.
I am amazed. distcc is exactly what it says. And the setup is so much simple.
I had been fucking my laptop by building KDE4 on it every week. Now I can give her some time to soothe and cool down. She'd gone very hot when building on her ;-)
BTW, KDE4 + distcc doesn't require much effort. Just modify the cmakekde() as mentioned on Techbase and customize it to include CC=distcc CPP=distcc CXX=distcc just before the keyword cmake
Wednesday 28 November 2007 at 3:12 pm
I recently came into the necessity of having something which could load equalizer prests by reading the genre from the current running track.
For Amarok, I couldn't find anything available. So I filed a bug report. But soon realised that my wishlist could be accomplished just bhy a small amount of work.
I then looked at Amarok's scripting framework. It is amazing. It took me just 3 hrs to get my wishlist item done.
And here we have:
autoEqualizer
autoEqualizer is a small application which will auto load equalizer presets based on genre of current running track in Amarok.
Go, get it. Try it.
Friday 10 August 2007 at 04:00 am
So in the search of finding a simple solution for printing colored text in python, it took me some time to dig up. Most solutions people have done were using curses or some modules. My ultimate intention has always been to cut down on the dependency on the 3rd party modules.
I think the ANSI Color Codes would be good enough for my requirements to print colored text on an ANSI compliant terminal.
The ANSI Terminal Specification gives programs the ability to change the text color or background color.
An ansi code begins with the ESC character [^ (ascii 27) followed by a number (or 2 or more separated by a semicolon) and a letter.
In the case of colour codes, the trailing letter is "m"...
So as an example, we have ESC[31m ... this will change the foreground colour to red.
The codes are as follows:
For Foreground Colors
1m - Hicolour (bold) mode
4m - Underline (doesn't seem to work)
5m - BLINK!!
8m - Hidden (same colour as bg)
30m - Black
31m - Red
32m - Green
33m - Yellow
34m - Blue
35m - Magenta
36m - Cyan
37m - White
For Background Colors
40m - Change Background to Black
41m - Red
42m - Green
43m - Yellow
44m - Blue
45m - Magenta
46m - Cyan
47m - White
7m - Change to Black text on a White bg
0m - Turn off all attributes.
Now for example, say I wanted blinking, yellow text on a magenta background... I'd type ESC[45;33;5m
This isn't a complete list of features provided by the ANSI Codes. There are many more....
Sunday 01 July 2007 at 3:17 pm
Does anyone know when really did coreutils get patched for this behavior ?
rrs@learner:~$ rm -foo
rm: invalid option -- o
Try `rm ./-foo' to remove the file `-foo'.
Try `rm --help' for more information.
This feature really wasn't earlier and if you ever ended up with files starting with characters like "-", it was not a straight task to remove it.
Earlier (when I wasn't aware of this patch), the workaround was to write a small 1 liner and not use getopt at all. Something like:
rrs@learner:~$ cat rm.py
#!/usr/bin/env python
import os, sys
sys.stdout.write("Removing file %s.\n" % (sys.argv[1]) )
os.unlink(sys.argv[1])
I'm really happy to see this bug fixed.
Saturday 17 March 2007 at 01:48 am
For those who are stuck up with using Kontact with an Exchange server should have experiences of how difficult it is to get everything properly working.
For instance, address book is an issue. Assuming that your exchange server holds more that 10,000 user records, it is going to be a challenging task to get your addressbook configurd to fetch those addresses.
A friend of mine figured out that this was rather a bug with either ldap or exchange (in that case a feature) which restricted the query response to 1000 replies. This bug is inherited in the ldap code of K Address Book also because it silently fetches 1000 records only.
Here's a workaround for this issue.
Read More
Tuesday 17 October 2006 at 8:12 pm
If you are a person like me who likes to read books in html format, you sure would have lot of soft books. These books occupy a lot of diskspace because they are small files and just text. Apache's transparent decompression (mod_deflate) is a good solution to read these books while keeping them compressed.
Hence this small utility which'll gunzip/gzip all your html/text files on all Python supported platforms. Hope you find it useful.
Note: There is a small bug in this script where giving a . as the path ends up in some error. I haven't tried looking much into it. Hence please give absolute path when using it. Eg: /tmp, C:\books et cetera.
#!/usr/bin/env python
import os, sys, gzip, string, tempfile
class ZipManipulator:
"""This class does the work of manipulating gz files.
Pass the repository as an argument during instantiation."""
def __init__(self, input):
self.repository = input
def files(self, root):
for path, folders, files in os.walk(root):
for file in files:
yield path, file
def starter(self, filetype, work_type):
'''Does the gzipping or gunzipping of given files.
work_type -> 0 is for gzip
work_type -> 1 is for gunzip
fileype -> is the type of file. Eg: html, txt, html.gz, txt.gz, HTML.gz et cetera'''
for path, file in self.files(self.repository):
#for path, file in files(repository):
if file.endswith(filetype):
if work_type == 0:
os.chdir(os.path.realpath(path))
ZipManipulator.gzip(self, file)
elif work_type == 1:
os.chdir(os.path.realpath(path))
ZipManipulator.gunzip(self, file)
else:
sys.stdout.write("Incorrect work type passed.\n")
def gzip(self, file):
'''Gzip the given file and then remove the file.'''
r_file = open(file, 'r')
w_file = gzip.GzipFile(file + '.gz', 'w', 9)
w_file.write(r_file.read())
w_file.flush()
w_file.close()
r_file.close()
os.unlink(file) #We don't need the file now
sys.stdout.write("%s gzipped.\n" % (file))
def gunzip(self, file):
'''Gunzip the given file and then remove the file.'''
r_file = gzip.GzipFile(file, 'r')
write_file = string.rstrip(file, '.gz')
w_file = open(write_file, 'w')
w_file.write(r_file.read())
w_file.close()
r_file.close()
os.unlink(file) # Yes this one too.
sys.stdout.write("%s gunzipped.\n" % (file))
def main():
repository = raw_input("Enter the repository path: ")
if repository == "":
repository = os.curdir
filetype = raw_input("Enter the filetype: ")
zip_type = int(raw_input("Enter 0 for gzip and 1 for gunzip: "))
instance = ZipManipulator(repository)
instance.starter(filetype, zip_type)
if __name__ == '__main__':
main()
You can download the script here. gz-1.py
Sunday 09 July 2006 at 4:19 pm
I'm happy that a new release has been possible.
This new release is almost a complete re-write and has many fixes and features.
For details, visit:
http://pypt-offline.sf.net
There's also a small HOWTO about pypt-offline
Cheers!
Ritesh
Read More
Tuesday 13 June 2006 at 10:31 am
Abnormal Program Termination are not something just seen on Microsoft Windows. I hope most users will have seen some kind of program error in GNU/Linux and *BSD platforms also.
Abnormal Program Termination can happen for multiple reasons of which Programming Errors are one of the major reasons. Badly Carelessly written programs often end up having such bugs.
Here's a sample C program which has generic programming errors because of which the compiler doesn't catch it but the program does do unexpected behavior.
#include <stdio.h>
#include <unistd.h>
int divide (int x, int y);
int main(void)
{
int x, y = 0;
printf ("Enter divident:\n");
scanf ("%d", &x);
printf ("Enter divisor:\n");
scanf ("%d", &y);
printf("The result is %d\n", divide(x, y));
return 0;
}
int divide (int x, int y)
{
return x / y;
}
The problem with the above mentioned code is that it has no checkings for the integers. This program will give an Arithmetic Division By Zero Error. Upon execution of such programs, most Unixes during termination of the program dump the core.
A core dump is noting but the state of the memory when the abnormal behavior occured. This comes out to be very handly to debug nasty bugs which creep away from the compiler.
Assuming you execute this program and get the core dump, you can easily debug and find the bug with gdb.
rrs@learner:~ $ gdb test coreGNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Core was generated by `./test'.
Program terminated with signal 8, Arithmetic exception.
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libc.so.6...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0 0x08048463 in divide (x=9, y=0) at test.c:22
22 return x / y;
(gdb)
If you look at the output of gdb you can clearly see what kind of error led to the unexpected behavior.
(gdb) bt
#0 0x08048463 in divide (x=9, y=0) at test.c:22
#1 0x08048437 in main () at test.c:16
You can do a backtrace and figure out the complete flow of the program andd see where exactly the error occured.
In this case the bug is in the divide() where y is passed the value 0 which has led to an Arithmetic Exception.
Analyzing core dumps is very helpful and fun while debugging applications. :-)
HTH,
Ritesh Raj Sarraf
Friday 19 May 2006 at 6:11 pm
I always keep forgetting where the colon (;) key should be placed in a Bash endless loop so thought of jotting it down.
while true; do ls; done
