11:25 < AakashkaushikGit> Hey @rcurtin I did answer most of the questions and fixed the cmake error because of which the tests weren't running can you take another look at https://github.com/mlpack/models/pull/52 ?

11:25 < AakashkaushikGit> (edited) ... weren't running can you ... => ... weren't running. Can you ...

12:53 < AakashkaushikGit> @zoq any ideas on how we can implement the `WeightSetVisitor` functionality inside ann/utils ?

13:01 < RishabhGargGitte> Hii @rcurtin, can you please address #2883. I guess it somehow fell off your radar. Thanks! :-)

13:09 < rcurtin[m]> It's still on my radar, I just haven't gotten to it yet. Typically my "PRs or issues to address" list is 30+ long...

13:14 < RishabhGargGitte> Ohh okay. No worries. Get back to it when it shows up on your list.

13:14 < RishabhGargGitte> Just a request, if you get time to address any of my open PRs, can you prioritise the one in which I am implementing regression tree?

13:31 < rcurtin[m]> sure, I can do that. it's hard to balance it all in the time I have available but I do my best 😃

17:26 < jonpsy[m]> rcurtin So I have a few PR's in ensmallen which might get marked as stale soon enough, my hands are currently full atm (till May 5th-ish), can I bother you with making them "keep-open" :) ?

17:27 < jonpsy[m]> * rcurtin So I have a few PR's in ensmallen which might get marked as stale soon enough, my hands are currently full atm (Endsem till May 5th-ish T_T ), can I bother you with making them "keep-open" :) ?

17:28 < zoq[m]> You can just leave a comment like „leave open“, that should do the trick.

17:28 < jonpsy[m]> oh!

17:31 < jonpsy[m]> Stupid question: Is that a github command for trigerring mlpack bot? If yes, I need to write ,,leave open'' letter-to-letter in comment (tried it didn't work)?

17:36 < zoq> jonpsy[m]: I think any comment will, do there is no stale label attached, so it's fine.

17:37 < jonpsy[m]> sorry, but i think only "optimizers" and "needs review" labels is attached? zoq

17:38 < zoq> The stale label will be attached based on activity, activity includes comments.

17:39 < zoq> Looking at the PR, I don't think it will go stale any time soon.

17:39 < jonpsy[m]> Understood

17:40 < jonpsy[m]> thanks

20:14 < shrit[m]> I think it would be nice if GitHub makes a difference between closed pull requests and merged one, resulting in three tabs, open, closed, merged

20:14 < shrit[m]> Anyone has thought about this before?

20:42 < zoq> shrit[m]: Haven't really thought about it, but not sure I can see what benefit that would provide?

20:46 < shrit[m]> This will filter a pull request that is merged from all other pull requests that have been closed for any other reason. I can see two benefits, first they do not have the same status, closed != merged. Second, this will allow easily to look through the pull requests that have been closed for no activity or for any other reason.

20:47 < shrit[m]> Especially, if you have a high frequency pull requests.

20:48 < shrit[m]> In addition, it is good for statistics, ration of closed vs merged.

20:48 < shrit[m]> * In addition, it is good for statistics, ratio of closed vs merged.

20:49 < zoq> You can click on the "stale" label to get a list of all stale issues (for GitHub PR's are issues as well).

20:51 < zoq> You can run thoses statistics already, I think there is no way to automate this if done right, because there are all sorts of reasons why a PR was closed and not merged.

20:55 < shrit[m]> Yeah, I see, they focus more on good filtering in two tabs, rather than several tabs

20:57 < zoq> I also like to get some more statistics, that's one reason why I created a project board, to keep track of issues I looked at.

20:59 < shrit[m]> Good point, I did not thought about that

21:00 < shrit[m]> You can filter the PR that you have already participated in?

21:00 < shrit[m]> * Can you filter the PR that you have already participated in?

21:00 < shrit[m]> or look at?

21:01 < zoq> Hopefully, I have the data, so at some point I can write a script to run some statistics.

21:05 < shrit[m]> BTW, did you try GitHub CLI?

21:05 < shrit[m]> * btw, did you try GitHub CLI?

21:06 < zoq> No, maybe I should?

21:07 < shrit[m]> Actually I am not a fan of browsers in general, therefore I am always look for alternative to stay on comand line

21:07 < shrit[m]> I gave it a try but it seems to be not very easy,

21:09 < shrit[m]> It requires time to master syntax, therefore, I stopped, maybe I should continue

21:10 < zoq> Maybe, I like the GitHub review interface, it's simple so I mainly use it.

21:12 < shrit[m]> It is true, they do have a great interface for reviewing, I hope that one day they port it to terminal

21:13 < zoq> I use vimium, so I don't have to use mouse, so I can mainly use the same navigation I use in vim, which is bascially my terminal.

21:17 < shrit[m]> This one is great, thanks, you have resolved all my life issues related to mouse

21:18 < shrit[m]> I always thought I have to change the browser or something since there exist other browsers with vim bindings by default.

21:18 < zoq> It's not perfect, but in most cases it works.