<gonidelis[m]>
anyways... still. that shouldn't be a problem
<gonidelis[m]>
I have just `git reset`ed `--hard`
<gonidelis[m]>
:@ still the same error pops! just can't figure out where this comes from. The only files that I am changing are on `libs/iterator_support/...` .
<gonidelis[m]>
although the problem stems from `libs/performance_counters/src/`
<hkaiser>
gonidelis[m]: we have reverted the coverage changes yesterday, try pulling from master again
<gonidelis[m]>
`pull` or `fetch` ?
<gonidelis[m]>
or doesn't matter? :p
<gonidelis[m]>
(I can see that this is a strong debate on various V.C. blogs)
<K-ballo>
fetch won't affect your working tree
<K-ballo>
I'm surprised there's a debate
<gonidelis[m]>
K-ballo: well just read an article that was like "git: fetch and merge, don’t pull"
<gonidelis[m]>
What do you mean?
<K-ballo>
ok, fetch+merge does make some sense
<K-ballo>
fetch just updates your local state of remote branches
<K-ballo>
that's still potentially confusing, let me try again
<K-ballo>
after fetching, your local clone notices there have been changes upstream, but it doesn't integrate those changes into your local branch
<gonidelis[m]>
yeah I completely understand your point :)
<K-ballo>
(it wouldn't affect the output of git diff, since your local branch didn't change)
<gonidelis[m]>
yy.... I get it
<gonidelis[m]>
So I just did `git pull upstream master` and then `make -j4` on my build dir
<gonidelis[m]>
The error from `libs/performance_counters/src/performance_counter_set.cpp:337` is still there. I am desperate ;[
<K-ballo>
is git diff the "error" ?
<gonidelis[m]>
What do you mean?
<K-ballo>
I have no idea what performance_counter_set error you are referring to
<gonidelis[m]>
1. `util::detail::sentinel` was working fine with `is_same`
<gonidelis[m]>
3. That line was `enable_if<typename is_iterator<Iter>::value>::value>` at first and we thought with hkaiser that it is unecassary work and it could be more straightforward
<gonidelis[m]>
2. Sorry i am not quite familiar with what re references and qualifiers are :/ could you explain?
<K-ballo>
typename is_iterator<Iter>::type would always be well-formed, it should be checking nothing
<K-ballo>
but then you have a false check for int64_t pairs, I'm not sure how would that correctly fail without the is_iterator check
<K-ballo>
actually, is_iterator doesn't even have a type... where is that coming from?
<K-ballo>
I'm so confused at how your tests can be passed right now
<K-ballo>
*passing
<K-ballo>
from what I can see, is_sentinel_for should always be yielding false.....
<K-ballo>
(and is_iterator needs ... help....)
<K-ballo>
gonidelis[m]: are tests actually passing? have you tried since you did that is_iterator change?
<hkaiser>
K-ballo: that's my fault, I didn't properly look at the is_iterator
<K-ballo>
well yes, but is_iterator<Iter>::type in always_void should have been meaningless anyways
<K-ballo>
is_iterator<Iter>::type should always exist, and be either true_type or false_type
<hkaiser>
right
<gonidelis[m]>
K-ballo: about the test... I was of the impression that I checked the tests after the change... might be wrong though. Sory. So bottom line: should I put that `enable_if` back again or should I try a completely different implementation?
<hkaiser>
the enable_if<is_iterator<>::value> was one correct way of doing things after all
<K-ballo>
gonidelis[m]: you want the enable_if, as you want to reject non-iterators
<Yorlik>
Did any of you ever use mimalloc with vcpkg and cmake? I'm running into a weird issue where having mimalloc installed and using the vcpkg toolchain file suddenly injects mi_version into every single executable and the build break in the linking phase when the symbol is missing, even if I'm not using the symbol or linking against mimalloc. CMake isn't even able to build it's test executable because of this
<Yorlik>
problem. I compiled HPX successfully with mimalloc, but even test programs in the project not using mimalloc or hpx now break.
<K-ballo>
we also want to fix our is_iterator to be a proper boolean characteristic trait
<hkaiser>
good point
<gonidelis[m]>
hkaiser: I add that on my task list then ;)... I will ask you more on this though as soon as I fix the existing PR first :)
<hkaiser>
thanks!
<gonidelis[m]>
K-ballo: So just to be sure: I change it like `typename util::always_void<
<K-ballo>
I misread, I thought you were doing something else
<K-ballo>
also, formatting
<gonidelis[m]>
hkaiser: yup... just did.
<gonidelis[m]>
K-ballo: yy I know... it should fix with `clang-format` right? Or is it sth that I should check manually like some camelcase thing
<gonidelis[m]>
?
<K-ballo>
just clang-format, your indentation is off
<gonidelis[m]>
yeah sure...
<gonidelis[m]>
OK so I hope everything is fine now... back to the main problem: whas should I do with `is_same` -> `is_sentinel_for` on the `is_range` trait?
<gonidelis[m]>
K-ballo: hkaiser ^^
<K-ballo>
now that is_sentinel_for is fixed, is_range should use it
<gonidelis[m]>
ahhh perfect...
<K-ballo>
the main problem ought to have been is_sentinel_for always returning false :P not is_range tripping on it
<gonidelis[m]>
So again: the reason that `is_sentinel_for` was returning false is because `is_iterator` was returning either `ture_type` or `false_type` instead of `true_type` - nothing ?
<hkaiser>
right, and again apologies, I misled you
<gonidelis[m]>
No .... believe me: that misunderstanding helped me a lot to understand better how the whole thing works (and when does it not work too ;p ). Not to mention that we 've spotted that `is_iterator` flaw ;)
<gonidelis[m]>
So np for me :D
<K-ballo>
well, almost.. it was returning false because is_iterator<X>::type did not exist, if it did exist as expected then is_sentinel_for would have always returned true
<gonidelis[m]>
side question: when I make a change on `is_range` and I recompile the whole thing, it takes like 2-3 minutes. Is that because `is_range` is a core trait that affects lots of object files??
<hkaiser>
make will always rebuild the files that are directly or indirectly affected by a change
<gonidelis[m]>
K-ballo: ahhh!!!! so it's exactly the opposite of what I said ;p
<K-ballo>
the important bit is that sfinae kicks in in the returns X or nothing case
<K-ballo>
enable_if<C>::type returns nothing when C is false
<gonidelis[m]>
yeah. That I definately understand ( kudos to hkaiser 's lectures). So we should change `is_iterator` in order to behave according to sfinea, is that right?
<hkaiser>
gonidelis[m]: it currently exposes only 'value', it also needs to expose 'type'
<gonidelis[m]>
hkaiser: so `is_range` must affect a lot of files ;).
<gonidelis[m]>
hkaiser: ok got it!
<gonidelis[m]>
ok good news: `is_range` both compiles and passes the tests :D
<Yorlik>
I think there is an issue with the way how HPX is using mimalloc. It is using find_package(mimalloc) but doesn't have its own find_mimalloc. So HPX basically requires vcpkg to provide mimalloc and I can't use a custom mimalloc installation, since - at least on windows - the mimalloc build does not provide a cmake file. So either I have to use vcpkg - which currently seems to not work - or roll my own
<Yorlik>
find_package for mimalloc.
<K-ballo>
gonidelis[m]: no, is_xxx traits are expected to extend true_type/false_type
<K-ballo>
if you want sfinae you add enable_if to that, as you just did
<gonidelis[m]>
ok ok... great. I have fully comprehended what you are saying :)
<Yorlik>
Seems the problem remains, even when building mimalloc directly with CMake. However - this strange symbol injection is still haunting me.
<gonidelis[m]>
Is it better if I include the original path for `iter_sent` which is on another test (`libs/algorithms/tests/regressions/`) or should I add `iter_sent` to the same folder with `is_sentinel_for.cpp` ??
<gonidelis[m]>
hkaiser: ^^
<hkaiser>
gonidelis[m]: no, it's a testin gfacility, I'd say leave it there
<gonidelis[m]>
ok ;)
<gonidelis[m]>
hkaiser: Just updated the PR. Feel free to have a look whenever you are available ;)
<hkaiser>
gonidelis[m]: great, looks good now
<Yorlik>
hkaiser: I believe there is an issue with mimalloc in the HPX find_package run. It performs a CMake test compile with /INCLUDE:mi_version propagated into the test compile which breaks it, since the test executable does not link with mimalloc. This leads to a missing symbol error in the cmake cache generation phase.
<hkaiser>
ok
<Yorlik>
So - HPX compiles with mimalloc, but using find_package(hpx ... afterwards is broken - at least for me (Windows)
<hkaiser>
any ideas how to fix this?
<Yorlik>
It's somewhere in the call stack of dind_package(hpx
<hkaiser>
isn't it suffiecient for HPX for load mimalloc?
<hkaiser>
does the app still need to do that?
<Yorlik>
For some reason find_packages starts a test compile of a small program and injects that symbol
<hkaiser>
Yorlik: do you need to do your own find_package(mimalloc)?
<Yorlik>
Any program linked with mimalloc has no issue with that, but that small test has
<Yorlik>
hkaiser: I managed to compile mimalloc on windows with cmake
<Yorlik>
So it generates a cmake file
<Yorlik>
But the issue is in HPX, I believe
<hkaiser>
that's not what I asked
<Yorlik>
I do not need to make any custom file, if and only if I do NOT compile mimalloc with VS but CMake
<Yorlik>
if I compile mimalloc with VS as is default on windows I have no cmake file
<hkaiser>
I meant: do you need to invoke find_package(mimalloc)
<Yorlik>
To build HPX?
<Yorlik>
I think i should rebuild HPX with my custom mimalloc build btw
<Yorlik>
It should be enough if I give HPX my mimalloc_DIR
<Yorlik>
testing that right now
diehlpk_work_ has joined #ste||ar
diehlpk_work has quit [Ping timeout: 260 seconds]
<hkaiser>
Yorlik: ok, I lost you - what is your problem again?
<hkaiser>
(sorry)
<Yorlik>
My main issue is, that with mimalloc activated find_package(hpx ... breaks with that linking error
<Yorlik>
Even if I can build HPX beforehand correctly
<Yorlik>
with mimalloc
<hkaiser>
ok
<hkaiser>
interesting
<hkaiser>
so we need to propagate mimalloc through the HPX::hpx target
<Yorlik>
it's a smallish testcompile run by cmake inside find_package
<hkaiser>
Yorlik: would you mind creating a ticket for this?
<Yorlik>
if I could just use the mimalloc includes and symbols by including a mimalloc anabled hpx that would be nice
<Yorlik>
NP
<Yorlik>
I'M doing this final test and then do a writeup
<hkaiser>
thansk
<Yorlik>
hkaiser: The HPX build breaks with my custom mimalloc
<Yorlik>
But it says it cannot find Findmimalloc.cmake
<hkaiser>
sure, it relies on it
<Yorlik>
the file is called mimalloc-config.cmake
<hkaiser>
then it should find it
<Yorlik>
There are actually two naming conventions for these files, which are both valid in the CMake world.
<hkaiser>
yes
<Yorlik>
mimalloc-config.cmake exists at the given location
<hkaiser>
then something else is wrong
<Yorlik>
Yep
<hkaiser>
we just instruct cmake to find it, the rest is out of our control
<Yorlik>
I think your find package commands mentions version 1.0 - I have 1.6 - so it should work, i think+
<Yorlik>
Let me rename that file as a test ...
<Yorlik>
Oh I see ...
<Yorlik>
By not providing "Findmimalloc.cmake" in CMAKE_MODULE_PATH this project has
<Yorlik>
asked CMake to find a package configuration file provided by "mimalloc",
<Yorlik>
but CMake did not find one.
<Yorlik>
So - giving it as mimalloc_DIR seems not to work - it wants it in the modules path
<hkaiser>
nah
<hkaiser>
doesn't sound right
<K-ballo>
a <pkg>_DIR pointing to the directory containing the config file is ok
<K-ballo>
a plain find_package call will first look for find, and then when that fails for -config
<Yorlik>
I gave it the mimalloc_DIR
<Yorlik>
Just like this: -Dmimalloc_DIR="C:/Arcanima/AC_INSTALL/mimalloc/mimalloc-1.6/cmake"
<hkaiser>
Yorlik: but you renamed you r-config file to find... that's wrong
<Yorlik>
Its a duplicate - I have both now
<hkaiser>
find operates differently from -config
<K-ballo>
it won't look for Find in _DIR
<Yorlik>
OK - removing it
<Yorlik>
Maybe its the quotes
<Yorlik>
Did I mention every sane person hates CMake?
<Yorlik>
crap - it was the quotes around the path - now it builds
<Yorlik>
I'll have to chack if that was the issue before too
<K-ballo>
that'd be interesting...
<Yorlik>
Still that symbol injection looks weird
<K-ballo>
I find it unlikely, but you never know... try `"-Dmi...."` for quotting next
<Yorlik>
Makes sense
<Yorlik>
So - I'm now building HPX with my custom mimalloc build. Got to see if using it then works.
jaafar has joined #ste||ar
<Yorlik>
Same error
<Yorlik>
I'll make an issue
<K-ballo>
which compile tests are actually being affected?
<Yorlik>
When I run the cmake cache creation, inside my find_package(HPX ... a small test compile is run and somehow a "/INCLUDE:mi_version" find's its way into the linker command line and breaks it all.
<Yorlik>
So - either the test compile would need to be linked against mimalloc or that part of the linker command must go away.
<K-ballo>
which compile test is that?
<K-ballo>
there should be no compile-tests running during a find_package call
<Yorlik>
It happens when using find_package(HPX CONFIG REQUIRED)
<Yorlik>
during the cache creation phase
<K-ballo>
what's the cache creation phase?
<Yorlik>
When building the cache but not yet compiling
<K-ballo>
the cmake configuration phase?
<Yorlik>
Yes
<K-ballo>
whose's projects configuration
<Yorlik>
Mine.
<Yorlik>
It happens inside this find_package call
<K-ballo>
is your find_package doing special stuff?
<Yorlik>
I have no custom find_package. I just giv it the HPX_DIR
<K-ballo>
everything HPX is already built when calling find_package(HPX, there are no compilation tests to be run
<K-ballo>
cmake's own compilation tests kick in when enabling languages, but since there's nothing to build in HPX there are no languages to enable either
<Yorlik>
Thats the variable: HPX_DIR = C:/Arcanima/AC_INSTALL/hpx/stable/RelWithDebInfo/lib/cmake/HPX
<K-ballo>
which compilation test is the one causing the problem?
<Yorlik>
It's a small testfile, which CMake is often using.
<Yorlik>
I have no idea why and how this is triggered.
<Yorlik>
I only know it happens inside the find_package
<K-ballo>
how have you diagnosed that?
<Yorlik>
I have big printouts above and below that line and the first is printed, the second not, because it breaks
<K-ballo>
file an issue with hpx, something seems to be massively broken
<Yorlik>
K-ballo: Just for fun I tried outcommenting the line you mentioned - I could generate the cache, but the build still has this issue, that the mi_version symbol get injected and not found in any program not linked against mimalloc
<Yorlik>
In the compilation/linking phase
<Yorlik>
So - little test and utility programs on the project get somehow "poisoned" with this symbol and then break.
<K-ballo>
that's a different error
<Yorlik>
I have no idea how that happens.
<Yorlik>
Needless to say I didn't change anything global or in the definition of these targets
<K-ballo>
well it appers mimalloc, whatever that is, has to be forced to be linked (for example by calling mi_version() somewhere)
<K-ballo>
but that's a mimalloc use problem, not a terribly bogus config file problem
<Yorlik>
So somehow they force it on every single target?
<Yorlik>
I looked in the mimalloc config files but couldn't find anything that would do that - I guess this is a bit over my head in the moment.
<K-ballo>
actually, now that you mention it... that /INCLUDE=mi_version is doing exactly that, attempting to force link
<Yorlik>
Yes. But why? And what triggers it?
<K-ballo>
mimalloc does
<Yorlik>
For the executable that is suppoised to use it I nly used local, target oriented commanbds