local open source contest

This project is officially winner of the "Concurso universitario de software libre de Granada" (something like college open source software contest of Granada)

To celebrate it, we've made a little video showing the design process

Empathy project from fabian seoane on Vimeo.

And yes, I promise that I'll put this app online soon.

Design love and formula output

Today has been a day for doing some design tweaks with my partner Angel Soler, just to give empathy a more dynamic look:



It's been also very interesting discussing with Ondrej and other members of the SymPy community the best way to output formulas. Proposed solutions so far are:

1. jsMath: this uses sympy's latex output and transforms it using javascript into something the browser can read (mathml or images, depending on the browser). Disadvantages: you have to load an entire javascript library, which takes quite a lot of time, and CPU goes up to 90% during 5 seconds.
2. MathML: sympy supports mathml output natively and mathml is a universal language for displaying formulas. This would be the ideal solution, if it wasn't because of ... 1. Sympy outputs "Content" MathML, whereas firefox (and other browsers) knows only how to display another variant of MathML, "Presentation" MathML. You can transform Content MathML to Presentation MathML (and sympy knows how to do it), but it is an expensive opperation (maybe too expensive to be done on every request), and 2: MathML support in browsers is partial. To view MathML in IE you have to install a plugin (MathPlayer) which, by the way is not open source.
   
3. Image. This would be a nice solution, and is the one chosen by wolfram's integrator as the main output. Sympy's png printer is a bit slow, since it does the following: expression -> latex -> dvi -> png.
   
4. ASCII (pretty). This is the easiest solution. It renders ok (although i'm having some issues with wrapping), but is not as pretty as the image output.
   

Empathy, first application using django-sympy

Today I committed the first web app that uses sympy-django. My friend Angel Soler did the design and called it Empathy, and it is supposed to be something similar to Wolfram's Integrator , but much more capable (not only integrals, but potentially any method implemented in SymPy In the following days I will finish the app and hopefully it will soon be working at http://empathy.sympy.org.



As you can see, it has some nice Ajax-autocompleters (done with prototype and script.aculo.us). A lot remains still to be done, for example, export the formulas to png would be nice (SymPy already has this feature, only that it exports LaTeX to dvi and then uses dvi2png, which is too slow for this app ...), right now I am trying with PlasTeX



By the way, the app is also free source, you can check the code in the empathy/ directory

killing python threads, part II

Today I found a (nicer) way of killing python threads

  def alarm(secs):
      def wait(secs):
          for n in xrange(timeout_secs):
              time.sleep(1)
              if signal_finished: break
          else:
              thread.interrupt_main()
      thread.start_new_thread(wait, (secs,))

  try:
      alarm(timeout_secs)
      exec code in context
      signal_finished = True
  except KeyboardInterrupt:
      raise SafeEvalTimeoutException(timeout_secs)

This is taken from http://code.activestate.com/recipes/496746/, and it is nice because it uses that thread.interrupt_main() raises a KeyboardInterrupt to stop the main thread.

Related to the previous article, I think that this way is cleaner (it does not use undocumented functions like ctypes.pythonapi.PyThreadState_SetAsyncExc). On the other side it only can kill other than the main thread (so this post should have been called "killing python evaluation"), but for now this is enough for me.

Kill python threads

To ensure that a user does not make an arbitrary complex request (like those that can hang your server, like sympy.factorint(345234523452353453*234423545244534535)), my solution was to implement threads that would be killed if they had not finished before a specified time.

But there is a problem ... python threads can not be killed!

This turns out to be a long-lived discussion on the python community: http://bugs.python.org/issue221115

Fortunately I found a piece of code ( http://code.activestate.com/recipes/496960/ )that implement a .terminate() method for threads. Great!

New repository location

I am proud to announce that the Git repo has moved to sympy's official repo, so you can check out the sources of this project by:

git clone git://git.sympy.org/django-sympy.git

svn repo is still available as ususal:

svn checkout https://forja.rediris.es/svn/cusl3-dsympy

First test running

Today I managed to get some useful code running:

import os
os.environ["DJANGO_SETTINGS_MODULE"] = "test_app.settings"

from django.test.client import Client
from django.utils import simplejson as json


data = {
"method" : "solve",
"params" : ["2 x + 1", "x"],
"id" : "null"
}
req = json.dumps(data)
c = Client()
response = c.post('/dsympy/jsonrpc/', data=req, content_type="text/json")
output = json.loads(response.content)
assert output['result'] == u'[-1/2]'
assert output['error'] == u'null'

As you can see, this takes some json data, makes a request and returns the result. It is not very complicated, but you can see how powerful this can become once we expose more methods to this json-rpc interface.

Full source code for this is available under directory test/