Time Nick Message 00:59 MTDiscord os.execute("killall -SIGSEGV minetestserver") 😃 01:25 MTDiscord Heh, I don't think that would give me an opportunity to catch a useful backtrace though. Luatic hooked me up with a simple bit of lua though. 01:26 MTDiscord The latest versions of https://hub.docker.com/r/warr1024/minetestserver will now run MT server under gdb and dump an automatic backtrace to the log on crash. I'm going to be vetting them against performance and other regressions soon. 01:43 MTDiscord Lovely! 01:57 MTDiscord 5.6.0 was 9MB compressed, 5.8.0 is now 73MB. Some of that is probably some tooling or dependencies I've added, but a lot of that is debugging symbols. I guess I'm hoping that ~75MB is not too much of a burden for a docker image ... it does seem like that's not really on the large end from what I've seen in the wild. 02:01 MTDiscord I'm confused, that sounds like a normal size for debug symbols 02:02 MTDiscord Didn't say it wasn't normal, just that it feels wrong. 02:03 MTDiscord It'd be nice if we had an option to only include debug symbols in areas that are hotspots for finding bugs ... but if we could do that, then that's like 80% of the way to "just don't put the bugs in in the first place" 😆 02:05 MTDiscord I remember having to get used to "large executibles" when I left the world of DOS and went to Windows, because they started embedding all kinds of bitmaps and resources in the exe files. Then I moved to Linux and suddenly those weren't embedded anymore (and in many cases not even necessary) so I got used to smaller programs again ... but then now enabling the debug symbols feels like migrating from DOS to Windows 95 again. 02:14 jonadab Heh. I used to use a text editor that would fit on a bootable 360K floppy. 02:14 jonadab With room to spare for files. 02:14 jonadab And yes, that was in the DOS days. 02:17 MTDiscord I'm still an old-school vi fan. OpenBSD's nvi on x86_64 would ALMOST fit. 02:18 jonadab I never learned vi. Upgraded from UED directly to Emacs. 02:18 jonadab Which is a _large_ jump in executable size. 02:21 MTDiscord Vim is fine, vi is awful. It purposefully includes maddening bugs because some old-timers got used to the bugs and didn't want to change their workflow. 02:23 MTDiscord "vim is fine but vi is awful" is like saying "Windows is fine but computers are awful." Vim is a fine implemenation of vi. I use vim.tiny on Linux, and nvi on OpenBSD (both of them are just aliased to "vi"). If there are any "maddening bugs" they don't crop up in my workflow. The workflow itself might be "maddening" but since I was already madder than that going in, it doesn't affect me. 02:24 * jonadab just checked: UED was 38704 bytes. 02:24 jonadab Packed a lot of functionality into that, for what it was. I mean, yes, it was basic, but it was _good_ basic. 02:25 MTDiscord All I know is that I often have vi (as a command name) installed by default on a system and have to manually install vim 02:25 jonadab That's probably nvi. 02:25 MTDiscord And that the package called vi is maddening 02:25 MTDiscord Probably 02:26 * jonadab contemplates making vi an alias that brings up Emacs in viper-mode, but thinks better of it. 02:26 MTDiscord I don't mind vim so much but I avoid interacting with any of the "m" parts. The whole "don't add unnecessary dependencies" thing is something I think I agree with MT on. 02:27 MTDiscord I don't mind using VS Code when I want a heavy editor, but vim just occupies this "middle child" kind of niche that I don't really need. 02:27 jonadab vim and Emacs are both too heavy to be included on things like tomsrtbt, but that's what nano is for, eh? 02:28 MTDiscord I don't really use the syntax highlighting and stuff... but the basic insert capability actually working ... is a must have 02:28 MTDiscord Nano is the one I can't really stand. With its submenus it basically fails to get rid of the modality that's the core problem with vi, so I don't see the point in using an editor that's harder to terminal map. 02:28 jonadab Though even nano is considerably larger than UED. 02:29 MTDiscord MisterE it sounds like you've found some broken implementation out there that we've never seen... 02:29 MTDiscord Yes. Openbsd. 02:30 jonadab Rule of thumb for BSDs in general, is that all the software you actually want to use will be under /usr/local 02:30 jonadab Including the shell and everything, usually. 02:30 jonadab Well, not init 02:33 MTDiscord In my experience, the less you can get away with installing stuff to /usr/local/, the better. That's only when they don't have something workable in base. 02:33 MTDiscord Well, I'm not sure about Free or Net, but particuarly in Open, the quality standards for /usr/local are way lower. 02:37 MTDiscord It sounds to me like your definition of a broken vi implementation is that it doesn't do what vim does 😆 ... in that case, sure, I just prefer broken vi then. 02:39 MTDiscord "basic insert capability actually working" ... sounds like the kind of complaint somebody will use when they don't really want to try to learn how to use something but just want to find an excuse to hate it, at least, coming from somebody who I know knows how to describe a problem correctly. 11:48 sfan5 @warr1024 any reason you chose not to just use the --debugger flag? 11:49 sfan5 regarding symbol size you might be able to split them from the executable and compress them indivudually (not sure if it's worth) 11:53 MTDiscord --debugger flag to what? 11:54 sfan5 https://github.com/minetest/minetest/pull/13157 this thing 11:58 MTDiscord Well, in order to "choose" not to use something, I would need to have ever heard of its existence. 11:58 MTDiscord And this seems to save me about 5% of the work I actually did. 11:59 MTDiscord Is just a simple "bt" really all you want in a crash bug report then? 12:05 sfan5 it's plenty IMO 12:06 sfan5 'bt full' is usually full of anyway and if you have a issue that crosses different threads it gets hairy anyway 12:13 MTDiscord I'll give it a try. I assume that if the crash happens even before MT attaches itself to a debugger, then that itself would be plenty of info to track down a bug too? 12:21 MTDiscord I had to learn vi... and got really frustrated with it... and then the teacher was like, well, there is also vim... and I was like, why didn't you start with that? Since vim is much more usable, and I was running into bugs in vi that the teacher snid were there on purpose. 12:22 MTDiscord The teacher told you they were bugs but that they were also on purpose? 12:22 MTDiscord I don't remember the details well thought 12:22 MTDiscord Yes. 12:23 MTDiscord Seeing how vi works fine for its other users, I think you just ran into bugs in thr teacher. 12:23 MTDiscord Hm 12:24 MTDiscord People often blame software just because it's easier to file a bug report there than with the wetware. 12:26 MTDiscord The world would be an interesting place if everyone had a personal issue tracker and everyone knew how to file a bug report. 12:26 sfan5 if it crashes before the debugger attaching happens then you're out of luck 12:26 sfan5 happens very early though, quite unlikely 12:28 MTDiscord Yeah, that's why I said that it would probably be very telling; it would narrow down the search area significantly... 12:28 MTDiscord But if it wouldn't be enough still then I suppose I'm still not sure about whether it makes sense to use the builtin option or just wrap externally to be sure. 12:30 MTDiscord It's been a long time since I've seen a real world representative crash though. Last time was when vertical_sprite was broken back in like 5.1 or something. I've just got a straightforward contrived example in voxelmanip I'm using to do basic testing, and I've never seen a cross thread crash before. 12:46 sfan5 minetest is not well multi-threaded so I suppose we don't have many race conditions ;) 12:58 jonadab 98% of the bugs filed in people's personal issue trackers, would get marked WONTFIX, @war1024. 12:59 jonadab And that would just be frustrating for everyone. 13:21 MTDiscord Haha if you think people might actually seriously address 2% of the bugs in their personal trackers then it sounds like that could be world-changing. 13:21 MTDiscord It's not uncommon for 98% of the bugs in any tracker to be trash anyway. 13:59 jonadab No, no, the remaining 2% wouldn't all get seriously addressed. Haha. 14:01 jonadab Most of the ones that weren't outright marked WONTFIX would only be looked at once and then never touched again. 14:01 jonadab Some would get assigned and then keep getting pushed back to next release every dev cycle. 19:44 limeee Hello all 19:47 mrkubax10 hi