sieve-dev FIAT import question

[Jed Brown]

On Tue 2008-03-25 08:57, Matthew Knepley wrote:
> On Tue, Mar 25, 2008 at 8:47 AM, Jed Brown <jed at 59a2.org> wrote:
> > On Tue 2008-03-25 08:24, Matthew Knepley wrote:
> >  > On Tue, Mar 25, 2008 at 7:22 AM, Jed Brown <jed at 59a2.org> wrote:
> >  > > When I try to build the sieve examples, I get errors like the one below.  If I
> >  > >  move the `import FIAT.shapes' up to the top of the file, it works just fine.  I
> >  > >  don't know if there is something peculiar about my configuration, but this
> >  > >  problem hasn't gone away in the last weeks so I thought I'd mention it.  My
> >  > >  configuration included the options:
> >  >
> >  > Do you have numpy in a weird place? You are the first to report this
> >  > error, and I
> >  > am not sure sure how moving an import would matter, but evidently on your
> >  > system it does somehow. In order to debug it, I need to know how you installed
> >  > numpy.
> >
> >  No, it is in /usr/lib/python2.5/site-packages/numpy/.  I see the same problem on
> >  two systems, an x86 Ubuntu system with numpy installed via apt and an x86_64
> 
> I have exactly an x86 Ubuntu apt system and do not get this error (and
> neither do
> my students, Bras at USGS, Charles at RPI, or Shi Jin in UMBC), so
> something must
> be different. There is something that prevents the import the second
> time, but it
> probably an error in some installed python package, and I would need
> to be on the
> system to find it (I already found one in the last version of numpy).

Well, that is indeed strange.  I suppose the purpose of importing after setup()
is to be able to fix paths, but in my case, FIAT is already available in my
PYTHONPATH.  Perhaps this has something to do with it.  It's not clear to me
that there is something wrong with my python install since ``do nothing'' is
exactly what needs to be done.  That is, just transposing the import line with
setup() works fine.  I'm not a python guru and hunting down the source of this
problem is really not interesting.  Apparently it doesn't affect anyone else.


By the way, building with gcc 4.3.0 brought out the need for the following.
Without <cmalloc>, there is no std::malloc or std::free.

diff -r 6cfe5326613c src/dm/mesh/sieve/ALE_mem.hh
--- a/src/dm/mesh/sieve/ALE_mem.hh      Tue Mar 25 06:13:18 2008 -0500
+++ b/src/dm/mesh/sieve/ALE_mem.hh      Tue Mar 25 15:38:50 2008 +0100
@@ -6,6 +6,7 @@
 #include <iostream>
 #include <map>
 #include <memory>
+#include <cstdlib>
 #include <typeinfo>
 #include <petsc.h>
 #include <ALE_log.hh>


Jed
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.mcs.anl.gov/mailman/private/sieve-dev/attachments/20080325/f34acfb2/attachment.pgp>