On 06/04/2013 03:52 AM, Brice Goglin wrote:
> (forgot to CC the list)
>
>
> Le 04/06/2013 10:48, Brice Goglin a écrit :
>> Hello,
>>
>> Here are some slightly fixed tests. cuda/cudart/nvml look good.
>> intel-mic looks good but I couldn't test on a real machine (I used XML
>> instead), so the
Le 04/06/2013 14:34, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 5:11 AM, Brice Goglin wrote:
>
>> 2) custom test with ltdl: The program just silently fails to load hwloc
>> symbols. Equivalent to passing the topology flag above.
>
> One option might be to try to
I know I'm not really an active member of the dev community, but I have
experience with this from working on TORQUE (my full-time job). We switched
to git (hosted on github) and it has been fantastic for us. I was familiar
with git but hardly an expert when we changed over, and the same was true
Take a look at svn2git. It takes care of some the the tag/branch naming
problems. If you use it make sure to pass the --metadata option to get the
git-svn-id's in the commit messages.
-Nathan
On Jun 4, 2013, at 4:23 AM, Brice Goglin wrote:
> When I switched Open-MX and
On Jun 4, 2013, at 5:22 AM, Brice Goglin wrote:
> I take that back. Topology flags come too late, plugins are loaded
> during the first topology_init().
Bummer.
> We're back to things like "export HWLOC_PLUGINS_PATH=/none"
Perhaps add a pre-init API to set flags like
On Jun 4, 2013, at 5:11 AM, Brice Goglin wrote:
> 2) custom test with ltdl: The program just silently fails to load hwloc
> symbols. Equivalent to passing the topology flag above.
One option might be to try to lt_dlsym one of the hwloc symbols that you know
you'll need
Le 04/06/2013 14:11, Brice Goglin a écrit :
> Adding topology flag to disable plugin may indeed be a nice workaround.
> As long as the hwloc user doesn't need what's in plugin, things will
> work fine. And I think things will work fine in the OpenCL case.
>
I take that back. Topology flags come
(adding the list to CC)
Le 04/06/2013 13:35, Jeff Squyres (jsquyres) a écrit :
> On Jun 4, 2013, at 4:10 AM, Brice Goglin wrote:
>
>>> I guess I'm asking - why can't that plugin link against an embedded
>>> (non-DSO) hwloc?
>> It can for sure. But if there's a hwloc
On Jun 4, 2013, at 3:38 AM, Brice Goglin wrote:
>> I'd like to explore converting all the old SVN log message mentions of
>> "r" to git hashes. git-svn doesn't do that, right?
>
> No it doesn't afaik, and that would be nice.
I know that MPICH went through this
On Jun 4, 2013, at 3:23 AM, Brice Goglin wrote:
> When I switched Open-MX and KNEM from SVN to GIT, I basically just
> pushed my git-svn clone. But I had to manually convert some svn
> tags/branches. IIRC, the main reason is that git-svn has a strange way
> to name svn
On Jun 3, 2013, at 11:11 AM, Samuel Thibault wrote:
> If only plugins and the core use these functions, the application does
> not have to use -lhwloc-helper at all. If the application uses them
> (e.g. bitmap functions), then it would have to use -lhwloc-helper,
> but
When I switched Open-MX and KNEM from SVN to GIT, I basically just
pushed my git-svn clone. But I had to manually convert some svn
tags/branches. IIRC, the main reason is that git-svn has a strange way
to name svn branches in git.
We may also have to pass --authors-file to git svn clone so that
Ok. This is kinda what I assumed your response would be. :-)
Let me talk to Dave Goodell later today, who just recently went through
converting MPICH from SVN -> Git, and see what kinds of things we need to do to
get the ball rolling here, and what kinds of dragons we should expect to
(forgot to CC the list)
Le 04/06/2013 10:48, Brice Goglin a écrit :
> Hello,
>
> Here are some slightly fixed tests. cuda/cudart/nvml look good.
> intel-mic looks good but I couldn't test on a real machine (I used XML
> instead), so the cpuset retrieving code wasn't tested.
>
> gl doesn't seem
+1000 !
I already use git-svn for most of my hwloc work. But I still need svn for
backports, and that wastes a lot of my time.
Brice
"Jeff Squyres (jsquyres)" a écrit :
>We're having a discussion (again :-) ) about moving OMPI to a DVCS.
>
>The short conclusion of the
We're having a discussion (again :-) ) about moving OMPI to a DVCS.
The short conclusion of the long conversation is: the OMPI dev community would
be much more comfortable moving to a DVCS if they could see some success with
other OMPI projects (e.g., hwloc and/or MTT).
Would hwloc be
16 matches
Mail list logo