00:02 <zoq[m]1> Hm, not sure ensmallen is the right place to do that, at the end it's header only, and I think you will find better cross-compilation tutorials on the internet.

00:03 <zoq[m]1> What I could imagine is a blog post or something that shows an example or something like that.

00:03 <zoq[m]1> Which we should do for mlpack anyway.

00:05 <shrit[m]> therefore I have thought about it

00:05 <shrit[m]> Agreed, it does not make sense to cross compile the ensmallen tests only for a rare case as we have faced an issue with armel debian

00:06 <shrit[m]> Eventually, the mlpack cross compilation allows to cross compile the CLI binding which is the most important I think

00:07 <shrit[m]> I am putting the idea on pause now, we have more important thing to focus on, if in the future, we discover a new use case that might be interesting for ensmallen then I think we can bring back the idea to the table, otherwise, I think it can wait as well

00:07 <shrit[m]> moving mlpack to header only is much more important

00:10 <zoq[m]1> Sorry, I didn't get what you are trying to do earlier.

01:49 <jonpsy[m]> For windows, i think its worth guiding users towards WSL path. It'll take much less downloads, the process will be, and i cant stress this enough, greatly simplified.

01:49 <jonpsy[m]> s/For windows, i think its worth guiding users towards WSL path. It'll take much less downloads, the process will be, and i cant stress this enough, greatly simplified./For windows, i think its worth guiding users towards WSL path. It'll take much less downloads and the process will be, and i cant stress this enough, greatly simplified./

02:38 <rcurtin[m]> hmmmmmm... I ran the `mnist_cnn` example on my updated `Convolution` layer and the loss increased instead of decreased. I think there might be a bug 😄

02:54 <jonpsy[m]> are you sure its not due to fluctuations?

04:07 <rcurtin[m]> nope it goes up monotonically over 11 epochs and gets awful training set performance 😃

04:32 <jonpsy[m]> Worth investigating

07:41 <jonpsy[m]> Found this interesting research paper: https://jabde.com/2021/05/23/girlfriends-mood-time-series-analysis/

12:35 <yugansharora01yu> I am compiling and i can see hundreds of linker error☹️

15:35 <yugansharora01yu> Building with master branch is even worse

15:37 <yugansharora01yu> 600 linker errors

15:37 <yugansharora01yu> And my visual studio stopped responding and closed on its own

15:41 <yugansharora01yu> @heisenbuug any idea what should i do?

15:45 <yugansharora01yu> I'm trying to build mlpack from 3-4 days and first time I got 1 linker error and now with master branch 600 linker errors and a non-responding visual studio 😅

16:00 <jonpsy[m]> jeffin143: hey got a minute?

16:12 <jeffin143[m]> Yes jonpsy ?

16:12 <jonpsy[m]> About the Amazon job you got, did you apply off campus?

16:13 <jeffin143[m]> Yes it was off campus

16:13 <jonpsy[m]> Okay, perfect.

16:50 <yugansharora01yu> @heisenbuug @marcusedel:matrix.org @shrit:matrix.org do you guys have anything else in mind? Now what should I do?

16:59 <heisenbuugGopiMT> can you show me the errors?

17:00 <yugansharora01yu> Visual studio closed but I got a pic of it

17:00 <yugansharora01yu> Is there any way that I can get the output or something like cmakecache

17:01 <shrit[m]> I still do no understand, what is the reason to use visual studio if you said that you are using the termianl?

17:02 <shrit[m]> you can just make from terminal after running cmake

17:03 <heisenbuugGopiMT> Yes, navigate to the build folder run make command from terminal...

17:03 <heisenbuugGopiMT> I just wanted you to follow keon's steps to get all the require files...

17:06 <jonpsy[m]> yugansharora01 (yugansharora01): on the side, can you install WSL. Once you got the Linux subsytem down, it'll be a cakewalk

17:11 <yugansharora01yu> Error LINK2019 : unresolved external symbol sgetrf_ referenced in function "void __cdecl arma::lapack" something --- this is the error

17:11 <yugansharora01yu> @heisenbuug keon's blog says use visual studio

17:12 <yugansharora01yu> It clearly says open the .sln and build the solution

17:16 <yugansharora01yu> Thing is there are a lot of linker errors

17:23 <yugansharora01yu> Here are some pics of the errors

17:25 <yugansharora01yu> 😟 i didn't knew it would be that difficult

17:31 <yugansharora01yu> Ohh I forgot I can't attach files from phone 😅

18:52 <shrit[m]> rcurtin: Do you have an idea how to handle math/random.cpp

18:53 <shrit[m]> it contains exported definition, I do know why these have been done that way

18:57 <shrit[m]> * I do not know why

20:54 <rcurtin[m]> the issue is that we need a singleton class for the RNG

20:54 <rcurtin[m]> that's why it's been in a .cpp in the past, but that may need to be rethought now that it will be header-only

20:54 <rcurtin[m]> it should still be a singleton though

22:10 <shrit[m]> we can create an RNG class and then we do not allow copy it?

22:10 <shrit[m]> only move it

22:11 <shrit[m]> this way we will only one class, impossible to copy, once it is declared we have it

22:49 <rcurtin[m]> yeah, that's a singleton, but it may not be necessary to prevent copies, etc... the key is just that there is only one of them

22:49 <rcurtin[m]> I think one per translation unit is okay

22:49 <rcurtin[m]> take a look at `IO::GetSingleton()` to see the pattern in use... the same thing might be necessary for the random code instead of `randGen`, as an inlined header function

22:50 <rcurtin[m]> but you may want to do some reading about header-only singletons first, in case there are some other intricacies that need to be considered 👍️