diehlpk_work has quit [Read error: Connection reset by peer]
nikunj97 has quit [Remote host closed the connection]
quaz0r has quit [Ping timeout: 244 seconds]
quaz0r has joined #ste||ar
<mdiers_>
heller: yt?
<heller>
Hey
<mdiers_>
heller: good morning, the gist paste is extended by the dependencies of the hpx lib and app.
<mdiers_>
heller: Did you perhaps have time to reproduce the problem besides the preparations for hlrs? ;-) I found your name there.
<heller>
No, didn't have time to look into it properly
simbergm has joined #ste||ar
<heller>
TBH, I never used gcc sanitizer successfully this far, only clang ones
<mdiers_>
heller: did you build the hpx libraries with clang? I could test it sometime.
<heller>
Yes, all of it
<heller>
One thing you could try is to alter one of the examples to reflect the problem and build it within the main hpx tree, see if the problem exists there as well
<mdiers_>
heller: ok, rebuild with clang is on the way
<simbergm>
tarzeau: I'd be happy to test packages
<simbergm>
I even started making them myself but really didn't like the complexity of the process so I stopped
<simbergm>
would be great to have a package for debian so I'd be happy to help any way I can
<Yorlik>
Why does this call: pecs::TeePtr tp = pecs::TeePtr::newTeePtr<pecs::animal_ent>(); resolve to T=pecs::TeePtr inside newTeePtr and not to pecs::animal_ent ?
<hkaiser>
simbergm: would you have the time to look at #3932? I'd like to get that in asap, if possible
<jbjnr>
hkaiser: heard from khuck recently? I'm going to have a look at APEX to see if I can fix the task names.
<hkaiser>
jbjnr: he is back around after his surgery
<jbjnr>
to your knowledge - does anyone else use apex?
<jbjnr>
I can't believe a bug like this has lasted a year without anyone else getting annoyed by it...
<simbergm>
hkaiser: feel free to merge :)
<jbjnr>
simbergm: I have nothing in my celendar, when it the meeting?
<jbjnr>
grrr. typing
<simbergm>
"the meeting" is probably tomorrow
<jbjnr>
at what O'Clock
<simbergm>
16 I think
<simbergm>
just a sec and I'll check
<jbjnr>
hkaiser: is anyone going to rewrite the SC paper? I'm hoping someone is on it as I can't help.
<simbergm>
9am cdt, whatever that means
<simbergm>
usually it's been 4pm in switzerland
<hkaiser>
jbjnr: we're working on the paper
<hkaiser>
simbergm: CDT == central daylight-saving time
<jbjnr>
hkaiser: thanks
<hkaiser>
jbjnr: any plans to actually get the LF pp into HPX proper?
<jbjnr>
will we be able to make the reviewers happy?
<hkaiser>
jbjnr: I think so
<jbjnr>
hkaiser: when you have met Thomas and convinced him we need it. Or give me a job at LSU!
<hkaiser>
lol
<hkaiser>
we can't afford you
<jbjnr>
too effing right.
<JClave>
hi all, i noticed that the latest commit in master to do with pack_traversal_rebind_container is failing my linux build using gcc. was wondering if its just me?
<hkaiser>
jclave: will be fixed in a sec, I'm going to merge the related PR soon
<hkaiser>
it's a gcc problem
<JClave>
thanks!
<hkaiser>
jclave: merged, pls try again
<JClave>
will do tomorrow. cheers
<hkaiser>
thanks
JClave has quit [Remote host closed the connection]
<Yorlik>
I have two constructors, one is a template: template <typename ENT> TeePtr( ENT* slotPtr ) and TeePtr( TeePtr const* tPtr ), where ENT is a complex template in itself. I am pondering to just change the first, templated one into a factory function, but wanted to ask first if there would be a better way to avoid the confusion that the template fires when I try to use the copy constructor. Ideas?
<Yorlik>
The first (the template) essentially creates a managing, type erased pointer from the raw pointer to the data. Not sure if that should be a in a constructor at all.
<Yorlik>
But std::unique does it too, afaik.
<Yorlik>
err .. unique_ptr
<heller>
Why not go with unique_ptr then?
<Yorlik>
Inside TeePtr is a Unique
<Yorlik>
TeePtr is a typeerased variant
<Yorlik>
It is meant to manage my raw Entities and provide the type erasure for the Gameobjects which use its data
<heller>
Sure, but you could use unique_ptr directly, that way you don't have to reinvent it's functionality and make the intent clear, also seperating functionality
diehlpk_work has joined #ste||ar
<Yorlik>
heller: unique_ptr wouldn't give me the type erasure, would it?
<Yorlik>
I finally separeted the constructors (turned out I made a stupid newbie error writing a copy ctor with * and not &)
* Yorlik
keeps fighting his countless newbie quirks
<heller>
Yorlik: depends, you could have a unique ptr as a member, implementing the type Erasure in your class, leaving ownership semantic to unique_ptr
<Yorlik>
That's how it is currently done.
<Yorlik>
But I think I am trying which might be impossible: Cloning the structure by doing a deep copy of the Unique by copying the data
<Yorlik>
Type erasure is getting in the way a lot
<Yorlik>
I wonder if copying a type erased pointer is possible at all.
<Yorlik>
== deep copy
<Yorlik>
I think I'd probably need some sort of dynamic dispatch - can't trick the type system after all.
<hkaiser>
Yorlik: all of this does not sound right, but I'm too far away to actually tell
<Yorlik>
I'm digging - there's a ton of newbie crap in between.
<Yorlik>
I'm hitting some walls which are far below your level here - need to work soem more on it.
<Yorlik>
I wish I were better trained In C++ already :D
<hkaiser>
Yorlik: it's not the C++ part of what I'm concerned about
<Yorlik>
The concept of cloning a type erased shmartPtr?
<hkaiser>
I think you're trying to solve the wrong problem, not trying to wrongly solve a problem
<hkaiser>
but I don't know anything of what you're doing, so please disregard me
<Yorlik>
I want to make a copy constructor for a type erased managing pointer which does a copy of the managed data
<hkaiser>
add a copy function to your type and call it
<Yorlik>
So I can write like entityPtr = otherPtr
<Yorlik>
Its type erased
<hkaiser>
I meant a copy on the derived type
<Yorlik>
I'm hitting stupid walls af various kinds
<Yorlik>
I think it's just some noob mess and I need to work on sorting it out
<Yorlik>
I have a copy ctor for derived already
<hkaiser>
then your copy() function should be trivial
<Yorlik>
rhis here explodes: std::unique_ptr<pecs::TeePtr::concept> cloned { new model<ENT>( this ) };
<hkaiser>
you can't make a constructor virtual
<zao>
At the point of erasure, that's where you need to capture all the operations you want to do on the erased thing.
<Yorlik>
OK- finally this here:: model<ENT> cloned { this }; gives me this:: No constructor could take the source type, or constructor overload resolution was ambiguous
<Yorlik>
my constructor templates and the copy ctor mess up
<Yorlik>
Just leave me to ma moaning .- i feel bad bothing you with this crap
<Yorlik>
;)
<hkaiser>
what you need is model<ENT> clones = that.clone();
<hkaiser>
or model<ENT>* clone = ...; where clone() is a virtual function on you rhs type
<Yorlik>
that ??
<Yorlik>
I mean that.clone?
<hkaiser>
or rhs.clone()
<hkaiser>
whatever the name of the variable of your rhs is