This is really a rather esoteric issue, but I feel I need to mention this to save someone, depending on the situation, anywhere between five minutes of googling or two hours of hair-pulling. In a nutshell, phenix gui may in some circumstances screw up other programs that use matplotlib. I can't track down which specific phenix gui action causes it, but it's safe to assume that whenever matplotlib libs are used the subsequent calls to logarithmic scale plots (and likely other things) throw this error TypeError: coercing to Unicode: need string or buffer, dict found The solution is to erase the ~/.matplotlib/fontList.cache. The likely cause is that phinix gui calls on bundled matplotlib which is different from one I have installed (not to mention that I am using Lucid (because it's LTS) which has python 2.6 and not the 2.7 that is bundled with phenix). However, it still writes into the same ~/.matplotlib folder, thus I end up with incompatible data. Certainly, the problem will be gone when matplotlib gets bumped up to 1.0.1 in next Ubuntu release. This is yet another example of why the standalone installation approach is ideologically objectionable on modern Linux. But of course, the practical advantage gained by not having to package the software for any possible OS flavor/version users may choose outweighs the lower risks of package incompatibility and the reduced size of the packaged product. -- Oh, suddenly throwing a giraffe into a volcano to make water is crazy? Julian, King of Lemurs
On Thu, Aug 18, 2011 at 10:39 AM, Ed Pozharski
In a nutshell, phenix gui may in some circumstances screw up other programs that use matplotlib.
It's not the fault of Phenix; matplotlib is unusually inflexible in how it deals with these cache files, and it is nearly unique among Python modules in its dependence on writing to the user's home directory. This isn't the only problem; another issue is that matplotlib creates these caches, and the maintainers appear to never have considered what would happen if the cached directory were removed. So when you run the GUI in version X of Phenix, then remove version X and install version Y, it will still look for the fonts installed with version X. I complained about this last December, and it remains unsolved in any of the official releases (one of which was this year). The likely cause is that phinix gui calls on bundled matplotlib which is
different from one I have installed (not to mention that I am using Lucid (because it's LTS) which has python 2.6 and not the 2.7 that is bundled with phenix). However, it still writes into the same ~/.matplotlib folder, thus I end up with incompatible data. Certainly, the problem will be gone when matplotlib gets bumped up to 1.0.1 in next Ubuntu release.
The issue with removing installations will remain, however. You could avoid the incompatibility problem by running "phenix.wxpython" if you need to use matplotlib. (We're using Python 2.7.2 right now, and generally update to the latest release in the 2.x series shortly after it comes out.) This is yet another example of why the standalone installation approach
is ideologically objectionable on modern Linux. But of course, the practical advantage gained by not having to package the software for any possible OS flavor/version users may choose outweighs the lower risks of package incompatibility and the reduced size of the packaged product.
We don't have the resources to support a more ideologically pure distribution mechanism - the installers are maintained by me and Ralf in between other projects. Also, we often depend on new features in the various dependencies that would not be immediately available through the package managers (for instance, we switched to Python 2.6 almost immediately because I needed the multiprocessing module). There are many things in the current installers that I'm unhappy with, but they don't take very much time to maintain, which is essential. -Nat
Since we're talking about phenix distributions.... <flamebait> So when are we going to see phenix on the App Store? I hear the next version of OS X will only run binaries signed by Apple. </flamebait> F On Aug 18, 2011, at 12:06 PM, Nathaniel Echols wrote:
On Thu, Aug 18, 2011 at 10:39 AM, Ed Pozharski
wrote: In a nutshell, phenix gui may in some circumstances screw up other programs that use matplotlib. It's not the fault of Phenix; matplotlib is unusually inflexible in how it deals with these cache files, and it is nearly unique among Python modules in its dependence on writing to the user's home directory. This isn't the only problem; another issue is that matplotlib creates these caches, and the maintainers appear to never have considered what would happen if the cached directory were removed. So when you run the GUI in version X of Phenix, then remove version X and install version Y, it will still look for the fonts installed with version X. I complained about this last December, and it remains unsolved in any of the official releases (one of which was this year).
The likely cause is that phinix gui calls on bundled matplotlib which is different from one I have installed (not to mention that I am using Lucid (because it's LTS) which has python 2.6 and not the 2.7 that is bundled with phenix). However, it still writes into the same ~/.matplotlib folder, thus I end up with incompatible data. Certainly, the problem will be gone when matplotlib gets bumped up to 1.0.1 in next Ubuntu release.
The issue with removing installations will remain, however. You could avoid the incompatibility problem by running "phenix.wxpython" if you need to use matplotlib. (We're using Python 2.7.2 right now, and generally update to the latest release in the 2.x series shortly after it comes out.)
This is yet another example of why the standalone installation approach is ideologically objectionable on modern Linux. But of course, the practical advantage gained by not having to package the software for any possible OS flavor/version users may choose outweighs the lower risks of package incompatibility and the reduced size of the packaged product.
We don't have the resources to support a more ideologically pure distribution mechanism - the installers are maintained by me and Ralf in between other projects. Also, we often depend on new features in the various dependencies that would not be immediately available through the package managers (for instance, we switched to Python 2.6 almost immediately because I needed the multiprocessing module). There are many things in the current installers that I'm unhappy with, but they don't take very much time to maintain, which is essential.
-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
--------------------------------------------- Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder
On Thu, Aug 18, 2011 at 11:29 AM, Francis E Reyes < [email protected]> wrote:
So when are we going to see phenix on the App Store?
I'm very confident this is never going to happen.
I hear the next version of OS X will only run binaries signed by Apple.
I haven't seen any mention of this beyond vague rumors more than a year ago. I can't believe Apple would be this stupid; it would destroy them in the education and high-end professional markets, where Macs are relatively popular. -Nat
On 08/19/2011 03:29 AM, Francis E Reyes wrote:
Since we're talking about phenix distributions....
<flamebait> So when are we going to see phenix on the App Store? I hear the next version of OS X will only run binaries signed by Apple.
Well, let's not accept this business model.
</flamebait>
F
On Aug 18, 2011, at 12:06 PM, Nathaniel Echols wrote:
On Thu, Aug 18, 2011 at 10:39 AM, Ed Pozharski
wrote: In a nutshell, phenix gui may in some circumstances screw up other programs that use matplotlib. It's not the fault of Phenix; matplotlib is unusually inflexible in how it deals with these cache files, and it is nearly unique among Python modules in its dependence on writing to the user's home directory. This isn't the only problem; another issue is that matplotlib creates these caches, and the maintainers appear to never have considered what would happen if the cached directory were removed. So when you run the GUI in version X of Phenix, then remove version X and install version Y, it will still look for the fonts installed with version X. I complained about this last December, and it remains unsolved in any of the official releases (one of which was this year).
The likely cause is that phinix gui calls on bundled matplotlib which is different from one I have installed (not to mention that I am using Lucid (because it's LTS) which has python 2.6 and not the 2.7 that is bundled with phenix). However, it still writes into the same ~/.matplotlib folder, thus I end up with incompatible data. Certainly, the problem will be gone when matplotlib gets bumped up to 1.0.1 in next Ubuntu release.
The issue with removing installations will remain, however. You could avoid the incompatibility problem by running "phenix.wxpython" if you need to use matplotlib. (We're using Python 2.7.2 right now, and generally update to the latest release in the 2.x series shortly after it comes out.)
This is yet another example of why the standalone installation approach is ideologically objectionable on modern Linux. But of course, the practical advantage gained by not having to package the software for any possible OS flavor/version users may choose outweighs the lower risks of package incompatibility and the reduced size of the packaged product.
We don't have the resources to support a more ideologically pure distribution mechanism - the installers are maintained by me and Ralf in between other projects. Also, we often depend on new features in the various dependencies that would not be immediately available through the package managers (for instance, we switched to Python 2.6 almost immediately because I needed the multiprocessing module). There are many things in the current installers that I'm unhappy with, but they don't take very much time to maintain, which is essential.
-Nat _______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
--------------------------------------------- Francis E. Reyes M.Sc. 215 UCB University of Colorado at Boulder
_______________________________________________ phenixbb mailing list [email protected] http://phenix-online.org/mailman/listinfo/phenixbb
On 11:06 Thu 18 Aug , Nathaniel Echols wrote:
This is yet another example of why the standalone installation approach is ideologically objectionable on modern Linux. But of course, the practical advantage gained by not having to package the software for any possible OS flavor/version users may choose outweighs the lower risks of package incompatibility and the reduced size of the packaged product.
We don't have the resources to support a more ideologically pure distribution mechanism - the installers are maintained by me and Ralf in between other projects. Also, we often depend on new features in the various dependencies that would not be immediately available through the package managers (for instance, we switched to Python 2.6 almost immediately because I needed the multiprocessing module). There are many things in the current installers that I'm unhappy with, but they don't take very much time to maintain, which is essential.
If this is something people are deeply interested in, they can write their own packages for various distributions. The main problem is that scons is a horrible "build system" (if it even merits the name) for the purposes of Linux distribution packaging. It's too customizable to behave in nonstandard ways and not modifiable on the command line, so it requires significant acrobatics to work well. Redistribution is another problem due to license issues, but that's solved easily enough by simply not redistributing the final rpm/deb/etc but only the .spec file or equivalent. -- Thanks, Donnie Donald S. Berkholz, Ph.D. Research Fellow James R. Thompson lab, Physiology & Biomedical Engineering Grazia Isaya lab, Pediatric & Adolescent Medicine Mayo Clinic ___________________ Medical Sciences 2-66 200 First Street SW Rochester, MN 55905 office: 507-538-6924 cell: 612-991-1321
participants (5)
-
Donnie Berkholz
-
Ed Pozharski
-
Francis E Reyes
-
Francois Berenger
-
Nathaniel Echols