| Time |
Nick |
Message |
| 00:51 |
|
sparky4 joined #minetest |
| 01:10 |
|
lissobone left #minetest |
| 01:21 |
|
smk joined #minetest |
| 01:40 |
fluxionary |
"how lua works"? |
| 01:46 |
fluxionary |
another thing. i've got my fps_max_unfocused setting set to 5. this seems to sometimes result w/ my client getting massively desynced w/ the server i'm connected to. if i leave for a couple hours and come back, it will then replay the events from the server at 5x or 10x the speed, over several minutes, while it catches up |
| 01:47 |
fluxionary |
is that an issue that's been reported already? i've searched before but couldn't find anything |
| 01:48 |
fluxionary |
i *think* it only happens if i'm near a mapblock that's changing a lot (e.g. running mesecons mechanisms) |
| 01:48 |
MTDiscord |
<wsor4035> off the top of my head, i havent seen an issue for that |
| 01:49 |
MTDiscord |
<wsor4035> if there is one, it will be zughy or I closing your duplicate anyways |
| 01:49 |
fluxionary |
i haven't reported it cuz i'm not 100% on a replication, the few times i've tried in single-player, i haven't been able to |
| 01:53 |
|
est31 joined #minetest |
| 02:30 |
|
Lesha_Vel joined #minetest |
| 02:34 |
|
v-rob joined #minetest |
| 02:39 |
muurkha |
how Lua works is that you integrate some version of Lua, like 5.0, into your project, and keep using it forever |
| 02:39 |
muurkha |
because newer versions of Lua are never backward-compatible |
| 03:16 |
fluxionary |
the changes w/ `LUAJIT_ENABLE_LUA52COMPAT` aren't backwards compatible, but they also aren't hard to modify code to use, and also not likely to cause problems for most minetest mods |
| 03:17 |
fluxionary |
the most successful software brands break backwards compatibility regularly and still continue to get used |
| 03:22 |
Blockhead256[m] |
the most successful software brands have enough resources to keep up with churn and enough of a 300-pound gorilla status to make anyone who complains move on anyway. I suspect we have neither of those |
| 03:28 |
muurkha |
fluxionary: the most successful software brands that use Lua don't do that. WoW is still using 5.0 or whatever they settled on when they launched the game |
| 03:30 |
muurkha |
Microsoft Windows just recently dropped compatibility with Win16 software from 01989 but still supports Win32 even though you can't buy a new 32-bit CPU to run Microsoft Windows on since like 02009 |
| 03:30 |
muurkha |
Win32 is from like 01994 |
| 03:31 |
muurkha |
Linux and MacOS meticulously maintain their compatibility with VT-100 terminals from 01976 |
| 03:34 |
muurkha |
Linux distributions are still mostly compatible with X-Windows from 01987, although the switch to Wayland is controversial because although it's compatible with regular X-Windows applications, it's not compatible with X-Windows window managers |
| 03:34 |
|
sparky4 joined #minetest |
| 03:35 |
fluxionary |
yeah, but you can't run new software on 1990s-era machines and operating systems. what? |
| 03:35 |
muurkha |
Java will still run bytecode compiled in 01996 |
| 03:35 |
muurkha |
no, you can't |
| 03:35 |
Blockhead256[m] |
muurkha: by the way, what's with the 0-prefix on your dates? Is it some sort of "long now" idea? |
| 03:35 |
muurkha |
yeah |
| 03:36 |
fluxionary |
i guess that point still stands |
| 03:36 |
Blockhead256[m] |
anyway flux are you volunteering to fix everyone's mods? |
| 03:37 |
fluxionary |
Blockhead256[m], possibly, depending on the scope |
| 03:37 |
fluxionary |
Blockhead256[m], my assumption is that the actual changes won't break more than a couple mods |
| 03:41 |
fluxionary |
Blockhead256[m], you mentioned advtrains, which i know but am not intimate w/, and dbf, which i've never heard of and isn't in the content db, nor can i find via web search |
| 03:42 |
Blockhead256[m] |
dbf was a typo of dbg, the technical name of LMD's debug mod |
| 03:42 |
Blockhead256[m] |
https://forum.minetest.net/viewtopic.php?f=9&t=28372 |
| 03:42 |
fluxionary |
potentially a lot of problems could be detected w/ the proper automated testing framework |
| 03:43 |
fluxionary |
oh dbg looks like something i want to get to know better, thanks for the link :) |
| 03:44 |
Blockhead256[m] |
just for the pretty print and better lua command than worldedit, it's pretty handy. The stepping is ok too, though I usually find it slower to work with than print statements (I know...) |
| 03:46 |
fluxionary |
the lua command only works in single-player though? |
| 03:46 |
Blockhead256[m] |
yes, it's disable for safety |
| 03:46 |
Blockhead256[m] |
but I do more debugging in singleplayer |
| 03:47 |
fluxionary |
does it have more security implications than just being an admin on a server? |
| 03:47 |
fluxionary |
i guess if it's insecure environment and doesn't restrict that, ok, i understand |
| 03:51 |
fluxionary |
i've also used the equivalent of print statements for debugging regularly, for lack of a stepping debugger. this certainly seems worth testing |
| 03:58 |
muurkha |
a stepping debugger can be nice (I have one open right now!) but an awful lot of debugging is better done with printf |
| 04:00 |
|
MTDiscord joined #minetest |
| 04:02 |
muurkha |
a stepping debugger is great for inspecting in detail the state of a program at a single moment of execution, or a few of them |
| 04:03 |
muurkha |
but printf debugging shows you the entire history of an execution |
| 04:03 |
muurkha |
I often find that the latter is more useful |
| 04:06 |
muurkha |
perhaps because I more often know what variables or what kind of events are relevant to a bug than which moment in time is the one where it manifests |
| 04:33 |
|
v-rob joined #minetest |
| 04:49 |
|
calcul0n_ joined #minetest |
| 05:01 |
|
fluxionary_ joined #minetest |
| 05:19 |
|
fluxionary_ joined #minetest |
| 06:00 |
fluxionary_ |
re: but printf debugging shows you the entire history of an execution |
| 06:00 |
fluxionary_ |
only if you manually instrument your own code. |
| 06:02 |
fluxionary_ |
i've used tools for java, c, and python, which let you rewind and replay your code w/out much trouble |
| 06:03 |
fluxionary_ |
i wouldn't be surprised if something similar existed for lua, but i haven't found it yet |
| 06:07 |
fluxionary_ |
"print" isn't a great debugging mechanism, but sometimes it's the best you've got access to |
| 06:09 |
fluxionary_ |
i've personally decided to add a "DEBUG" detector to my pre-commit script, so i can add debugging stuff to my code and reduce my chance of accidentally committing it |
| 06:29 |
|
YuGiOhJCJ joined #minetest |
| 06:29 |
muurkha |
I keep planning to try out rr-project now that I have a CPU that supports it properly |
| 06:29 |
muurkha |
my experiences with replay debugging in GDB were disappointing; the slowdown was something like a factor of 100,000 |
| 06:31 |
muurkha |
so you kind of need a nondeterministic bug to justify using that kind of replay debugging; it's almost invariably faster to just restart the program 100 times with breakpoints in different places instead of running it once with replay recording turned on and then reverse-executing to a series of watchpoints or whatever |
| 06:32 |
muurkha |
what kind of tools for Java and Python do you mean? |
| 06:32 |
muurkha |
you could use rr (or GDB) with a Lua program too |
| 06:32 |
muurkha |
with respect to manually instrumenting code, I've often manually instrumented someone else's code for this kind of thing :) |
| 06:33 |
muurkha |
but yeah breakpoint debugging definitely moves up the league table significantly when Other People's Code gets involved |
| 06:38 |
|
TheSilentLink joined #minetest |
| 06:51 |
|
definitelya joined #minetest |
| 06:52 |
|
proller joined #minetest |
| 07:22 |
|
Guest65 joined #minetest |
| 07:51 |
|
mrkubax10 joined #minetest |
| 08:03 |
|
jvalleroy joined #minetest |
| 08:22 |
|
Warr1024 joined #minetest |
| 08:43 |
|
olliy1or joined #minetest |
| 08:44 |
|
bodiccea_ joined #minetest |
| 08:44 |
|
Trifton_ joined #minetest |
| 08:45 |
|
Lunatrius` joined #minetest |
| 08:46 |
|
Warr1024 joined #minetest |
| 08:47 |
|
Noisytoot joined #minetest |
| 08:48 |
|
TomTom_ joined #minetest |
| 08:48 |
|
TheSilentLink_ joined #minetest |
| 08:48 |
|
Leopold_ joined #minetest |
| 08:49 |
|
lumidify_ joined #minetest |
| 08:49 |
|
lemonzest1 joined #minetest |
| 08:49 |
|
TeXMaster joined #minetest |
| 09:00 |
|
lemonzest joined #minetest |
| 09:12 |
|
appguru joined #minetest |
| 09:15 |
|
appguru1 joined #minetest |
| 09:35 |
|
mrkubax10 joined #minetest |
| 10:40 |
|
Alnotz joined #minetest |
| 12:26 |
|
Alnotz joined #minetest |
| 12:48 |
MTDiscord |
<bla8722> mh is it just me or is the minetest repo missing a commit/PR to match the TextureLayer renaming commit in the irrlicht repo? |
| 13:02 |
|
bodiccea joined #minetest |
| 14:18 |
|
sparky4 joined #minetest |
| 14:42 |
|
appguru joined #minetest |
| 14:47 |
|
sid0_ joined #minetest |
| 14:54 |
|
Desour joined #minetest |
| 14:54 |
|
sparky4 joined #minetest |
| 15:07 |
|
btdmaster joined #minetest |
| 16:37 |
|
behalebabo joined #minetest |
| 16:53 |
sfan5 |
yes |
| 16:54 |
sfan5 |
use whatever version is documented in misc/irrlichtmt_tag.txt if you want a guaranteed working build |
| 17:18 |
|
est31 joined #minetest |
| 17:26 |
|
sparky4 joined #minetest |
| 17:59 |
|
mrkubax10 joined #minetest |
| 18:05 |
|
qqq joined #minetest |
| 18:09 |
|
jojje joined #minetest |
| 18:24 |
|
Desour joined #minetest |
| 18:45 |
|
mrkubax10 joined #minetest |
| 18:46 |
|
mrkubax10 joined #minetest |
| 20:22 |
|
sparky4 joined #minetest |
| 21:41 |
|
appguru joined #minetest |
| 21:44 |
|
Helenah joined #minetest |
| 21:56 |
|
Helenah joined #minetest |
| 22:11 |
|
Helenah joined #minetest |
| 22:34 |
|
panwolfram joined #minetest |
