<ms[m]>
that was before we knew about cpp-dependencies
<ms[m]>
but I wouldn't do anything about this now before we've given object libraries another go
<ms[m]>
if that works we won't need another tool
<ms[m]>
it's not like we didn't have funky dependencies before all the modularization started
<ms[m]>
so we're improving, we just don't have quite the proper tools to enforce it at the moment
<hkaiser>
ok
<Yorlik>
If you'd like Doxygen to produce controlled dependencies you could use its grouping commands. For my own purposes I usually rely on the file dependency graphs it produces.
<ms[m]>
we could easily throw a std::exception there instead
<K-ballo>
I never liked our errors, I'm gonna have another look again
<ms[m]>
on the other hand the dependency from errors to functional comes from my recent change from std::function to hpx::function_nonser
<ms[m]>
that could also be reverted just in the errors module
<K-ballo>
any "errors" module ought to be way more lower level
<ms[m]>
K-ballo: that'd be very nice ;) I don't think I've made it any better...
<ms[m]>
agreed
kale[m] has quit [Ping timeout: 260 seconds]
<ms[m]>
zao: sorry, not ignoring you, just distracted :) do you happen to know of a standard-ish findmake file? I guess throwing one together wouldn't be too hard either...
kale[m] has joined #ste||ar
<zao>
not really, just bothered by that the test always seems to be broken :D
<ms[m]>
make is not a huge dependency ;) but I get that it's annoying...
<zao>
It's a huge dependency if you don't have it installed.
<zao>
Bare-bones containers, some msys environments on Windows, etc.
<ms[m]>
it's not going to be very bare-bones once hpx is there ;)
<ms[m]>
but point taken
nikunj has quit [Read error: Connection reset by peer]
nikunj97 has quit [Read error: Connection reset by peer]
<ms[m]>
zao: how do you feel about make *and* tr as a forced dependency? ;)
<zao>
Document it and make it work in all scenarios on Windows, sure :P
<ms[m]>
that looks like the missing stack frames are from hpx_main or whatever the entry point is?
<hkaiser>
run_hlepr invokes hpx_main, yes
<ms[m]>
:/
<hkaiser>
run_helper
<ms[m]>
can nan reproduce it?
<hkaiser>
yes, it's her error log
<hkaiser>
nan11: yt?
<ms[m]>
yeah, but I mean reliably?
<hkaiser>
I think so
<ms[m]>
unless there's a race in setting the thread local runtime_distributed pointer, that should be more or less impossible...
<hkaiser>
that's what I was thinking as well
<ms[m]>
or the runtime mode is set to local for some reason
<hkaiser>
would that be diagnosable?
<ms[m]>
yeah, I suppose it would
<ms[m]>
if get_runtime_ptr is not nullptr the mode can be checked from runtime_configuration/command_line_handling
<hkaiser>
no idea how this could happen, I'll ask her to tell us how she built things
<ms[m]>
mismatching headers? ;) default_ used to be 3, now local is 3...
<hkaiser>
ms[m]: that could be the case, some stale headers installed
<hkaiser>
ms[m]: never change enum numbers ;-)
<ms[m]>
it seems unlikely things would build cleanly in that case though...
<ms[m]>
but it's not impossible
<ms[m]>
always break abi!
<hkaiser>
worth trying to clean things
<ms[m]>
we can still swap them before the release if you think it would be a problem
<hkaiser>
nod
<ms[m]>
yep
hkaiser has quit [Quit: bye]
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
hkaiser has joined #ste||ar
bita_ has quit [Ping timeout: 264 seconds]
kale[m] has quit [Ping timeout: 260 seconds]
kale[m] has joined #ste||ar
kale[m] has quit [Ping timeout: 260 seconds]
sayefsakin has joined #ste||ar
kale[m] has joined #ste||ar
rtohid has quit [Ping timeout: 245 seconds]
rtohid has joined #ste||ar
sayefsakin has quit [Quit: Leaving]
<weilewei>
So I get a segfault, and then use gdb to go back to the frame that causes segfault, I print that pointer. It says Cannot access memory at address 0x48
<weilewei>
How should I know who deletes it?
nan11 has quit [Remote host closed the connection]