<Yorlik>
simbergm: Was it you who set up breathe for the docs?
<Yorlik>
NVM - found the answer in the source ..
<simbergm>
Yorlik: I'm the guilty one
<Yorlik>
OK
<Yorlik>
I just was shocked looking at this huge CMake for the docs
<simbergm>
if there's something you'd like to see documented outside of the source let me know
<Yorlik>
And i wondered if there is a simple answer
<Yorlik>
to template documenting
<Yorlik>
I tried it with breathe and failed horribly
<Yorlik>
I use doxygen in general
<Yorlik>
But I have a more high level documentation in sphinx and trid using breathe to pull docs from the doxy xml
<Yorlik>
Buit templates explode on me. Simple structs are fine
<Yorlik>
Hints 7 Tps / ideas ?
<simbergm>
you can use vanilla sphinx+breathe+(auto)doxygen without cmake and I think you'd get decent results
<simbergm>
yeah, the doxygen/breathe bridge is a bit flakey
<Yorlik>
Its only the templates
<simbergm>
we use what we have but there's a ton of warnings
<Yorlik>
Did you run into any issues concerning templates?
<simbergm>
yep
<simbergm>
I don't have a good solution for that
<Yorlik>
How did you manage to get them documented?
<Yorlik>
A bad working solution would also be nice :)
<simbergm>
it hasn't blown up with hard errors though
<simbergm>
and shouldn't in most cases
<Yorlik>
I'm getting this in the doc output: doxygenstruct: Cannot find class “agns::memory::ContiguousPoolAllocator<typename T, FreelistType FL>” in doxygen xml output f
<Yorlik>
Its printed on the page. The rest of the page is OK
<Yorlik>
But the templkate is undocumented
<simbergm>
everything we have is through breathe, so no manual .. doxygenstruct:s
<Yorlik>
Its in the Doxygen output though - I double checked
<Yorlik>
Uh .. How did you do that? Is it in the plain breathe docs?
<Yorlik>
Like just follow the recipe?
<Yorlik>
OK .. doxygenindex:: seems to work
<Yorlik>
OMG - it's not even respecting my namespaces ....
<Yorlik>
That's painful
<simbergm>
It is painful :/ I'm not happy with our api docs but sphinx was overall better than boostbook
<Yorlik>
I thinka high level documentation with links to doxygen and an occasional manual snippet is good enough
<Yorlik>
But then the code really needs to have good comments
<Yorlik>
I have big hpes in the GSOD
<Yorlik>
hopes
aserio has quit [Ping timeout: 276 seconds]
aserio has joined #ste||ar
diehlpk_mobile has joined #ste||ar
<Yorlik>
simbergm: OK - finally got it working by fuzzing it (trying stuff randomly)
<Yorlik>
I tried a ton of themes, but there is no decent theme for API documentation.
<Yorlik>
We need a C++ developer who uses breathe and has a pro webdev partner doing an awesome theme for C++ documentation :)
diehlpk_mobile has quit [Ping timeout: 276 seconds]
<simbergm>
Yorlik yep that'd be great...
<Yorlik>
After trying a ton I came back to the rtd theme - I think its the best for APIs, concerning the typography
<Yorlik>
For plain text stuff I like agogo and some others
<simbergm>
BTW, exhale is something we want to try again, could give slightly more usable api docs
<simbergm>
It's another sphinx plugin
<Yorlik>
I saw it, but didn't try it yet. I only know it'Äs on top of breathe
jaafar has quit [Ping timeout: 276 seconds]
<Yorlik>
Do any of you have experience with Apache Ignite? I am pondering to use it for storage, alternatively Cassandra.
aserio has quit [Ping timeout: 276 seconds]
<zao>
As a rule, I don't even bother with anything Apache <X> for personal or work purposes.
<zao>
It's where over-engineered enterprise junk goes to die :)
<zao>
(I'm sure there may be worthwhile projects there, just that I never ran into any)
<Yorlik>
And how does that apply to Ignite or Cassandra?
<Yorlik>
Are junk? Overengineered?
<Yorlik>
Dying?
<zao>
I've never heard of Ignite, but in general if anything is prefixed with "Apache", it's nothing I want.
<Yorlik>
So your answer to my question is a general "Apache stuff is mostly shit" ?
<zao>
Not necessarily "shit", but often over-engineered and abandoned by the original owners into the ASF's welcoming arms.
<zao>
As for these two, again, no idea.
<zao>
Just a good guideline, I've found.
<Yorlik>
I'm sure you have better alternativs then, especially for distributed in memory databases?
<Yorlik>
Redis?
<zao>
Not my department, sorry.
<Yorlik>
Allright. I'll watch out for overengineered Trolls in their code then ;)
<heller>
Yorlik: exasol :P
<Yorlik>
Hey Thomas!
<heller>
hey chris!
<Yorlik>
So - you want to sponsor us a permanent ExaSol Cluster License? ;)
<heller>
Ha
nikunj97 has joined #ste||ar
rori has quit [Quit: WeeChat 1.9.1]
jaafar has joined #ste||ar
jaafar_ has joined #ste||ar
jaafar has quit [Ping timeout: 248 seconds]
aserio has joined #ste||ar
hkaiser has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
hkaiser has joined #ste||ar
<parsa>
what's the difference between `hpx::shared_future(std::move(f))` and `hpx::make_shared_future(std::move(f))`?
<parsa>
nvm
<parsa>
probably pre-c++17 the template arg requirement is the answer
<hkaiser>
parsa: I think constructing a shared future gives you a shared_future<T>, your make_shared_future gives you a shared_future<shared_future<T>>
<parsa>
hkaiser: both give me hpx::lcos::shared_future<int>. my code wouldn't work otherwise
<hkaiser>
parsa: ok
<hkaiser>
however note that a shared_future<T> is constructable from a shared_future<shared_future<T>>
<parsa>
not sure what that means. are you saying both shared_futures will be unwrapped and the result is put in a new shared_future?
<parsa>
:s/both/the nested/
<hkaiser>
yes
<hkaiser>
you can assign a sf<sf<T>> to a sf<T>
<hkaiser>
(I think so at least, let me have a look)