Time |
Nick |
Message |
00:25 |
|
khimaros_ joined #minetest |
00:30 |
|
MTDiscord1 joined #minetest |
00:59 |
MTDiscord |
<savilli> os.execute("killall -SIGSEGV minetestserver") 😃 |
01:18 |
|
smk joined #minetest |
01:25 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<luatic> Lovely! |
01:57 |
MTDiscord |
<warr1024> 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 |
<greenxenith> I'm confused, that sounds like a normal size for debug symbols |
02:02 |
MTDiscord |
<warr1024> Didn't say it wasn't normal, just that it feels wrong. |
02:03 |
MTDiscord |
<warr1024> 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 |
|
Bombo joined #minetest |
02:05 |
|
Bombo joined #minetest |
02:05 |
MTDiscord |
<warr1024> 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:11 |
|
Trifton joined #minetest |
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 |
<warr1024> 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 |
<mistere_123> 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 |
<warr1024> "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 |
<mistere_123> 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 |
<mistere_123> And that the package called vi is maddening |
02:25 |
MTDiscord |
<mistere_123> Probably |
02:26 |
* jonadab |
contemplates making vi an alias that brings up Emacs in viper-mode, but thinks better of it. |
02:26 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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 |
<mistere_123> I don't really use the syntax highlighting and stuff... but the basic insert capability actually working ... is a must have |
02:28 |
MTDiscord |
<warr1024> 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 |
<warr1024> MisterE it sounds like you've found some broken implementation out there that we've never seen... |
02:29 |
MTDiscord |
<mistere_123> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> 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 |
<warr1024> "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. |
03:12 |
|
sparky4 joined #minetest |
03:39 |
|
hawtsitaht joined #minetest |
04:26 |
|
calcul0n_ joined #minetest |
04:44 |
|
fluxionary_ joined #minetest |
05:00 |
|
MTDiscord joined #minetest |
05:34 |
|
liceDibrarian joined #minetest |
05:56 |
|
est31 joined #minetest |
06:10 |
|
Sobinec joined #minetest |
06:29 |
|
skeletronix1 joined #minetest |
06:42 |
|
Leopold joined #minetest |
06:48 |
|
TomTom joined #minetest |
07:50 |
|
Sobinec joined #minetest |
08:05 |
|
definitelya joined #minetest |
08:48 |
|
Leopold joined #minetest |
09:03 |
|
mrkubax10 joined #minetest |
09:27 |
|
sys4 joined #minetest |
09:32 |
|
sys4 joined #minetest |
09:35 |
|
lemonzest joined #minetest |
10:31 |
|
s20 joined #minetest |
10:32 |
|
Sobinec joined #minetest |
10:41 |
|
beanzilla joined #minetest |
10:43 |
|
Yonle_ joined #minetest |
10:43 |
|
muurkha_ joined #minetest |
10:44 |
|
bigfoot547 joined #minetest |
10:59 |
|
Yonle joined #minetest |
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 |
<warr1024> --debugger flag to what? |
11:54 |
sfan5 |
https://github.com/minetest/minetest/pull/13157 this thing |
11:58 |
MTDiscord |
<warr1024> Well, in order to "choose" not to use something, I would need to have ever heard of its existence. |
11:58 |
MTDiscord |
<warr1024> And this seems to save me about 5% of the work I actually did. |
11:59 |
MTDiscord |
<warr1024> 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 <optimized out> anyway and if you have a issue that crosses different threads it gets hairy anyway |
12:13 |
MTDiscord |
<warr1024> 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:18 |
|
proller joined #minetest |
12:21 |
MTDiscord |
<mistere_123> 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 |
<warr1024> The teacher told you they were bugs but that they were also on purpose? |
12:22 |
MTDiscord |
<mistere_123> I don't remember the details well thought |
12:22 |
MTDiscord |
<mistere_123> Yes. |
12:23 |
MTDiscord |
<warr1024> Seeing how vi works fine for its other users, I think you just ran into bugs in thr teacher. |
12:23 |
MTDiscord |
<mistere_123> Hm |
12:24 |
MTDiscord |
<warr1024> People often blame software just because it's easier to file a bug report there than with the wetware. |
12:26 |
MTDiscord |
<warr1024> 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 |
<warr1024> Yeah, that's why I said that it would probably be very telling; it would narrow down the search area significantly... |
12:28 |
MTDiscord |
<warr1024> 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 |
<warr1024> 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:32 |
|
vampirefrog joined #minetest |
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:00 |
|
proller joined #minetest |
13:21 |
MTDiscord |
<warr1024> 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 |
<warr1024> It's not uncommon for 98% of the bugs in any tracker to be trash anyway. |
13:41 |
|
s20_ joined #minetest |
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. |
14:17 |
|
json joined #minetest |
14:29 |
|
Niklp43 joined #minetest |
14:30 |
|
Niklp43 joined #minetest |
15:42 |
|
jaca122 joined #minetest |
15:46 |
|
khimaros_ joined #minetest |
16:02 |
|
illwieckz joined #minetest |
16:03 |
|
sparky4 joined #minetest |
16:11 |
|
mrkubax10 joined #minetest |
16:53 |
|
appguru joined #minetest |
17:26 |
|
Niklp joined #minetest |
17:30 |
|
Niklp joined #minetest |
17:48 |
|
TheCoffeMaker joined #minetest |
18:14 |
|
iamweasel joined #minetest |
18:23 |
|
iamweasel joined #minetest |
18:24 |
|
Talkless joined #minetest |
18:34 |
|
appguru joined #minetest |
18:36 |
|
qqq joined #minetest |
19:16 |
|
appguru joined #minetest |
19:43 |
|
limeee joined #minetest |
19:44 |
limeee |
Hello all |
19:47 |
mrkubax10 |
hi |
19:47 |
|
khimaros_ joined #minetest |
21:04 |
|
khimaros_ joined #minetest |
21:14 |
|
proller joined #minetest |
21:46 |
|
sparky4 joined #minetest |
22:11 |
|
khimaros_ joined #minetest |
22:32 |
|
Niklp joined #minetest |
22:39 |
|
xBarkDog joined #minetest |
22:58 |
|
xBarkDog joined #minetest |
23:04 |
|
celeron55 joined #minetest |
23:32 |
|
panwolfram joined #minetest |
23:32 |
|
appguru joined #minetest |