Minetest logo

IRC log for #minetest, 2022-06-09

| Channels | #minetest index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:00 fling joined #minetest
01:06 KvL joined #minetest
01:17 Lesha_Vel joined #minetest
01:23 fling joined #minetest
02:37 leo_rockway joined #minetest
04:00 MTDiscord joined #minetest
04:10 sec0nd joined #minetest
05:09 lemonzest joined #minetest
05:26 calcul0n joined #minetest
05:58 Lesha_Vel_ joined #minetest
07:22 Alias joined #minetest
07:29 Edgy27 joined #minetest
07:51 luk3yx joined #minetest
08:11 behalebabo joined #minetest
08:11 mannerism joined #minetest
08:14 erstazi joined #minetest
08:19 appguru joined #minetest
08:39 sagax joined #minetest
09:20 ___nick___ joined #minetest
09:43 fling joined #minetest
10:46 proller joined #minetest
10:46 definitelya joined #minetest
11:10 specing joined #minetest
12:34 proller joined #minetest
13:04 dabbill joined #minetest
13:43 Fixer joined #minetest
15:00 debiankaios joined #minetest
16:16 Verticen joined #minetest
16:56 Talkless joined #minetest
17:03 peterz joined #minetest
17:12 fling joined #minetest
17:20 mannerism joined #minetest
17:32 mannerism joined #minetest
17:36 mannerism joined #minetest
17:36 sobkas joined #minetest
17:37 Alias joined #minetest
17:48 mannerism joined #minetest
18:03 fling joined #minetest
18:45 Talkless joined #minetest
19:35 clavi joined #minetest
19:35 clavi joined #minetest
20:14 sfan5 paradust: should never be the case
20:14 sfan5 can I summon some lua experts here
20:14 sfan5 https://0x0.st/oM6i.png what is wrong with this code
20:14 sfan5 I can't figure it out
20:15 sfan5 instead of a three high cobble column the nodes are all over the place, as if the indexes were wrong
20:18 sfan5 okay nevermind reading the docs helped
20:18 Krock_ wrong minp/maxp?
20:19 Krock_ local vm, emin, emax = minetest.get_mapgen_object("voxelmanip")
20:19 Krock_ local va = VoxelArea:new{MinEdge=emin, MaxEdge=emax}
20:19 sfan5 yes
20:19 sfan5 that begs the question why minp ~= emin or maxp ~= emax
20:20 Krock the mapgen may emerge more blocks around
20:20 Krock IIRC for structures that overlap the borders
20:21 Krock schematics placement with Vmanip for example
20:21 Krock the coordinates may go outside of minp/maxp but there's still vmanip data from the generator to place it
20:23 sfan5 hm
20:36 MTDiscord <FatalError> Breaking: Local core dev cant understand API
20:36 proller joined #minetest
20:37 Krock even devs cannot remember what each part of the API is supposed to do
20:37 muurkha to be fair there are some aspects of the API that are a bit obscure
20:37 muurkha not to say rebarbative
20:37 Krock clearly 9000 lines of documentation is not enough :/
20:40 muurkha it's over 9000!
21:00 MTDiscord <luatic> sfan5: I believe everybody is bound to shoot themselves in the foot with this
21:01 MTDiscord <luatic> Krock: A clean API would feed the VoxelArea with emin, emax on itself - modders couldn't possibly mess up
21:01 sfan5 https://0x0.st/oM6j.png is this too much gravel
21:01 muurkha documentation can tell you how to work around a bad interface but it doesn't make it a good one.  most of the Minetest API is great but there are some boners
21:04 YuGiOhJCJ joined #minetest
21:04 MTDiscord <luatic> No, most of the MT API isn't great.
21:05 erle yeah most of it has grown, but not necessarily prospered
21:05 erle it works, for the most part
21:05 muurkha maybe your standards are higher than mine, but I've seen a lot of people with only minimal programming experience get interesting mods working, which in my mind is the mark of a great API
21:06 erle oh no, that's a basic requirement for something that wants mods
21:06 MTDiscord <luatic> That's on Lua rather than the MT API
21:06 MTDiscord <luatic> cue erle hating on the global environment
21:06 muurkha the global environment is definitely a design flaw in Lua
21:07 MTDiscord <luatic> Elaborate
21:07 MTDiscord <luatic> Would you prefer local by default?
21:07 erle lua is basically a bunch of design flaws that are easily embeddable :P
21:07 MTDiscord <luatic> NOOOOOOOOOOOOOOOO
21:07 muurkha I'd prefer syntax-error-by-default and no variable scope larger than a file
21:07 muurkha well, compile-error-by-default
21:08 MTDiscord <luatic> You can use Lua that way and it is in fact often done
21:08 erle lua is so cool it can do boolean operations on non-boolean arguments
21:08 MTDiscord <luatic> Most script langs do that
21:08 erle > print(0 or 1)
21:08 erle 0
21:08 MTDiscord <luatic> Lua isn't strictly typed, what a surprise
21:08 MTDiscord <luatic> erle: Yes, that's immensely useful
21:09 erle yes, but many others would evaluate 0 to falsy
21:09 MTDiscord <luatic> But Lua isn't C
21:09 muurkha I think the best design is something like `a = 5` declares a new variable named `a` and errors if it's already in scope, while `set a = 5` changes the value of the existing variable `a` to 5 and errors if it's not already in scope
21:09 erle or python
21:10 muurkha Perl with `use strict;` is the closest I've encountered on this, but it spells them `my $a = 5;` and `$a = 5;` respectively, which is backwards and also has line noise in it
21:10 MTDiscord <luatic> The truthiness is just a detail
21:10 erle come on, lua sucks big time
21:10 muurkha lua is pretty gret
21:10 MTDiscord <luatic> muurkha: Backwards? This is the next big disagreement
21:10 muurkha *great
21:10 MTDiscord <luatic> Should mutable or immutable be the standard?
21:11 MTDiscord <luatic> Syntax-wise I'd prefer a := x or <keyword> a = x for declaration and a = x for assignment
21:11 muurkha luatic: declaring new variables should be the default, mutating them an exception.  I don't think you necessarily need to make them immutable
21:11 muurkha yeah, Golang does it the way you prefer
21:11 MTDiscord <luatic> I know :) I like go
21:11 MTDiscord <luatic> erle: Lua doesn't "suck big time"
21:12 MTDiscord <luatic> Only Lua written by C programmers sucks big time
21:12 muurkha Lua has some real flaws, but it's a brilliant language
21:12 MTDiscord <luatic> ^
21:12 MTDiscord <luatic> I have compiled lists of actual flaws
21:12 MTDiscord <luatic> https://cdn.discordapp.com/attachments/749727888659447960/984565751283327026/Why_Lua_sucks.md
21:12 muurkha mine is short: 1-based indices, global by default, no integers
21:13 erle what lol
21:13 muurkha (unless you compile it without floats, which is worse)
21:13 MTDiscord <luatic> erle: It's in my "heresy" folder :)
21:13 MTDiscord <luatic> muurkha: why'd you want integers?
21:13 MTDiscord <luatic> doubles are literally a superset of 32-bit itns
21:13 MTDiscord <luatic> ints*
21:14 muurkha floating-point is a powerful and dangerous facility that should be reserved for the cases where it's necessary
21:14 MTDiscord <luatic> Using doubles as ints is not dangerous at all.
21:14 erle check out my doubles
21:14 MTDiscord <luatic> This just stems from the common misconception that floating point means "random inaccuracies in calculations"
21:14 muurkha addition and multiplication on 32-bit integers are commutative, associative, and distributive.  none of those is true of floating-point
21:15 muurkha no, I've taken basic numerical analysis :)
21:15 muurkha while I don't want to say I know what I'm talking about, my level of not knowing what I'm talking about is a little higher than *thta*
21:15 muurkha *that*
21:15 MTDiscord <luatic> good
21:15 MTDiscord <luatic> Still, I don't see any issues with floats
21:15 MTDiscord <luatic> You don't get weird overflow behavior
21:16 muurkha you do, actually
21:16 MTDiscord <luatic> (instead you get inaccuracies and eventually +inf)
21:16 muurkha you get cases where x ~= 0 but x + y == y
21:16 MTDiscord <luatic> Yes
21:16 muurkha that's weird overflow behavior and sometimes it results in nonterminating computations
21:16 muurkha I don't think there's a perfect solution to overflow, just tradeoffs
21:17 MTDiscord <luatic> When possible use fractions instead of floats ;)
21:17 MTDiscord <luatic> https://github.com/TheAlgorithms/Lua/blob/main/src/math/fraction.lua
21:17 erle issues with floats: everybody gangsta until NaN
21:17 muurkha heh
21:17 erle issues with ints: everybody gangsta until integer overflow
21:17 muurkha my first program in Smalltalk rendered a Mandelbrot set, and I couldn't figure out why it became unusably slow after 15 iterations or so
21:17 MTDiscord <luatic> seriously though muurkha, you can trivially emulate uint behavior just by doing % 2^32 after each op
21:18 muurkha yes, that is true
21:18 MTDiscord <luatic> but normally you won't want this
21:18 MTDiscord <luatic> because you know that all your integer numbers (including intermediate results) will fall in the 2^52 range which is represented accurately
21:18 muurkha well, it's a better tradeoff for some applications, but yes
21:19 muurkha so my Smalltalk would approximate a Mandelbrot just fine at 10 iterations
21:19 muurkha and 11, 12, 13
21:19 muurkha at 14 iterations it got slow
21:19 muurkha at 16 iterations it was four times as slow
21:19 muurkha at 17 iterations it was even slower, unusably so
21:20 muurkha finally I figured out what the problem was
21:20 muurkha I was calculating the pixel increment by dividing the view range (-2 to 2) by the number of pixels
21:20 muurkha as it happened my view range was integers.  in Smalltalk dividing integers gives you a fraction
21:21 muurkha guess what happens when you repeatedly square a fraction?  the numerator and denominator double in length on every iteration
21:21 MTDiscord <luatic> bigint moment
21:21 MTDiscord <luatic> Python programmers nowadays often run into similar issues
21:21 muurkha and Smalltalk, like most Lisps and recent versions of Python, handles overflow by transparently failing over to, yes, bigints.  arbitrary precision
21:22 MTDiscord <luatic> bigints just violate the assumption that arithmetic ops are constant time
21:22 muurkha from a semantic Lisp-programmer point of view this is the perfect solution to overflow
21:22 muurkha but I did not think it was perfect
21:22 muurkha inserting a ".0" in my program made it render the Mandelbrot instantly
21:22 MTDiscord <luatic> much like all these spread operators etc. today or ops on string obstruct the hidden runtime cost
21:23 Pexin < muurkha> luatic: declaring new variables should be the default, mutating them an exception.
21:23 Pexin ^ u wot
21:23 MTDiscord <luatic> garbage collection  also hides complexity
21:23 muurkha yeah, but usually it's not an exponential factor as it was in this case
21:24 MTDiscord <luatic> anyways erle: If you want more quirks, just try math.random(2^40) on PUC Lua ;)
21:25 muurkha Pexin: take a look at a piece of your code and look at how many places you'd have to insert `set ` if you were programming in a language designed the way I suggest.  you'll be surprised how few it is
21:25 muurkha pre-Golang I would have suggested `a = 5` for the definition and Pascal-style `a := 5` for the mutation
21:25 Pexin as a C++ person, I'd use #defines or const in those cases
21:26 Pexin variables exist to be variable
21:26 muurkha in C++ you might be right, though I do see a pretty large number of const declarations in C++
21:27 MTDiscord <luatic> := for mutation? sorry but that's gross
21:27 muurkha that's what Pascal uses, luatic
21:27 MTDiscord <luatic> := is mathematically always used for definitions
21:27 muurkha sorry, I didn't do it
21:27 MTDiscord <luatic> "let x := the number of ..."
21:27 MTDiscord <luatic> muurkha: then don't repeat it ;)
21:28 muurkha well, like I said, I think post-Golang it's not a reasonable solution
21:28 muurkha `set a = 5` or `now a = 5` is
21:28 MTDiscord <luatic> pascal also brought the evil of code-data distinction upon programmers
21:28 muurkha or `a <- 5` if you don't have chans
21:28 muurkha luatic: how much memory does mushing together hashmaps and lists really cost?  I have the sense that lists in Lua use a lot less memory than in Python or Perl
21:29 MTDiscord <luatic> muurkha: considering that both parts start at size 0: not much
21:29 muurkha you mention it as one of the defects of Lua
21:30 muurkha program and data have been distinct since before stored-program computers; unifying them was Turing's great insight
21:30 MTDiscord <luatic> not compared to Python though
21:30 MTDiscord <luatic> muurkha: basically I was writing a character set
21:31 MTDiscord <luatic> Something that could trivially fit into 32 bytes (256 characters)
21:31 muurkha as a bitvector you mean?
21:31 MTDiscord <luatic> now the idiomatic Lua data structure for this would be a table, specifically the hash part
21:31 MTDiscord <luatic> as a bitvector, yes
21:31 muurkha yeah
21:31 MTDiscord <luatic> you can emulate it using a bitstring
21:31 muurkha I agree that Lua's implicit coercion is pretty problematic, and in particular `nil`
21:31 MTDiscord <luatic> but it's not nearly as convenient
21:32 muurkha so maybe I should update my list to: 1-based indices, global by default, no integers, implicit coercion
21:32 sfan5 what about immutable strings
21:33 muurkha immutable strings can be argued either way, like most immutable things
21:33 MTDiscord <luatic> the memory savings are neat
21:33 MTDiscord <luatic> but a consequence is that string building is gross
21:33 MTDiscord <luatic> you can use a rope, sure
21:33 muurkha it would be a lot less problematic if reading a nonexistent table entry returned you an error object containing the message "nonexistent table entry `choppy` at wurble/init.lua:47" instead of nil
21:34 MTDiscord <luatic> 8x memory consumption when you write character-wise though
21:34 MTDiscord <luatic> muurkha: You can set a metatable if you want that behavior ;)
21:34 muurkha you can amortize that by auto-compacting your rope leaves
21:34 muurkha you can, except that Lua doesn't have error objects
21:34 MTDiscord <luatic> muurkha: Yes, but then you create lots of garbage strigns again
21:35 muurkha that's true, but doesn't the Lua GC deal pretty well with high allocation rates of small short-lived objects?
21:35 MTDiscord <luatic> Fun fact: Lua actually even has a builtin string builder, but you don't get to use it ;)
21:35 muurkha haha
21:35 MTDiscord <luatic> Except if you happen to be gsubing something
21:35 MTDiscord <luatic> If you can use gsub, use gsub, don't roll your own ;)
21:36 MTDiscord <luatic> Mhm, GC
21:36 muurkha I think LPeg answers the pattern-matching limitations pretty well
21:37 muurkha like, most languages don't have anything similar to LPeg
21:38 MTDiscord <luatic> No, not the LPeg
21:38 MTDiscord <luatic> not the LPeg
21:39 MTDiscord <luatic> it scares us
21:39 muurkha regexps, guns, and floating-point are in the category of "powerful tools that should be reserved for uses where they are justified"
21:39 MTDiscord <luatic> I'll take proper RegEx + CFG over LPeg any time
21:39 MTDiscord <luatic> PEG is the kind of grammar with the least theory behind it
21:40 MTDiscord <luatic> regular grammars are safe to use if you know how to use them
21:40 muurkha PEGs are both more powerful (usually) and safer than regular expressions
21:40 MTDiscord <luatic> What?
21:40 muurkha most regexp engines have exponential-time blowup problems
21:40 MTDiscord <luatic> Not at all
21:40 MTDiscord <luatic> That's on the engines
21:40 muurkha sure
21:40 MTDiscord <luatic> Actual regular expressions can be matched in linear time in the size of the input
21:40 MTDiscord <luatic> And decent engines like those of Go or Rust do it that way
21:40 MTDiscord <luatic> Or the PoC engine I'm writing in Lua :)
21:41 MTDiscord <luatic> That's how I stumbled on the charset problem BTW
21:41 MTDiscord <luatic> Naive charsets take up 2kB per full charset
21:41 muurkha it's true that PEGs are not all that analytically tractable.  I was surprised to learn a few weeks ago that even the question of whether a PEG production can match the empty string is undecidable
21:41 muurkha but there's actually a fair bit of theory behind them
21:41 MTDiscord <luatic> because 8 + 8 bytes for each k/v pair
21:41 muurkha that's a lot
21:43 muurkha here's a thought about csets: √256 = 16.  what if you have a table with 16 entries, each of which is "none", "all", or a 16-bit bitvector?
21:43 muurkha this is obviously dumb for 256 characters I guess, and not adequate even for 65536
21:44 MTDiscord <luatic> Lua uses UTF-8 so I don't care about 2^16 ^.^
21:44 MTDiscord <luatic> I did in fact consider just splitting at 4-bit nibbles
21:44 muurkha heh
21:44 MTDiscord <luatic> But it'd make the implementation significantly more gross
21:44 MTDiscord <luatic> Also TBF a couple kB for RegEx are fine xD
21:44 muurkha I've done a little work on Hammer, a PEG engine that supports matching arbitrarily aligned bitfields
21:45 muurkha well, I shouldn't say it's a PEG engine
21:45 muurkha since it also has other backends including LALR, if your grammar is LALR-compatible
21:47 muurkha nibblematching might be a good approach if you were going to run your matcher in hardware, with a ROM driving a state register like the Apple ][ disk drive
21:48 muurkha does LuaJIT do a reasonable job of compiling the obvious code for indexing into a 32-byte bitvector?
21:49 MTDiscord <luatic> yes
21:49 MTDiscord <luatic> in fact it's faster than indexing the hash table
21:49 muurkha good!
21:49 MTDiscord <luatic> despite using numerous ops
21:49 muurkha in theory having a decent JIT backing your DSL could be a big win for DSL implementations: compile your regexp into Lua or JS or whatever, then hope the JIT compiler does a good job of compiling that into efficient binary code
21:50 muurkha but every time I've tried it, for example in http://canonical.org/~kragen/sw/dev3/sweetdreams.html, I've been disappointed
21:50 muurkha which probably is because I was hoping to not have to understand how the JIT compiler works at a deep level
21:52 muurkha compiling to naïve C and then feeding it to GCC and dlopen()ing the result sometimes works better
21:54 muurkha (I know that page is mostly about the C++ version of the softsynth; I'm talking about the part where I say, "I also wrote a JS version in Node.js which compiles the dataflow graph into a JS function in order to take advantage of runtime code generation. Instead of being faster than the C++ version, it’s about 10× slower. That’s still twice as fast as when it was just interpreting the dataflow graph
21:54 muurkha the way the C++ version does, and 20× as fast as my first JS draft, where I had totally messed up the buffering."
21:54 muurkha )
21:55 muurkha LuaJIT is really great at dlopen()ing things!
22:00 Sven_vB joined #minetest
22:02 kaeza joined #minetest
22:34 panwolfram joined #minetest
23:09 specing_ joined #minetest
23:19 mannerism joined #minetest
23:51 leo_rockway joined #minetest

| Channels | #minetest index | Today | | Google Search | Plaintext