hkaiser changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
jpenuchot has quit [Quit: Lost terminal]
<heller>
just for the record, I didn't merge the PP stuff ;)
quaz0r has quit [Ping timeout: 252 seconds]
quaz0r has joined #ste||ar
nikunj has quit [Remote host closed the connection]
K-ballo has joined #ste||ar
hkaiser has joined #ste||ar
<simbergm>
heller: yt?
<heller>
Hey
<heller>
What's up?
<simbergm>
just want to sync with you about the config PR so we don't end up doing the same work ;)
<simbergm>
I have a branch which builds currently
<heller>
Ok
<simbergm>
just wanted to check if you're cleaning up yours
<heller>
No
<heller>
Not necessarily
<heller>
If you have something that's good, that's great
<heller>
I just wanted to get it out the door ;)
<simbergm>
don't know if it's good, but it compiles :P
<simbergm>
it's mostly yours anyway
<heller>
Since something needs to get done, obviously
<simbergm>
so that means it's good anyway ;)
<heller>
Sure
<simbergm>
yep
<heller>
:p
<simbergm>
right, I'll open that as a PR then
<simbergm>
I hope I haven't butchered it completely because I didn't necessarily understand everything that you did
<simbergm>
but if you have time to look through it that'd be great
<simbergm>
I'm more than happy to do the work otherwise
<heller>
Sure, I'll do
<heller>
Let's consolidate what we have
<heller>
With the config module, we'll also get clearer dependencies ;)
<hkaiser>
cmake's source_group stuff is annoying
<hkaiser>
that will require some redesign, I believe
<hkaiser>
I'd say, let's get the pp module sorted out before adding even more
<simbergm>
heller: do you have more coming...? eek
<simbergm>
there's pp, config, assert, and hardware there but let's focus on pp first
<zao>
Is this about preprocessor or parcelports? Have not been able to tell :)
<hkaiser>
preprocessor
<heller>
hkaiser: ok, is there anything about the source groups that you'd like to see?
<heller>
Or what you absolutely don't want to see
<hkaiser>
heller: I'd like for them to actually work ;-)
<heller>
Sure
<hkaiser>
that's all ;-)
<heller>
But all the files can be grouped differently
<hkaiser>
I tried yesterday, but can't make it work
<heller>
I'll get myself a copy of visual studio and try
<hkaiser>
well, currently the headers don't show up in the solution at all, sources are all flat in the root directory of the solution
<simbergm>
considering zao's question, should we just change pp to preprocessor?
<hkaiser>
simbergm: sure, names are just names after all
<simbergm>
blarg it is then ;)
nikunj has joined #ste||ar
<hkaiser>
right
<simbergm>
hkaiser: if you're there it's your turn to explain something to me...
<simbergm>
source groups ;)
<simbergm>
I still don't get how both of the conditions you mentioned aren't completely satisfied
<simbergm>
the only thing I can maybe understand is that source_group is called through add_hpx_source_group, but that's exactly like the working example in the issue you linked
<hkaiser>
simbergm: nod
<hkaiser>
source_group has to be called in the same cmake scope as the corresponding add_library the files in the source group belong to
<hkaiser>
also, the files listed in the source group are not passed through to the add_library call, currently
<simbergm>
and add_hpx_source_group is called just below that
<hkaiser>
but this is not the main hpx target, this particular target does not require any builds, so it will not create a project in VS
<simbergm>
so maybe I don't understand how add_hpx_source_group works
<simbergm>
I feel dumb...
<hkaiser>
sorry, misunderstanding
<hkaiser>
in order for the source groups to be added to the (main) hpx project they need to be aligned with add_library(hpx ...)
<simbergm>
should they be added to the main hpx project?
<hkaiser>
yes
<simbergm>
a source group is some kind of vs directory?
<hkaiser>
yes
<hkaiser>
it just organizes the files inside the tree in VS
<simbergm>
so they can't just be part a hpx_config (or whatever) project
<simbergm>
?
<hkaiser>
right
<simbergm>
hmm, getting there
<hkaiser>
I know this breaks the whole idea of separating things from the main project
<simbergm>
"need to be aligned with add_library(hpx ...)"
<simbergm>
what do you mean by that?
<hkaiser>
need to be in the same cmake scope as our add_library(hpx ...)
<simbergm>
uh...
<K-ballo>
isn't source group a file property?
<simbergm>
fun
<hkaiser>
simbergm: are the files related to a module part of the target somehow? can we retrieve the list of those files?
<hkaiser>
K-ballo: it is, but only if its defined in the same cmake scope
<hkaiser>
otherwise it will not show up in VS
<simbergm>
I think it's possible
<K-ballo>
then it must not be a file property
<hkaiser>
if that wa spossible we could iterate all modules before calling add_library(hpx...) and add the files to that call
<hkaiser>
K-ballo: could be, I don't know
<K-ballo>
yeah, doesn't seem to be a property at all
<simbergm>
wait, but is it enough to do source_group in the same scope as add_library(hpx) or does add_library(hpx_blah) also need to be in it?
<hkaiser>
add_library(blah...) is unrelated
<simbergm>
ok, but the source group for hpx_blah needs to be there
<hkaiser>
yes
<hkaiser>
isn't cmake lovely?
<simbergm>
yes, I might just propose to cmake
<hkaiser>
:D
<hkaiser>
and btw, the source group must be defined before add_library is called, I think
<simbergm>
ok, I think (not really) I understand the problem now
<simbergm>
oh...
<simbergm>
I was just going to say it's not fun but should be doable
<simbergm>
now I'm not so sure
<hkaiser>
simbergm: if we could a) attach the two list of files (headers, sources) as a property to the hpx.blah targets and b) attach the root directory as a property as well, then we should be able to invoke the add_hpx_source_group right before the add_library(hpx)
<hkaiser>
in a loop that iterates over our module targets
<simbergm>
ah right, add_library(hpx), not add_library(hpx_blah) again
<simbergm>
yes, then it should be possible
<hkaiser>
yes
<hkaiser>
instead of calling add_hpx_source_group in the module cmake file
<simbergm>
ok, thanks for being patient with me :)
<simbergm>
(I wish it wasn't necessary...)
<hkaiser>
thanks for trying to solve this, I'm too cmake-ignorant for this
<simbergm>
I'll see what I can do
<simbergm>
bah, so am I :P
<hkaiser>
K-ballo: can we attach arbitrary (user-defined) properties to targets?
<simbergm>
btw, so the result right now is that you can't see module sources in vs?
<hkaiser>
yes
<hkaiser>
I probably would see sources (imported through that target dependencies), but the headers are gone - but even sources would be listed in the same VS directory
<simbergm>
get_target_property might do the trick
<simbergm>
anyway, not now... I'll try to look at it over the weekend
<simbergm>
happy easter holidays for those that do that!
<hkaiser>
simbergm: happy easter to you as well, happy egg hunting
<K-ballo>
we can define custom properties, yes
<hkaiser>
ok, that should solve it then
nikunj has quit [Quit: Leaving]
jaafar has quit [Ping timeout: 250 seconds]
<heller>
hkaiser: what yould you need it for?
<heller>
hkaiser: regarding the distributed object stuff
<heller>
hkaiser: do you stlil remember what I did a few years back with trying to add generic remote objects?
<hkaiser>
heller: no
<heller>
ah, different use case ... took me a while...
<heller>
reminds a bit of the things that PGAS languages have
<hkaiser>
right, it's stolen from UPC++
<hkaiser>
slightly modified
<heller>
and a bit misleading (from the name)
<hkaiser>
well, names are names - suggestions welcome
<heller>
they are called distributed objects in UPC++?
<hkaiser>
dist_object
<weilewei09>
Oh, I changed dist_object to distributed_object for my next fix, though
<hkaiser>
weilewei09: sure, will not be the last name change ;-)
<weilewei09>
Do I need to change it back to dist_object...?
<hkaiser>
weilewei09: nah, be patient
<heller>
wait for it
<weilewei09>
Oh, ok, I will keep distributed_object for now
<hkaiser>
nod
<hkaiser>
it's as good as any other name for now
<heller>
it took me a while to realize what the actual intent was...
<hkaiser>
heller: more of an partitioned_object
<heller>
indeed
<heller>
but the actual data doesn't need to be a partition of anything
<hkaiser>
right
<hkaiser>
heller: would you object to making the deprecation warning in the new pp headers conditional?
<heller>
I think for PGAS, the original name was "shared memory" or something
<heller>
not at all
<heller>
weilewei09: hkaiser: why not have the implementation live and grow with phlyanx?
<hkaiser>
I'd like to either be able to decide which of the headers to use r supress the warning
<heller>
sure
<heller>
I suspect there will be quite a few more changes incoming
<heller>
NB: I still don't get in which situations I would instantiate a "Meta Object"?
<hkaiser>
heller : it reduces the setup communication overhead
<hkaiser>
O(N) vs. O(N^2)
<heller>
it has a congestion point on the root
<hkaiser>
it's something like a communicator
<hkaiser>
the idea is to do measurements...
<heller>
I don't see the O(N^2) for the all_to_all part
<heller>
unless you really have an all to all access pattern ...
<heller>
interesting
<heller>
yeah, measurements would have been interesting to better evaluate the approach
<hkaiser>
heller: how should I add a pp constant specific to the pp module?
<hkaiser>
HPX_PP_HAVE_COMPATIBILITY_HEADERS
<hkaiser>
should that go in the global defines.hpp?
<hkaiser>
or should eahc module have its own config header?
<heller>
I think each should have their own
<heller>
Not sure if there is infrastructure for that already
<hkaiser>
there is not
<hkaiser>
I'll add it to the main one for now
<heller>
Ok
<hkaiser>
we could use the option categories for that
<heller>
Does it really have to be that complicated?
<hkaiser>
we also already have options namespaces
<hkaiser>
currently being used for the parcelports