dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

Anders Logg wrote:
> On Tue, Feb 16, 2010 at 03:38:18PM +0000, Garth N. Wells wrote:
>>
>> Anders Logg wrote:
>>> On Tue, Feb 16, 2010 at 04:29:24PM +0100, Anders Logg wrote:
>>>> On Tue, Feb 16, 2010 at 01:23:33PM +0100, Johannes Ring wrote:
>>>>> On Tue, Feb 16, 2010 at 12:49 PM, Harish Narayanan
>>>>> <harish.mlists@xxxxxxxxx> wrote:
>>>>>> On 2/16/10 10:27 AM, Johannes Ring wrote:
>>>>>>> On Tue, Feb 16, 2010 at 10:37 AM, Harish Narayanan
>>>>>>> <harish.mlists@xxxxxxxxx> wrote:
>>>>>>>> On 2/16/10 9:06 AM, Garth N. Wells wrote:
>>>>>>>>> Anders Logg wrote:
>>>>>>>>>> On Tue, Feb 16, 2010 at 08:42:55AM +0000, Garth N. Wells wrote:
>>>>>>>>>>> Anders Logg wrote:
>>>>>>>>>>>> On Tue, Feb 16, 2010 at 09:09:31AM +0100, Johannes Ring wrote:
>>>>>>>>>>>>> On Mon, Feb 15, 2010 at 6:06 PM, Anders Logg <logg@xxxxxxxxx> wrote:
>>>>>>>>>>>>>> On Mon, Feb 15, 2010 at 03:49:05PM +0100, Anders Logg wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   UFL    0.5.2
>>>>>>>>>>>>>>>>>>>>>   FErari 0.2.0
>>>>>>>>>>>>>>>>>>>>>   FFC    0.9.1
>>>>>>>>>>>>>> Now released.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   Instant 0.9.8: Why is the buildbot failing?
>>>>>>>>>>>>>> Now released.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>   DOLFIN  0.9.7: SCOTCH problems
>>>>>>>>>>>>>> Remains to fix:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  - Drop Hardy support (upgrade buildbots)
>>>>>>>>>>>>> This might take some time, at least for linux64-exp since I have no
>>>>>>>>>>>>> control over this. I guess it will be upgraded when Lucid is out.
>>>>>>>>>>>>>
>>>>>>>>>>>>> What should we install on hardy-i386? Karmic or perhaps Lucid?
>>>>>>>>>>>> I think we should choose the simplest option. I don't know what is
>>>>>>>>>>>> easiest and fastest, either dropping Hardy support (which requires
>>>>>>>>>>>> upgrades of buildbots and some extra administration) or adding the
>>>>>>>>>>>> required #ifdefs for unordered_set/set. Garth?
>>>>>>>>>>>>
>>>>>>>>>>> I don't want to add ifdefs (it actually involves more than just that).
>>>>>>>>>>> Harish told me yesterday that he wasn't using the standard OSX gcc (his
>>>>>>>>>>> old version didn't support tr1 well), which means we could probably
>>>>>>>>>>> switch back to using the tr1 unordered containers and not break Hardy or
>>>>>>>>>>> standard standard OSX installations.
>>>>>>>>>>>
>>>>>>>>>>> I would still suggest that we drop Hardy in the near future, perhaps
>>>>>>>>>>> once Lucid is out.
>>>>>>>>>> That seems like a good plan since Lucid is the next LTS release.
>>>>>>>>>>
>>>>>>>>>> Do you know which #ifdefs to add so we can get the buildbot green?
>>>>>>>>>>
>>>>>>>>> No ifdefs. Just change
>>>>>>>>>
>>>>>>>>>   boost::unordered_set -> std::tr1::unordered_set
>>>>>>>>>   boost::unordered_map -> std::tr1::unordered_map
>>>>>>>>>
>>>>>>>>> and the relevant includes.
>>>>>>>> This should work, except it might break the mac buildbot. While I wasn't
>>>>>>>> using the most recent OS X or gcc, I think I was in line with the mac
>>>>>>>> buildbot.
>>>>>>>>
>>>>>>>> Johannes, what does the buildbot run? Leopard or Snow Leopard, and what
>>>>>>>> gcc does it use?
>>>>>>> I think it was Leopard and gcc 4.3 from fink. However, the mac
>>>>>>> buildbot has been offline for some weeks now. We have bought a new
>>>>>>> imac to be used as a dedicated mac buildbot but I haven't started to
>>>>>>> install anything on it yet. I'm not sure if we should go for fink or
>>>>>>> macports. Any recommendations?
>>>>>> I suggest MacPorts. It is a bit more unstable than fink, but it allows
>>>>>> for greater control and has a very recent collection of packages.
>>>>> Thanks, I will look at MacPorts when I setup the new buildbot.
>>>>>
>>>>> Johannes
>>>> So is the conclusion that std::tr1::unordered_set will work with
>>>>
>>>>   1. Modern operating systems
>>>>   2. Ubuntu Hardy
>>>>   3. New Mac versions (which is what we will run on the buildbot)
>>>>
>>>> ?
>>>>
>>>> If so I (or someone else) can switch to std::tr1::unordered_set.
>>> And the scotch/parmetis include thing needs to be fixed. Garth?
>>>
>> I can take a look tonight, although I haven't followed closely what the
>> problem is.
> 
> Great. There seems to be a conflict between two versions of
> parmetis.h, the ParMETIS one and another installed by SCOTCH.
> 
> I think the solution is to add a scotch/ prefix in the #include
> and modify the include path accordingly so it doesn't pick up
> parmetis.h from SCOTCH when the real one is needed.
> 

How can I reproduce the problem? I don't see it on my machine. Sounds
strange that SCOTCH includes parmetis.h. Is it the compatibility
functions that SCOTCH provides that cause the problem?

Garth

> --
> Anders