Re: [vsipl++] [patch] Distributed transpose

[Stefan Seefeld <stefan@xxxxxxxxxxxxxxxx>]

Jules Bergmann wrote:
> > * We need to address the many header interdependencies, in particular 
> > between the serial and the parallel set. There is some circularity 
> > that is very hard to break out of.
> I completely agree.
>
> Was there a particular dependency between the parallel/serial headers? 
> Unfortunately the spec has a circular definition where maps return the 
> processor set in a Vector, but Vectors have blocks, and blocks have 
> maps, and maps have processor sets ... well you get the idea.
Yes, that's the one. :-)

One issue that so far I have only been able to work around by somewhere 
injecting "#include <vsip/parallel.hpp>" was that some 
(expression-)block types use a Local_or_global_map, which derives from 
Global_map, which comes from parallel/*.
And unless all relevant templates (traits, etc.) are seen by the 
compiler, some operations may raise a compilation-error pointing out 
that it's invalid to mix local and global blocks in assignments...
> > * There are sets of templates that form a self-contained block of 
> > functionality that I think is important to document, both, from a low 
> > level as well as middel-level view. I'm in particular thinking of the 
> > Combine_return_type logic (which I have run across multiple times this 
> > week already)
> I completely agree too.
>
> I'll take an action to add some documentation for Combine_return_type.
>
> You'll notice I did add some gratuitous documentation to one of 
> Subset_map_decl's functors ;)  Let's take this opportunity as we get 
> back into the library (relearning what we've written before but didn't 
> document), to add some documentation.
Yes ! (I have a list of topics that I want to document myself, so I'm 
happy to wrap that up, too.)
Thanks,
		Stefan

--
Stefan Seefeld
CodeSourcery
stefan@xxxxxxxxxxxxxxxx
(650) 331-3385 x718