Python reliability
I would need to make some high-reliability software running on Linux in an embedded system. Performance (or lack of it) is not an issue, reliability is. The piece of software is rather simple, probably a few hundred lines of code in Python. There is a need to interact with network using the socket module, and then probably a need to do something hardware- related which will get its own driver written in C. Threading and other more error-prone techniques can be left aside, everything can run in one thread with a poll loop. The software should be running continously for practically forever (at least a year without a reboot). Is the Python interpreter (on Linux) stable and leak-free enough to achieve this? - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
wxPython in a PDA
Does anyone know of an inexpensive PDA which would run wxPython? The availability of a conventional (wired) Ethernet would be nice, as well (e.g., using a CF adapter). TIA, - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > I would say give the app the heaviest stress testing that you can > before deploying it, checking carefully for leaks and crashes. I'd > say that regardless of the implementation language. Goes without saying. But I would like to be confident (or as confident as possible) that all bugs are mine. If I use plain C, I think this is the case. Of course, bad memory management in the underlying platform will wreak havoc. I am planning to use Linux 2.4.somethingnew as the OS kernel, and there I have not experienced too many problems before. Adding the Python interpreter adds one layer on uncertainty. On the other hand, I am after the simplicity of programming offered by Python. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Steven D'Aprano wrote: > If performance is really not such an issue, would it really matter if you > periodically restarted Python? Starting Python takes a tiny amount of time: Uhhh. Sounds like playing with Microsoft :) I know of a mission- critical system which was restarted every week due to some memory leaks. If it wasn't, it crashed after two weeks. Guess which platform... > $ time python -c pass > real0m0.164s > user0m0.021s > sys 0m0.015s This is on the limit of being acceptable. I'd say that a one-second time lag is the maximum. The system is a safety system after all, and there will be a hardware watchdog to take care of odd crashes. The software itself is stateless in the sense that its previous state does not affect the next round. Basically, it is just checking a few numbers over the network. Even the network connection is stateless (single UDP packet pairs) to avoid TCP problems with partial closings, etc. There are a gazillion things which may go wrong. A stray cosmic ray may change the state of one bit in the wrong place of memory, and that's it, etc. So, the system has to be able to recover from pretty much everything. I will in any case build an independent process which probes the state of the main process. However, I hope it is never really needed. > I'm not saying that you will need to restart Python once an hour, or even > once a month. But if you did, would it matter? What's more important is > the state of the operating system. (I'm assuming that, with a year uptime > the requirements, you aren't even thinking of WinCE.) Not even in my worst nightmares! The platform will be an embedded Linux computer running 2.4.somethingnew. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Steven D'Aprano wrote: > If you have enough hardware grunt, you could think > about having three independent processes working in > parallel. They vote on their output, and best out of > three gets reported back to the user. In other words, > only if all three results are different does the device > throw its hands up in the air and say "I don't know!" Ok, I will give you a bit more information, so that the situation is a bit clearer. (Sorry, I cannot tell you the exact application.) The system is a safety system which supervises several independent measurements (two or more). The measurements are carried out by independent measurement instruments which have their independent power supplies, etc. The application communicates with the independent measurement instruments thrgough the network. Each instrument is queried its measurement results and status information regularly. If the results given by different instruments differ more than a given amount, then an alarm is set (relay contacts opened). Naturally, in case of equipment malfunction, the alarm is set. This covers a wide range of problems from errors reported by the instrument to physical failures or program bugs. The system has several weak spots. However, the basic principle is simple: if anything goes wrong, start yelling. A false alarm is costly, but not giving the alarm when required is downright impossible. I am not building a redundant system with independent instruments voting. At this point I am trying to minimize the false alarms. This is why I want to know if Python is reliable enough to be used in this application. By the postings I have seen in this thread it seems that the answer is positive. At least if I do not try apply any adventorous programming techniques. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > You might be better off with a 2.6 series kernel. If you use Python > conservatively (be careful with the most advanced features, and don't > stress anything too hard) you should be ok. Python works pretty well > if you use it the way the implementers expected you to. Its > shortcomings are when you try to press it to its limits. Just one thing: how reliable is the garbage collecting system? Should I try to either not produce any garbage or try to clean up manually? > You do want reliable hardware with ECC and all that, maybe with multiple > servers and automatic failover. This site might be of interest: Well... Here the uptime benefit from using several servers is not eceonomically justifiable. I am right now at the phase of trying to minimize the downtime with given hardware resources. This is not flying; downtime does not kill anyone. I just want to avoid choosing tools which belong more to the problem than to the solution set. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Thomas Bartkus wrote: > > All in all, it would seem that the reliability of the Python run time is the > least of your worries. The best multi-tasking operating systems do a good > job of segragating different processes BUT what multitasking operating > system meets the standard you request in that last paragraph? Well, let's put it this way. I have seen many computers running Linux with a high load of this and that (web services, etc.) with uptimes of years. I have not seen any recent Linux crash without faulty hardware or drivers. If using Python does not add significantly to the level of irreliability, then I can use it. If it adds, then I cannot use it. > type of rugged use you are demanding. I would google "embedded systems". > If you want to use Python/Linux, I might suggest you search "Embedded > Linux". I am an embedded system designer by my profession :) Both hardware and software for industrial instruments. Computers are just a side effect of nicer things. But here I am looking into the possibility of making something with embedded PC hardware (industrial PC/104 cards). The name of the game is "as good as possible with the given amount of money". In that respect this is not flying or shooting. If something goes wrong, someone loses a bunch of dollars, not their life. I think that in this game Python might be handy when it comes to maintainability and legibility (vs. C). But choosing a tool which is known to be bad for the task is not a good idea. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python reliability
In article <[EMAIL PROTECTED]>, Peter Hansen wrote: > Other than that, we had no real issues and definitely felt the choice of > Python was completely justified. I have no hesitation recommending it, > other than to caution (as I believe Paul R did) that use of new features > is "dangerous" in that they won't have as wide usage and shouldn't > always be considered "proven" in long-term field use, by definition. Thank you for this information. Of course, we try to be as conservative as possible. The application fortunately allows for this, cyclic references and new features can most probably be avoided. > Also test heavily. We were using test-driven development and had > effectively thousands of hours of run-time by the time the first system > shipped, so we had great confidence in it. Yes, it is usually much nicer to debug the software in the quiet, air-conditioned lab than somewhere in a jungle on the other side of the globe with an extremely angry customer next to you... - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: UI toolkits for Python
In article <[EMAIL PROTECTED]>, Kenneth McDonald wrote: > 4) Ease of installation/use on OS X? There are two questions which may restrict your choice rather a lot: #1 Should the UI look the same on each platform or should it look the same as all other apps on the platform? #2 Are you trying to make a simple installation package which includes everything needed? With OS X compatibility you tend to come across with the fact that many "OS X compatible" things are actually X11 things. X11 certainly looks different from Aqua (the native interface). Also, X11 is not always installed, and some unixish things require using Fink to install them. Not something Joe A. User usually has on his Mac. GTK is an example of this. There is an Aqua version of GTK, but it seems to be rather outdated. The newer versions run on X11 but installing them may be just laborious or then plain pain depending on your luck. And you still need the X11 installed. So, if you are looking for something that looks like Mac and works like Mac, do not touch anything with X11. OTOH, if you just need to get something working on your own OS X computer, then X11 is fine. --- I have tried using wxPython for Mac/Windows cross-platform GUIs. This far it seems to work fine, but I have not tried anything very fancy. Mac applications have the OS X looks, and Windows applications look Windowsish. Without having a single line of platform-dependent code. Making simple installation files (exe for Windows and dmg for OS X) seems to work, as well. So, the installation should be easy for the user. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
wxPython and window sizing
I have a small problem; I would like to have a reasonable minimum size for a wx.Window. A simplified version of my code: s = wx.SplitterWindow(self, -1) curves = wx.Notebook(s) curve = wx.Window(curves, ID_BLANKCURVE, style=wx.SUNKEN_BORDER, size=(300,200)) curves.AddPage(curve, "Blank") textbox = wx.TextCtrl(s, ID_TEXTBOX, style=wx.TE_MULTILINE, size=(-1,50)) s.SetMinimumPaneSize(50) s.SplitHorizontally(curves, textbox) s.SetSashGravity(0.8) Here 'self' is the main window class, i.e. inherited from wx.Frame. What I would like to happen is that both the curve area and the textbox would have an absolute minimum size when moving the sash or resizing the window. How to get this behaviour? I have tried setting the minimum sizes of the curve and the textbox by using the SetMinSize() method, but this does not seem to affect anything. Already when the window is shown the upper pane (i.e. the notebook curves) is smaller than (300,200) set in the code. TIA, - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
Re: wxPython and window sizing
In article <[EMAIL PROTECTED]>, Franz GEIGER wrote: > Couldn't you register for a handler? Oui, mais... I can figure out a few ugly workarounds. However, my question is if there is a nice and clean way to make wxPython set the minimum size. I'd really hate to start calculating the sizes myself or making any extra handlers, if the existing infrastructure can handle what I want. - Ville -- Ville Voipio, Dr.Tech., M.Sc. (EE) -- http://mail.python.org/mailman/listinfo/python-list
