00:46 < bridge> https://lkml.org/lkml/2024/10/5/453 the new linus is boring, I want the old Linus back 02:10 < bridge> It must get tiring to ferociously defend the codebase for so long, I don't think I could do it 02:14 < bridge> I agree with his side, the other guy should do more testing 02:14 < bridge> the last night thing is crazy 02:17 < bridge> I think the actual patches are 2 weeks old but the commits were reformatted the night before. but still I would think for the kernel you'd want to have them in their final format for a while before shipping them 02:19 < bridge> yeah 07:32 < bridge> good morning vietnam 08:34 < bridge> :crylove: 08:34 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1293461616427401248/image.png?ex=67077580&is=67062400&hm=d7a7e074951bca7d41cf8a0cf22fb2b88bb933e5d1033fb98f8af21fde8739c4& 08:38 < bridge> Yo, I'm writing a "type checker" for my language and I wanted to ask if you know how to make the code better because what I made is... not the best code 08:38 < bridge> ```rust 08:38 < bridge> pub fn check_sub(lhs: &Expr, rhs: &Expr, scope: &Scope) -> Result<()> { 08:38 < bridge> // This function has to check if subtract expression has valid operands 08:38 < bridge> // Rules: 08:38 < bridge> // `foo - 69` check if type of 69 is not bigger than type of foo 08:38 < bridge> // `69 - foo` check if type of 69 is not bigger than type of foo 08:38 < bridge> // `foo - bar` check if foo and bar of the same type 08:39 < bridge> // `ptr - offset` variable offset has to be either variable of type usize or immediate 08:39 < bridge> 08:39 < bridge> let left_type = lhs.type_(scope)?; 08:39 < bridge> let right_type = rhs.type_(scope)?; 08:39 < bridge> 08:39 < bridge> if left_type.ptr() { 08:39 < bridge> if !Expr::int_lit_only(rhs) { 08:39 < bridge> assert_eq!(right_type, Type::UInt(UintType::Usize)); 08:39 < bridge> } 08:39 < bridge> } 08:39 < bridge> 08:39 < bridge> if left_type.int() && right_type.int() { 08:39 < bridge> match (Expr::int_lit_only(lhs), Expr::int_lit_only(rhs)) { 08:39 < bridge> (true, false) => { 08:39 < bridge> assert!(Type::common_type(left_type, right_type.clone()) < right_type); 08:39 < bridge> } 08:39 < bridge> (false, true) => { 08:39 < bridge> assert!(Type::common_type(left_type.clone(), right_type) < left_type); 08:39 < bridge> } 08:39 < bridge> (false, false) => assert_eq!(left_type, right_type), 08:39 < bridge> (true, true) => (), 08:39 < bridge> }; 08:39 < bridge> } 08:43 < bridge> mornin 08:55 < bridge> hi developa 08:56 < bridge> hi 08:58 < bridge> Hi 10:06 < bridge> why does rust implement `std::ops::Shl`/`std::ops::Shr` for all possible integer types but not for addition / subtraction etc.? 10:07 < bridge> why does rust implement `std::ops::Shl`/`std::ops::Shr` for all possible integer type combinations but not for addition / subtraction etc.? 10:44 < bridge> maybe because the inputs to `<<` and `>>` are treated differently 10:45 < bridge> how would you even define "correct"? 10:51 < bridge> "correct" would be a model that if simulated results in the exact same behaviour as real life in every case. But there is no way to know if smth is "correct" except observing things. I'm just ranting that people just accept the current models as correct. 10:53 < bridge> in practice, all of the models I use are incorrect then, I think 10:54 < bridge> but I find them much more useful than their more correct counterparts, because I can actually compute stuff with them and make useful predictions 10:57 < bridge> ddnet physics are better than RL physics 10:57 < bridge> no falldmg is just a selling argument 12:53 < bridge> The other guy has to play by the release cycle rules. You don't blindside the maintainer with critical patches in rc... 13:02 < bridge> What is the sense of rc then? 13:03 < bridge> Rcs are release candidates, they are for minor touchups if needed, not critical patches that have been held for 2 weeks because mr man didn't feel like putting it up before the rc 13:04 < bridge> And now? 13:04 < bridge> How can you tell the patches were ready 2 weeks ago? 13:05 < bridge> He said they were ready 2 weeks ago 13:05 < bridge> And how did Linus not notice it when he prepared the rc? 13:06 < bridge> Because he didn't say it 2 weeks ago. He said in that mail chain when submitting the patches 13:07 < bridge> When accused of pushing untested commits into an rc the night before it's release, he said he had been testing the changes in his tree for 2 weeks now 13:07 < bridge> The kernel has a way of doing release cycles, you just have to play by the rules. It's non-negotiable, everyone else has no issue pushing their changes in time 13:08 < bridge> I dunno I read the dialog a bit and to me it sounds like both sides are at fault. But I am not so much in the material 13:08 < bridge> If you don't want to play by the rules, you can ship your thing as a kernel module 13:09 < bridge> The only context you need to know is that idk any other mainline project that is having this issue of not putting up their patches in time 13:10 < bridge> Mr Kent thinks his project needs special treatment 13:12 < bridge> Ok sure. But the question I have is, why did Linus then pull his tree at all. Did the other maintainer say he wants "this" for the RC? 13:12 < bridge> 13:12 < bridge> Like is there no communication or smth 13:12 < bridge> Sounds all so random lmao 13:13 < bridge> They should just switch to a proper git and do pull requests properly lmao 13:15 < bridge> Idk why Linus still let these patches in because last rc when Kent tried to pull the same shit he didn't let them in. 13:15 < bridge> 13:15 < bridge> My guess would be that these ones are actually critical unlike the last ones 13:16 < bridge> Also his jabs towards btrfs throughout his mails were a little disgusting ngl. I wouldn't tolerate that attitude 13:17 < bridge> tja, 2 egos hit each others xd 13:17 < bridge> @learath2 do u know where to find gcc docs on weakref attribute? 13:18 < bridge> ```C 13:18 < bridge> extern uint64_t* X; 13:18 < bridge> 13:18 < bridge> int main() 13:18 < bridge> { 13:18 < bridge> X = ...; 13:18 < bridge> return 0; 13:18 < bridge> } 13:18 < bridge> ``` 13:18 < bridge> 13:18 < bridge> if i have a static lib .a that defines a global like this, and define in a C file this global with extern, it will modify it right? 13:18 < bridge> I only know this https://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/Function-Attributes.html 13:18 < bridge> xd 13:18 < bridge> Idk if there is anything more detailed about weakref specifically 13:18 < bridge> @learath2 have you ever contributed to a project that uses mailing lists btw? 13:19 < bridge> Not yet, I always wanted to get something into the kernel but never found what to do 13:20 < bridge> Yes, if I understood you correctly 13:20 < bridge> I see. I always wonder if these older than oldschool projects are unattractive for young ppl 13:21 < bridge> if the global is a pointer the extern should be a double ptr? 13:21 < bridge> xd 13:21 < bridge> I once contributed to an SVN project, and it was really annoying how they did things xD 13:21 < bridge> The barrier to entry is just too high I guess. When contributing something to a git project on github it's a breeze 13:21 < bridge> No not like that 13:22 < bridge> ok 13:22 < bridge> Yeah but also depends on the project. 13:22 < bridge> 13:22 < bridge> I doubt I want to pr smth to rust upstream again. Overloaded maintainers with no idea what they want 13:23 < bridge> @gdin hi 13:23 < bridge> I guess maintaining is always a _annoying_ job xD 13:23 < bridge> You have to deal with so many different ppl of different skill sets & language 13:23 < bridge> You alive bro 13:35 < bridge> Sorry had to step away for a second. Think of it like the names directly aliasing eachother 13:35 < bridge> ye it worked 13:37 < bridge> Rust imo also has a governance issue. 13:37 < bridge> There are features and proposals that have been just waiting around for yeaaaars now 13:39 < bridge> Yep true. It's also a very divisive topic ig. 13:39 < bridge> 13:39 < bridge> Some ppl work a lot with rust, so any cool feature makes the life easier. And then there are ppl that want the language to stay clean and not too overpowered. 13:39 < bridge> 13:39 < bridge> Yeah dunno, where are my AI friends hhehehe 13:39 < bridge> It seems after a language gets to a certain level of adoption, things just grind to a halt because of all the politics and expectations involved 13:40 < bridge> Atleast rust has the mechanism of editions to let them break stuff 13:40 < bridge> But I feel likey they don't do that 13:40 < bridge> Like really breaking stuff 13:40 < bridge> Just like cpp would never do 13:41 < bridge> Yeah, it feels underused. Is a 6 year discussion worth not breaking stuff when we have a mechanism that explicitly allows us to get out of this stalemate? 13:41 < bridge> But I still find that interesting. It seems like almost all projects suffer from that, and in the end there is smth new that simply replaces it until it suffers the same fate 13:42 < bridge> I wonder if a scheduled edition break every 2 years would help with these projects. If breakage is inevitable maybe the maintainers would become less conservative 13:43 < bridge> Maybe the problem is also simply that maintainers are not replaced. 13:43 < bridge> 13:43 < bridge> To not sound unfair. ofc the old maintainers have much more experience and probably carry that a project stays stable. 13:43 < bridge> 13:43 < bridge> But I guess humans are simply not motivated over years to come 13:44 < bridge> This is also an issue yeah. Term limits for maintainers when? 13:44 < bridge> 😬 13:46 < bridge> I guess the issue is the caliber of individual required to be a maintainer of something like rust. You can't just pick any random programmer for the job. So maybe it's not even easy to replace them even if you wanted 13:46 < bridge> Yeah true 13:48 < bridge> <0xdeen> I think Rust suffers from being designed by committee, similar to C++. Languages like that end up adding a lot of features, which makes it extremely hard to become proficient in the language 13:51 < bridge> Hm, perhaps you do have a point. The standard libraries of both are huuuge and they have many tools available for the same job. What do you think is a viable alternative? A language designed by a BDFL? 13:52 < bridge> Useless English word of the day: `loquacious`, means `talkative` 13:53 < bridge> And what does talkative mean 13:53 < bridge> Well I translated it now, so you don't need to answer anymore xd 13:55 < bridge> <0xdeen> Strongly opinionated BDFL who doesn't approve most ideas (Python), or just a small team that develops the product without accepting any outside contributions (SQLite) 13:55 < bridge> <0xdeen> but there has to be a vision, and it's usually easier for a person to have that vision compared to an organization/committee 13:56 < bridge> <0xdeen> (DDNet also suffers from this, we just merge a lot of stuff) 13:56 < bridge> I have a vision about ddnet too 13:56 < bridge> Given I'm not a huge fan of either, I'm unsure whether I agree that's a good way to run a project. But given their success in the market it's hard to deny that their approach delivers a decent product 13:56 < bridge> <0xdeen> I wanted to fix something in SQLite and that's when I found out you can't contribute at all 😄 13:58 < bridge> We are faar too soft indeed, we should really stop accepting anything that hasn't gone through a discussion and pre-approved 13:59 < bridge> We just end up merging because someone put in the time to develop something, but that's not a great reason 14:00 < bridge> I think our problem is somewhere else. 14:00 < bridge> We mod to be mod friendly and have backward compatiblity and compatible to all versions of teeworlds and motivate people to contribute their ideas to ddnet and want to be stable xD 14:00 < bridge> I think our problem is somewhere else. 14:00 < bridge> We want to be mod friendly and have backward compatiblity and compatible to all versions of teeworlds and motivate people to contribute their ideas to ddnet and want to be stable xD 14:00 < bridge> Yeah and the solution is so obvious actually 14:02 < bridge> All this crud has to be chopped off. Plugin support, downloadable gamecore, separate backwards compatibility layer 14:02 < bridge> Well I defs have ideas to solve some of our problems, but defs not all xD 14:02 < bridge> E.g. I'd NEVER accept plugin support for ddnet 14:02 < bridge> Just as modloaders for minecraft don't upstream their stuff 14:02 < bridge> Russia and Turkey banned discord 14:03 < bridge> What I'd accept is to replace components in total (at once) where the interface is clear 14:03 < bridge> That is also what the idea of dd-pg is. You can replace ingame rendering and physics 14:03 < bridge> But you cannot load a plugin that only changes 1 line of code 14:03 < bridge> That is a thing I'm not a huge fan of. But I do understand why they do it. It's really hard to ensure outside contributions quality. People hate their code getting reviewed and get argumentative 14:03 < bridge> :c 14:04 < bridge> rust is relatively easy to contribute to IME 14:04 < bridge> Learath2, how are you here? VPN? xd 14:04 < bridge> well, it's good that not everything is accepted. I guess it needs more explicit rejections though 14:04 < bridge> Mh maybe u got a better experience then xD. 14:04 < bridge> 14:04 < bridge> I literally felt the burn out of rust maintainers 14:04 < bridge> You just don't want to make any API promises? Idk I think if we had an easy way for people to modify their clients and servers we wouldn't get so many complaints 14:05 < bridge> Yes, that is allowed, but not as plugin system. Well depends on the definition of plugin maybe 14:05 < bridge> 😄 yesterday I read something on reddit, people complaining about the rust stdlib being way too small 14:06 < bridge> Huh, what are they missing even lol 😄 14:06 < bridge> I wouldn't want to allow "small" lua scripts for example. 14:06 < bridge> 14:06 < bridge> I prefer it to see it like mc, there can be a mod loader that replaces the whole physics system and add their lua support 14:06 < bridge> That is the reason I chose WASM 14:07 < bridge> So less granular hooks 14:07 < bridge> Yeah exactly 14:07 < bridge> But the less granular your hooks the harder it is to make a mod/plugin 14:07 < bridge> I feel like upstream code with 14:07 < bridge> 14:07 < bridge> call_lua_this 14:07 < bridge> call_lua_that 14:07 < bridge> 14:07 < bridge> will just be a pain 14:07 < bridge> 14:07 < bridge> But that's my opinion 14:07 < bridge> Well the mod loader has to deal with it 14:08 < bridge> I think @gutzufusss made a nice lua client that shows how it could work 14:08 < bridge> Yes, but not upstream 14:08 < bridge> With C++ it's much harder, you can't really replace entire classes on the go like with Java 14:08 < bridge> btw, I actually didn't think that rust's stdlib is too large. what makes you feel that way? @learath2 14:09 < bridge> Yeah, so if you want it like java, compile your java runtime to wasm xDDD 14:11 < bridge> I feel every type has so many methods available. E.g. just check the doc page for Vec 14:12 < bridge> I feel like that isn't a problem 14:12 < bridge> at least that in particular: vec having many methods 14:13 < bridge> It isn't a problem per se, but it makes it harder to be proficient 14:13 < bridge> I have a v8 client aswell 14:13 < bridge> So javascript 14:14 < bridge> that could be merged with upstream 14:14 < bridge> and WASM so virtually any programming language 14:14 < bridge> Yeah but not wasm only 14:14 < bridge> E.g. in Python, List has like 6-7 methods. It's usually obvious how to use a List properly 14:15 < bridge> I assume this: 14:15 < bridge> https://github.com/AllTheHaxx/CDXX 14:15 < bridge> yes 14:15 < bridge> it just has console.print bound iirc 14:16 < bridge> How do you share memory with your v8 engine? 14:16 < bridge> 14:16 < bridge> Is it uploaded on fly for single functions? 14:16 < bridge> 14:16 < bridge> E.g. let's say you have a `OnClientJoin`, how would that look like? 14:16 < bridge> Once upon a time, I imagined a future where this worked in a layered way. Only level of abstraction "upstream" would be aware of would be a `CPluginManager` which would load a `.so` file and just call hooks in it, nothing more. Then one could implement a python or lua or whatever loader plugin 14:17 < bridge> you can just bind variables and callbacks as you said 14:17 < bridge> So the c++ object gets transformed into what? 😄 14:17 < bridge> I did not spend a lot of thought on how to approach that 14:17 < bridge> Oh ok 14:17 < bridge> javascript objects 14:17 < bridge> Is there any limitations? 14:17 < bridge> 14:18 < bridge> U have no raw pointers at least ig :d 14:18 < bridge> `extract_if`, `pop_if`, `into_flattened` are the methods that I didn't know from just their names. after looking at the methods, I feel like this is okay 14:18 < bridge> not really 14:18 < bridge> discord refuses to work at times 14:18 < bridge> I think it makes sense that rust has a lot more functions on a vector since it wants to have performant ways to manipulate it 14:19 < bridge> Additionally how is the performance if an object needs to be translated to js object every frame 14:20 < bridge> @jupeyy_keks do you share your host memory directly with wasm? 14:21 < bridge> @heinrich5991 I'd really like to see how you want to integrate lua in a sane matter and also deliver a good amount of customization. 14:21 < bridge> 14:21 < bridge> I mean it's not like I never thought about not doing the approach I do rn. 14:21 < bridge> 14:21 < bridge> But just bcs factario uses LUA, I don't think that this is generally a good approach. It depends on what your goal is ig^^ 14:21 < bridge> 14:21 < bridge> So I am seriously interested, also about how much complexity is added with such an approach 14:22 < bridge> I literally stopped it when I noticed that switching to a wasm runtime all the time is annoying and also not _that_ fast 14:22 < bridge> Ofc not, that's not even possible 😄 14:22 < bridge> I serialize and deserailize it 14:22 < bridge> That is also costly btw, but apparently not my bottleneck 14:23 < bridge> Since it happens on low rates currently 14:23 < bridge> It would be cool if you could expose parts of host memory directly 14:23 < bridge> wdym, directly? 14:23 < bridge> share a byte array with the VM, that the VM has bounds-checked access to? 14:23 < bridge> sounds doable 14:23 < bridge> Yes 14:24 < bridge> I want to support complex types tho 14:25 < bridge> factorio for example implements much of the game logic in lua, in a sense, the actual game is just a mod as well 14:25 < bridge> But complex types are only a composition of primitive types. As long as you can ensure the layout is the same, you could share data that way. Pointers are probably the biggest issue in there. Idk how one would keep that safe 14:25 < bridge> I'd probably go with a similar approach for ddnet 14:25 < bridge> Ah yeah, that is what I do with wasm too then, and can still support lua 14:25 < bridge> 14:25 < bridge> I just don't get why lua instead of wasm 14:26 < bridge> wasm is good if you want to have first-class support for C/C++/Rust 14:26 < bridge> 3 letter word is quicker to type than 4 letter word, it's obvious 14:26 < bridge> lua is good if you want first-class support for lua 14:26 < bridge> And the lua interpreter compiles to wasm, since it's in c 14:27 < bridge> and thus u have lua support 14:27 < bridge> without upstreaming it 14:27 < bridge> I would guess, but would be happy to be convinced otherwise, that the lua support is not going to be first class 14:27 < bridge> i.e. that you need a lot of tinkering to make it work — but I'd like for anyone with a text editor to be able to make a mod, that'd be amazing 14:27 < bridge> Actually I wonder if anyone wrote a lua to wasm compiler 14:27 < bridge> But why.. If you add lua support in your rust library or if you add lua support to your rust library that compiles to wasm 14:28 < bridge> where is the difference xD 14:28 < bridge> Yes but that is required anyway 14:28 < bridge> WASM is just an additional layer 14:28 < bridge> it's not a given that a lot of tinkering is required 14:28 < bridge> I could also say it differently. You don't even notice dd-pg has WASM 14:29 < bridge> Since the code is the same rust code 14:29 < bridge> while trying to cross-compile client on windows to .exe file, it just won't open for some reason... any ideas? 14:29 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1293550812034760776/image.png?ex=6707c892&is=67067712&hm=f67e306050de4cb71c2490dc47afa01373e88e438bac60fd0f0048066438f5ae& 14:29 < bridge> This is probably the most important thing. The ability to mod with just a text editor is great for so many games 14:29 < bridge> But I don't see how wasm isntead of lua stops that. Your lua stuff can be hot reloaded too in a wasm module 14:30 < bridge> it's literally like you code native minus some stuff like threading 14:30 < bridge> You are saying someone develops and maintains a wasm-lua-loader layer that handles this? 14:30 < bridge> Apparently there is an interest for that 14:30 < bridge> I mean someone has to maintain the lua part 14:30 < bridge> and that's what he ends up doing 14:30 < bridge> i've used a ddnet documentation for cross compile from -> https://github.com/ddnet/ddnet 14:30 < bridge> my russian isn't good enough, could you help me? 14:31 < bridge> he doesn't care about WASM 14:31 < bridge> he doesn't need to care about WASM 14:31 < bridge> impossible to launch this application in this pc 14:31 < bridge> impossible to launch this application on this pc 14:32 < bridge> do you know which CPU architecture the binary is for and which CPU architecture your computer has? there's probably some way to find out what the actual error in launching was, too… 14:33 < bridge> and that's where I think a standardized language might be superior, be it lua or javascript 14:33 < bridge> But that makes no sense xD 14:33 < bridge> It's the same for whoever maintains that project 14:33 < bridge> ok 14:33 < bridge> let's do it differently 14:34 < bridge> let's say i load a .so file 14:34 < bridge> 14:34 < bridge> and the .so file has all lua stuff 14:34 < bridge> is it 14:34 < bridge> 1. harder for that person 14:34 < bridge> 2. just the same as if there is no .so file 14:34 < bridge> it'd mean there aren't mutually incompatible mod source bases. also if you start depending on ddnet-pg-lua, then you might be worried if that is maintained forever. but if the lua binding is *THE* official modding API, then you think that it'll probably stay around 14:35 < bridge> But that would mean that ddnet maintainers have to maintain it, even if they dislike it. 14:35 < bridge> 14:35 < bridge> While a cleanly separated project would be maintained by ppl that actually like lua 14:36 < bridge> yes. it'd also mean that it'll probably stay maintained, and that people can rely on it 14:36 < bridge> And even if we'd accept first class lua support, we could still allow wasm on top, so someone can opt-out of the lua stuff 14:36 < bridge> bcs the wasm stuff is simply not dominating the source code 14:36 < bridge> it's a wasm manager, and some macros 14:37 < bridge> that's it, the rest is normal dd-pg code 14:37 < bridge> I'm not super focused on lua tbh btw 14:37 < bridge> not my pc tho, so i can't, well i mostly sure its exactly cmake problem, cause i'm getting this somehow 14:37 < bridge> 14:37 < bridge> cmake options `-DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/mingw64.toolchain` 14:37 < bridge> and i just relize it compiling as shell fine xd 14:37 < bridge> https://cdn.discordapp.com/attachments/293493549758939136/1293553005169344573/image.png?ex=6707ca9d&is=6706791d&hm=f451a34bac88dfda5bf6116655d154293fc824fdd9b1cdb2ed4cd12559ed94e8& 14:38 < bridge> just something that can be edited without installing further programs 14:38 < bridge> Im not gonna code gamemodes in lua please spare me 14:38 < bridge> Yes, I am just interested in the arguments for lua or js. 14:38 < bridge> 14:38 < bridge> I am all for mod support, I guess I kinda hope to demotivate ppl from upstreaming every change they have to make _their_ mods easier to use 14:39 < bridge> If it makes ddnet code more readable. fine 14:39 < bridge> 14:39 < bridge> If it adds some weird hacks so they can add some extra parameter to some function.. I dunno 😄 14:40 < bridge> Are you just loading and running a massive wasm blob? 14:40 < bridge> Yes 14:40 < bridge> Well depends on massive 14:40 < bridge> physics are really small 14:40 < bridge> but rendering is quite a bit bigger yeah 14:41 < bridge> rendering is a different problem anyway.. much harder to sandbox etc. 14:41 < bridge> I think this is not very modding friendly. To make a mod now you need to rewrite or copy the entire wasm code you have. 14:41 < bridge> 14:41 < bridge> I think granular hooks are a better way to make userfriendly modding possible 14:41 < bridge> I'd already be happy to some day have really good physics modding support 14:42 < bridge> No wasm code is copied tho. It's the rust code that is copied 14:42 < bridge> > I think granular hooks are a better way to make userfriendly modding possible 14:42 < bridge> Again, this still works 14:42 < bridge> Whatever. They need to basically fork your copy and mod it, just the way mods are currently made 14:42 < bridge> You can fork the dd-pg physics, add your lua runtime 14:42 < bridge> 14:42 < bridge> compile to wasm 14:42 < bridge> and that's it 14:42 < bridge> But they don't need to upstream it 14:43 < bridge> Bcs the client will have the exact same support 14:43 < bridge> If ddnet wants ddnet physics to be lua friendly, so be it 14:43 < bridge> The value is in allowing the client to download a blob from the server. Not the way you pick your hooks 14:43 < bridge> That doesn't mean fng has to be 14:44 < bridge> Ok, and for client side prediction you then download lua scripts 14:44 < bridge> is that better? 14:44 < bridge> Or is 1MB blob too much traffic 14:46 < bridge> Yes, that's what I would experiment with. I'm not saying your way is wrong. I'm saying it's better UX for the mainline to have easy moddability 14:46 < bridge> Ok twgame is currently 2.9 after 14:46 < bridge> wasm-strip 14:46 < bridge> and 14:46 < bridge> wasm-opt 14:46 < bridge> calls to it 14:46 < bridge> 2.9MB 14:47 < bridge> Yes and i totally don't block that, we can have a repo: 14:47 < bridge> ddnet-physics 14:47 < bridge> 14:47 < bridge> and you can maintain it 😄 14:47 < bridge> I am not super interested in ddnet as physics anyway.. 14:47 < bridge> Enough to play gores if fine for me 14:48 < bridge> Kaffaine might need different things u _can_ support in ddnet modding anyway 14:48 < bridge> So he can do his infection-class however he wants, and ddnet as they want 14:48 < bridge> and chiller can add his epyc stuff as he wants 14:48 < bridge> This is the issue. I'm saying the MAINLINE needs to have good moddability UX. Not a fork, what if we go away and you break some api promise? Now all lua mods are broken 14:48 < bridge> and all are happy 14:48 < bridge> until someone wants to change the interface :lol: 14:49 < bridge> But what if MAINLINE has a bug in the API.. then it might also break everything 14:49 < bridge> Anyway, your project, your rules. Knock yourself out. I'm just telling you what I would experiment with 14:49 < bridge> I trust other devs as much as a trust myself 14:49 < bridge> NOT AT ALL 14:50 < bridge> And I am just saying that I feel like my idea is a superset of what you want and thus not blocking your idea 14:51 < bridge> It's not blocking technically, but it requires the modders to trust a second third party repo 14:51 < bridge> Now your mod is on shaky ground because it depends on 2 layers of api provided by distinct vendors 14:52 < bridge> but in minecraft it kinda works too, bcs the modding community simply decided that they get what they need. 14:52 < bridge> 14:52 < bridge> So mojang can still do whatever the shit they want. And they even break the game very often. Smth ddnet will probs not do (as much at least) 14:52 < bridge> Again, I do not care particularly what you do. It's your business. I'm just letting you know my opinion on it 14:53 < bridge> Yes 14:53 < bridge> All fine 14:54 < bridge> In this case there is one vendor you can't interact with at all. So the stable middleman is the best you can do. It's better than nothing, but is it as good as a first party api, unlikely, you can see how often stuff breaks on updates 14:55 < bridge> Sure but I don't see how ddnet never breaks their API ever 14:55 < bridge> There is also a bit of a performance concern as you keep adding on layers, though I doubt it's bad enough to consider 14:55 < bridge> Do you want to first try a perfect API or what 14:56 < bridge> Sure, benchmarking is always important 14:56 < bridge> for example: 14:56 < bridge> The rendering module is defs slower than the physics module, bcs it interacts much more with the client 14:57 < bridge> (Or with outside apis, fs, graphics etc.)( 14:57 < bridge> (Or with outside apis, fs, graphics etc.) 14:58 < bridge> No, but you can version an api, you can be considerate with how you make changes. With Microsoft and Minecraft you get 0 promises. 14:58 < bridge> 14:58 < bridge> With dd-pg and dd-pg-lua you have already implied that you don't care much about a lua layer on top. How much would you care about that layers stability? Is it better than Microsoft, sure. Is it better than you personally being responsible for it's stability, unlikely 14:59 < bridge> I'm just not a huge fan of third party middleware 15:00 < bridge> I personally would not maintain the lua api anyway, so it's more about other ddnet maintainers anyway. 15:00 < bridge> 15:00 < bridge> So why should it even be my problem, I don't directly understand 😄 15:00 < bridge> Like if you think it has to be stable, you can invest as much time as you want 15:00 < bridge> Totally fine by me 15:00 < bridge> Your project defines the stability of the LUA API 15:00 < bridge> not dd-pg 15:01 < bridge> Exactly, you don't care, you break an api promise, dd-pg-lua can no longer provide a lua api they used to provide, now mods broke 15:01 < bridge> Well why was the API break needed? How did lua prevent this from breaking 15:01 < bridge> I don't understand your point tbh 15:01 < bridge> The lua api can maybe workaround the API change 15:02 < bridge> E.g. say you decided to multithread the server, now I can no longer provide a sync teleport function because all entity teleports are async now 15:02 < bridge> If the mods are _only_ lua files then this is probably as easy as replacing a binary bob or not? 15:03 < bridge> Uff 15:03 < bridge> But that isn't an API break 15:03 < bridge> that is a new game xD 15:04 < bridge>