06:03 <Neeraj> SeverityDescriptionProjectFileLineSuppression State

06:03 <Neeraj> ErrorThe command "setlocal

06:03 <Neeraj> "C:\Program Files\CMake\bin\cmake.exe" -DBUILD_TYPE=Debug -P cmake_install.cmake

06:03 <Neeraj> if %errorlevel% neq 0 goto :cmEnd

06:03 <Neeraj> :cmEnd

06:03 <Neeraj> endlocal & call :cmErrorLevel %errorlevel% & goto :cmDone

06:03 <Neeraj> :cmErrorLevel

06:03 <Neeraj> exit /b %1

06:03 <Neeraj> :cmDone

06:03 <Neeraj> if %errorlevel% neq 0 goto :VCEnd

06:03 <Neeraj> :VCEnd" exited with code 1.INSTALLC:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets159

06:03 <Neeraj> anyone help with this error

06:19 <Neeraj> ok got it and resolve this problem

11:31 <Neeraj> I got error in build tests ,in which dir I have to run "cmake --build . --target tests " this command

11:32 <Neeraj> hkaiser

11:32 <hkaiser> Neeraj: what error do you see (please paste the logs somewhere and give us the link)

11:34 <Neeraj> when I try to run this command in build dir I got "MSBuild version 17.5.0+6f08c67f3 for .NET Framework

11:34 <Neeraj> MSBUILD : error MSB1009: Project file does not exist.

11:34 <Neeraj> Switch: tests.vcxproj"

11:34 <hkaiser> Neeraj: difficult to say what's wrong - but definitely not HPX related

11:36 <Neeraj> and also all binary application showing an error that "libhwloc-5.dll was not found" while I provided actual root dir

11:37 <Neeraj> 2-3 time I rebuilt HPX there is no error but when I try to build tests they showing error

11:41 <Neeraj> I went through you link and try to find the error but my tests are not built yet , tests.unit.modules.runtime_components.distributed.tcp.migrate_component , If the test case is failing due to a timeout, you can try increasing the timeout limit.

11:41 <hkaiser> Neeraj: the easiest ist to copy over that .dll into the directory where the HPX binaries live

11:44 <Neeraj> thanks that resolve the problem

11:47 <Neeraj> so for above tests problem I have  do configuration again and make On the HPX_WITH_TESTS that resolve the problem ?

11:48 <hkaiser> Neeraj: HPX_WITH_TESTS has to be set to on for the tests to be compiled, yes

11:52 <Neeraj> https://app.circleci.com/pipelines/github/STEllAR-GROUP/hpx/14287/workflows/11133811-c981-451a-b4f2-902e2f073e85/jobs/338992/steps      is this issue is resolved or not ?

11:53 <hkaiser> Neeraj: this link shows you the intermittend error we're seeing

11:53 <hkaiser> it doesn't fail always, but it would be nice to understand what's happeneing

11:54 <Neeraj> so this test is updated on HPX repo

11:57 <Neeraj> so this is about runtime I guess , when It takes more time to find any global objects or something then its fails

12:00 <hkaiser> it's not a timing issue - it's most likely a bug in the implementation

12:01 <hkaiser> the way migration works is described here: https://github.com/STEllAR-GROUP/hpx/blob/master/libs/full/runtime_distributed/include/hpx/runtime_distributed/server/migrate_component.hpp#L25-L109

12:02 <hkaiser> well, it's how it is supposed to work anyways

12:04 <Neeraj> that's good

12:15 <Neeraj> so migration is also part of that project because in this we to made new GIDs from agas and also change the location where it was

12:26 <Neeraj> HPX_WITH_TESTS to be set on then still get same error

14:41 <Yorlik> How does HPX serialization handle raw pointers to strings?

14:45 <hkaiser> Yorlik: not at all ;-)

14:45 <hkaiser> it should fail compiling

14:46 <Yorlik> IC. Houston I have a problem.

14:46 <zao> \o/

14:46 <hkaiser> Yorlik: how should we handle raw pointers?

14:46 <hkaiser> sending those doesn't make sense as the address is locality-specific

14:47 <Yorlik> It would help to have a special case, where the pointed to object is sent along the pointer if the message goes over the network and just pack the pointer if everything is local.

14:47 <Yorlik> Not sure yet what HPX should do and what I should do.

14:48 <Yorlik> Putting aside ownership issues.

14:48 <hkaiser> Yorlik: how do I know how many objects the pointer points to?

14:48 <Yorlik> I think it would have to depend on the type of the pointee.

14:48 <hkaiser> very subjective

14:48 <Yorlik> Yes, I see the issue.

14:49 <hkaiser> just use unique_ptr/shared_ptr and everything is fine

14:49 <Yorlik> I'm having issues with shared_ptr - not a hpx problem - it's a problem with our use of Lua.

14:50 <Yorlik> SOL says tehy can handle shared_ptr - but I'm running into some madness and I don't know yet entirely ehy.

14:50 <Yorlik> why.

14:50 <hkaiser> Yorlik: or wrap your pointer into a type and create special serialization support for this type

14:50 <Yorlik> I could try to make an owning wrapper - like a custom unique_ptr.

14:51 <Yorlik> I guess I'll experiment with that and see where I end up.

14:51 <hkaiser> struct my_ptr { char const* p; template <Archive> void serialize(Archive&ar, unsigned) {...}};

14:51 <hkaiser> inside the serialize function you can do whatever you want

14:52 <Yorlik> Yeah - rtaw memory in an envelope :)

14:53 <zao> Heh, reading the sol docs on ownership and they just abruptly end in the middle of a sentence :D

14:53 <zao> https://usercontent.irccloud-cdn.com/file/o1cYcgFY/sol-own.png

14:55 <zao> You're not doing something funny like constructing multiple shared_ptr families to the same object? Maybe enable_shared_from_this helps in some way? Never touched sol, happy over here in my corner with manual LuaJIT bindings.

15:06 <Yorlik> zao: I have a shared_ptr to string inside a variant. The entire issue is here: https://github.com/ThePhD/sol2/issues/1459#issuecomment-1466905936

15:07 <HHN93> hkaiser I have performed a few tests and found very little difference, I am working on updating pansysk75[m] to my convenience. Will try to provide better results soon.

15:07 <HHN93> Do i need to make a formal report? if yes, any reference for a report??

15:07 <hkaiser> HHN93: thanks! measuring things often reveals surprising (and unexpected) results

15:08 <hkaiser> HHN93: a simple graph would help - in the end we don't want to add things to the library that do not improve things, do we?

15:11 <HHN93> sure, will try to get it done on wed

15:14 <HHN93> pansysk75[m] I am trying to change testbench code so that algorithms can be tested by calling TestBench<MakeHeapAlgorithmTest>(N);

15:17 <satacker[m]> because you are already experimenting, may I suggest to try with google benchmarks? It gives a much more detailed output. For starters we can benchmark against std HHN93 (not an imposition, just curious what it would look like)

15:17 <HHN93> pansysk75[m] can you please try looking into https://github.com/Johan511/HPX-Performance-Benchmarks/tree/master/src (main.cpp and tb.hpp) and comment on if there are any issues with it?

15:17 <HHN93> satacker[m] sure I was also initially under the assumption we would be using google bench for benchmarks

15:18 <HHN93> given that my project would work extensively with bench marking I will definitely try to work on a google benchmark based testbench sometime soon

15:19 <pansysk75[m]> HHN93: Oh I had sent you a different branch on purpose, this one was unecessarily complicated 😅 you can of course try Google benchmark, I will check out what you sent me in just a moment

15:22 <HHN93> there is a function call being made in between the timer start and stop, I have inlined it (hope it has the intended effect) apart from that I don't see any major issues.

15:23 <HHN93> I just wanted to tweak it to my convenience as I felt I would be extensively in the forthcoming months

15:23 <HHN93> extensively using it in the forthcoming months

16:01 <satacker[m]> btw contributor applications open today iirc

16:01 <HHN93> yup

16:01 <HHN93> 20th march to 4th april

19:08 <Yorlik> hkaiser: I finally solved my Lua problems by making a wrapper for the variant with defined accessor functions and constructors that work in Lua. But I need to ask again: If I create a type that has a shared_ptr: Will that shared_ptr be automagically serializable and recreated if I migrate across machine boundaries?

19:09 <Yorlik> As long as the pointed to type is serializable ofc.

19:27 <hkaiser> Yorlik: yes

19:27 <Yorlik> hkaiser: Thanks. Seems I can get quite far with wrappers which avoid the Lua problems then.

19:27 <Yorlik> After all Lua is type-oblivious.

19:28 <hkaiser> Yorlik: serialization even takes care of the case when the same shared_ptr is serialized twice or more in the same archive

19:30 <Yorlik> Nice! Lua is much more simple and restricted and it needs some help to use certain C++ constructs. Even when having such nice Lua bindings as Sol.

19:30 <hkaiser> making sure that on the receiving end you still get one shared_ptr object

19:31 <Yorlik> I wonder if we coulde use HPX to find an elegant way to serialize Lua Tables.

19:31 <hkaiser> Yorlik: sure you can do that, as long as you know how to (de-)serilize them

19:31 <Yorlik> I'd like to use shared Lua Tables on the heap - Sol has such a construct which ~methinks allows tables detached from a Lua State

19:32 <Yorlik> The trick is always cyclic tables which require you to keep track of pointers.

19:33 <hkaiser> our serialization layer tracks pointer, as I said

19:33 <Yorlik> Yes - that's why I wonder if we could use it for that. Lua ofc uses raw pointers.

19:34 <hkaiser> you'd have to do some custom magic to use the existing pointer tracking, but sure

19:34 <Yorlik> I feel so tempted to rewrite some C libraries we are using in modern C++, but If I do that I'll get nothing else done.

19:34 <Yorlik> E.g. Lua and Yojimbo(networking lib on top of UDP)

19:35 <Yorlik> Lua rewritten in modern C++ could be really nice.

22:45 <sarkar_t[m]> <hkaiser> "sarkar_t: I think you could..." <- Sure!