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/
< rcurtin>
I'm happy to look into it if you don't have a quick idea of what the issue might be :-D
petris has quit [Quit: Bye bye.]
petris has joined #mlpack
< jeffin143[m]>
rcurtin: from my experience mlh are very strict about mentors , they are selecting only people who have worked 6-7 years in related field
< jeffin143[m]>
So they would be far quicker than I am , in order to contribute and get a grasp of Mlpack
< jeffin143[m]>
Mentors , wouldn't help in reviewing , review should be done by maintainers
< jeffin143[m]>
They would be only managing students
< jeffin143[m]>
If students seek any help with the language or something , scrum meetings about what they did , what would they be doing and so on
< jeffin143[m]>
All such activities would be done by mentors
ImQ009 has joined #mlpack
Eddie has joined #mlpack
< Eddie>
Hi Guys!
< Eddie>
I am a newbie here. Today I complied mlpack as the build instruction and after several hours, it turned out the mlpack.dll is missing. Is this normal?
< zoq>
Wonder if it has to be at least 2 spaces, and it ignores anything else.
< shrit[m]>
Also, it does check if two spaces are added for `public` and `private` in mlpack classes, and tell you that you have to put one space here.
< shrit[m]>
But for 4 spaces, it will much harder to find examples.
< shrit[m]>
You can check the link for all similar indentation errors, since I use usually use a different style than one in mlpack.
ImQ009 has quit [Quit: Leaving]
ImQ009 has joined #mlpack
travis-ci has joined #mlpack
< travis-ci>
UtR491/ensmallen#4 (moead_exp - 63f86e2 : UtR491): The build is still failing.
< rcurtin>
R bindings are merged :-D awesome work yashwants19[m]!
< shrit[m]>
rcurtin: I am having armadillo 6.5 on xenial
< shrit[m]>
is this normal?
< rcurtin>
shrit[m]: yeah, the xenial version is super old; if you take a look at .ci/linux-steps.yaml (I think), it will show a step to install 8.400.0 from a ppa
< rcurtin>
oh, that should definitely be new enough
< rcurtin>
well... I think?
< rcurtin>
I have 3.16.3 locally
< shrit[m]>
The error is the same, on master and cereal
< rcurtin>
is that when building configuring armadillo or mlpack? also, is it a fatal error? if it's not maybe you could just ignore it :)
< shrit[m]>
mlpack
< shrit[m]>
and it is fatal error,
< rcurtin>
if you look in the file GNUInstallDirs.cmake that comes with your cmake distribution, does it have that function in it?
< rcurtin>
I'm not sure what the issue here is, you'll probably have to dig a bit; I haven't seen it before
< shrit[m]>
OK, I will see what to do,
< rcurtin>
sounds good, also, consider a quick workaround like a new version of cmake if you weren't aiming to dig to the bottom of this issue and were just trying to, e.g., test an old version of cereal :)
< shrit[m]>
The function does not exist in cmake 3.5, and the issue is resolved in cmake 3.18. It is strange that is working on the build farm.
< himanshu_pathak[>
Great rcurtin We are using github actions for Rbindings :)
< shrit[m]>
rcurtin: There is another error from cereal 1.1, in which it is not able to find `Archive::is_saving::value` which is similar to the old error `Archive::is_loading::value`
< shrit[m]>
/home/omar/mlpack/src/mlpack/methods/hoeffding_trees/hoeffding_tree_main.cpp:107:1: required from here
< shrit[m]>
/home/omar/mlpack/src/mlpack/methods/hoeffding_trees/hoeffding_tree_impl.hpp:811:3: error: no type named 'is_saving' in 'class cereal::BinaryOutputArchive'
< shrit[m]>
if (Archive::is_saving::value)
< shrit[m]>
Do you thnink it is worth it to write a similar function for is_saving?
< shrit[m]>
It should be easy
< jeffin143[m]>
Hi @walragatver:matrix.org @birm:matrix.org today is our last meet
< jeffin143[m]>
Officially as gsoc ,
< jeffin143[m]>
It was a pleasure working with you :)
< jeffin143[m]>
Thanks for all the support :)
< birm[m]>
Aww, hopefully I was some amount of helpful :)
< jeffin143[m]>
I am for sure going to contribute more , after the gsoc so probably I would be distrubing you with all my prs for s longer duration
< jeffin143[m]>
> Aww, hopefully I was some amount of helpful :)
< jeffin143[m]>
Certainly
< jeffin143[m]>
Thanks for helping me with cmake and all the review :)
< shrit[m]>
rcurtin: cereal 1.1 did not have support to serialize `std::map`
< rcurtin>
shrit[m]: what do you think, we could backport it or require 1.2?
< walragatver[m]>
jeffin143: Let's merge the final PR which is remaining
< shrit[m]>
rcurtin: I am not sure
< rcurtin>
shrit[m]: so, if you are lucky, you might be able to just grab the header file from a newer version and then include it, if the underlying API didn't change
< rcurtin>
if it's significantly harder than that, maybe it is not worth the effort, and requiring 1.2 is fine
< rcurtin>
it would be great to be able to support xenial (16.04) which has cereal 1.1, but I don't see it as a requirement... we definitely should make an effort to support bionic (18.04) though since a lot of people and departments will still be using it
< shrit[m]>
Ok, I will try to include the header.
< shrit[m]>
If it is still complicated I will start an ubuntu 18 docker and continue the work in a similar way.