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/
eschnett has joined #ste||ar
jgolinowski has quit [Remote host closed the connection]
<brjsp>
should i copy the rest or do you see chat history?
<hkaiser>
I can see the history, sec
<hkaiser>
yes, your assessment is correct
<hkaiser>
the hpx::ostream needs a major overhaul
<brjsp>
The lazy operators call to streaming_operator_lazy
<brjsp>
Which calls to
<brjsp>
the std::ostream operators
<brjsp>
Which calls to whatever streambuf we pass
<brjsp>
But the problem is
<brjsp>
The non-lazy operators
<brjsp>
ALSO use std::ostream::operator<<
<hkaiser>
yah, it's royally screwed up ;-)
<brjsp>
Which means it is not possible to fix only the lazy operator without rewriting everything else
<hkaiser>
nod
<hkaiser>
the lazy operator is not really necessary as it's doing almost the same as the other one
<hkaiser>
both are 'lazy' in some sense
eschnett has joined #ste||ar
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
brjsp has quit [Quit: Page closed]
david_pfander has quit [Quit: david_pfander]
<K-ballo>
after some unexplained issues with vcpkg, I finally got to build phylanx
<K-ballo>
apparently not successfully though, get an error about missing functions in symbol tables
<K-ballo>
are there subtleties to working directories, plugins, etc?
<aserio>
K-ballo: yes
<aserio>
K-ballo: you have to build the plugins explicitly in VS
<K-ballo>
I build them, they ended up in phylanx/ relative to my test binary, that ok?
jaafar has quit [Ping timeout: 252 seconds]
<aserio>
K-ballo: The last time I build them it just worked out of the box..... so yes?
<aserio>
:p
<aserio>
I want to say that they are automatically built in the right place but there was some CMake issue with Windows which required to to explicitly build them
hkaiser has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
aserio has joined #ste||ar
<diehlpk_work>
Some one transformed the university to Super Mario Land. Was amazing
aserio has quit [Ping timeout: 252 seconds]
aserio has joined #ste||ar
jaafar has joined #ste||ar
aserio has quit [Ping timeout: 260 seconds]
<K-ballo>
it's crashing in some weird ways, I'll have to build in debug mode to see what's going on
aserio has joined #ste||ar
aserio has quit [Ping timeout: 250 seconds]
jgolinowski has quit [Quit: Leaving]
aserio has joined #ste||ar
aserio has quit [Ping timeout: 240 seconds]
hkaiser has quit [Quit: bye]
bibek has quit [Quit: Konversation terminated!]
brjsp has joined #ste||ar
<brjsp>
I am adjusting the find_* algorithms for Ranges TS
<brjsp>
And just found a very stupid bug when find_end sometime used == istead of the user given comparison operator
bibek has joined #ste||ar
<K-ballo>
missed by the tests?
<brjsp>
yes
<brjsp>
The tests apparently never bothered to to custom equalities
<K-ballo>
:/
<brjsp>
I will be doing a pull request today or tomorrow
<K-ballo>
we can't use `std::equal_to<void>` because that's C++14, but there is a C++ implementation in the codebase already
<brjsp>
Ouch
<K-ballo>
just check the implementation of other algorithms, it's just a matter of replacing `std::equal_to<void>` with `util::equal_to` or something like that
<brjsp>
Ouch, detail::compare_to requires the type to be copyable
<brjsp>
And find doesnt
<brjsp>
Or is it something we dont care about because parallel and all
<brjsp>
As in, can i copy val int copare_to
<brjsp>
into*
<K-ballo>
no, it doesn't
<brjsp>
I can't do this
<brjsp>
detail::compare_to<T const &>
<K-ballo>
it a) requires copy or move, b) works with references too
<K-ballo>
no?
<brjsp>
Because then the constructors get duplicated
<K-ballo>
that's odd, we have tie-breaker rules for that case in the standard
<K-ballo>
T const& const& would win over T const& &&
<K-ballo>
note your std::bind based predicate requires copies too
<brjsp>
How would you do this function
<brjsp>
detail::compare_to<T const &> does not compile under MSVC, haven't checked other compilers
<brjsp>
Ugh
<brjsp>
This may take a long time
<K-ballo>
you could look at parallel find_if for inspiration
<brjsp>
I can do a pull request with just the bug fix for find_end
<brjsp>
find_if is easy
<brjsp>
Or i could rangify everything except find
<K-ballo>
my bad, I meant parallel find
<K-ballo>
rangify-ed parallel find will end up calling parallel find underneat anyhow, won't it?
<brjsp>
Nnnnno
<brjsp>
You see, the whole problem is how to put the value into find_if
<K-ballo>
no? mmh
<brjsp>
Should we just use a freaking capturing lambda? That still won't help with the range version
<K-ballo>
I no longer understand what the concern is, what I've been imagining so far apparently isn't, and I can see you are starting to get frustrated
<K-ballo>
you should probably wait for hkaiser to pop up, and ask advice on how to proceed
<K-ballo>
I don't see anything immediately wrong with a lambda.. but I'm just going with your std::bind snippet from above