| Time |
Nick |
Message |
| 01:07 |
|
user333_ joined #luanti |
| 01:27 |
|
gera joined #luanti |
| 01:34 |
|
SwissalpS joined #luanti |
| 01:43 |
|
SFENCE joined #luanti |
| 02:02 |
|
SFENCE joined #luanti |
| 02:05 |
|
Eragon joined #luanti |
| 02:06 |
|
Confines joined #luanti |
| 02:06 |
Confines |
Yo user333_ |
| 02:06 |
Confines |
Finally got back from the work trip, nice attack lmao |
| 02:08 |
Confines |
Finally got around to adding a packet size limiter, I don't have enough ram to serve massive packets |
| 02:18 |
|
SFENCE joined #luanti |
| 02:34 |
user333_ |
oh hi Confines |
| 02:41 |
user333_ |
... |
| 02:45 |
user333_ |
he just timed out |
| 02:49 |
|
SFENCE joined #luanti |
| 03:05 |
|
Confines joined #luanti |
| 03:05 |
Confines |
I'm back |
| 03:08 |
Confines |
Just finished bringing the backend back from the dead and adding some much needed security measures |
| 03:13 |
|
SFENCE joined #luanti |
| 03:14 |
user333_ |
took you long enough, it was offline for almost 24h |
| 03:15 |
Confines |
I was on a work trip out of state |
| 03:19 |
user333_ |
i was setting up my new PC :P |
| 03:19 |
|
SFENCE joined #luanti |
| 03:20 |
user333_ |
anyway, that's twice i crashed your backend |
| 03:23 |
Confines |
Yeah, although both times the actual backend was fine, it just ran out of memory, either way that should be fixed now |
| 03:23 |
user333_ |
time to find more exploits! |
| 03:24 |
Confines |
Please do!@ |
| 03:24 |
user333_ |
also remove the 28,000 accounts a friend registered with a script :> |
| 03:24 |
Confines |
Already did |
| 03:24 |
Confines |
Closer to 34,000 |
| 03:24 |
user333_ |
oh wow |
| 03:24 |
Confines |
Still only took 100 kb |
| 03:25 |
user333_ |
also did you find any buggy ones? i registered a few with newlines/carriage returns/random unicode characters/escapes |
| 03:31 |
user333_ |
yay my new PC can run luanti with (almost) all shaders on |
| 03:31 |
[MatrxMT] |
<Blockhead256> reject shaders, embrace 1000 render distance |
| 03:31 |
user333_ |
nah |
| 03:32 |
user333_ |
i have a (relatively) good PC now, 6 cores/12 threads @3.5ish GHz, 16GB DDR4, 512GB SSD, dualbooting windows 11 23H2 and ubuntu 24.04.3 |
| 03:34 |
user333_ |
and some AMD GPU, lucky it wasn't NVIDIA, i hear their drivers are a pain to install on linux |
| 03:34 |
[MatrxMT] |
<Blockhead256> things have gotten better for nvidia lately, but, yes |
| 03:34 |
[MatrxMT] |
<Blockhead256> you have to have a lot of money lying around to buy their late model GPUs though |
| 03:35 |
user333_ |
this was some mini PC from amazon for like $500, very good price/specs ratio |
| 03:36 |
user333_ |
it's about ~2x larger than my RPi5+it's case |
| 03:38 |
|
Verticen joined #luanti |
| 03:41 |
Confines |
I'm so happy for you! |
| 03:41 |
Confines |
Now you can attack my backend with even more speed! |
| 03:41 |
user333_ |
now the fun part... transferring files from my RPi5 to my new PC |
| 03:41 |
user333_ |
using SFTP is giving me like ~30s of lag here though |
| 03:42 |
Confines |
Do you not have a usb stick |
| 03:42 |
user333_ |
you sound sarcastic :P |
| 03:42 |
Confines |
Nah |
| 03:43 |
user333_ |
i have a 128GB usb drive and a 1TB external hard drive... + some cheap 4GB USB drives that will corrupt if you touch them |
| 03:43 |
user333_ |
lucky the -l option for scp exists |
| 03:44 |
Confines |
Nice |
| 03:45 |
user333_ |
i'm using SFTP bc it's more convenient .-. |
| 03:45 |
user333_ |
il just let it run overnight and suffer the lag while i copy over my important stuff (totally not pirated games) |
| 03:47 |
Confines |
I love pirated games! |
| 03:47 |
user333_ |
so do i! i have (almost) every half-life and portal games, and a few SNES ROMS |
| 03:48 |
user333_ |
*nintendo and valve knock on my door* |
| 03:48 |
Confines |
nintendo can smb |
| 03:49 |
user333_ |
the SNES roms don't require a network connection to work so gl nintendo :P |
| 03:55 |
user333_ |
anyway im still waiting for an IRC channel :P |
| 04:00 |
|
MTDiscord joined #luanti |
| 04:00 |
|
SFENCE joined #luanti |
| 04:02 |
|
SFENCE_ joined #luanti |
| 04:04 |
|
SFENCE_ joined #luanti |
| 04:04 |
|
SFENCE_ joined #luanti |
| 04:14 |
|
SFENCE joined #luanti |
| 04:17 |
|
SFENCE_ joined #luanti |
| 04:20 |
|
SFENCE joined #luanti |
| 04:28 |
|
Confines joined #luanti |
| 04:28 |
Confines |
I'll do that soon, you've been keeping me busy on less fun things lol |
| 04:33 |
user333_ |
happy to help |
| 04:41 |
user333_ |
'Request entity too large\n' looks like you fixed it |
| 04:44 |
user333_ |
now to find an SQL injection vulnerability |
| 04:46 |
|
SFENCE_ joined #luanti |
| 04:48 |
Confines |
SQL injection hasn't been a thing since I made the backend |
| 04:48 |
Confines |
I was awake enough to make sure I had that |
| 04:48 |
Confines |
when I made the backend |
| 04:54 |
user333_ |
oh good lol |
| 04:54 |
user333_ |
i'm no cybersecurity expert but it lgtm (for now :P) |
| 04:58 |
user333_ |
i still have a few ideas to crash it but they are closer to a DDoS than an exploit |
| 05:04 |
Confines |
Please give it all you got |
| 05:22 |
repetitivestrai- |
https://github.com/luanti-org/luanti/issues/16633 |
| 05:22 |
|
repetitivestrain joined #luanti |
| 05:23 |
repetitivestrain |
https://github.com/luanti-org/luanti/issues/16633 since this proposal surfaces every so often and the ergonomics of configuring mineclonia's lua map generator are abysmal as it stands, why can't num_emerge_threads simply be fixed to one for the built-in map generators, which do not support multiple emerge threads, and configured to 0 or some other suitable default on singlenode |
| 05:26 |
repetitivestrain |
e.g.: https://github.com/luanti-org/luanti/issues/10606, https://github.com/luanti-org/luanti/issues/15630 |
| 05:26 |
repetitivestrain |
and i receive the impression that it was 0 by default some years ago |
| 06:17 |
|
YuGiOhJCJ joined #luanti |
| 06:20 |
|
sofar_ joined #luanti |
| 06:21 |
|
fluxionary joined #luanti |
| 06:24 |
|
swee joined #luanti |
| 06:41 |
|
FeXoR joined #luanti |
| 06:47 |
|
YuGiOhJCJ joined #luanti |
| 08:02 |
|
alias joined #luanti |
| 08:43 |
sfan5 |
repetitivestrain: wouldn't just setting this in your game's minetest.conf work? |
| 08:44 |
repetitivestrain |
sfan5: unfortunately not, because we also support the built-in mapgens |
| 08:45 |
repetitivestrain |
and i'm not sure whether modifying the option from lua would be possible, but it's still out of the question as it would overwrite players' minetest.confs on singleplayer |
| 08:46 |
sfan5 |
set_mapgen_setting does not work for this, no |
| 08:47 |
repetitivestrain |
yeah, i've already attempted this, but i was speaking of altering core.settings |
| 10:43 |
|
mrkubax10 joined #luanti |
| 10:50 |
|
mrkubax10 joined #luanti |
| 10:50 |
|
mrkubax10 joined #luanti |
| 10:51 |
|
mrkubax10 joined #luanti |
| 11:16 |
|
repetitivestrai- joined #luanti |
| 11:26 |
|
repetitivestrain joined #luanti |
| 11:39 |
|
mrkubax10 joined #luanti |
| 11:56 |
|
jaca122 joined #luanti |
| 12:11 |
sfan5 |
repetitivestrain: good news https://github.com/luanti-org/luanti/pull/16634 |
| 12:11 |
repetitivestrain |
sfan5: much appreciated, thank you! |
| 12:33 |
repetitivestrain |
sfan: i think the upper limit should be more conservative by default, as each lua environment started must by nature redundantly allocate memory for a great amount of information, voxelmanips, and cid and param2 arrays, which can amount to up to 500-700MB/thread, and defaulting to a maximum of 20 threads might unduly stress the system for memory |
| 12:33 |
repetitivestrain |
particularly on recent laptops with 16+ thread processors but only 16 gigabytes of ram that must be shared with other programs |
| 12:54 |
|
PoochInquisitor joined #luanti |
| 13:03 |
sfan5 |
what do you suggest |
| 13:04 |
repetitivestrain |
8, i think |
| 13:04 |
repetitivestrain |
that's what i use on my server (which has 64 cores) and produces a maximum rss of 6 gigabytes without any loaded blocks and 8 otherwise |
| 13:05 |
repetitivestrain |
otherwise with 1-2 players online* |
| 13:07 |
sfan5 |
6GB for 8 threads sounds like a lot |
| 13:07 |
repetitivestrain |
there's also the main thread and one async environment thread which share the same data |
| 13:08 |
[MatrxMT] |
<Blockhead256> is this the mcla mapgen with redundant data or one of the C++ mapgens? |
| 13:08 |
sfan5 |
hold on |
| 13:09 |
sfan5 |
!c (5*16)**4 * 4 / (1024*1024) |
| 13:09 |
MinetestBot |
156.25 |
| 13:09 |
repetitivestrain |
Blockhead256: with the lua map generator, yes |
| 13:12 |
sfan5 |
wait i calculated wrong |
| 13:12 |
sfan5 |
!c (5*16)**3 * 4 / (1024*1024) |
| 13:12 |
MinetestBot |
1.953125 |
| 13:13 |
repetitivestrain |
well that's not exactly accurate, since lua arrays are composed of 8 byte doubles |
| 13:13 |
sfan5 |
even by a conservative estimate one copy of a chunk is <10MB |
| 13:13 |
sfan5 |
how much do you store that you arrive at 700MB |
| 13:15 |
repetitivestrain |
three arrays of 80x512x80 data that amount to 75 megabytes, a 50 mb biome table, 75 megabytes of loaded schematics, i think, and hundreds of megabytes of jit code cache |
| 13:15 |
sfan5 |
!c 3*75+50+75 |
| 13:15 |
MinetestBot |
350 |
| 13:16 |
repetitivestrain |
you can reduce maxmcode to the default 64k and observe performance decline as you move between areas with different terrain characteristics but also maximum rss decline by a few hundred megabytes per thread |
| 13:16 |
|
silverwolf73827 joined #luanti |
| 13:23 |
repetitivestrain |
right, i also overlooked the generated biome array |
| 13:24 |
repetitivestrain |
which is as large as the mapblock itself and is also serialized and reported to the main thread as a gennotify |
| 13:28 |
repetitivestrain |
hmm, it's actually vmanip:get_data and vmanip:get_param2_data that allocate nearly 128 mb |
| 13:30 |
repetitivestrain |
-> Pre-on_generated.: 29 MB (+ 2) -> on_generated.: 157 MB (+ 128) -> Biome generation.: 158 MB (+ 1) -> Terrain generation.: 197 MB (+ 39) -> Biome encoding.: 197 MB (+ 0) -> Biome data serialization.: 197 MB (+ 0) -> Chunk generation.: 197 MB (+ 0) |
| 13:30 |
repetitivestrain |
and the jit code that continues to inflate rss after these buffers are allocated, because a call to jit.flush always reduces each environment's memory requirements to the initial ~200 MB |
| 13:30 |
repetitivestrain |
possibly as a result of the emerged area being one mapblock around the bounds of the mapchunk, even under singlenode? |
| 13:31 |
sfan5 |
!c ((5+2)*16)**3 * 8 / (1024*1024) |
| 13:31 |
MinetestBot |
10.71875 |
| 13:31 |
sfan5 |
idk how much overhead a lua table has |
| 13:32 |
repetitivestrain |
my mapchunks are 5x32x5 |
| 13:32 |
repetitivestrain |
!c (80*512*80)**3 * 8 / (1024 * 1024) |
| 13:32 |
MinetestBot |
268435456000000.0 |
| 13:32 |
repetitivestrain |
uh no haha |
| 13:32 |
sfan5 |
!c (80*512*80) * 8 / (1024 * 1024) |
| 13:32 |
MinetestBot |
25.0 |
| 13:32 |
repetitivestrain |
!c !c (80*512*80) * 8 / 8 |
| 13:32 |
MinetestBot |
SyntaxError: invalid syntax (<string>, line 1) |
| 13:33 |
sfan5 |
still not 128 mb |
| 13:33 |
repetitivestrain |
!c (80*512*80) * 8 * 3 / 8 |
| 13:33 |
MinetestBot |
9830400.0 |
| 13:33 |
repetitivestrain |
this is literally how i instrumented the code, though: |
| 13:34 |
repetitivestrain |
mcl_levelgen.report_consing ("-> Pre-on_generated"); local emin, emax = vmanip:get_emerged_area (); area = VoxelArea (vector.subtract (emin, minp), vector.subtract (emax, minp)); vmanip:get_data (cids); vmanip:get_param2_data (param2s); local generated = false; mcl_levelgen.report_consing ("-> on_generated") |
| 13:34 |
repetitivestrain |
where report_consing simply runs collectgarbage ("collect") and collectgarbage ("count") before deducting the value from the result recorded during the previous call |
| 13:42 |
|
mrkubax10 joined #luanti |
| 13:50 |
|
kamdard joined #luanti |
| 13:53 |
|
turtleman joined #luanti |
| 13:54 |
repetitivestrain |
sfan5: with no mcode size limit (maxmcode=32 GB), mcode usage (as measured by the reduction in memory consumption incurred by jit.flush) plateaus at 570 MB |
| 13:56 |
sfan5 |
per-thread? |
| 13:56 |
repetitivestrain |
yes |
| 13:58 |
repetitivestrain |
with the 40 mb mcode size limit that is defined in the main lua environment, the jit cache is flushed after several hundred chunks are generated, and after such a cache flush i recall that trace selection for the main terrain sampling loop would proceed much less optimally |
| 13:58 |
repetitivestrain |
but i'm not registering the same performance impact that i did when last i benchmarked this phenomenon |
| 14:00 |
repetitivestrain |
ye gods, i am blind |
| 14:00 |
repetitivestrain |
https://codeberg.org/mineclonia/mineclonia/commit/0cf0b6d36c1957e8ae05b8ef915f04cf7c6fecdc |
| 14:01 |
repetitivestrain |
i fixed the performance issue after trace flushes in august and it shouldn't be necessary to keep mcode unbounded any longer |
| 14:08 |
sfan5 |
https://store.steampowered.com/hwsurvey/cpus/ interesting |
| 14:09 |
sfan5 |
so most people would either get 3, 4 or 2 emerge threads |
| 14:09 |
sfan5 |
sounds ok |
| 14:10 |
repetitivestrain |
i concur, and thanks |
| 15:07 |
|
qqe joined #luanti |
| 15:23 |
|
bgstack15 joined #luanti |
| 15:29 |
erle |
repetitivestrain are you halon? i forgot |
| 15:29 |
repetitivestrain |
I am, yes\ |
| 15:30 |
erle |
repetitivestrain i understand the issues you have with faulty luajit versions. however, since you have a base function that is working and only the optimization fails, i think logging an error and using the normal unoptimized function would be enough for this use case. not every user is able to upgrade their luajit. why do you think the code being slower and a log message is not enough? |
| 15:31 |
repetitivestrain |
erle: it's not only the optimized version that fails, but only the optimized version that is aggressively _tested_ |
| 15:31 |
erle |
repetitivestrain also i used to do a similar tihng for faulty minetest versions, run tests at startup and complain if they failed. however, literally no one appreciated this. |
| 15:31 |
erle |
repetitivestrain if your optimization is not tested well enough, the equivalence of it is at best questionable. |
| 15:32 |
repetitivestrain |
the functions in question are supposed to yield mathematically well defined results, as they do on functioning versions of luajit |
| 15:32 |
erle |
repetitivestrain are you aware of what property testing is? if so: in this case you have a property: f(x) must equal f_optimized(x). a property testing framework can make sure this is true for all x. |
| 15:34 |
repetitivestrain |
erle: the problem is not whether the optimized and unoptimized versions are equivalent, but whether either version is compiled correctly by luajit and yields results equivalent to a completely separate ground truth |
| 15:35 |
repetitivestrain |
there's no telling whether a defective version of luajit will operate correctly, and, on account of luajit's character as a jit and trace compiler, even when these miscompilations will manifest |
| 15:35 |
erle |
repetitivestrain well then why don't you fall back to the base version in that case? |
| 15:35 |
repetitivestrain |
erle: as i said, the base version is equally liable to be miscompiled |
| 15:36 |
repetitivestrain |
the upshot is that the defective luajit cannot be tested and should be upgraded |
| 15:36 |
erle |
repetitivestrain oh i didn't understand that. so you are saying that regardless of code path, defective luajit is unserviceable? |
| 15:36 |
repetitivestrain |
correctly |
| 15:36 |
repetitivestrain |
you understand correctly* |
| 15:36 |
erle |
repetitivestrain and what is the impact of the miscompilation? |
| 15:37 |
erle |
defective PRNG? |
| 15:37 |
MTDiscord |
<luatic> you can turn JIT off for a function, but this risks massive performance hits |
| 15:37 |
repetitivestrain |
the rng will generate non-deterministic random values that are also inconsistent with properly functioning lua installations |
| 15:37 |
repetitivestrain |
because luajit is a trace compiler, not even jit.off is 100% reliable |
| 15:37 |
erle |
repetitivestrain that sounds like something that outside of cryptographic applications and test suites it should be a warning, not a crash. |
| 15:37 |
repetitivestrain |
erle: correct |
| 15:37 |
repetitivestrain |
erle: then the map generator will cease to be deterministic |
| 15:39 |
erle |
repetitivestrain then mention that in the log message? i am pretty sure that most people would prefer “luajit defective, mapgen is not deterministic” as a warning over NOT BEING ABLE TO RUN THE GAME. |
| 15:39 |
repetitivestrain |
That is worse than not being able to run the game |
| 15:39 |
erle |
repetitivestrain unless it outputs 3 3 3 3 3 3 3 |
| 15:39 |
erle |
how? |
| 15:39 |
erle |
i mean you have thought a lot about it, and i haven't |
| 15:39 |
erle |
so what's the worst that could (and inevitably will) happen? |
| 15:39 |
erle |
fucked up schematics? broken biomes? |
| 15:39 |
repetitivestrain |
each emerge environment is completely independent of others, and the result will be that chunks generated by one emerge thread may be discontinuous with chunks generated by others, and seeds will, in difficult to observe manners, not produce the same results after a restart or on different systems |
| 15:40 |
erle |
and this is true for all mapgens? |
| 15:40 |
repetitivestrain |
yes |
| 15:40 |
erle |
was it true in the past as well? |
| 15:40 |
repetitivestrain |
on the built in map generators it'll only impact structures, but the effect is just as catastrophic |
| 15:40 |
repetitivestrain |
no, because RNGs were not implemented in Lua in the past |
| 15:40 |
repetitivestrain |
but there were inexplicable crashes in dripstone.lua produced by the very same luajit package |
| 15:40 |
repetitivestrain |
dripstone's init.lua* |
| 15:40 |
erle |
oh interesting |
| 15:41 |
erle |
now i have a bit of experience doing bit-twiddling in lua. could you point me to the luajit issue regarding that topic so i can make sure i don't run into this? |
| 15:43 |
repetitivestrain |
erle: search for "ARM64: Don't fuse sign extensions into logical operands" in the LuaJIT repository |
| 15:44 |
repetitivestrain |
however, the luajit release at issue is impacted by all arm64 jit compilation issues that have been addressed since 2021 or so |
| 15:45 |
repetitivestrain |
and should not be trusted with _any_ lua code whatever, whether it implements random number generators or merely iterates over a table |
| 15:45 |
erle |
repetitivestrain well i do have an aarch64 laptop, does that mean i can't run it there? |
| 15:45 |
erle |
or is aarch64 different from arm64? |
| 15:45 |
repetitivestrain |
erle: no, it means you must _update luajit_ |
| 15:46 |
repetitivestrain |
the OP's version of luajit was multiple years out of date and is only distributed by distributions who are wedded to tagged releases, which prevents them from accepting luajit's switch to a rolling release schedule |
| 15:46 |
erle |
repetitivestrain do you have any idea which luajit version is the first “good” one and which one is the first “bad” one? |
| 15:47 |
repetitivestrain |
erle: any luajit compiled from source code after 10 Sep 2023 |
| 15:47 |
erle |
repetitivestrain this seems like you *can* pinpoint which commit/release it is. |
| 15:48 |
repetitivestrain |
but i can't disable luajit |
| 15:48 |
repetitivestrain |
obviously |
| 15:48 |
erle |
https://openresty.org/en/changelog-1025003.html |
| 15:48 |
erle |
> ARM64: Fuse rotates into logical operands and don't fuse sign extensions into these operands. |
| 15:48 |
repetitivestrain |
this is openresty's luajit distribution, yes |
| 15:48 |
erle |
so this is the first good or first bad one? Version 1.25.3.1 - 04 Jan 2024 |
| 15:49 |
repetitivestrain |
this is an unofficial luajit fork |
| 15:49 |
erle |
damn |
| 15:49 |
repetitivestrain |
luajit upstream doesn't tag releases at all |
| 15:49 |
MTDiscord |
<a.corp.serot> luajit's versioning scheme is a bit weird |
| 15:49 |
erle |
repetitivestrain great. i guess like irrlicht, at some point people will think it is dead lol |
| 15:49 |
repetitivestrain |
users are always advised to compile luajit from the most recent revision of the repository |
| 15:49 |
erle |
(irrlicht is not dead, it just has a very … rare … release schedule) |
| 15:49 |
repetitivestrain |
https://luajit.org/download.html |
| 15:50 |
repetitivestrain |
> LuaJIT uses rolling releases. There are no release tarballs available for download. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads — these links will cease to work soon. Do not use pseudo-releases or tarballs created by third parties. Do not use binaries offered for download by third parties. Pre-built packages should only be installed via a trusted |
| 15:50 |
repetitivestrain |
package manager for your operating system (distro). But you should be aware these often carry old versions that miss important fixes. Before reporting an issue, always try the latest version available from the git repository. Distro maintainers for distros that require the fiction of a release should do frequent snapshots of a branch. Do not attempt to cherry-pick or backport individual changes, no matter how self-standing |
| 15:50 |
repetitivestrain |
individual changes look (because they often are not). |
| 15:50 |
MTDiscord |
<a.corp.serot> are there really repos that have not caught up with luajit's rolling release scheme? |
| 15:50 |
erle |
repetitivestrain this seems it actually fucking sucks |
| 15:50 |
repetitivestrain |
a.corp.serot: Alpine, apparently |
| 15:50 |
repetitivestrain |
erle: everyone else has adapted, even debian i believe |
| 15:50 |
erle |
repetitivestrain do you have a standalone test that i can use to see if debian aarch64 code exhibits this? |
| 15:51 |
repetitivestrain |
erle: just run "luajit random.lua" and report whether it aborts |
| 15:51 |
repetitivestrain |
well, "luajit init.lua" |
| 15:51 |
repetitivestrain |
in the mcl_levelgen mod directory |
| 15:51 |
erle |
; luajit random.lua |
| 15:51 |
erle |
luajit: cannot open random.lua: No such file or directory |
| 15:51 |
erle |
# exited 1 |
| 15:52 |
repetitivestrain |
it should have been apparent from context that i meant you to load this file within mineclonia's mods/MAPGEN/mcl_levelgen directory... |
| 15:52 |
erle |
context-free or regular please |
| 15:52 |
erle |
i have an attention deficit, furthermore i can not read minds via TCP/IP |
| 15:53 |
erle |
i asked for a *standalone* test for a reason |
| 15:53 |
erle |
repetitivestrain in return, i will share a standalone test so you can see if your python installation is defective. |
| 15:53 |
repetitivestrain |
erle: i don't have any, sorry |
| 15:53 |
repetitivestrain |
however, i think there is one in the luajit repository |
| 15:54 |
repetitivestrain |
local t = {}; local zero = 0LL; local bit = require("bit"); for i = 1, 60 do t[i] = bit.bor(-i, zero); end; for i = 1, 60 do assert(tonumber(t[i]) == -i); end |
| 15:55 |
erle |
repetitivestrain here is one |
| 15:55 |
erle |
python3 -c 'import base64; print(base64.b64decode("=V=M=0="))' |
| 15:55 |
repetitivestrain |
b'T\xcd' |
| 15:55 |
erle |
if this does not output an error, your python3 installation is defective |
| 15:55 |
repetitivestrain |
Oh yes haha |
| 15:55 |
erle |
because "=V=M=0=" is not a valid base64 string |
| 15:56 |
repetitivestrain |
Emacs passes with flying colors |
| 15:56 |
repetitivestrain |
Debugger entered--Lisp error: (error "Invalid base64 data") base64-decode-string("=V=M=0=") |
| 15:56 |
erle |
however, if you remove one = sign at the end, python will fail |
| 15:56 |
erle |
(correctly) |
| 15:56 |
repetitivestrain |
Task failed successfully |
| 15:57 |
erle |
this error lets you infer that python3 base64 decoder is what LANGSEC people call a “shotgun parser” |
| 15:57 |
erle |
i.e. it does not validate its inputs as the first step, and has validation logic interspersed with processing code |
| 15:57 |
erle |
which is generally a recipe for disaster |
| 15:58 |
erle |
for this reason, *every single time* you handle base64 data in python, you have to make sure it is really actual base64 e.g. using a regular expression (base64 is regular) |
| 15:59 |
|
mrkubax10 joined #luanti |
| 15:59 |
erle |
repetitivestrain for additional amusement, “VM0” is the beginning of the fixed point of base64 |
| 16:00 |
erle |
; printf 'foo' |base64 |base64 |base64 |base64 |base64 |base64 |base64 |base64 |
| 16:00 |
erle |
Vm0weGQxTnRVWGxWV0dSUFZtMW9WMWxzVWxkalJuQllZMFZPVlZKVk5YVlZSbEYzVTNkdlBRbz0K |
| 16:00 |
erle |
; printf 'bar' |base64 |base64 |base64 |base64 |base64 |base64 |base64 |base64 |
| 16:00 |
erle |
Vm0weGQxSXlSblJXYTJSVVYwZDRXRmxyVm5kalJuQllZMFZPVlZKVk5YVlZSbEYzVTNkdlBRbz0K |
| 16:01 |
erle |
amusing, isn't it? |
| 16:01 |
repetitivestrain |
debian trixie's luajit is good |
| 16:01 |
erle |
applying the encoding to itself will always produce the thing |
| 16:01 |
repetitivestrain |
2.1.0+openresty20250117 |
| 16:01 |
erle |
https://www.joshisanerd.com/projects/base64fixpoint/d3ish.html |
| 16:01 |
erle |
repetitivestrain do you think the ENGINE should contain a self-test for luajit breakage? |
| 16:02 |
repetitivestrain |
but debian oldstable's luajit is an outdated release of 2.1.0-beta3 (with backports such as luajit's developer specifically advises against) and oldoldstable's is even more hopelessly out of date |
| 16:02 |
repetitivestrain |
erle: i think there is already some code in the CMakeFile for performing such tests, but it's far too conservative |
| 16:03 |
erle |
repetitivestrain well it's not like the engine developers are actually known for testing things much more than the average dev, despite the former name. you are probably an outlier. |
| 16:05 |
erle |
i used to moderate coding dojos. those are programming teamwork training games where who writes the code changes every 5 minutes or so and among the rules are “if a test fails, make it pass” and “if no test fails, implement a new test, possibly for something unimplemented”. |
| 16:05 |
erle |
what i learned was that people who have held programmer jobs for 10 or 15 years are sometimes unwilling to write a test at all, if the result is supposed to be only like 5 lines of cdoe. |
| 16:06 |
erle |
the tasks are stuff that is useless and of low complexity, like “add two roman numbers” |
| 16:06 |
erle |
so that people can focus entirely on testing and team communication |
| 16:06 |
repetitivestrain |
well we don't engage in such simulations at work, but everyone understands the advantages of aggressive testing |
| 16:06 |
erle |
repetitivestrain well, then are you aware of property testing? |
| 16:07 |
erle |
i happen to have held a lecture about that to a bunch of devs, was my highest-rated internal talk |
| 16:07 |
repetitivestrain |
i am, yes, but that's not the correct form of testing here |
| 16:07 |
erle |
repetitivestrain i understand that. i just wanted to let you know. |
| 16:07 |
repetitivestrain |
where the object is to guarantee that each unit generates results consistent with a precomputed ground truth |
| 16:07 |
erle |
well, in that case, you have your property |
| 16:07 |
erle |
it just needs to be precomputed |
| 16:08 |
erle |
“function output matches oracle” is a very common thing that people rarely test |
| 16:08 |
erle |
but it *is* a property |
| 16:08 |
erle |
like, one of the seven (or eight?) basic properties i told people about |
| 16:08 |
repetitivestrain |
the property in question is purely fortuitously implemented by Microsoft in Java, but that's as maybe |
| 16:08 |
erle |
“purely fortuitously”, what does tat mean? |
| 16:09 |
repetitivestrain |
uh it means it is a circumstance that arose by chance rather than for a purpose |
| 16:09 |
repetitivestrain |
accidentally |
| 16:09 |
repetitivestrain |
coincidentally |
| 16:10 |
repetitivestrain |
and it is proprietary, yes, so i can't incorporate it into mineclonia or even acknowledge its presence, and my knowledge of it was derived not from reading its source code, but public documentation elsewhere, and writing batteries of unit tests linked against unmodified minecraft class files, with the assistance of yarn mappings |
| 16:10 |
repetitivestrain |
acknowledge its existence* |
| 16:11 |
erle |
repetitivestrain oh right i get it |
| 16:12 |
erle |
repetitivestrain the “exactly like minecraft” thing |
| 16:12 |
erle |
hard to test a PRNG without a cross-language property testing framework (and even then) |
| 16:13 |
repetitivestrain |
for example: microsoft's version of java's default prng does not match the implementation in openjdk and the java specification |
| 16:13 |
erle |
repetitivestrain thanks i hate it |
| 16:13 |
repetitivestrain |
https://bugs.mojang.com/browse/MC/issues/MC-239059 |
| 16:13 |
erle |
repetitivestrain so that means if you run M***C***** using openjdk or so it fails? |
| 16:14 |
erle |
i used to browse the mojang bug tracker for funsies when i needed a laugh |
| 16:14 |
erle |
it's *very* funny at times |
| 16:14 |
cheapie |
repetitivestrain: Is this supposed to load eventually? |
| 16:14 |
erle |
best thing i found was an autocloser bot that responded to “i can confirm that this issue is NOT a duplicate of #whatever” with “closed as duplicate of issue #whatever” |
| 16:14 |
repetitivestrain |
no, but now imagine how many weeks i had a slightly defective prng, derived from the openjdk implementation, before inconsistencies with minecraft in the seeding of certain noises on very specific seeds led me independently to diagnose their bug and locate this issue ^ |
| 16:14 |
repetitivestrain |
cheapie: is what? |
| 16:15 |
erle |
repetitivestrain reverse engineering is a pain |
| 16:15 |
cheapie |
repetitivestrain: The page you linked, it just shows a loading spinner and nothing else |
| 16:15 |
erle |
cheapie might be js or adblocker shenanigans |
| 16:15 |
repetitivestrain |
oh, it's microsoft's fault then |
| 16:15 |
cheapie |
I don't have JS blocked and my ad blocker reports not having blocked anything on this page, *shrug* |
| 16:16 |
sfan5 |
doesn't load for me in either firefox or chromium |
| 16:16 |
repetitivestrain |
Hahaha |
| 16:16 |
erle |
well, mojang delivers again |
| 16:16 |
repetitivestrain |
leave it to Microsoft not to be able to keep an issue tracker online |
| 16:16 |
erle |
fun for the whole internet |
| 16:17 |
erle |
repetitivestrain ever since they overtook github it became SLOW in some browsers. i believe safari? |
| 16:17 |
erle |
what a coincidence. right up the alley with youtube being slower in firefox |
| 16:17 |
repetitivestrain |
i don't use github anyway |
| 16:17 |
repetitivestrain |
well, i browse it, but only with noscript on |
| 16:18 |
erle |
yeah me too, it became worse and worse |
| 16:18 |
erle |
i mean forgejo is kinda shitty performance-wise lately |
| 16:18 |
erle |
but github takes the cake |
| 16:18 |
repetitivestrain |
cheapie: anyway, the issue was that the final rshift for truncating the lcg state when the desired number of bits is fewer than 48 was arithmetic in mojang's implementation |
| 16:19 |
repetitivestrain |
while openjdk's was a logical operation |
| 16:29 |
|
mrkubax10 joined #luanti |
| 17:11 |
|
jonadab joined #luanti |
| 18:39 |
|
mrkubax10 joined #luanti |
| 18:41 |
|
mrkubax10 joined #luanti |
| 19:31 |
|
crazylad joined #luanti |
| 19:32 |
|
___nick___ joined #luanti |
| 19:44 |
|
MTDiscord1 joined #luanti |
| 19:45 |
crazylad |
man, #16239 should get merged lol |
| 19:45 |
ShadowBot |
https://github.com/luanti-org/luanti/issues/16239 -- Add new setting to enable/disable dark mode in main menu by ZenonSeth |
| 19:46 |
crazylad |
I even forked this PR to be able to set the top half and bottom half of the menu sky by passing a second parameter to 'core.set_sky_color()' |
| 20:10 |
|
___nick___ joined #luanti |
| 20:11 |
|
___nick___ joined #luanti |
| 20:46 |
|
Talkless joined #luanti |
| 21:16 |
|
stephan48 joined #luanti |
| 23:16 |
|
germ_ joined #luanti |
| 23:33 |
|
panwolfram joined #luanti |
