00:47 < rcurtin[m]> dkipke: thanks for digging so much! sorry that I disappeared---I had to go to pollworker training

00:48 < rcurtin[m]> they taught us about the "voting equipment exception form"; I hope I get the opportunity to use it, since I think it will be the only time I get to physically throw an exception

00:48 < rcurtin[m]> anyway, I was thinking the same thing you were---some memory allocation/deallocation issue, which is why I suggested trying k-means or mean shift, just to see if it did the same thing

00:48 < rcurtin[m]> what version of Armadillo are you using?

00:50 < rcurtin[m]> and for the issue about the type of the assignments, yeah, that looks like an error in our automatically generated documentation: https://github.com/mlpack/mlpack/blob/master/src/mlpack/bindings/go/get_printable_type_impl.hpp#L108

00:50 < rcurtin[m]> I think the idea was to print that it is a 1d Gonum matrix holding Ints that are represented as Float64s, but that's not very clear in what's printed there

00:50 < rcurtin[m]> so maybe the best idea is just to remove the "(with ints)" and "(1d with ints)"; I'll open a PR momentarily

01:14 < rcurtin[m]> https://github.com/mlpack/mlpack/pull/2778

02:24 < rcurtin[m]> can you try downgrading to Armadillo 9.x? if that changes the behavior... I think that I know the problem (https://github.com/mlpack/mlpack/pull/2688, but in that PR I only fixed Python and Julia, since I thought Go did not have the same problem)

02:24 < rcurtin[m]> wait, no, looking at the diff, I am wrong, I did fix it in Go there... are you using mlpack 3.4.2 or git master?

02:42 < rcurtin[m]> ahh, want to try the git master branch? if you built 3.4.2 this is the exact same process

02:54 < rcurtin[m]> 👍happy to help out! sorry you are having issues---I'm sure we'll get it worked out though

15:02 < rcurtin[m]> sweet! I'm really happy to hear it worked---I was scared there might be some other subtle issue that needed to be debugged

15:02 < rcurtin[m]> if you have more issues, please do feel free to reach out!

15:08 < rcurtin[m]> 👍️ sounds good!

15:45 < zoq> Wondering if it makes sense to switch back to Serialize instead of serialize now that we use cereal.

15:47 < rcurtin[m]> hmm, is there an easy way to specify the name of the function? the cereal docs suggest `serialize()`, just like boost::serialization

15:48 < rcurtin[m]> if it's easy it seems like it would be good, but if it requires the awful hacks I wrote for boost::serialization we should avoid those... in retrospect those were a bad idea :-D

15:48 < zoq> ahh, okay so I guess it doesn't make sense.

15:48 < rcurtin[m]> yeah, the shims I wrote were cool proof-of-concepts, but they were very fragile

15:50 < zoq> Yeah, I remember the PR, but at the end it was in accordance with our style guide :)

15:50 < rcurtin[m]> :)

15:50 < zoq> Also is some of the bridges down?

15:51 < rcurtin[m]> it seems like messages from Slack are getting to Matrix, but not onwards to Freenode

15:51 < rcurtin[m]> Matrix messages seem to make it to Freenode just fine though

15:51 < zoq> Good :)

15:52 < rcurtin[m]> I'm not quite sure where to start debugging... it might be safe to assume that it will just magically start working again at some point

17:03 < rcurtin[m]> dkipke: yeah, this came up in the context of Julia bindings some time back, but I have not had a chance to do a redesign. the reality is that we use a singleton that is not threadsafe, and this singleton is used in each call to a binding. so, some refactoring is needed; I am hoping that I will have a chance to do it in the first part of 2021. in the meantime, unfortunately, all I can recommend is separate processes :(

23:01 < jenkins-mlpack2> Project mlpack - git commit test build #622: UNSTABLE in 3 hr 45 min: http://ci.mlpack.org/job/mlpack%20-%20git%20commit%20test/622/