ChanServ changed the topic of #mlpack to: "mlpack: a fast, flexible machine learning library :: We don't always respond instantly, but we will respond; please be patient :: Logs at http://www.mlpack.org/irc/
< kartikdutt18[m]>
<KimSangYeon-DGU[ "Saksham[m] , kartikdutt18 : I'm "> Have a great flight.
ImQ009 has joined #mlpack
< saksham189Gitter>
Yeah have a safe journey @KimSangYeon-DGU and we'll meet on Sunday
< jeffin143[m]>
@walragatver:matrix.org:
< jeffin143[m]>
Were you able to run it in local that pr ?
favre49 has joined #mlpack
< jeffin143[m]>
Anyone here , would like to teach me what is ABI in c++
< jeffin143[m]>
I have read through many articles but I am not sure
< jeffin143[m]>
Like what exactly it is
< shrit[m]1>
For me, ABI is your libstdc++.so or .a
< shrit[m]1>
the compiled version,
< jeffin143[m]>
Yes shrit , but then how does one change and abi , I mean Mlpack is used by many others then what should I do in mlpack that will break the abi and other programs will fail until and unless they are recompiled
< jeffin143[m]>
I gues if we change any function or ordering of arguments that will break the abi ? Correct
< shrit[m]1>
easy just update the current version of boost, and your boost ABI is broken and you can not run mlpack
< shrit[m]1>
so you will have to compile mlpack from start and reinstall it
< shrit[m]1>
* By supposing that some functions have changed between boost versions that is used by mlpack
< shrit[m]1>
even not, if you have linked with a specific version, only change the version will break the ABI
< jeffin143[m]>
Ok now , whenever I hit make it will tend to compile only some files which are changed correct ??? So now consider a file called that boost function which changed abi and now if that is never compiled then I would never know that the functions have been changed until runtime when it will throw undefined symbol correct ?
< jeffin143[m]>
Like it will not throw an error at compile time --> because the file never got compiled I mean it was Aldeardy compiled since there was no new changes and it didn't re compile it
< jeffin143[m]>
And hence I would only know at run time that the function defination had been changed
< shrit[m]1>
Hmm, I will try to be more specific. the compiler detect only changes in implementations, for example, a new version of boost_serialization.so is installed, in this case if you try to compile mlpack the compiler will detect the new version. If it is a header library the compiler will detect nothing so you will have to clean the compiled binaries are re-compile. Another case, suppose mlpack is installed on your machine
< shrit[m]1>
already and boost have changed, if you tried to run any mlpack_main the library.so will fail because it will not find the specific boost version that was installed to recover the functions from at run time,
< shrit[m]1>
in order to make life simpler, static linking does exist for this kind of issues
< jeffin143[m]>
Yes , Thanks a lot shrit :)
< jeffin143[m]>
Thank you so much :)
< jeffin143[m]>
Yes I have been using static Linking but never knew why 😂
< jeffin143[m]>
But got that today because of abi change issues and everything
< shrit[m]1>
The reason of not using static linking is the requirement for terabytes of storage, and half of them will have boost serialization inside for example if they use it,
< jeffin143[m]>
shrit : yes that makes sense
< walragatver[m]1>
> Were you able to run it in local that pr ?
< walragatver[m]1>
Yes
< walragatver[m]1>
jeffin143: I have commented on that PR it's outcome
< walragatver[m]1>
Getting error while linking mlboard_tests
< walragatver[m]1>
Rest looks good
< jeffin143[m]>
> <@walragatver:matrix.org> > Were you able to run it in local that pr ?
< jeffin143[m]>
> Yes
< jeffin143[m]>
How did you manage to run it in local walragatver
< rcurtin>
meetings? sigh. today I had 7 scheduled meetings
< rcurtin>
I typically spend maybe 20-30% of my time in meetings, some weeks more (this week definitely more)
< rcurtin>
I really would prefer my meeting time to be more like 5-10% and handle the rest of everything asynchronously (chat or email) but that's unfortunately not how my company works
< rcurtin>
for today I gave up on actually writing code, since the longest break I have between any two meetings is less than two hours
< jeffin143[m]>
That's a lot of discussion
< jeffin143[m]>
Wohhh
< rcurtin>
too much discussion, at some point it's pointless...
< walragatver[m]1>
From here download the tar file for cpp
< walragatver[m]1>
And then follow the instructions given in previous link I shared with you in the evening
< jeffin143>
ok I have unistalled everything
< jeffin143>
Let's see
< walragatver[m]1>
Yeah whatever you are going through just note it down we might need it in future for mac
< walragatver[m]1>
> Yeah whatever you are going through just note it down we might need it in future for mac
< walragatver[m]1>
Instructions I mean to install properly
< jeffin143[m]>
Ok
< jeffin143[m]>
@walragatver:matrix.org:
< jeffin143[m]>
After installing
< jeffin143[m]>
Does protoc comes in your computer ?
< walragatver[m]1>
Not sure
< walragatver[m]1>
jeffin143: I was just able to run protoc --version successfully everytime
< jeffin143[m]>
Ok that means it's there
< walragatver[m]1>
It might also be like I have installed it for some other lib
< jeffin143[m]>
Ohh
< walragatver[m]1>
I think protoc comes with protobuf right in the build?
< walragatver[m]1>
jeffin143: protocs binary also comes with pip. I had one installed with pip and it superseded my protobuf's protoc. So at the end I was required to uninstall protoc installed from pip to work correctly
< walragatver[m]1>
That version was quite different than protobuf
< jeffin143>
huh walragatver[m]1, finally download protoc 3.11 version
< jeffin143>
at least was able to compile mlboard's master branch with it
< jeffin143>
I have wasted almost 3 days trying all this out, no doubt why mlpack is strongly against introducing new dependcy
ImQ009 has quit [Quit: Leaving]
< rcurtin>
zoq: any chance you can install sloccount on pioneer?
< zoq>
rcurtin: done
< rcurtin>
thanks!
< jeffin143>
walragatver[m]1 : the error still persist, when you compiled on local did you use precompiled headers ?
jeffin143 has quit [Remote host closed the connection]
< rcurtin>
I upgraded gitdub, but the diff between the version I had running and the current up-to-date version was like 3 lines, so I don't know if it will really fix anything :)