gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Some unhandled exceptions, also console output


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Some unhandled exceptions, also console output
Date: Tue, 29 Jun 2010 10:45:43 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Jun 29, 2010 at 09:30:47AM +0200, Hilbert, Sebastian wrote:

> Am Dienstag 29 Juni 2010, 07:10:48 schrieb Jim Busser:
> > 1) unhandled exceptions
> > 
> > I generated two reports (as jim @ ca) to gnumed-bugs. If those could be
> > consulted, I assume that they reflect excess inactivity,

I would think so. Will try to improve upon the handling thereof.

> Inactivity should not let you connection go away (unless I am wrong).

Tell you what:

        http://www.postgresql.org/community/weeklynews/pwn20100627

This is the PostgreSQL newsletter from *this week*.

Look under "Applied Patches"  ;-)

> > and I just
> > wondered whether such errors (or a subset thereof) -- if identifiable with
> > some confidence --could in future be more cleanly "trapped" and presented
> > to the user as a dialog that says:
> > 
> >     While you were last working on patient <name>, your database connection
> > timed out. This GNUmed session is now expired.
> > 
> There is no such thing as a session unless I am totally mistaken.

Sure, formally there is no session (unless one wants to
define the duration of an encounter as a virtual session -
which can then span several connects to the database).

Nonetheless it is a useful abstraction and users are used to it.

> > 2) Console output.
> > 
> > i) the MimeWriter module notice... is this likely to be Mac specific

No.

> > or upstream?

No.

> > is it anything the end user should try to attend to?

No. Unless they want to upgrade our code no use the email
package instead of the MimeWriter package.

> > ii) DISPATCHER WARNINGS ... do those arise from some default configuration
> > of GNUmed?

One could put it that way, yes. Hardwired, though.

> > Is it intentional that those signals are being looked-for by
> > default?

Yes.

> > iii) Xlib:  extension "RANDR" missing on display
> > "/tmp/launch-nf7uqn/org.x:0".   ... anything to do?
> > 
> It just tells you that from your X11/video driver/BSD-subsystem RANDR is 
> missing which will prevent you from stuff like resizing or ratating your 
> screen from within X11 (you can still do that from MacOS if you want). This 
> is 
> harmless. However your GNUmed runs on GTK on X11. There is also wxpython 
> which 
> uses the Mac user interface like round buttons and blueish tabs in GNUmed.
> 
> It has something to do with the options in MacPort. You could check if 
> wxpyhton in MacPorts lets you select options which lead to the Macish user 
> interface instead of the X11 one.

Before messing/worrying too much with/about this I should
chip in with the fact that it will not gain much. It won't
be possible to somehow "activate" the missing
ResizeAndRotate code in the Mac X server. Simply setting a
Macish theme won't make GNUmed be Macish either (it may look
better, though). There's some special code in wxPython to
make wxPython apps behave more Macish but we are (I am)
quite some way from worrying about that.

> > | Unhandled exception caught !
> > | Type : <class 'psycopg2.InterfaceError'>
> > | Value: connection already closed
> >
> psycopg2 lost connection. Public database ?
> same could happen when PG goes down for maintenance but we have a feature to 
> push a notification to all client if we intend to kill the connection.

Not that I have ever seen anyone duly react to it though <=:-)

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]