[Top][All Lists]

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

Re: [Gnumed-bugs] Allergies plugin breaks Workplace

From: Jim Busser
Subject: Re: [Gnumed-bugs] Allergies plugin breaks Workplace
Date: Sun, 12 Jul 2009 21:52:21 -0700

On 12-Jul-09, at 10:30 AM, Karsten Hilbert wrote:

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

Hi, I added to my workplace list the Allergies plugin

...The tarballs creation
script explicitely removes it. How did you manage to select
it for the workplace ?

I selected it from inside the GNUmed > Preferences > ... > Workplaces menu, after (within the list of available Workplaces) I selected "GNUmed default", edited it, and added Allergies plugin which was listed there, as was a ConfigReg plugin and a Referrals plugin and so on.

Therefore the tarballs script either wasn't run, or did not do what it was expected to do? Or is there some way for plugins to get into the database, either via bootstrapping or via import from an earlier version database, when upgrading?

Did you wish me to email you any file listing from any particular directory within my untarred 0.5.rc3 tarball?

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


called from --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

So is the above implying that the broken libraries are unlikely to have anything to do with my selection of an unavailable or broken plugin?


Fixable by any uninstalling and reinstalling of any python packages? I am sensing there may be a job for apt-get here?

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

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

Can I suggest we remove all of the existing Workplaces that have no current meaning except nostalgic or sentimental but will have no meaning to regular users? We can keep documented in the wiki, for example, what was available with Librarian Release (0.2). I think part of the problem is that users see so many pre-loaded workplaces that these are confusing. Also, it is customary for users to expect to need to change defaults, and therefore not unusual for them to select "GNUmed default", for the reason that they desire to *change* their default. The purpose of these other workplaces would be a mystery to most users who would more likely leave *those* alone than leave "GNUmed default" alone.

I suggest we ship GNUmed with only two workplaces, pre-defined to have the same plugins:

        GNUmed backup
        GNUmed reserved

        Local default
        Database default

so that in the absence of any other defined workplace, it would normally be the local/database default that would load, and only in the event of some other issue (or with knowledgeable user over-ride, to call GNUmed backup / reserved) would GNUmed backup / reserved get utilized.

reply via email to

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