And now for something completely different...
Even though it is recommended not to serve static files using Django and one should run a separate lightweight server (such as lighthttpd) for this task, it is not uncommon that website systems written in Django sometimes need to send big files directly. In my case it was to restrict access to PDF files only to specific IP addresses which are stored in the systems database.
The main reason you should not send static files directly from Django - by reading the content of the file and sending it out - is that the whole file would be read into memory before sending it. For larger files - in my case about one to several megabytes - this is very inefficient and could easily choke the system where 90% of the traffic is generated by those bulky PDFs.
My original idea was to serve this data as other static files and use some form of name mangling in order for the user not to be able to guess the right name. However, such security through obscurity just moves the problem somewhere else - once a user obtains the right URL, he is not restricted in any way to use it.
Because of this, I decided that it would be useful to find a way to more effectively serve static files from Django, even if I should write it myself. Fortunately, I did not have to :)
After quick Google search, I found this ticket on Django website. It is an already approved patch that adds the HttpResponseSendFile function which does exactly what I need - very efficiently sends static files using the underlying systems optimized routines.
The patch attached to this ticked applied without problems to my Django 1.0.2 installation and in fifteen minutes was serving my static files to the world :)
I hope this information might get useful to other Django fans who stumble upon a similar problem.
neděle 15. března 2009
čtvrtek 26. února 2009
BKChem enters Trophees du Libre
I am pround to announce that BKChem has entered the competition for important free software awards - Trophees du Libre.
pondělí 23. února 2009
Find 9 differences
Can you find nine differences in the following two pictures?


This is the difference between double bonds for which the second line is drawn using only 2D coordinates of the end atoms and for which the complete 3D geometry is used.
Because chemical drawings, unlike real molecules, are often flat, there was never much need for me to implement the better drawing method, especially when there are always many more important things to do. However this omission cropped up again when I rotated benzene in 3D during testing of new BKChem code that allows 3D rotation of molecular fragment around a particular bond. Because I had this feature on my to-do list for a long time anyway, I finally decided to dust off my basic knowledge of analytic geometry and implement this feature.
You can see the result on the pictures above.
Note: the pictures were created using OASA 0.12.7 and 0.13.0 respectively and a similar code is used in BKChem 0.13.0.


This is the difference between double bonds for which the second line is drawn using only 2D coordinates of the end atoms and for which the complete 3D geometry is used.
Because chemical drawings, unlike real molecules, are often flat, there was never much need for me to implement the better drawing method, especially when there are always many more important things to do. However this omission cropped up again when I rotated benzene in 3D during testing of new BKChem code that allows 3D rotation of molecular fragment around a particular bond. Because I had this feature on my to-do list for a long time anyway, I finally decided to dust off my basic knowledge of analytic geometry and implement this feature.
You can see the result on the pictures above.
Note: the pictures were created using OASA 0.12.7 and 0.13.0 respectively and a similar code is used in BKChem 0.13.0.
pondělí 16. února 2009
How to embed PDF in LaTeX documents
In the previous entry to this blog, I have shown that OASA can create pictures of molecules in PDF. However a picture of a molecule as a separate PDF file is not very useful.
Today, I will show a snippet of LaTeX code that can be used to embed the exported PDF file inside a PDF document produced by
The whole LaTeX source looks like this:
The most important commands are the following two -
After running
Today, I will show a snippet of LaTeX code that can be used to embed the exported PDF file inside a PDF document produced by
pdflatex. (Please note that this post is not intended to be an in-depth tutorial, its main purpose it to inform that the possibility to use PDFs this way even exists.)The whole LaTeX source looks like this:
\documentclass[a4paper,12pt]{article}
\usepackage{graphics}
\usepackage[left=1.5cm,right=2cm,top=2cm]{geometry}
\begin{document}
\begin{center}
\begin{large}Exam - \bf{1A}\end{large}
\end{center}
Write down SMILES for the following molecule:
\includegraphics{test}
Name the following molecule:
\includegraphics{test2}
\end{document}
The most important commands are the following two -
\usepackage{graphics} and \includegraphics{test} (please note that the name of the file to embed is used without the extension .pdf).After running
pdflatex on this code you will get a PDF file with the two images embedded inside (provided the two images exist in the same directory). The result looks like this, you can download the source files of this example here.
pondělí 9. února 2009
PDF and SVG support added to OASA
In the newest versions of OASA, I have added the possibility to create images not only in PNG, but also in SVG and PDF.
This functionality comes for free as a courtesy of the Cairo library and gives the user the possibility to create output much more suitable for printing.
Here is a small example code showing how to create a PDF export:
The output looks like this (of course, this is rendered to PNG, the PDF can be found here):
For SVG, just replace "pdf" with "svg" in the example above.
The cairo_out.mol_to_cairo function has many keyword arguments that allows for changing of almost every aspect of the output. For example, the following adds hydrogen symbols to hetero-atoms and changes the line width for bonds.
The output now looks like this (again in PNG, the SVG can be found here):

One big advantage of the SVG generated by Cairo is that all text is converted to curves. This means that the output will look the same on every machine, regardless of installed fonts.
This functionality comes for free as a courtesy of the Cairo library and gives the user the possibility to create output much more suitable for printing.
Here is a small example code showing how to create a PDF export:
from oasa import smiles, cairo_out
mol = smiles.text_to_mol( "Oc1ccc(N)cc1Cl")
mol.normalize_bond_length( 30)
mol.remove_unimportant_hydrogens()
cairo_out.mol_to_cairo( mol, "example.pdf", format="pdf")
The output looks like this (of course, this is rendered to PNG, the PDF can be found here):
(Because SMILES was used as input, OASA generates the 2D structure for you.)
For SVG, just replace "pdf" with "svg" in the example above.
The cairo_out.mol_to_cairo function has many keyword arguments that allows for changing of almost every aspect of the output. For example, the following adds hydrogen symbols to hetero-atoms and changes the line width for bonds.
cairo_out.mol_to_cairo( mol, "example.svg", format="svg",
show_hydrogens_on_hetero=True,
line_width=2)
The output now looks like this (again in PNG, the SVG can be found here):

One big advantage of the SVG generated by Cairo is that all text is converted to curves. This means that the output will look the same on every machine, regardless of installed fonts.
pátek 30. ledna 2009
Converting old InChI strings to the new standard InChI format
Today I was faced with a task of converting a list of InChI strings in the format used prior to the release of InChI 1.02 final to the new standard format.
Even though it would be a no-brainer to write a small script for OASA to do it, it seemed to me that the InChI software itself should allow something like this.
After some poking around the
This command assumes you have the
The input file
The sequence of commands at first converts the old InChI into the AuxInfo format used by the InChI program, then uses it as input to generate a new standard InChI.
Hopefully someone would find this information useful.
Even though it would be a no-brainer to write a small script for OASA to do it, it seemed to me that the InChI software itself should allow something like this.
After some poking around the
stdinchi-1 help messages, here is my solution:cat test.inchi | stdinchi-1 -STDIO -InChI2Struct 2>/dev/null |(the code was broken into multiple lines to display properly)
grep AuxInfo | stdinchi-1 -STDIO -InpAux 2>/dev/null |
grep InChI=
This command assumes you have the
stdinchi-1 program in your path and that you are using a decent OS, with grep and cat commands available (or at least some approximation like Cygwin).The input file
test.inchi contains a list of InChIs - one per line. The output is in the same format.The sequence of commands at first converts the old InChI into the AuxInfo format used by the InChI program, then uses it as input to generate a new standard InChI.
Hopefully someone would find this information useful.
Přihlásit se k odběru:
Příspěvky (Atom)
