| Time |
Nick |
Message |
| 00:21 |
|
specing_ joined #minetest-dev |
| 01:01 |
|
specing joined #minetest-dev |
| 02:12 |
|
YuGiOhJCJ joined #minetest-dev |
| 02:41 |
|
Kimapr joined #minetest-dev |
| 04:11 |
|
Evergreen joined #minetest-dev |
| 05:04 |
|
luk3yx joined #minetest-dev |
| 05:54 |
|
Extex joined #minetest-dev |
| 05:56 |
|
olliy joined #minetest-dev |
| 07:34 |
|
Kimapr joined #minetest-dev |
| 08:12 |
|
Kimapr joined #minetest-dev |
| 09:18 |
|
Fixer joined #minetest-dev |
| 09:22 |
|
ForgeBot joined #minetest-dev |
| 09:22 |
ForgeBot |
<Ad> aymanbouraaman: g |
| 09:23 |
ForgeBot |
<Ad> aymanbouraaman: gg |
| 09:23 |
ForgeBot |
<Ad> aymanbouraaman: re |
| 09:23 |
ForgeBot |
<Ad> aymanbouraaman: ez |
| 09:23 |
|
ForgeBot was kicked by sfan5: ForgeBot |
| 09:27 |
|
entuland joined #minetest-dev |
| 09:46 |
|
luk3yx` joined #minetest-dev |
| 09:49 |
|
Krock joined #minetest-dev |
| 10:08 |
|
asdflkj_sh joined #minetest-dev |
| 10:16 |
|
calcul0n joined #minetest-dev |
| 10:18 |
|
calcul0n joined #minetest-dev |
| 10:20 |
|
calcul0n joined #minetest-dev |
| 10:34 |
|
longerstaff13 joined #minetest-dev |
| 10:54 |
|
Fixer joined #minetest-dev |
| 10:54 |
|
calcul0n_ joined #minetest-dev |
| 11:01 |
|
hecks joined #minetest-dev |
| 11:07 |
|
Fixer_ joined #minetest-dev |
| 11:14 |
|
Fixer joined #minetest-dev |
| 11:17 |
|
Fixer_ joined #minetest-dev |
| 11:35 |
|
Fixer joined #minetest-dev |
| 11:54 |
|
Fixer_ joined #minetest-dev |
| 12:05 |
|
entuland joined #minetest-dev |
| 12:11 |
|
Fixer joined #minetest-dev |
| 12:20 |
|
specing_ joined #minetest-dev |
| 12:25 |
|
Fixer joined #minetest-dev |
| 15:38 |
|
Extex joined #minetest-dev |
| 16:26 |
|
Alias joined #minetest-dev |
| 16:48 |
Krock |
will merge #11435 and #11519 in 10 minutes |
| 16:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/11435 -- Gettext support on Android by Pevernow |
| 16:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/11519 -- Fix GUIEditBoxWithScrollBar using a smaller small-/largeStep than intlGUIEditBox by Desour |
| 16:57 |
Krock |
merging |
| 17:08 |
MTDiscord |
<luatic> How important do you consider an iterative serialization? That would be able to handle nested objects beyond the stack limit (16k on Lua 5.1, 65k on LuaJIT) |
| 17:10 |
hecks |
explain this serialization problem to me, why is it limited to 64k? |
| 17:11 |
Krock |
local variable limit |
| 17:11 |
hecks |
wait wait, that's not the limits I ran into |
| 17:11 |
hecks |
are you talking about the uh |
| 17:11 |
hecks |
constant limit? |
| 17:11 |
hecks |
per chunk? |
| 17:17 |
hecks |
because that's a limit *per chunk* and can be worked around pretty easily |
| 17:18 |
hecks |
just consult the manual about what exactly a "chunk" is and you'll see what I mean |
| 17:19 |
|
queria joined #minetest-dev |
| 17:22 |
sfan5 |
well minetest.serialize doesn't do that, isn't that exactly the problem? |
| 17:23 |
hecks |
I'm just saying the solution is simple, guard nested tables with (function() return {} end)() |
| 18:04 |
|
Extex joined #minetest-dev |
| 18:15 |
|
v-rob joined #minetest-dev |
| 18:39 |
|
v-rob joined #minetest-dev |
| 18:42 |
v-rob |
Excuse a poor ignorant person, but why is `GL.SomeFunction` better than normal `glSomeFunction` besides extension wrangling and forcing a core profile of functions? I'm just mostly curious. |
| 18:47 |
v-rob |
It seems to my limited knowledge that simply ignoring non-core functions would be fine since non-core is just a superset of core (I think). Of course, I'm probably missing something. |
| 20:01 |
v-rob |
Should static class functions be camelCase or snake_case? They're in a class, but aren't member functions. The code style guidelines aren't clear on them |
| 21:00 |
|
hecks_ joined #minetest-dev |
| 21:25 |
|
specing joined #minetest-dev |
| 21:59 |
hecks_ |
v-rob: 1. i don't want to conflict with an actual GL header someone might include by mistake |
| 22:00 |
hecks_ |
2. PascalCase without the gl prefix is actually how the GL specification lists them |
| 22:00 |
hecks_ |
3. exporting one symbol (the GL func table) is less messy than exporting a whole bunch of them |
| 22:02 |
hecks_ |
4. you cannot force a core profile before GL 3.3 and GLES2 compat requires core-like restrictions; I basically had to target a nonexistent GL profile with this to cover both desktop and mobile |
| 22:03 |
hecks_ |
and I won't be changing the case of the functions or the constants because this is what they are all named in the GL specification |
| 22:04 |
hecks_ |
the 'gl' and 'GL_' prefixes for procedures and constants respectively are practical namespacing considerations and are not part of the spec, thus it's "okay" to replace them with an actual scoping mechanism provided by the language |
| 22:05 |
hecks_ |
and using a struct instead of a namespace provides further utility and simplicity: one DLL symbol, no ABI gremlins, easy to reset and reassign |
| 22:06 |
hecks_ |
on some platforms, GL procedure pointers are not valid between contexts and must be fetched again; if we ever needed multiple contexts then this is the cleanest solution, you can just swap out the struct itself as you switch the context |
| 22:12 |
|
Extex joined #minetest-dev |
| 22:12 |
hecks_ |
and lastly, the ABI for GL functions varies by platform; each has a different set of procedures that you fetch from a header and link to directly vs. the ones that you have to getProcAddress; my binding additionally simplifies this by funneling everything to function pointers and not caring what is fetched in which way (instead, proc address is chained with dlsym and header prototypes are not used at all) |
| 22:20 |
hecks_ |
if anyone brings this up again please point them to this log or something |
| 22:25 |
specing |
SpringRTS has gl.function, can you do the same? |
| 22:25 |
specing |
I saw v-rob mention GL> |
| 22:25 |
specing |
GL. |
| 23:34 |
|
AliasAlreadyTake joined #minetest-dev |
| 23:53 |
|
calcul0n_ joined #minetest-dev |
