On 10:59 Wed 02 Feb , Nathaniel Echols wrote:

On Wed, Feb 2, 2011 at 9:34 AM, Edward A. Berry wrote:

...

By the way, what is the preferred etiquette- "reply all" or just reply to the list? I usually assume the recipient is subscribed to the list and doesn't need or want an extra copy, but it is very easy to delete a duplicate email and i can see if one is subscribed to the digest then having a personal copy would make the dialog go faster.

I don't have strong feelings about this. Approximately one quarter of subscribers only get the digest, and due to multiple complaints about too much Phenix-related email, I've decreased the frequency with which digests are sent out, several times now. (They used to be at least daily, but I changed that on Monday.) So it may make more sense to reply-to-all, but I can't speak for everyone else. If you're replying to one of the developers, however, we all get instant delivery.

I recommend CC'ing people, which is nice for many groups: - digest subscribers, to keep discussions going more quickly and without breaking everyone else's threading; - people who don't get list mail for other reasons (it's possible to subscribe as a post-only user); and - those of us with separate mail filters set up for mails with our names attached. That way, we don't need to immediately read every mailing list we're on. Regarding the digest frequency, it sounds like the real problem is people who haven't yet learned how to deal with lots of email, where lots is hundreds/thousands per day instead of 50 or so. Perhaps posting a prominent link that teaches people how to use things like mail filters, subfolders/tags, threading, and "mark thread/all as read" would be equally or more valuable than trying to find a single digest frequency that's perfect for everyone. Honestly, it's much faster to do things this way than dealing with digests, once you get the hang of it. -- Thanks, Donnie Donald S. Berkholz, Ph.D. Research Fellow James R. Thompson lab, Physiology & Biomedical Engineering Grazia Isaya lab, Pediatric & Adolescent Medicine Medical Sciences 2-66 Mayo Clinic College of Medicine 200 First Street SW Rochester, MN 55905 office: 507-538-6924 cell: 612-991-1321

On Wed, Feb 2, 2011 at 12:42 PM, Ben Eisenbraun wrote:

Nat is talking about a different PyMOL.  The binary at /usr/local/crys/64/phenix-1.7-650/pymol/pymol.exe generated the error, but you're showing the info for one installed from YUM.

Oops, I totally missed the different paths. That's definitely the problem.

In any case, the problem is that the PyMOL shipped _with_ PHENIX is a 32-bit binary, even in the 64-bit download.

Perhaps it would save everyone trouble if we stopped distributing PyMOL with Phenix? Version 0.99 is so obsolete anyway that I'd really prefer that everyone obtain the latest version separately.

I got a window on my OS X machine the other day telling me that PHENIX would prefer to use a newer MacPyMOL if it could find one in /Applications. Can I configure this to find the newer MacPyMOL in a different path?  How about on linux?  That might be another possible solution to Leonid's problem.

Yes: Preferences->Graphics->Full path to PyMOL. On Mac, this could either be the native .app bundle, or a Unix-style executable installed from the open-source distribution. However, Phenix really should look in more places before giving up and start 'phenix.pymol'; I'll start by checking in /usr/bin, /usr/local/bin, /sw/bin/, and /sw64/bin, but we can probably examine the shell environment for aliases too - Ralf did something like this for Coot, which has worked reasonably well for most situations. -Nat

On Thu, Feb 3, 2011 at 9:24 AM, Ben Eisenbraun wrote:

...

Phenix really should look in more places before giving up and start 'phenix.pymol'; I'll start by checking in /usr/bin, /usr/local/bin, /sw/bin/, and /sw64/bin, but we can probably examine the shell environment for aliases too - Ralf did something like this for Coot, which has worked reasonably well for most situations.

Finding it in the environment or via an environment variable would be my preferences, since I'd like to configure it in one place for all my users.

I definitely think we should be able to do this, but I forgot about the method for setting Phenix preferences globally (for all users). There are two environment variables, PHENIX_GUI_DEFAULT_PREFS, and PHENIX_GUI_SITE_PREFS; the first is read in before an individual user's preferences, the second is read in afterwards (so it will override whatever the user has set). So you could, for instance, create a file named "phenix_prefs.linux-i386.eff", and put this in it: preferences.graphics.pymol_app_path=/path/to/linux-i386/pymol and then: setenv PHENIX_GUI_SITE_PREFS /some/path/phenix_prefs.linux-i386.eff Or something like that. I added this mechanism so industry users could route bug reports to a local contact instead of bouncing off the corporate firewall, but it's potentially useful for any other large installation. I'll put something in the documentation about this. -Nat