| Time |
Nick |
Message |
| 00:45 |
|
proller__ joined #minetest-dev |
| 00:53 |
|
paramat joined #minetest-dev |
| 01:07 |
|
Tmanyo joined #minetest-dev |
| 01:41 |
|
Foz joined #minetest-dev |
| 02:01 |
|
indiana joined #minetest-dev |
| 02:38 |
|
AndroBuilder joined #minetest-dev |
| 02:56 |
|
indiana joined #minetest-dev |
| 05:25 |
|
Fritigern joined #minetest-dev |
| 06:04 |
nerzhul |
too many labels make labels usage too complicated |
| 06:13 |
|
longerstaff13-m joined #minetest-dev |
| 07:49 |
|
oiaohm joined #minetest-dev |
| 07:53 |
oiaohm |
I have been looking a bit the source code of both minetest and minetest_game. Has the project ever looked at using like .ini file for storage craft-able and so on in the mods to avoid as much Lua code and to improve start-up speed. So like a init.ini next to the init.lua with the ini containing all the stuff that can be just straight up declared. |
| 07:53 |
sfan5 |
that's much additional complexity for little gain |
| 07:55 |
oiaohm |
sfan5: reading the lua code to work what a mod create is what you call exactly non complex either. |
| 07:55 |
sfan5 |
for external programs, maybe |
| 07:56 |
sfan5 |
but Minetest needs to run Lua anyway, so why add some custom data format to "bypass" the lua vm? |
| 08:00 |
oiaohm |
Lua not always what you can speed or memory friendly. You have to remember LuaJit does does cache stuff in memory. So a lot of init stuff is consuming memory that could freed very quickly. Read file process file close file in C++ can be very memory tidy Not as memory tidy when you go Lua or LuaJit. |
| 08:02 |
oiaohm |
Also it could remove a lot of conversions and Lua state handling that do also effect start up time. |
| 08:02 |
sfan5 |
>So a lot of init stuff is consuming memory that could freed very quickly. |
| 08:02 |
sfan5 |
isn't that the GC's job? |
| 08:03 |
sfan5 |
of course, reading a file from C++ is faster than letting Lua do some stuff |
| 08:03 |
sfan5 |
but I doubt that would make a significant difference in startup time |
| 08:06 |
|
Player-2 joined #minetest-dev |
| 08:12 |
oiaohm |
GC job is made lot more complex when you have jit in the mix caches. Because it can only be cleaned up with the JIT lets go. Just because you need VM/JIT todo something does not mean you should use it for everything. |
| 08:14 |
oiaohm |
From what you are saying sfan5 no one as really looked at if a ini or like file should be there. In past I worked on custom mud servers. yes we did just a different jit for bot automation. But the static items we took from ini files. It do improve server restart times a lot. |
| 08:28 |
|
Darcidride joined #minetest-dev |
| 08:31 |
|
Player-2 joined #minetest-dev |
| 09:02 |
|
Fixer joined #minetest-dev |
| 09:16 |
nerzhul |
oiaohm if you mean the node def i have a working branch with nodedefs in database, but it's not easy to distribute |
| 09:17 |
nerzhul |
also starting a server with many mods is due to the code size added in the init.lua, changing format will not help. Also it's fast to load generally |
| 09:29 |
oiaohm |
nerzhul: I was looking ini part for simple to distribute and being a one time read on load what does. The code size for processing what could be static data in some mods is quite high as well. So what I am talking about is part about reducing over all code size as well. |
| 09:29 |
oiaohm |
ok it will make core engine size larger but will allow the mods code to be smaller. |
| 09:40 |
|
Player-2 joined #minetest-dev |
| 10:15 |
|
Wuzzy joined #minetest-dev |
| 10:29 |
|
rubenwardy joined #minetest-dev |
| 10:48 |
|
Krock joined #minetest-dev |
| 10:52 |
|
proller__ joined #minetest-dev |
| 11:51 |
|
longerstaff13-m joined #minetest-dev |
| 12:21 |
|
proller__ joined #minetest-dev |
| 13:14 |
|
DI3HARD139 joined #minetest-dev |
| 14:00 |
|
Player-2 joined #minetest-dev |
| 14:03 |
|
crazyR joined #minetest-dev |
| 14:04 |
|
Taoki joined #minetest-dev |
| 14:39 |
|
proller__ joined #minetest-dev |
| 15:10 |
|
johnnyjoy joined #minetest-dev |
| 15:29 |
|
longerstaff13-m joined #minetest-dev |
| 15:35 |
|
rubenwardy joined #minetest-dev |
| 16:09 |
rubenwardy |
was it ever decided whether assignments in if-statements should be allowed? |
| 16:09 |
rubenwardy |
ala: https://github.com/minetest/minetest/pull/6786/files#diff-722710b5ecd9db42e7dd785dd517e186R1409 |
| 16:25 |
|
proller__ joined #minetest-dev |
| 16:30 |
|
Beton joined #minetest-dev |
| 16:31 |
sfan5 |
pretty sure nrz suggested using those |
| 16:32 |
rubenwardy |
tbh, it's not that bad there |
| 16:43 |
Krock |
we've used it in some places and IMO that's fine. while writing this message: "oh, that's actually my code" |
| 16:43 |
rubenwardy |
ok, it's fine there |
| 16:45 |
|
Darcidride_ joined #minetest-dev |
| 16:57 |
rubenwardy |
Krock: please may you use the review feature properly? |
| 16:58 |
rubenwardy |
ie: start a review |
| 16:58 |
rubenwardy |
then submit when you're happy you've made all the comments you need to |
| 16:58 |
rubenwardy |
otherwise I get spammed with notifications |
| 16:59 |
Krock |
either that or check less frequently. Will however make use of the review-comment feature in the future |
| 17:00 |
Krock |
however, I can't reduce the notification flood when commenting on comments. I hope that's acceptable |
| 17:36 |
|
longerstaff13-m joined #minetest-dev |
| 18:21 |
|
longerstaff13-m joined #minetest-dev |
| 18:36 |
|
Raven262 joined #minetest-dev |
| 19:47 |
|
Gael-de-Sailly joined #minetest-dev |
| 19:50 |
|
proller__ joined #minetest-dev |
| 19:52 |
|
Cornelia joined #minetest-dev |
| 19:53 |
|
Raven262 joined #minetest-dev |
| 20:18 |
|
Vadtec joined #minetest-dev |
| 20:43 |
|
rubenwardy joined #minetest-dev |
| 20:44 |
Krock |
will merge #7126 in 10 minutes |
| 20:44 |
ShadowBot |
https://github.com/minetest/minetest/issues/7126 -- Android: Replace movement buttons with joystick by srifqi |
| 20:45 |
nerzhul |
Krock, very nice |
| 20:45 |
|
longerstaff13-m joined #minetest-dev |
| 20:46 |
nerzhul |
sfan5: right, sometimes i suggest that :) i like to use it when it's readable :p |
| 20:54 |
Krock |
merging.. |
| 20:56 |
|
Andrej1 joined #minetest-dev |
| 21:25 |
|
paramat joined #minetest-dev |
| 21:45 |
paramat |
rubenwardy and all, after how many years shall we close a feature request that has no core dev interest? how about 2? |
| 21:45 |
|
proller joined #minetest-dev |
| 22:16 |
nerzhul |
don't forget sometimes we just loose them due to some visiblity problems :) |
| 22:16 |
|
oiaohm joined #minetest-dev |
| 22:27 |
Fixer |
feature requests can't be closed unless they are invalid |
| 22:27 |
rubenwardy |
I think they should only be closed if there's low interest (no more than say 2 reactions) and no dev interest too |
| 22:28 |
rubenwardy |
or obviously if they're outright rejected as per usual |
| 22:34 |
paramat |
hmm any idea gets non-core-dev support, this would mean an ever-growing number of feature requests with no core dev interest :] |
| 22:34 |
paramat |
i feel that if there is no core-dev interest for 2-3 years it can be closed, after a bump for reconsideration |
| 22:35 |
rubenwardy |
just because none comment doesn't mean they're not interested |
| 22:35 |
paramat |
true |
| 22:35 |
rubenwardy |
for example, it could just be straight forward in design or they could have larger priorities |
| 22:37 |
paramat |
that's why it should be bumped for consideration, in case core devs missed it |
| 22:37 |
Fixer |
btw, we don't have cart collisions, do you think it is legitimate goal to have? |
| 22:38 |
Fixer |
not just carts, but boats |
| 22:38 |
Fixer |
entities |
| 22:38 |
paramat |
i think a feature request needs a core dev to say (within 2-3 years): it's worth keeping this open |
| 22:38 |
rubenwardy |
sure |
| 22:39 |
rubenwardy |
maybe have concept approval then |
| 22:39 |
rubenwardy |
idk |
| 22:39 |
rubenwardy |
not the same |
| 22:40 |
paramat |
otherwse we have feature requests that no core dev supports hanging around forever, the current problem |
| 22:40 |
rubenwardy |
yeah, there's some obviously meh stuff |
| 22:41 |
paramat |
i think entity collisions are an option actually |
| 22:41 |
paramat |
but reduce performance |
