gnumed-bugs
[Top][All Lists]
Advanced

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

Re: [Gnumed-bugs] Allergies plugin breaks Workplace


From: Karsten Hilbert
Subject: Re: [Gnumed-bugs] Allergies plugin breaks Workplace
Date: Sun, 12 Jul 2009 19:30:11 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Jul 11, 2009 at 07:17:54PM -0700, Jim Busser wrote:

>> Hi, I added to my workplace list the Allergies plugin and, on trying to 
>> start the client, it cannot progress past loadin because of what shows 
>> in the terminal as:
>>
>> ./gm-from-cvs.sh: line 30:  3251 Segmentation fault      python  
>> wxpython/gnumed.py --log-file=$LOG --conf-file=gm-from-cvs.conf -- 
>> override-schema-check --debug --local-import $@
>
>> Therefore wondering... if Allergies was deprecated, shall it be  
>> removed from the options if it will only break things?

It is only an option if it is there. The tarballs creation
script explicitely removes it. How did you manage to select
it for the workplace ?

>> The problem now 
>> is that with this coded in the database, it requires a workaround to 
>> fix (login using other workplace as manageable thtough a config file, 
>> and then deselect in the GNUmed default workplace).

Well, errors we *can* do something about are handled - such
plugins will simply not load. Errors we cannot do anything
about (because they happen below the Python layer) we cannot
do anything about.

> Actually I seem trapped *out* of my v11 database, since despite that I 
> logged in (using my client 0.4.6) to v10, and noted several of the  
> workplace names, and tried them each in
>
>       gnumed-from-cvs.conf
>
> called from
>
>       gnumed-from-cvs.sh --conf-file=gnumed-from-cvs.conf
>
> but even despite that I tried under [workplace]
>
>       name = Librarian Release (0.2)
>
> I could not get past the segmentation fault. Ideas?

That seems to prove that the allergies plugin doesn't even
specifically provoke the fault. It's nothing GNUmed can do
anything about. The underlying libraries are broken
somewhere.

> Do we wish / need "GNUmed default" to be non-modifiable?

We wish, and we recommend against using it in production,
perhaps needing more prominence.

> Better yet, I am 
> thinking... should the workplace be nested inside some deeper loop of 
> code so that if there is a problem, users are not totally locked out of 
> instantiating GNUmed and getting up the GUI where, if this were made 
> possible, they could at least try and re-set some problematic plugin?

Plugins don't load if they fail in a way we can do anything about.

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]