01:29 < jenkins-mlpack2> Project mlpack - git commit test build #308: FAILURE in 17 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/308/

03:11 < jenkins-mlpack2> Project mlpack - git commit test build #309: STILL FAILING in 14 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/309/

04:33 < rcurtin> baffling error on the jenkins build

06:07 < sreenik[m]> ``````

06:10 < sreenik[m]> For the code above, the output for the interpreted layer is strange (extremely large integers, probably rubbish values). If I try static_cast, it says invalid types, so I guess the issue is with the casting. Any suggestion on what coujld be a possible solution?

06:11 < sreenik[m]> Oh, the first line of the code got deleted somehow, it was just the definition of a simple ```Linear<>``` layer called ```linear```

13:13 < ssk441> The memory checks build for Jenkins just failed for me. I also noticed that all the builds for the last couple of days all failed with the same error:

13:13 < ssk441> CMake Error: File /home/jenkins-mlpack/workspace/pull-requests/ mlpack/ memory/src/mlpack/bindings/python/setup.py.in does not exist.

13:13 < ssk441> Does anyone know why this is happening?

13:51 < Shikhar-SGitter[> I am also getting same error. @matrixbot Probably something's wrong with build environment on server.

13:51 < Shikhar-SGitter[> (edited) ... error. @matrixbot Probably ... => ... error. @ssk441 Probably ...

14:16 < rcurtin> ssk441, Shikhar-S: yeah, I am not clear on what's going on yet. the error does not make sense to me

16:34 < rcurtin> ok, it seems that the build problem is a CMake versioning issue: a new version of CMake does not seem to handle paths with spaces in the same way

16:35 < rcurtin> I'm debugging now...

16:36 < rcurtin> sreenik[m]: since LayerTypes is a boost::variant, I think actually you have to use the visitor pattern to extract the Linear<> layer from it

16:37 < rcurtin> I'm not 100% sure on that though, but my guess is that the reinterpret_cast<> is just resulting in a Linear<> pointer that's off by a few bytes or something

17:58 < rcurtin> ok, the video meet-up is starting in just a moment at https://zoom.us/j/3820896170, feel free to join

18:08 < zoq> sreenik[m]: Just an exmaple about how to use an visitor to e.g. get the width from a layer: size_t width = boost::apply_visitor(OutputWidthVisitor(), layer);

18:09 < zoq> sreenik[m]: Vistors are here: https://github.com/mlpack/mlpack/tree/master/src/mlpack/methods/ann/visitor

18:37 < favre49> Is the meeting over?

18:37 < rcurtin> not yet, we are still here :)

18:37 < favre49> Ah okay I'll try to join in a bit

18:46 < rcurtin> apt-get install libboost-all-dev

18:47 < rcurtin> compiling with debugging symbols: -O0 -g -DDEBUG

18:48 < sreenik[m]> zoq I tried that out. Gives a 0 as output (I guess that's a visitor for the input width as in similar to height). Going through the list I couldn't find one that matches InputSize or OutputSize. Maybe I missed it?

18:50 < rcurtin> -lboost_serialization should be needed

18:50 < sreenik[m]> g++ -o test_converter src/test_converter.cpp -lboost_serialization -lboost_program_options -larmadillo -lopenblas -fopenmp -lmlpack

18:50 < sreenik[m]> This is what I use

18:51 < zoq> sreenik[m]: I see, so either we implement another vistor that does exactly that or I think you could use ParametersVisitor() and do n_rows, n_cols, to get the input output size.

18:51 < _adi_> let me try that out. -lboost_serialization alone still gives me the error.

18:53 < sreenik[m]> I tried without the -lboost_program_options. Works fine without it. I guess I was using it uselessly all the time

18:53 < sreenik[m]> zoq: Right. Will check that out

18:58 < favre49> I need to go to bed now, but it was nice meeting you guys :) I'll try to make it for the next meeting as well

19:01 < rcurtin> no worries, see you next time :)

19:01 < rcurtin> hopefully I didn't just end the meeting for everyone, I think I just hit "leave meeting" correctly... let me know if not :)

19:01 < zoq> Ãstill works

19:02 < _adi_> yep.. works...

19:04 < tavishjain> Hello there

19:04 < tavishjain> Could someone please guide me on how could i contribute to mlpack ?

19:05 < zoq> cmake ../

19:06 < zoq> tavishjain: Hello there, https://www.mlpack.org/community.html and https://www.mlpack.org/gsoc.html is probably what you are looking for.

19:06 < tavishjain> Thank you zoq[m]

19:07 < tavishjain> Just wished to confirm, this is the official IRC for mlpack right ?

19:07 < tavishjain> And no other one ?

19:07 < sreenik[m]> Yes this is the official IRC

19:07 < sreenik[m]> We also have a mailing list

19:08 < abernauer[m]> tavishjain: Yeah this it. You might want to use one the bridges if you prefer using a client. Riot.

19:09 < tavishjain> No thank you abernauer[m] this platform seems good enough to me :-)

19:13 < abernauer[m]> rcurtin: Missed the meeting because of some job search stuff and other life stuff. Going to prioritize that PR for Fast Max Kernel Search and that tree method when I find the time.

19:13 < rcurtin> no worries, and no hurry! I think the job search and other life things are generally more important :)

19:19 < birm[m]> I was able to replicate cmake space issue seen in the builds with cmake 3.16.2.

19:23 < rcurtin> ok, I think I *almost* have a fix for the cmake space issue, but it needs a little more testing and cleanup

21:09 < pickle-rick[m]> <sreenik[m] " g++ -o test_converter src/test_"> The version that worked for me follows the same pattern as well. Just linked up the right libraries as suggested by rcurtin and zoq . I can now compile, run files and see the environment in action using zoq's gym_api. Thanks guys!

21:10 < pickle-rick[m]> this is the command i used btw: g++ example.cpp -lboost_iostreams -pthread -lboost_system -o ex

23:06 < rcurtin> it seems like I'm able to replicate the spaces issue with even CMake 3.5!

23:06 < rcurtin> I'm wondering if what's going on here is that a system upgrade caused the version of Cython installed to now be new enough that Python bindings are built :)

23:06 < rcurtin> so maybe it was never a CMake version issue all along

23:09 < rcurtin> https://github.com/mlpack/mlpack/pull/2148 should fix the issue... I hope! I'll have to keep an eye on whether it successfully builds :)