12:34 < rcurtin[m]> at least for me, I guess I keep it simple---vim + gdb + a shell are basically the only tools I use... I could probably put some time into making things a bit nicer, but I guess this works for me 😃

12:51 < jonpsy[m]> I've been using VSC for about 2 years now, and I've never faced this problem, and my specs are lower than yours. Does your desktop have virus or something? I use Linux 20.04 with 6-8 tabs of firefox open + 2 VSC open and it runs butter smooth unless I start compiling. imo, VSC is good as is, integrating with gdb is super easy and much more visual, and you can have terminal + gdb + editor all in one with minimal overhead

12:51 < jonpsy[m]> which is the same as using vim + gdb

12:52 < jonpsy[m]> * I've been using VSC for about 2 years now, and I've never faced this problem, and my specs are lower than yours. I think your laptop has virus/ or requires cleaning (not sure). I use Linux 20.04 with 6-8 tabs of firefox open + 2 VSC open and it runs butter smooth unless I start compiling. imo, VSC is good as is, integrating with gdb is super easy and much more visual, and you can have terminal + gdb + editor all in one

12:52 < jonpsy[m]> with minimal overhead which is the same as using vim + gdb

13:00 < ShahAnwaarKhalid> If you are new to vim, I'd recommend SpaceVim-- it comes with a lot of pre-installed plugins. Once you get a taste of them, you can even configure Vim like Vscode.

13:02 < ShahAnwaarKhalid> btw there's also an extension on chrome called Vimium which allows you to run vim commands on the browser-- it's pretty neat.

13:54 < jonpsy[m]> > I've been using VSC for about 2 years now, and I've never faced this problem, and my specs are lower than yours. I think your laptop has virus/ or requires cleaning (not sure). I use Linux 20.04 with 6-8 tabs of firefox open + 2 VSC open and it runs butter smooth unless I start compiling. imo, VSC is good as is, integrating with gdb is super easy and much more visual, and you can have terminal + gdb + editor all in one

13:54 < jonpsy[m]> with minimal overhead which is the same as using vim + gdb

13:54 < jonpsy[m]> I apologize if it came out rude, perhaps I'm too fond of VSC :). Please feel free to use whatever you like Gopi 👍️

21:06 < rcurtin[m]> zoq: should we merge #2908? (https://github.com/mlpack/mlpack/pull/2908) or were there still changes you planned to make to it?

21:16 < zoq> rcurtin[m]: I still have to add the PVS results, but I can open another PR for that one.

21:20 < rcurtin[m]> ok, maybe let's do that? if I merge #2908 now it should fix the failing static code analysis build for other PRs :)

21:20 < zoq> yes

21:21 < rcurtin[m]> cool, hit the magic button 😃

21:21 < rcurtin[m]> oops, I guess I should have written, "I hit" the magic button :")

21:26 < shrit[m]> Great, I have finished modifications for #2931 too. 👍️

21:27 < rcurtin[m]> 👍️

21:39 < rcurtin[m]> zoq: I was looking at the ANN visitor refactoring branch; it seems like in the new version, each layer does not use an alias of the main weights matrix?

21:40 < rcurtin[m]> I think that's ok; I doubt it will make any serious runtime difference (and in the past that restriction actually made it kinda hard to share weights between networks, I remember years ago Shangtong having some issues with that)... I just want to make sure that's the goal before I try to make serialization work like that :)

23:13 < zoq> rcurtin[m]: correct, but maybe it's a good idea to wait with the serialization part a little bit longer, having all this changes in different repositories makes the current refactoring a little bit challenging.

23:51 < rcurtin[m]> oh, I was going to do it directly from your branch and open a PR into that branch; does that work?

23:53 < zoq> Sure that works, the branch is more WIP so testing might be a little bit difficult.

23:53 < rcurtin[m]> yeah, I think I see how things are set up though. I'll try to make it work 😃

23:53 < zoq> But I guess you are not starting today?

23:58 < rcurtin[m]> I played with it a little bit this afternoon; I'll work harder on it tomorrow. I think making the serialization work should not be too much code

23:58 < zoq> Okay, one more reason for me to get the branch ready.