Time Nick Message 16:30 jonadab "Implemented in C" is the only sense in which I can think of lua as C-based. 16:30 jonadab And let's be honest, _most_ programming languages are implemented in C. 16:30 jonadab And almost all of the rest, are self-hosting. 16:32 MTDiscord Well, Lua being implemented in C does also manifest in the design of Lua, esp. the standard library, which is in large parts just a Lua wrapper around the C standard library whereas many other languages that don't value portability as much go the extra mile to write much more platform-specific stdlib code. 16:55 jonadab Higher-level languages typically have a lot of the stuff the C standard library does, as native built-in functions or whatever. 16:56 jonadab But lua was designed to be lightweight because it's intended to be embedded in other applications. 16:56 jonadab Similar to rep. 16:57 celeron55 most computers are basically designed for C, thus C-based, from processors to keyboards, and everything in between 16:57 celeron55 just due to the history that is built into everything 16:58 jonadab I mean, by that logic you could say that computers are designed to run Unix. 16:58 celeron55 that goes with the C thing 16:58 jonadab I suppose. 16:59 celeron55 once you get into machines and environments not designed for C, you feel it. it's entirely different, and not many practically exist 16:59 erle celeron55 which ones do you have in mind? 17:00 celeron55 of course arguably this is stretching it a bit 17:00 erle lisp machines? 17:00 erle the colorforth processors? 17:00 celeron55 maybe something like smalltalk or APL 17:01 celeron55 not sure 17:02 celeron55 certainly lisp machines 17:04 erle should we take this to #minetest maybe 18:05 [MTMatrix] position locker, it works... https://git.phreedom.club/localhost_frssoft/fediauth/src/branch/master/join.lua#L205 18:34 nrz_ Hello, merging #13847 18:34 ShadowBot https://github.com/minetest/minetest/issues/13847 -- doc: fix improper code blocks parsing for lua_api_deploy by using pymdown-extensions by corpserot 18:36 nrz_ sfan5, i merge irr#245 which is whitespace only. I don't know why ci link build fail, but it's not related to the PR, let's move forward on this huge topic 18:36 ShadowBot https://github.com/minetest/irrlicht/issues/245 -- Cleanup line endings by numberZero 18:42 sfan5 every existing PR will now need to be rebased 18:44 Krock dear god 18:44 sfan5 (which is like 5 or 6 but still bad) 18:45 sfan5 also we cannot merge upstream changes anymore 18:45 Krock wasn't it possible to wait a day to at least give a chance for feedback? 18:47 Krock I suppose this was done in regard to the irrlicht merge into Minetest, though. 19:00 nrz_ i thought it was validated we moved forward on this topic my bad. What's the goal on the irrlicht repo ? merge all current PR then merge code in MT ? or freeze PR, (they can be reopened after merge if useful, it's not a big deal) 19:01 nrz_ github doesn't say it require rebase , whitespaces are pretty properly handled by git 19:02 nrz_ hard question about the render, we continue to maintain this irrlicht version or at a moment we try a big bang to another solution, like godot or something ? 19:02 sfan5 https://github.com/minetest/irrlicht/pull/243 this one does 19:02 sfan5 anyway I don't think the full path before merging irrlicht has been decided yet 19:03 nrz_ tbh we talked about this for months, i now some "mature" OSS tools have some lag on some important decisions. Do we have some issues remaining before the merge ? 19:03 nrz_ (i saw that irrlichtmt doesn't build on the whitespace PR on mingw for example) 19:04 sfan5 https://github.com/minetest/irrlicht/issues/107 19:04 sfan5 and there's also open bugs with sdl2 19:04 nrz_ understood, but it's not related to the code merge in MT 19:05 nrz_ there is not much remaining point in your roadmap, and they can be merged as a section in MT roadmap no ? 19:07 nrz_ oh there is my started work on the IRR_DEFINE which may block yeah 19:08 nrz_ it's i think the most blocking part to merge both, other are just cpp, this one is the build system 19:08 sfan5 I'd like to get as many intrusive changes as possible done before the import 19:08 sfan5 (because importing and then changing everything again clutters git history) 19:09 nrz_ which change are your refering about, in the previous list ? 19:10 nrz_ because, for example the interface removal is huge, but can be done over time. Interfaces are pretty nice if properly used (irrlicht used a bit too much i think) 19:12 MTDiscord Does this mean getting upstream help for the glTF loader is now no longer possible? 19:16 sfan5 " Remove compressed color formats" for example 19:16 sfan5 or "Drop anything but SDL2" 19:16 sfan5 every line of code we don't have to copy into MT is a win 19:18 nrz_ for the color format what's the point, code removal sound too simple, i may miss something 19:18 nrz_ why do we want to remove that ? there is no side effect ? 19:21 sfan5 why do you want to keep unused code? 19:27 nrz_ if it's unused why we don't have removed it yet ? ๐Ÿ˜„ 19:27 nrz_ if it's unused i'm totally with you, i just don't understand this point in the roadmap, it sounds simpler than the build system itself which requires a bit rework on those shit includes 19:30 sfan5 it's indeed unused, I just haven't had time to do this yet 19:31 sfan5 in case someone is worrying about future usage: I did ask x2048 about this and he said that it won't be useful to have even in the future 19:33 erle nrz_ you can look at the tradeoffs yourself https://www.khronos.org/opengl/wiki/S3_Texture_Compression 19:33 erle nrz_ basically you have the option to sacrifice texture accuracy for memory bandwith 19:34 erle nrz_ for the general style of minetest you'd *probably* notice any degradation in textures? no idea 19:36 erle if bandwith is the bottleneck on any GPU for a game, you can use compressed texture formats ig 19:37 pgimeno I thought it was a question of memory capacity more than bandwidth 19:37 pgimeno (GPU memory capacity, that is) 19:38 erle i guess? when your GPU memory becomes full of stuff, you have to switch out and in textures in some kind of streaming setup. 19:38 nrz_ Ok it's more for old hardware 19:38 erle no? 19:40 erle nrz_ what makes you think that actually? 19:42 erle i know very little about 3D and opengl, but i am pretty sure it is lossy compression that is just inappropriate for pixel art 19:43 erle nrz_ look at pages 7 and 8 here https://www.oldunreal.com/editing/s3tc/ARB_texture_compression.pdf 19:45 erle and maybe, just maybe, read the paragraph with the heading โ€œRuntimeโ€ that goes from page 8 to 9 22:22 Desour merging #13244 in 5 22:22 ShadowBot https://github.com/minetest/minetest/issues/13244 -- MapblockMeshGenerator: Use more verbose member names by Desour 22:28 [MTMatrix] ๐Ÿ‘