Links to Free Icons for Desktop and Web Applications

I'm always on the search for free icons for my software applications. Here are some icon web sites originally compiled by [1].

* Gallery and search:

• IconArchive
• Free Icons Web
• IconsPedia

* Icon search engines:

• Very Icon
• Icon Seeker
• Iconfinder

* Galleries:

• Icon Easy
• Icon Fever
• Iconza
• 365icon

And here are some icon sets I like and have liberal licenses (compiled from [2]).

* These are particularly good for standard sized buttons and toolbars on traditional desktop applications.

• FamFamFam Mini Icons My personal favourite; been using for years. Thanks so much!.
• Brand Spanking New Mini Icons
• Farm-Fresh Web Icons
• Led Icon Set
• Web Development Icons

* A little more exotic, and perhaps more suitable for web pages or desktop applications with large buttons.

• Function Free Icon Set
• Quartz
• WooFunction
• Milky

References

[1] Steven Snell, 11 Great Resources to Find Free Icons, Jan 31, 2010, http://designm.ag/resources/find-icons/

[2] Steven Snell, 35 of the Best Icon Sets for Web Designers, Dec 28, 2009, http://designm.ag/resources/icons-for-web-designers/

Ignore Warnings Emitted from Python

Launch python with the -W arguments.

python -W arg, where arg is action:message:category:module:lineno

This assumes python is on your path. If not, a full path is required, such as

C:\Python26\python -W arg

and on linux

#!/usr/bin/env python -W arg
Example for
#!/usr/bin/env python -W ignore::DeprecationWarning  name_of_script.py
#!/usr/bin/env python -W ignore::DeprecationWarning
 
C|> python -?
usage: python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options and arguments (and corresponding environment variables):
-B     : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d     : debug output from parser; also PYTHONDEBUG=x
-E     : ignore PYTHON* environment variables (such as PYTHONPATH)
-h     : print this help message and exit (also --help)
-i     : inspect interactively after running script; forces a prompt even
         if stdin does not appear to be a terminal; also PYTHONINSPECT=x
-m mod : run library module as a script (terminates option list)
-O     : optimize generated bytecode slightly; also PYTHONOPTIMIZE=x
-OO    : remove doc-strings in addition to the -O optimizations
-Q arg : division options: -Qold (default), -Qwarn, -Qwarnall, -Qnew
-s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-tt: issue errors)
-u     : unbuffered binary stdout and stderr; also PYTHONUNBUFFERED=x
         see man page for details on internal buffering relating to '-u'
-v     : verbose (trace import statements); also PYTHONVERBOSE=x
         can be supplied multiple times to increase verbosity
-V     : print the Python version number and exit (also --version)
-W arg : warning control; arg is action:message:category:module:lineno
-x     : skip first line of source, allowing use of non-Unix forms of #!cmd
-3     : warn about Python 3.x incompatibilities that 2to3 cannot trivially fix
file   : program read from script file
-      : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]

Other environment variables:
PYTHONSTARTUP: file executed on interactive startup (no default)
PYTHONPATH   : ';'-separated list of directories prefixed to the
               default module search path.  The result is sys.path.
PYTHONHOME   : alternate <prefix> directory (or <prefix>;<exec_prefix>).
               The default module search path uses <prefix>\lib.
PYTHONCASEOK : ignore case in 'import' statements (Windows).
PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.

Invalid File Name Characters (Windows, Linux)

On Windows, NTFS the following characters are not permitted [Filename, Microsoft KB 177506]:

* : < > ? \ / " |

Useful to also avoid:

[ ] = + , . : ;

From File Naming Conventions in Linux:

File names in Linux can contain any characters other than (1) a forward slash ( / ), which is reserved for use as the name of the root directory (i.e., the directory that contains all other directories and files) and as a directory separator, and (2) the null character (which is used to terminate segments of text). Spaces are permitted, although they are best avoided because they can be incompatible with legacy software in some cases.

Building a Windows Installer (wininst) for Django

The Django website does not have a Windows installer for Django (at least not for version 1.1). However, you can easily build an installer yourself.

Download django.<version>.tar.gz. Unpack (e.g. using 7-Zip), and run the following command in the directory where setup.py is located (the root of the unpacked project), say Django1.1.1.

python setup.py bdist --format=wininst

This will create the installer Django-<version>.win32.exe the dist directory.

Running Python's Distutil Created Wininst Installers (.exe) from the Commmand Line

I recently created an installer with Inno Setup that was used to launch a bunch of other installers. As such, I needed to, more or less, run those sub-installers from the command line during install and uninstall. The sub-installers were executables generated by Python's distutils using the wininst bdist command (i.e. "wininst" installers for Windows).

Given the wininst installer mypymodule.1.2.exe, to install, execute the command mypymodule.1.2.exe. This places the files Removemypymodule.exe and wininst-mypymodule.log in the root directory of the Python installation. To uninstall execute the command path/to/python/root/Removemypymodule.exe -u path/to/python/root/wininst-mypymodule.log.

Updating Subversion's (SVN's) Repository Version

Sometimes it's necessary to manually upgrade Subversion's repository after upgrading Subversion (SVN) itself, such as to take advantage of a new feature. For example, I recently upgraded Subversion from 1.4 to 1.5, but did not upgrade my repository. This worked fine until I (inadvertently) tried to use a 1.5 feature. Using TortoiseSVN, I tried to merge a branch into the trunk using the 1.5 "merge tracking" feature, but because of the older repository version, I got an error something like "Error: Retrieval of mergeinfo unsupported by 'http://svnserver/myrepo'". Following are the steps I used to upgrade my repository.

• Check the Subversion server software version:
  • Logon to the computer on which the repository server software is running. From the command line, execute svnadmin --version to get the server software version.
  • Execute svn --version to check the client software.
• The server software version may be different from the repository version. To check the actual repository (layout) version number:
  • Navigate to <repository_dir>/db and open the file format. For SVN 1.5 compatibility, it should read something like:

      3
      layout shared 1000
    

    The key number here is 3. For SVN 1.4, this number is 2 and for SVN 1.6, 4.

• To upgrade the repository, the server command svnadmin upgrade <repos_dir> is often sufficient (as is the case going from SVN 1.4 to 1.5). Here's the help documentation for this command:

    Upgrade the repository located at REPOS_PATH to the latest supported
    schema version.
  
    This functionality is provided as a convenience for repository
    administrators who wish to make use of new Subversion functionality
    without having to undertake a potentially costly full repository dump
    and load operation.  As such, the upgrade performs only the minimum
    amount of work needed to accomplish this while still maintaining the
    integrity of the repository.  It does not guarantee the most optimized
    repository state as a dump and subsequent load would.
  
  

• Depending on which user did the update, it might be necessary to update the owner of the repository files. On Ubuntu Linux I had to issue the command sudo chmod -R www-data myrepo to change the owner of files from root back to www-data (the Apache user). Otherwise, trying to commit (remotely) to the repository will result in an error something like Can't open file '/path/to/repo/db/txn-current-lock': Permission denied

  Here's what others recommend:

  # chown -R www-data:www-data /var/svn/*
  # chmod -R 770 /var/svn/*
  
  assume that /var/svn/ is where are all your repositories
  

  (from svnform) and:

  $ sudo chown -R www-data:subversion myproject
  $ sudo chmod -R g+rws myproject
  

  (from ubuntu help).

The "LdrpWalkImportDescriptor() failed to probe XXX.dll for its manifest, ntstatus 0xc0150002" Error and Manifiests

I got this error the other day:

error: LDR: LdrpWalkImportDescriptor() failed to probe QtCored4.dll for its manifest, ntstatus 0xc0150002

I did some googling, and here's what I found out:

• The error may be a red herring, it's really a SideBySide DLL error. Look in the Event Viewer (see Control Panel, Administrative Tools) for the real error [Mombu, MSDN Social]. It turned out the Microsoft.VC80.DebugCRT DLL could not be found.
• Usually occurs because of missing DLLs, or DLLs with the incorrect version number (as specified in the DLL's manifest) on the deployment machine.
• Solutions:


• Recompile the offending DLL(s) [Nabble, Bytes]
• Recompile the offending DLL(s), but make sure the DLL project is configured to embed the manifest in the DLL. Have a look at the "dependentAssembly" tag in the generated YourDLLName.intermediate.manifest file. It must be the same as the "dependentAssembly" version in the manifest file generated for your EXE project. Make sure the same service packs are installed (i.e. same msvc) on the machine that built the DLL and the one that built the EXE [Trolltech Lists]
• Recompile the offending DLL(s), or download and install MSVC Redist SP1 [OpenCV Wiki]
  


• FAQ on manifests [CodeGuru]

Here's what worked for me: I checked the manifest file in the DLL that caused the error -- QtCore4d.dll in this example -- and noticed it required the Microsoft.VC80.DebugCRT DLL of a certain version. A colleague of mine compiled the DLL, so I had easy access to the manifest since an "intermediate" copy is stored in the DLL project's build directory. If that wasn't the case, I could use mt.exe from Microsoft to extract it from the DLL. I then inspected the manifest generated by Visual Studio when I compiled my EXE project. It turned out my EXE manifest required a version of the Microsoft.VC80.DebugCRT DLL that was older than that required by the QtCore4d.dll DLL, which means my machine had older DLLs than that required by QtCored4.dll. I simply applied a few Microsoft Visual Studio updates, recompiled my EXE project (not the DLL project), and the newly generated manifest showed the dependent DLL (Microsoft.VC80.DebugCRT) version to be the same as that in the QtCored4.dll manifest. Everything worked fine afterwards.