Rewriting a Python application to Haskell
Hello, The company I work for [1] develops highly sensitive trace gas detectors. We also develop software that is used to control these detectors from a PC or laptop. With this software a user can setup an experiment, execute it and analyse and visualise the data in real-time. While executing, the application gives commands to the detector and gets concentrations from the detector which it plots. See [5] for a screenshot. The application is written in Python and uses wxPython for its GUI. The software is highly threaded; The experiment executor, the analyzer, the communication system and the GUI all have their own threads. In order to synchronise these threads we make extensive use of locks [2]. This thread synchronisation mechanism worked fine in the beginning. However, as the application becomes more complex, it is increasingly difficult not to introduce bugs that are caused by forgetting to release or acquire locks. Also the use of locks makes the code hard to understand. Finally it's hard to compose functions that use locks. I've long been interested in Haskell and played around with it for some time. Recently I became aware of the Haskell STM implementation [3]. I think STM can solve my thread synchronisation problems. Because of this and because I would like to know how suitable Haskell is for developing real-world GUI applications, I would like to rewrite our application in Haskell (in my free time of course ;-) ). I think I need to use wxHaskell for the GUI because it's runs on a lot of platforms and we are currently using wxPython which should make the transition easier. 1) I would like to know if its difficult to use wxHaskell and STM side by side and if there are any issues I need to know about. 2) Also, we use pySerial [4] for serial communication with the detector. Is there something like that for Haskell or is it easy to make it yourself? 3) How portable is Haskell? We like to run our application on Mac, Windows and Linux. Greetings, Bas van Dijk [1] http://www.sensor-sense.nl [2] http://docs.python.org/lib/lock-objects.html [3] http://haskell.org/ghc/docs/latest/html/libraries/stm/Control-Concurrent-STM... [4] http://pyserial.sourceforge.net [5] http://members.home.nl/basvandijk/vc-screenshot.png
Hi
1) I would like to know if its difficult to use wxHaskell and STM side by side and if there are any issues I need to know about.
I have no idea about wxHaskell and STM, but I found out that hard way that Gtk2Hs + threads = bad idea. Depending on the machine I used, I got a wide class of unrepeatable behaviour, and (really) poor performance. You might find wxHaskell doesn't suffer from these problems, but I don't know.
3) How portable is Haskell? We like to run our application on Mac, Windows and Linux. The Haskell compiler (GHC) is very portable, and runs on Mac/Windows and most common Linux architectures. wxHaskell does those 3 platforms as well. Haskell tends to be very portable. Some of the more advanced features on some of the less common platforms are sometimes a bit buggy or untested - but usually there are people who are willing to work and fix any issues you run into.
Thanks, and good luck Neil
Hello Neil, Friday, September 1, 2006, 6:47:12 PM, you wrote:
I have no idea about wxHaskell and STM, but I found out that hard way that Gtk2Hs + threads = bad idea.
Duncan Coutts, gtk2hs author, writes the same and proposed solution - use dedicated thread to execute all graphics commands and send these commands to the thread using Chan. it's just several lines of code: c <- newChan forkOS (graphicsThread c) writeChan c (drawCircle ...) graphicsThread c = forever $ do cmd <- readChan c cmd Just mention that forkOS, but not forkIO, should be used. one my friend tried this setting and it worked fine -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On Sat, 2006-09-02 at 11:00 +0400, Bulat Ziganshin wrote:
Hello Neil,
Friday, September 1, 2006, 6:47:12 PM, you wrote:
I have no idea about wxHaskell and STM, but I found out that hard way that Gtk2Hs + threads = bad idea.
No, no, Gtk2Hs + threads = great idea :-) It's just that currently we can't fully follow through on the promise. There are some tricky problems.
Duncan Coutts, gtk2hs author, writes the same and proposed solution - use dedicated thread to execute all graphics commands and send these commands to the thread using Chan. it's just several lines of code:
I mentioned this thread + channel technique as a way of taking advantage of threads to avoid having lots of IORefs, not as a way to avoid threading problems.
Just mention that forkOS, but not forkIO, should be used. one my friend tried this setting and it worked fine
On the contrary, using forkOS and the threaded rts is highly likely to break your GUI program at the moment because there is now way to ensure that all the GUI operations are done on the right OS thread. The way to make it work is to use the single threaded rts and read the FAQ on the issue. The issue that Neil ran into is specific to windows. I've used threads in other Gtk2Hs progs quite happily. On windows there's something odd going on with the RTS scheduler that we couldn't quite pin down. Duncan
Hello basvandijk, Friday, September 1, 2006, 6:38:43 PM, you wrote:
2) Also, we use pySerial [4] for serial communication with the detector. Is there something like that for Haskell or is it easy to make it yourself?
i never hear about such library for Haskell. you can use ffipkg utility (http://haskell.org/haskellwiki/FFI_imports_packaging_utility) to easily generate binding to appropriate C library. then, my Streams library can be used on top of this: http://haskell.org/haskellwiki/Library/Streams http://haskell.org/haskellwiki/Library/AltBinary -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
participants (4)
-
basvandijk＠home.nl -
Bulat Ziganshin -
Duncan Coutts -
Neil Mitchell