nikunj has quit [Remote host closed the connection]
nikunj has joined #ste||ar
Amy1 has quit [Quit: WeeChat 2.2]
Amy has joined #ste||ar
Amy has quit [Client Quit]
Amy has joined #ste||ar
Amy is now known as Guest88210
rori has joined #ste||ar
jbjnr_ has quit [*.net *.split]
tarzeau has quit [*.net *.split]
nikunj has quit [*.net *.split]
jbjnr has joined #ste||ar
nikunj has joined #ste||ar
hkaiser has joined #ste||ar
<hkaiser>
simbergm: yt?
<simbergm>
hkaiser: here
<hkaiser>
hey
<hkaiser>
yesterday I noticed a minor inconsistency in how we structure various modules
<hkaiser>
some modules have their associated traits directly in the module directory, some have those in hpx/traits
<hkaiser>
where should we put those?
<hkaiser>
hpx/traits/? hpx/foo/? or peraps hpx/foo/traits/?
<hkaiser>
simbergm: ^
<simbergm>
mmh, true
<simbergm>
we never really discussed or decided on anything on this
<simbergm>
rori ^
<simbergm>
I think hpx/modulename/traits sounds best
<simbergm>
opinions?
<simbergm>
hkaiser: ^
<hkaiser>
I think so too
<hkaiser>
hpx/modulename/traits sounds best to me
<hkaiser>
second best option would be hpx/traits (i.e. leave the relative path as is, just move the file)
<rori>
same !
<hkaiser>
let's create a ticket
<hkaiser>
to track the required changes
<simbergm>
sure
<simbergm>
you'll open it?
<hkaiser>
I'm at fault here mostly, sorry for not discussing this earlier
<hkaiser>
will do
<simbergm>
no problem, we should do some thinking as well ;)
<simbergm>
thanks for bringing it up
<simbergm>
hkaiser: I replied on 4050, were there other tests on pycicle that you saw fail?
<simbergm>
I think it looks okay to merge (after a bit of waiting...)
<hkaiser>
simbergm: yah, I resolved some conflicts just now, let's see
<hkaiser>
simbergm, rori: #4053
<simbergm>
hkaiser: thanks!
<simbergm>
btw, does the resiliency module need reviewing? nikunj is still dealing with c++11 compatibility?
<hkaiser>
simbergm: yes, nikunj is working on the c++ compatibility, otherwise this is good to go
<simbergm>
all right, nice
<rori>
And any reason why we called our modules target hpx_<name> instead of <name>_module ?
<zao>
Slightly less chance of collision with the consuming application, or are they scoped somehow?
<simbergm>
zao is right, although it doesn't matter too much right now since we don't install the modules
<simbergm>
but this way the libraries end up being called libhpx_modulename and when we eventually install (some) modules they'll be namespaced
<simbergm>
adding a module suffix seems redundant since they already have a lib prefix (at least on linux)
<Yorlik>
First graphical output in a really looong time I generated when playing with Hilbert Curves today: https://imgur.com/a/OFmziRy
<Yorlik>
I really missed messing with graphic - should do it more - it's just so much fun :)
<rori>
right
<hkaiser>
Yorlik: nice
aserio has joined #ste||ar
hkaiser has quit [Quit: bye]
<nikunj>
simbergm: I will try to finish everything by the weekend, I'm having some trouble making it C++11 compatible
<simbergm>
nikunj: no rush! I was just curious about the state of that PR
hkaiser has joined #ste||ar
<hkaiser>
simbergm: I did look at the serialization stuff yesterday
<hkaiser>
simbergm: I think I know what needs to be done, so I'd suggest to first do some refactoring (akin what you're doing with threads) and only after that extract it into a module
<hkaiser>
I believe the resulting module wouldn't depend on anything but config etc.
<hkaiser>
also, on an unrelated note, I did the bost library detection for the program_options module in the module itself
<hkaiser>
this might be doable for the filesystem module as well (i.e. remove it from SetupBoost.cmake)
<simbergm>
yes, and yes! I saw your changes for program options and that's a really good direction
<simbergm>
I can update the filesystem module to do the same
<simbergm>
and thanks for having a look at serialization
<simbergm>
how are you planning on getting rid of naming/agas/etc.?
<hkaiser>
externalize it
<simbergm>
wait, does that mean something specific?
<hkaiser>
we already have the actual functionality in the preprocess helper
<hkaiser>
no, I want to separate the serialization from a) handling futures and b) handling id_types
<hkaiser>
all of this can be done externally to the base serialization
<hkaiser>
all we need is a opaque pointer stored in the archive
jaafar has quit [Ping timeout: 276 seconds]
<simbergm>
okay, sounds like you're on top of things
<simbergm>
this is why I appreciate your help on those parts of the code base!
<rori>
hkaiser: if you have time, could you have a look at the travisci error on windows for the cmake refactoring PR, cause I think it almost ready to go, and I couldn't find the reason for this error on windows from my linux env :/
aserio has quit [Ping timeout: 276 seconds]
<heller>
hkaiser: I'd rather get rid of the special handling entirely
<heller>
The special handling for the corner case when gids are being split isn't only in the serialization layer but also bubbles up in the parcelport
Yorlik has quit [Read error: Connection reset by peer]
USTOBRE has quit [Quit: Connection closed for inactivity]
<K-ballo>
hkaiser: yt?
rori has quit [Quit: bye]
aserio has joined #ste||ar
<hkaiser>
K-ballo: here now
<K-ballo>
hlaiser: see pm
Yorlik has joined #ste||ar
<Yorlik>
hkaiser: yt?
hkaiser has quit [Quit: bye]
aserio has quit [Ping timeout: 258 seconds]
aserio has joined #ste||ar
aserio has quit [Quit: aserio]
hkaiser has joined #ste||ar
<Yorlik>
hkaiser: yt?
<hkaiser>
Yorlik: here
<Yorlik>
Up for some tedious work? ;)
<Yorlik>
hkaiser: ^
<hkaiser>
Yorlik: not now, sorry
<Yorlik>
OK. I'll work on my Quadtree then :)
<Yorlik>
hkaiser: Just realized you were involved in the creation of the Boost R-Tree. Would it be hard to modify this R-Tree to utilize Hilbert Curves to speed up insertions and relocation of entries (moving objects)?
<Yorlik>
I'm a bit torn wether to use Quadtrees or R-Trees for my spatial search.
<hkaiser>
quadtrees are difficult to use if you have anything but point data
<hkaiser>
Yorlik: ^^
<Yorlik>
So - Since Objects have bounding boxes or capsules --> R-Tree? What about using Hilbert Curves?
<Yorlik>
Since many objects will move there will be lots of changes
<hkaiser>
why hilbert curves?
<Yorlik>
I was thinking about dividing the objects into grounded (= 2.5D ) and flying (full 3D) ones.
<hkaiser>
they may give you proximity, but only in certain directions
<Yorlik>
Hilbert Curves for faster reindexing / insertion
<hkaiser>
nah
<hkaiser>
nobody has shown that hilbert curves are actually faster
<hkaiser>
they are just cooler ;-)
<Yorlik>
lol
<Yorlik>
How would you optimize an R-Tree for frequent reindexing of moving objects?
<Yorlik>
My idea still is to use fixed size, relatively small buckets at the lowest level / leaf level
<Yorlik>
Like 16*16 m or so
<Yorlik>
maybe smaller
<Yorlik>
Imagine a crowd of moving bounding boxes = players/animals/monsters
<hkaiser>
rtrees are fairly fast
<zao>
Spatial hashes are nice too, especially if you have a good idea of the granularity you want to query with.
<hkaiser>
sure, but quadtrees are bad if you have bboxes
<Yorlik>
I think we will use bboxes and capsiles mostly
<hkaiser>
sure
<hkaiser>
long time ago I developed a special quadtree-like structure for handling bboxes
<hkaiser>
essentially a 4d quadtree
<hkaiser>
extremely fast
<hkaiser>
in 4d a bbox is representable by a 4d point
<Yorlik>
4d Quadtree sounds like a generalization beyond the Octree