<Mukund>
My install script was: mkdir my_builld && cd my_build
<Mukund>
cmake ..
<Mukund>
make -j4
<Mukund>
make install
nikunj97 has joined #ste||ar
<heller1>
No space left on device?
<Mukund>
How much space does it need?
<Mukund>
I definitely have about 20 GB atleast
<Mukund>
sorry
<Mukund>
I have 17 GB
DragonMain has quit [Remote host closed the connection]
Abhishek09 has joined #ste||ar
<Abhishek09>
i have error in installing blaze on ubuntu http://dpaste.com/2T4XVJC . Can anyone see what i missed?
<Abhishek09>
nikunj97
<nikunj97>
Abhishek09, what are you trying to achieve with this command: cmake -DCMAKE_BUILD_TYPE={Release,Debug} -DCMAKE_INSTALL_PREFIX=/blaze/install/path -DBLAZE_SMP_THREADS=HPX -DHPX_DIR=/path/to/hpx ..
<nikunj97>
you need to choose one build type, either Release or Debug
<Abhishek09>
We can't do both?
<nikunj97>
installation prefix and hpx dir needs to be existing path
<nikunj97>
Abhishek09, sure you can build both. But you've got to build them separately
<nikunj97>
you can't build both at the same time
<Abhishek09>
i have done in building hpx
<Abhishek09>
both at same time
<Abhishek09>
hpx install path: /path/install/path
<Abhishek09>
Sorry /hpx//install/path
<Abhishek09>
build files written to /hpx/build
<Abhishek09>
nikunj97
<nikunj97>
cool
<nikunj97>
not sure if it's possible to build more than 1 build type at a time. zao ^^
<Abhishek09>
i have done in bulding hpx 2 build type
<Mukund>
how much space does hpx require for a release build?
Abhishek09 has quit [Remote host closed the connection]
Hashmi has joined #ste||ar
Mukund has quit [Remote host closed the connection]
Abhishek09 has joined #ste||ar
<Abhishek09>
HPXConfig.cmake is not found on my installation path of hpx . Why?
<simbergm>
Abhishek09: you probably need to set `CMAKE_PREFIX_PATH` to the location of your HPX installation, or set `HPX_DIR` to the location of `HPXConfig.cmake` (usually `<install_location>/lib64/cmake/HPX`)
<simbergm>
the two methods are more or less equivalent but require specifying slightly different directories
<simbergm>
MukundVaradaraja: less than a gb should be more than enough for release
<simbergm>
debug might be a bit more
<simbergm>
MukundVaradaraja: are you installing to `/usr/local` with super user privileges or not?
<simbergm>
MukundVaradaraja: does `/home/mukund/open-source/hpx/my_build/bin/hpxrun.py` exist? if yes, most likely you need to `sudo make install`
<simbergm>
Abhishek09: yeah, replace `-DHPX_DIR=/path/to/hpx` with the actual path to your HPX installation (plus the `lib64/cmake/HPX` suffix, check that directory exists, it could be `lib/cmake/HPX` as well)
<simbergm>
another thing, `-DCMAKE_INSTALL_PREFIX={Release,Debug}` expands to `-DCMAKE_INSTALL_PREFIX=Release -DCMAKE_INSTALL_PREFIX` (the shell does this)
<simbergm>
you need to pick only one of those at a time
<Abhishek09>
but i build hpx with both
<Abhishek09>
thanks i found that config file
<simbergm>
you have to pick one at a time
<simbergm>
you can have two separate build directories, one for release and one for debug
<Abhishek09>
my build have done with my syntax only
<Hashmi>
@simbergm: hey. I have build hpx and phylanx but ctest in both says no test configuration found after cmake tests. Cmakelists.txt are correct in both.
<simbergm>
Abhishek09: the tests run the same, the latter just gives you more information if something fails
<simbergm>
try leaving out `-j3`, you might be running out of memory
<simbergm>
Hashmi: what command do you run exactly?
<Abhishek09>
have allocated 6 gb ram to docker simbergm
<simbergm>
Abhishek09: 2 gb per job is an estimate, it might end up going over 6 gb with three jobs
<Abhishek09>
What to do for fast ?
<Abhishek09>
simbergm
<simbergm>
fast? faster builds?
<Abhishek09>
Yes
<Abhishek09>
for fast build , i run -j3
<Hashmi>
@simbergm: after make install.
<Hashmi>
I ran cmake tests and ctest
<Abhishek09>
Hashmi: Which project u working?
<Hashmi>
@Abhishek09: sorry
<Hashmi>
What project am I planning to work on?
<Hashmi>
Pypi package for phylanx
<simbergm>
Abhishek09: get a different machine or run `make -j2` or `make`, there's not much you can do to make the compilation use less memory
<Hashmi>
What about you?
<simbergm>
Hashmi: `make tests` not `cmake tests`
<Hashmi>
@simbergem Ya sorry make tests. Problem is still there.
<Abhishek09>
Hashmi: same project
<Hashmi>
@Abhishek09: great
<Hashmi>
How is response from patrick so far?
<Abhishek09>
i m talking with him from past 1.5 year
<Hashmi>
Oh then you have been involved with this project before?
<Abhishek09>
i already chose this project previous
<Abhishek09>
year
<Hashmi>
Oh so howdidit go?
<Abhishek09>
well !
<Hashmi>
But there isnt a python package available rn
nikunj97 has quit [Ping timeout: 260 seconds]
Abhishek09 has quit [Remote host closed the connection]
<diehlpk_mobile[m>
Hashmi Abishek wanted to apply for the project last year, but we did not got accepted as Ste||ar Group last year
<Hashmi>
Oh I see..
<Hashmi>
Can we work together this year @diehlpk_mobile[m
nikunj97 has joined #ste||ar
<diehlpk_mobile[m>
Hashmi No, GSOC does not allow that multiple students work on the same project
<diehlpk_mobile[m>
Only one student per project
<diehlpk_mobile[m>
The best proposal will decide how is working on the project
<Hashmi>
@diehlpk_mobile[m: great will try my best
<diehlpk_mobile[m>
Also the hpx toy application and community bounding period will be considered
<diehlpk_mobile[m>
Have you started on your hpx toy application?
<Hashmi>
@diehlpk_mobile[m: no I have not. I was not aware of that. How can I learn more about it?
<Hashmi>
Right you meant how
<Hashmi>
You meant whats mentioned in the guidelines*
<Hashmi>
I was thinking about publishing a dummy c++ project to pypi for that
<Hashmi>
Not necessarily related to hpx. Would that be good enough?
<diehlpk_mobile[m>
Yes
<Hashmi>
Alright!
<nikunj97>
diehlpk_mobile[m, see pm please
hkaiser has joined #ste||ar
Mukund has joined #ste||ar
Mukund has quit [Remote host closed the connection]
<Yorlik>
hkaiser: yt?
<Yorlik>
Is there an id_type I could use as "nil" or invalid as answer to a search?
<Yorlik>
I allowed myself to try this: return hpx::id_type( 0 ); -- not sure about it though
Abhishek09 has joined #ste||ar
<Abhishek09>
building phylanx is very slow
<nikunj97>
Abhishek09, patience ;0
<Abhishek09>
nikunj97: How much time to build phylanx for ur machine?
<nikunj97>
it's been pretty long since I last built
<nikunj97>
I don't remember, something like 15-20min is my guess
<Abhishek09>
What ur system config?
<Abhishek09>
nikunj97
<nikunj97>
at that time I had an 8thread H series i7 with 16gb ram
<nikunj97>
the fastest I've seen was on the workstation I had at LSU. Took about 5min I guess, but it was 32 thread Xeon E5 and 64gb ram
<nikunj97>
so that's in a league of it's own
<Abhishek09>
i have dual cores i5 with 8GB
<nikunj97>
hkaiser, LSU workstations were the fastest personal computers I had worked on. I kinda miss them these days :/
<nikunj97>
Abhishek09, I'd say patience. Build times are pretty high for phylanx and hpx and there's nothing you can do about it really.
<nikunj97>
hkaiser, btw charm++ is pretty uninteresting. You should've warned me about this. That's mostly C code trying to look cool calling itself c++
<Abhishek09>
nikunj97 : You are at iitr or lsu?
<nikunj97>
I'm at iitr. I've been to lsu a couple of times now though
<Abhishek09>
For ur project ppt after gsoc?
<nikunj97>
no, for an internship.
<Abhishek09>
Does ste||ar call gsocer for project ppt presentation in gsoc mentor summit at google hq? nikunj97
<nikunj97>
idk, nobody called me
Abhishek09 has quit [Ping timeout: 240 seconds]
<zao>
nikunj97: It depends on generator. MSVC ones on Windows doesn't do build type selection, it generates some or all of the set available.
<zao>
The command line that our dear student tried to run was verbatim from the phylanx wiki on how to install :D
<nikunj97>
zao, aah!
<nikunj97>
never knew you could do that
Abhishek09 has joined #ste||ar
<zao>
In either case, the syntax is as you found out a suggestion to the user to pick the right one for generators that only support a single build type.
<zao>
Kind of amusing that it happened to be legal shell syntax as well, with {}
<zao>
I use it almost daily when making patches - `diff -ru software-x.y.z{.orig,}` which expands to `diff -ru software-x.y.z.orig software-x.y.z`
<nikunj97>
completely true, but seems like it's currently supported for msvc as of now
<hkaiser>
nikunj97: didn't I warn you ?
<nikunj97>
I mean a cmake script opening to 2 doesn't make much sense
<nikunj97>
hkaiser, none that I can remember
<hkaiser>
lol
<hkaiser>
I think I did
<nikunj97>
I kinda feel stuck uk
<hkaiser>
anyways, let's hope it works out
<nikunj97>
I don't like the syntax
<hkaiser>
nikunj97: I think that's exactly why Sanjay wants to have you
<nikunj97>
yes, I'm making progress. It's pretty easy to get started. Just don't like the syntax stuff
<hkaiser>
he knows you know hpx
<nikunj97>
i now understand why he asked me about my c++ proficiency during our call
<hkaiser>
I think you should definitely take the opportunity, in the worst (best) case to see how _not_ to do things
<nikunj97>
hkaiser, totally. As of now I don't see much future of charm++
<nikunj97>
it feels cluttered really
<hkaiser>
it's not wasted on you, I'm sure - he knows a lot of people and can help
<nikunj97>
a lot of restrictions put on the user. For one make things blocking or local if you want to return non-void
<hkaiser>
you've been spoiled by HPX ;-)
<nikunj97>
and here I was playing with all sorts of futures
<nikunj97>
hkaiser, totally. I very well understand the simplicity and effectiveness of scaling an hpx application over other runtimes
<hkaiser>
good, that's what you need to take away wherever you go
<nikunj97>
i'm still a novice when it comes to charm++, maybe things get better once I get into it deeply. But my first impression isn't great
<nikunj97>
I've told this to sanjay as well
<zao>
Meanwhile I'm writing parallel code with nothing but the std threads and a lot of vectors. It could be worse, nikunj97 :P
<hkaiser>
Sanjay wants you to mend things based on your knowledge of HPX and you experience working with us
<hkaiser>
what did he say?
<hkaiser>
zao: if you used HPX it would be nothing but standard c++ too
<nikunj97>
let me quote him: C++ vs C: for stdio, it was kept because of CkPrintf, but I should replace that with ckout stream output. About arrays vs vectors.. I prefer arrays because of efficiency in simple situations. But I can be persuaded. At heart, I am an old C programmer.
<hkaiser>
nikunj97: right
<nikunj97>
I was telling him how he writes c++ in a c-like fashion
<hkaiser>
that's the main issue - they don't see the benefit and read a lot non-favorable things about C++
<nikunj97>
most of my charm++ codes are written in a modern C++ fashion, and he's already started to like my codes
<zao>
hkaiser: Right, but proper composable futures gets rid of a lot of the headaches.
<hkaiser>
zao: indeed
<hkaiser>
nikunj97: good
<hkaiser>
(almost) nobody is teaching modern c++, really
<nikunj97>
maybe I'll introduce the group to some modern c++ practices
<hkaiser>
please do
<nikunj97>
hkaiser, I agree completely. Been checking CGAL past few days to help a friend with gsoc.
<nikunj97>
The code base is pretty messed up
<nikunj97>
reminded me of flecsi to some extent
<hkaiser>
heh
<nikunj97>
they've been trying to shift to modern C++ these days
<nikunj97>
and that makes it a bit non understandable at places
<nikunj97>
they've got good use of meta templates though
<hkaiser>
it's a long way for existing codes
<zao>
aaw, waits on std::atomic are not until C++20 :(
<hkaiser>
zao: yah, there is a lot of the necessary functionality coming only
<nikunj97>
hkaiser, true. But it's nice to see people shifting to modern c++, even if modern for them is c++11 ;)
<hkaiser>
nod
<hkaiser>
nikunj97: don't worry about charm++, you'll be fine - and it's a foot into the door for you
<nikunj97>
hkaiser, yea that's how I'm considering the situation. Post charm++, I guess I'll have to get back to hpx though. I like it better here ;)
<hkaiser>
absolutely!
<hkaiser>
Yorlik: hpx::naming::invalid_id_type;
<Yorlik>
hkaiser: Thanks !
<hkaiser>
nikunj97: you did ask about the HPX initialization in Phylanx yesterday
<nikunj97>
hkaiser, yes
<nikunj97>
I'm curious to know why you go through such hardships
<hkaiser>
yes, this is very similar to what the global_init example does
<hkaiser>
because when you run a python script there is no way to get into main() to initialize HPX
<nikunj97>
does a python script run without main?
<nikunj97>
how does that work really? I'm curious
<hkaiser>
the main() is in the python interpreter
<hkaiser>
it's compiled in there
<nikunj97>
so how do you register python calls to run on hpx threads?
<hkaiser>
we have a python extension module such that you can do a 'import phylanx' in your Python script
<hkaiser>
that one initializes HPX when being loaded and exist HPX on unload
<hkaiser>
*exits*
<nikunj97>
does the user require to initialize and finalize?
<hkaiser>
no, the user does 'import phylanx'
<nikunj97>
how does an import statement initialize the runtime as well?
<hkaiser>
uhh, that's a long story
<nikunj97>
ohh so there's an actual story behind it, I'm more curious now
<nikunj97>
maybe a call someday explaining me that?
<hkaiser>
we use pybind11 to expose C++ functionalities to Python, you might want to starting reading there
<nikunj97>
my reason behind asking this question is because I feel that we can employ the same tactic that we make use with hpx_main.hpp
<nikunj97>
and initialize/finalize the runtime directly without using the hpx_init you've got in phylanx
<nikunj97>
that's why I was curious to know the reasoning behind it. I can add a backend using my techniques from hpx_main to automate the initialization/finalization in phylanx
<hkaiser>
not sure about that
<hkaiser>
well, it might work if you know what std library the Python executable is compiled against
<nikunj97>
again, that won't work for windows, coz uggh.. but I guess it'll be better than working with sections that are architecture and os dependents
<hkaiser>
otoh, when Python is started you don't know whether you will need HPX, so you want to initialize it only on demand, i.e. whenever 'import phylanx' is seen
<nikunj97>
aah, that makes more sense
<nikunj97>
on demand runtime initialization seems more appropriate for this situation
Hashmi has quit [Quit: Connection closed for inactivity]
<Yorlik>
Sending id_types across messages for referencing objects is pure awesomesauce - I love it. Objects can now properly reference each other and communicate.
<nikunj97>
hkaiser, understood. That's a clever way ;)
<hkaiser>
Yorlik: right, and the garbage collection makes sure they are deleted as necessary
<Yorlik>
How will HPX handle an action called on an invalid id_type?
<Yorlik>
Like an ettempt to send a message to a deleted object
<hkaiser>
Yorlik: it will throw an exception
<Yorlik>
Locally AND remnotely?
<hkaiser>
yah
<hkaiser>
the future you get back from the async will rethrow the exception on its .get()
<Yorlik>
Makes sense. I like that system.
<Yorlik>
Where will it throw on the remote side?
<Yorlik>
Since the object and thus the member function addressed doesn't exist
<heller1>
The exception will be propagated to the call site
<hkaiser>
no locally, whenever you access the future's value
<Yorlik>
So the remote locality is totally unaffected?
<hkaiser>
yes
<Yorlik>
Good. Thanks !
<hkaiser>
it will transport the remote exception back to the caller
<Yorlik>
Nice. I like that.
<hkaiser>
Yorlik: one caveat, though
<hkaiser>
HPX knows only how to transport hpx::exception and std::exception types
<Yorlik>
So no strings and crap?
<hkaiser>
your own exceptions might not be handled properly ATM
<Yorlik>
OK
<nikunj97>
hkaiser, is there a way to get the return type of a function with decltype(auto) return type. This function is hidden somewhere in the middle of the library and is completely generic.
<nikunj97>
or convert it into std::result_of or std::invoke_result?
<hkaiser>
well, either std::invoke_result or decltype(F(...))
<hkaiser>
result_of is deprecated starting c++20
<nikunj97>
aah, didn't know. why is it deprecated?
<hkaiser>
it relies on a special protocol to expose the return type from function objects, which is not needed anymore (because we have decltype()) now
<nikunj97>
i thought result_of and invoke_result does pretty much the same think
<nikunj97>
check whether the argument is callable
<nikunj97>
and invoke result if callable
<nikunj97>
how are they different then?
<hkaiser>
functionally they are equivalent
<hkaiser>
result_of relies on expliti return type calculation (pre c++11) while invoke_result relies on decltype()
<nikunj97>
so invoke_result is more powerful than result_of
<hkaiser>
nikunj: see wg21.link/n1454 for the initial result_of paper
<hkaiser>
yes
<heller1>
This reminds me of the awesome phoenix result_of protocol...
<nikunj97>
I see. Btw I don't see any examples of invoke_result anywhere
<nikunj97>
heller1, do tell
<heller1>
pre c++11 only supported one fixed result type per function object. For phoenix, there was one supporting result type calculation based on the argument types
<hkaiser>
nikunj97: well, decltype() does the trick, usually invoke_result<> is more complex to write
<hkaiser>
heller1: that's what turned into std::result_of<> later
<nikunj97>
hkaiser, at the same time decltype usually gives back a type for any expression, which may be undesirable in cases where you need a type only when you're passing it callable (functions, functors etc.)
<hkaiser>
nod
<heller1>
hkaiser: I was under the impression, that this still required a single embedded type member
<nikunj97>
that's why I wanted to write one with std::invoke_result
<hkaiser>
heller1: no, you can specialize the embedded template <...> result {}; as needed
<nikunj97>
hkaiser, for a function `int foo(int)`. This doesn't seem to work: using int_t = std::invoke_result<decltype(&foo)(int), int>::type;
<nikunj97>
while this does: using int_t = std::result_of<decltype(&foo)(int)>::type;
<nikunj97>
I'm pretty sure that I don't know how to use std::invoke_result
<hkaiser>
shouldn't it be invoke_result<decltype(&foo), int>::type ?
Abhishek09 has quit [Remote host closed the connection]
<nikunj97>
hkaiser, doesn't work either
<nikunj97>
tried that first
<nikunj97>
try.cpp:20:24: error: ‘invoke_result’ in namespace ‘std’ does not name a template type
<hkaiser>
did you compile with c++17 ?
<nikunj97>
that did it
<nikunj97>
I thought gcc compiled with 17 by default
<nikunj97>
thanks!
<hkaiser>
nikunj97: but decltype(foo(std::declval<int>()) should work as well
<nikunj97>
hkaiser, sure. It was simply that I wanted to play around with invoke_result
<nikunj97>
parsa taught me to play around with random standard library functions. So I was playing around with invoke_result these days :D
<hkaiser>
:D
shahrzad has quit [Ping timeout: 260 seconds]
shahrzad has joined #ste||ar
Hashmi has joined #ste||ar
shahrzad has quit [Ping timeout: 246 seconds]
Abhishek09 has joined #ste||ar
<Abhishek09>
How long does `make test` take?
<Abhishek09>
simbergm
<hkaiser>
Abhishek09: depends on your machine
<hkaiser>
a full circleci build cycle takes ~2 hours, but they use upto 4 machines for this
<hkaiser>
for hpx that is
<hkaiser>
for Phylanx it's a bit less
hkaiser has quit [Quit: bye]
<zao>
Some tests take way longer than others, so if you happen to be working on a narrow part of the codebase, you can also tell it to run a particular range of tests.
<zao>
(but as your goal is the packaging project, I doubt that is of interest :D )
<nikunj97>
K-ballo, yt?
shahrzad has joined #ste||ar
diehlpk_work has joined #ste||ar
<Abhishek09>
How many test are there in phylanx?
<Abhishek09>
zao
<Abhishek09>
?
shahrzad has quit [Ping timeout: 246 seconds]
<zao>
Couple of hundred?
<zao>
Don't remember, but I had like 35% fail :D
<Abhishek09>
i have not numpy , that's why some are fail
<Abhishek09>
zao
<zao>
Mine fail in something allocator-related with tcmalloc.
<zao>
(I've got numpy from our module system, like a civilized admin :D )
<Abhishek09>
make test is performing test instead of ctest. Why? zao
<zao>
It's a convenience to be able to launch the tests via the build system, regardless of what test library is used - as it doesn't necessarily have to be ctest.
<zao>
If you want to control tests more, you can invoke ctest yourself with the flags you want.
<Abhishek09>
that means i not need to do `ctest` zao . Am i correct?
<Abhishek09>
292 tests are there
nikunj97 has quit [Remote host closed the connection]
nikunj97 has joined #ste||ar
shahrzad has joined #ste||ar
Hashmi has quit [Quit: Connection closed for inactivity]
shahrzad has quit [Ping timeout: 260 seconds]
Abhishek09 has quit [Remote host closed the connection]
Hashmi has joined #ste||ar
hkaiser has joined #ste||ar
nk__ has joined #ste||ar
nikunj97 has quit [Ping timeout: 260 seconds]
<Yorlik>
Is something wrong with this code? HPX spuriously produces an error here:
<Yorlik>
When I inspect that pointer in the debugger it actually is NOT nullptr but has a value
nikunj97 has joined #ste||ar
nk__ has quit [Ping timeout: 250 seconds]
<nikunj97>
hkaiser, can decltype(auto) lead to implicit conversions?
<hkaiser>
decltype(auto) will represent the result type deduced from the return expression
<hkaiser>
where should it do implicit conversions?
<nikunj97>
a basic example, let's say you're returning a rvalue say 42
<hkaiser>
Yorlik: get_ptr works only for local objects
<nikunj97>
it will return an int right
<Yorlik>
I am only using local objects in the moment.
<hkaiser>
yes
<nikunj97>
well alright, I figured what I'm going wrong
<hkaiser>
if the assert fires, then the pointer IS a nullptr
<hkaiser>
otherwise it wouldn't fire
* Yorlik
please for a memory error by cosmic rays.
<Yorlik>
I had it only once ever.
<Yorlik>
Or twice
<hkaiser>
Yorlik: then it's a race
<Yorlik>
I have no clue how this code ever could cause a race. I'll dig ...
<Yorlik>
I'm doing more aggressive use of the engine now - also had to (finally) make my memory allocator thread safe. I guess there might be more dragons lurking.
<hkaiser>
Yorlik: btw, get_ptr<>(hpx::launch::sync, ...) is more efficient than get_ptr<>(...).get()
<Yorlik>
Oh - I had totally forgotten about that
<Yorlik>
Thanks !
<hkaiser>
it shortcuts the future creation and will not create an hpx thread for its operation
<Yorlik>
I need that actually quite a lot
<Yorlik>
When I need to resolve the real object locally
<Yorlik>
I try to avoid it usually
<Yorlik>
But there are some occasions
<Yorlik>
I could put the pointer to the object on the entity ofc.
<Yorlik>
For now I just store the id_type
<hkaiser>
nod
<Yorlik>
I assume the local get will be almost as fast as retrieving it from the entity
<hkaiser>
for local (non-migratable) objects the lsb 64 bits of the id_type IS the local ptr
<hkaiser>
so its a not too expensive operation
<Yorlik>
They can all migrate
<Yorlik>
So its not safe
<hkaiser>
then it can't apply this optimization
<Yorlik>
The workload is divided in tiles which can move anywhere
<Yorlik>
On the long run I'll probaly make an optimization to store the local pointer, even after migration
<hkaiser>
k
<hkaiser>
sensible - always first do measurements before optimizing things
<Yorlik>
That code above is in the tight update loop
<Yorlik>
OFC I lose most time in Lua itself
<Yorlik>
So writing good lua code and optmizing there is the most critical area
nikunj97 has joined #ste||ar
<nikunj97>
hkaiser, typeid(static_cast<const F*>(this)->operator()(get(vpm_,p),get(vpm_,q))).name() is bool
<nikunj97>
typeid(decltype(get(vpm_,p))).name() is same as typeid(typename boost::property_traits<PointPropertyMap>::value_type).name()
<nikunj97>
and typeid(decltype(std::declval<typename add_ptr<F>::type>() -> operator()(std::declval<typename boost::property_traits<PointPropertyMap>::value_type>(), std::declval<typename boost::property_traits<PointPropertyMap>::value_type>()))).name() also gives bool
<nikunj97>
why replacing decltype(auto) with typeid(decltype(std::declval<typename add_ptr<F>::type>() -> operator()(std::declval<typename boost::property_traits<PointPropertyMap>::value_type>(), std::declval<typename boost::property_traits<PointPropertyMap>::value_type>()))).name() leads to an error where return statement is typeid(static_cast<const F*>(this)->operator()(get(vpm_,p),get(vpm_,q))).name()
<nikunj97>
I've been scratching my head over this. Both have the same types
<nikunj97>
yet when I replace decltype(auto) with the appropriate type, compiler just blows up
<nikunj97>
and says no such call exists, when all of them are actually types that I have printed with std::cout and confirmed with c++filt
<hkaiser>
nikunj97: give me the full example, I can't really put things together from the pieces you provided
<nikunj97>
don't think so. I played with that as well
<nikunj97>
does typeid delete constness?
<nikunj97>
coz none of the typeid seemed to mention it
<nikunj97>
boost::property_trait<map>::value_type gives back the value type of the map
<nikunj97>
and get function as well gives back the value type
<nikunj97>
but using get in the function type seems to compile while using boost::property_train<map>::value_type does not
<nikunj97>
for ex: decltype(std::declval<F*>()->operator()(get(std::declval<PointPropertyMap>(),std::declval<const Vertex&>),get(std::declval<PointPropertyMap>(),std::declval<const Vertex&>))) compiles well in the function type
<nikunj97>
but this decltype(std::declval<F*>()->operator()(std::declval<typename boost::property_traits<PointPropertyMap>::value_type>(), std::declval<typename boost::property_traits<PointPropertyMap>::value_type>())) does not compile
<nikunj97>
which is so weird to me. But I didn't look this from constness perspective. I should probably do that now
<Yorlik>
hkaiser: For some reason I cannot checkout anymore your variant fix 5a221c1205dcbe92f8cf9c5c361b9562e3f75ea5 . Is there any particular reason for this?
<zao>
Maybe it was force-pushed away?
<Yorlik>
Maybe. I'm now getting: fatal: reference is not a tree: 5a221c1205dcbe92f8cf9c5c361b9562e3f75ea5
<Yorlik>
Seems I need to use e95e1f83818088fb122ff5993ec651e0fe4cb71d now - lets see .. Git still is somewhat black magic to me. Even after using it for some years now.
<Yorlik>
Hmmm ... Doesn't work either.
<hkaiser>
Yorlik: I might have forced pushed
<hkaiser>
why do you go with a commit and not just with the branch?