From: Olive <enc...@ya...> - 2005-04-14 23:47:16
|
Hello, I've juste downloaded the last version (0.8) of matplotlib and successfully built it on SunOS 5.8 with GTK backend (gcc 3.2.2). "import matplolib" is OK but typing "from matplotlib.pylab import *" result in a core dumped ! without any error message or exception... "import gtk", "import pygtk", and "import wx" works OK. I've tried with version 0.72, same error : Python 2.4.1 (#3, Apr 14 2005, 10:58:02) [GCC 3.2.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> from matplotlib.pylab import * Bus Error (core dumped) One more thing is that after importing matplotlib, I got an error when using help : python Python 2.4.1 (#3, Apr 14 2005, 10:58:02) [GCC 3.2.2] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import matplotlib >>> help(matplotlib) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/opt/SunOS/5.8/lib/python2.4/site.py", line 328, in__call__ return pydoc.help(*args, **kwds) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1647, in __call__ self.help(request) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1691, in help else: doc(request, 'Help on %s:') File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1475, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 295, in document if inspect.ismodule(object): return self.docmodule(*args) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1069, in docmodule contents.append(self.document(value, key, name)) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 296, in document if inspect.isclass(object): return self.docclass(*args) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1193, in docclass lambda t: t[1] == 'method') File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1143, in spill name, mod, object)) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 297, in document if inspect.isroutine(object): return self.docroutine(*args) File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 1254, in docroutine doc = getdoc(object) or '' File "/opt/SunOS/5.8/lib/python2.4/pydoc.py", line 75, in getdoc result = inspect.getdoc(object) or inspect.getcomments(object) File "/opt/SunOS/5.8/lib/python2.4/inspect.py", line 448, in getcomments lines, lnum = findsource(object) File "/opt/SunOS/5.8/lib/python2.4/inspect.py", line 437, in findsource if pat.match(lines[lnum]): break IndexError: list index out of range I really don't know where to begin to isolate the problem. Do I missed an option in the build process to have some kind of debug ? What can I do to help you better understand the problem ? Thank you in advance for your help, |
From: John H. <jdh...@ac...> - 2005-04-15 05:34:22
|
>>>>> "Olive" == Olive <enc...@ya...> writes: Olive> Hello, I've juste downloaded the last version (0.8) of Olive> matplotlib and successfully built it on SunOS 5.8 with GTK Olive> backend (gcc 3.2.2). "import matplolib" is OK but typing Olive> "from matplotlib.pylab import *" result in a core dumped ! Olive> without any error message or exception... "import gtk", Olive> "import pygtk", and "import wx" works OK. Olive> I've tried with version 0.72, same error : I don't have a lot of good advice for you, but here is how I would go about debugging the problem. You can recompile mpl in verbose mode. rm -rf "site-packages/matplotlib" and your "build" subdir and edit setup.py and set VERBOSE=True and recompile/reinstall. This can sometimes provide information about which extension code function is failing. You also want to create a test script that replicates the problem (in your case it's a one-liner that simply imports matplotlib.pylab) and run it with the --verbose-debug flag > python myscript.py --verbose-debug This prints maximal debug info which can provide helpful information to narrow down the possible culprits. Olive> Python 2.4.1 (#3, Apr 14 2005, 10:58:02) [GCC 3.2.2] on Olive> sunos5 Type "help", "copyright", "credits" or "license" for Olive> more information. >>>> from matplotlib.pylab import * Olive> Bus Error (core dumped) The old-fashioned but effective way to triangulate this kind of segfault is to put a lot of print statements into the module that is segfaulting (in this case site-packages/matplotlib/pylab.py). Space these print statements every 50 lines or so print 'debug 1' ...50 lines of pylab... print 'debug 2' ...50 lines of pylab... print 'debug 3' When you have narrowed the segfault to be between two numbers, say 2 and 3, add more statements between them, maybe with a delimiter such as TAB '\t' print '\t debug 2a' ...5 lines of pylab... print '\t debug 2b' ...5 lines of pylab... print '\t debug 2c' ...5 lines of pylab... and repeat as necessary with a finer grain until you find the actual line causing the segfault. Posting this info will go a long way to actually discovering the bug. I call this "poor man's debugging" or "manual binary search" and it's primitive, ugly, and highly effective. Olive> One more thing is that after importing matplotlib, I got an Olive> error when using help : Don't know if this is related or not... JDH |
From: Michael B. <mb...@jp...> - 2005-04-21 15:27:50
|
Hi Olive, I've had similar problems on both Solaris 8 and 9. By running python under truss: truss python I saw that the "illegal instruction" and core dump was happening in the freetype libraries. I had built freetype 2.1.9 myself. When I deleted my own libfreetype.* and instead used the prebuilt versions /usr/sfw/lib/libfreetype.* my crashes went away. (Note that /usr/sfw/lib is the Solaris 9 location. I'm not sure if it's the Solaris 8 location or not). I had built libfreetype.6.3.7 (freetype 2.1.9) and /usr/sfw/lib contained the earlier version libfreetype.6.3.1 . I don't whether this is a Solaris-only bug in later versions of freetype, or if the /usr/sfw/lib versions were built a different way than I built mine. Anyway, that's how I solved the problem. I would suggest that you try: (1) Finding the Sun-supplied libfreetype.so binaries and using those, or (2) building the version of libfreetype that produces libfreetype.6.3.1. Please let me know how you solve the problem. Good luck! --Michael Brady |
From: Olive <enc...@ya...> - 2005-04-21 21:03:31
|
On Thu, 21 Apr 2005 08:27:41 -0700 (PDT), Michael Brady <mb...@jp...> wrote : > Hi Olive, > > I've had similar problems on both Solaris 8 and 9. By running python > under truss: > > truss python > > I saw that the "illegal instruction" and core dump was happening in > the freetype libraries. I had built freetype 2.1.9 myself. When I > deleted my own libfreetype.* and instead used the prebuilt versions > /usr/sfw/lib/libfreetype.* my crashes went away. > > (Note that /usr/sfw/lib is the Solaris 9 location. I'm not sure if > it's the Solaris 8 location or not). > > I had built libfreetype.6.3.7 (freetype 2.1.9) and /usr/sfw/lib > contained the earlier version libfreetype.6.3.1 . I don't whether this > is a Solaris-only bug in later versions of freetype, or if the > /usr/sfw/lib versions were built a different way than I built mine. > > Anyway, that's how I solved the problem. > > I would suggest that you try: > > (1) Finding the Sun-supplied libfreetype.so binaries and using those, > or(2) building the version of libfreetype that produces > libfreetype.6.3.1. > > Please let me know how you solve the problem. > > Good luck! > Hello Michael, Like I said I solved temporarily the problem by editing the file ft2font.cpp (from matplotlib !) at line 354 : const char* ps_name = FT_Get_Postscript_Name(face ); I replaced it by : const char* ps_name = NULL; It's just a quick and dirty hack while waiting for a clean patch from either matplotlib or freetype. I still don't know wether it's a bug from matplotlib or freetype, because I don't know what is the argument 'face' and what is inside... I don't understand a thing in C++ so I can't be of much help here... But I was working with freetype 2.1.7, I have also tried with 2.1.9 and I also have a core dumped but no at the same place ! Don't know if my hack could work also with 2.1.9 ? I can test if you're interested. P.S. : I couldn't help noticing your email address, I'm also working on space rockets but in France and also trying to promote matplotlib here ! ;-) |
From: Daniel W. <dan...@ni...> - 2005-04-21 21:37:31
|
Is it currently possible to make contour plots using unstructured data with matplotlib? By unstructured data I mean the typical data from a 2D finite element simulation that uses an unstructured polygonal mesh. As far as I can tell the "pylab.contourf(X, Y, Z)" command requires structured data with X, Y and Z each having to be 2D gridded arrays. I have previously used the gist package to do this type of plotting using the "gist.plfp(Z, X, Y, F)" command. This command allows plotting of polygonal data specified by arrays Z, X, Y, F. - Z is the data value, shape(Z) = (NPolygons) - X is the vertex x coordinates, shape(X) = (NPolygons, NVertices). - Y is vertex y coordinates, shape(Y) = (NPolygons, NVertices) - F is the number of vertices for each cell, shape(F) = (NPolygons) Is there a similar functionality in matplotlib? Thanks ------------------------------------- Daniel Wheeler |
From: Olive <enc...@ya...> - 2005-04-15 22:17:41
|
On Fri, 15 Apr 2005 00:34:15 -0500, John Hunter <jdh...@ac...> wrote : > Olive> Hello, I've juste downloaded the last version (0.8) of > Olive> matplotlib and successfully built it on SunOS 5.8 with GTK > Olive> backend (gcc 3.2.2). "import matplolib" is OK but typing > Olive> "from matplotlib.pylab import *" result in a core dumped ! > Olive> without any error message or exception... "import gtk", > Olive> "import pygtk", and "import wx" works OK. > > Olive> I've tried with version 0.72, same error : > > I don't have a lot of good advice for you, but here is how I would go > about debugging the problem. You can recompile mpl in verbose mode. > rm -rf "site-packages/matplotlib" and your "build" subdir and edit > setup.py and set VERBOSE=True and recompile/reinstall. Ah ! that was what I was looking for ! So I've managed to isolate the culprit : >>> from font_manager import FontProperties Glyph::init_type FT2Font::init_type ft2font_module::new_ft2font FT2Font::FT2Font FT2Font::clear Illegal Instruction (core dumped) It appears that the problem was in file ft2font.cpp at line 354 : const char* ps_name = FT_Get_Postscript_Name( face ); I don't know what is wrong here but I managed to get matplotlib working by replacing it by : const char* ps_name = NULL; I forgot to take the version number of the freetype library before leaving work, I will get it on monday. I haven't understand what is really in the argument 'face', can you give me a code which print the fields of 'face' ? (I don't know C++...) Thank you anyway for your help ! |
From: Olive <enc...@ya...> - 2005-04-18 17:58:20
|
On Sat, 16 Apr 2005 00:19:37 +0200, Olive <enc...@ya...> wrote : > I forgot to take the version number of the freetype library before > leaving work, I will get it on monday. > Version of freetype is 2.1.7 ! |