<parsa>
hkaiser: did make changes till this morning… it got extended till the 14th
weilewei has joined #ste||ar
<hkaiser>
ok, extending makes sense of we were only submission #3
<hkaiser>
parsa: I'd say, stop working on it - it's as good as it gets
<hkaiser>
parsa: we might want to ask Katie to read it over, though
<parsa>
if you feel like it please take peek at the changes i made to the text you added
<hkaiser>
ok
<parsa>
oh if Katie goes through it i'd be greatful
<parsa>
grateful* :)
<weilewei>
How do you know what is the order of your submission? Does it depend on workshops? Scala workshop does not reveal it
<hkaiser>
weilewei: it said submission #3 in the email
<weilewei>
hkaiser ok, our scala email does not say anything
<hkaiser>
parsa: yt?
<parsa>
weilewei: sometimes the order is submission is in the submission id they give you. it's not something they try hard to hide. last year my paper's id was ws_ipdrm103s2 so we figure it was submission #2
<parsa>
hkaiser: yes
<hkaiser>
see pm, pls
<weilewei>
our id is ws_lasalss106s1.... does it mean we are #1 LOL
<parsa>
yes, possibly
<weilewei>
lol, we are so early
<parsa>
or keeping knowledge works at home does decrease productivity or virtual conference are not exciting
<hkaiser>
ms[m]: yt?
<ms[m]>
hkaiser: hey, here
<ms[m]>
did I already manage to break something? :(
<hkaiser>
ms[m]: yah :/
<hkaiser>
two things: a) (not that important) - do you plan to update the script for creating new modules?
<ms[m]>
wee, sorry, how badly?
<ms[m]>
a) that should already work
<hkaiser>
b) the switch_to_fiber stuff is broken, I'm still figuring things out
<hkaiser>
ahh, cool
<ms[m]>
b) ah, that was the part I assumed I might've messed up, sorry
<hkaiser>
I think the linker switch needs to be added to the core module instead the coroutines library
<ms[m]>
would that make sense to enable on the windows builders? I could have a go at fixing it
<ms[m]>
ah, I see
<hkaiser>
yes, makes sense
<ms[m]>
we have two anyway, so we could have one with and one without
<hkaiser>
it's a pure debug option, I'm probably th eonly one ever using it, sorry
<ms[m]>
np, sorry for breaking it
<ms[m]>
do you have time to fix it or should I try fixing it?
<hkaiser>
I'm looking into it, let's see - I might need your help
<ms[m]>
I guess the object files themselves should be in the coroutines module, but the flags on the shared librar(y/ies)
<ms[m]>
ok, I'm here, just let me know
<hkaiser>
yes, thanks
<hkaiser>
ms[m]: also, the object fle currently somehow ends up being part of the hpx_full module
<ms[m]>
hkaiser: clean cache? it might've been in one of the variables that are used for giving sources/objects to the main library
<hkaiser>
could be, true
bita_ has joined #ste||ar
<ms[m]>
hkaiser: sorry about the time for the call with kate... I'll give you a summary at the next hpx meeting
<ms[m]>
hkaiser: I think so but, but I've forgotten already :/
<ms[m]>
*just one but...
<ms[m]>
is it giving you trouble?
<ms[m]>
I can check what happens if I remove it
<K-ballo>
if you remove it as well as removing the explicit instantiation?
<hkaiser>
I think it should be sufficient to export it
<hkaiser>
ms[m]: same is true for all the other explicit instantiations of the same template
<hkaiser>
I'm seeing warnings saying the extern will be ignored if the type is exported
<hkaiser>
btw, I think I have the swit_to_fiber issue solved
<ms[m]>
the only restriction is that it has to be explicitly instantiated once, and once only in the whichever library the template type is
<ms[m]>
if we can do that without the extern that's fine
<hkaiser>
yah, I'll just export all of them
<hkaiser>
that will do the trick
<ms[m]>
hkaiser: ok, sounds good
<K-ballo>
shouldn't the export be on the definition, rather than the declaration?
<hkaiser>
K-ballo: good point - I'm not sure - for msvc it shouldn't make a difference
<hkaiser>
for msvc the declaration will be either marked as import or export depending on the context
<K-ballo>
> Having to mark the definitions only in the explicit instantiations case (for MSVC) whereas everything else requires you to mark the declarations is a weird inconsistency.
<hkaiser>
if it's export then the declaration is actually not a declaration but the definition and the template will be instantiated but still exported
<K-ballo>
ok, so for msvc with dllexport there would be no need for either extern nor the definition then?
<hkaiser>
not sure about gcc/clang, though
<K-ballo>
gcc needs it in the declaration, but also needs a definition
<hkaiser>
K-ballo: yes, the extern is not needed (would receive a warning anyways) and the 'definition in the cpp file would be a duplicate that is discarded at link time
<K-ballo>
bad msvc :/
<hkaiser>
ms[m]: everything compiles and works now for me (see #4953)
<hkaiser>
but gcc fails :/
<K-ballo>
msvc is weird... the entire point of the `extern` is to make it a declaration rather than a definition
<hkaiser>
in other places we have not declared the explicit template at all, just exported it from a source file
<hkaiser>
I'll try to add extern in the header and export it from the source, let's see
<ms[m]>
hkaiser: thanks
<K-ballo>
without the extern declaration, any library including that header will export its own copy of the instantiation
<K-ballo>
this is not necessarily a problem for .so files, though
<hkaiser>
right
<ms[m]>
Do we explicitly instantiate any other templates?
<hkaiser>
I thought we did, but it's only function templates
<hkaiser>
ms[m]: also, hpx_full does not do a unity build anymore
<hkaiser>
K-ballo: yah, extern in the header file and export in the source works for msvc
<ms[m]>
hkaiser: ah, good catch
<K-ballo>
other way around?
<K-ballo>
ah no, my bad
<K-ballo>
darn it msvc
<hkaiser>
let's see what gcc says
<ms[m]>
do you want me to add that back or will you add it to the pr?
<hkaiser>
ms[m]: I can do it if you tell me where ;-)