| Time |
Nick |
Message |
| 00:16 |
ShadowNinja |
http://sprunge.us/MNYN?diff This loads player files only when they're needed, it cuts my server's memory usage in half (and should reduce CPU usage a bit). |
| 00:16 |
ShadowNinja |
(40MiB -> 20MiB) |
| 00:18 |
sapier |
saveAllPlayers really? even not active players? ;-) |
| 00:20 |
sapier |
if (newplayer) {<<< newline |
| 00:21 |
sapier |
that's true for a lot of other lines in there too |
| 00:21 |
LemonLake |
The only problem with allowing multiple contributors is code formatting |
| 00:21 |
LemonLake |
It makes the code look like a pile of spices poured on the floor by children |
| 00:21 |
sapier |
why don't you follow your own coding style rules? |
| 00:24 |
VanessaE |
ShadowNinja: nice |
| 00:24 |
sapier |
No it's not a problem if everyone sticks to the rules, as shadow was the one bugging me for months to follow the rules I wont let him add code following the rules too ... and don't even try to change the rules once you're affected shadow ;-P |
| 00:26 |
VanessaE |
sapier, ShadowNinja: to be fair, the engine's coding style guidelines aren't exactly written down anywhere... |
| 00:27 |
sapier |
they are ShadowNinja kept bugging me for months with those damn "put bracket to newline" ... ;-P |
| 00:27 |
VanessaE |
you know what I meant :P |
| 00:36 |
sapier |
wow ... I just managed to start my current development version on a 600 MHz single core device with 320x480 3,2" |
| 00:36 |
VanessaE |
O_o |
| 00:36 |
VanessaE |
did it actually *work*? |
| 00:37 |
sapier |
well <1 fps might be an issue |
| 00:40 |
sapier |
but I never did manage to see anything but blue screen on that device by now ;-) |
| 00:45 |
ShadowNinja |
sapier: No, There isn't supposed to be a newline before brackets. I've been telling you to remove those newlines! |
| 00:45 |
ShadowNinja |
I'll change it to saveLoadedPlayers. |
| 00:45 |
|
Piggybear87 joined #minetest-dev |
| 00:45 |
|
kaeza joined #minetest-dev |
| 00:46 |
sapier |
you've bugged me for month to add those newlines |
| 00:46 |
ShadowNinja |
sapier: You must have misunderstood me. |
| 00:46 |
sapier |
if you now change your mind I want you to write down the very exact guidelines on wiki because I'm really really annoyed about having to change the codings style twice a year |
| 00:47 |
sapier |
I don't like wasting hours of time to move around newlines |
| 00:48 |
ShadowNinja |
sapier: https://www.kernel.org/doc/Documentation/CodingStyle -- Chapter 3 |
| 00:49 |
ShadowNinja |
I haven't changed it, you just didn't understand what I was saying. |
| 00:49 |
ShadowNinja |
I suggest you read that document, and http://dev.minetest.net/Code_style_guidelines of course. |
| 00:49 |
sapier |
grrrrrrrrrrrr |
| 00:51 |
sapier |
delete that damn wiki page and define kernel coding style to be the only reference |
| 00:51 |
sapier |
>>Use your best judgement for C++-specific syntax.<< basicaly results in "demand what you want to annoy ppl |
| 01:03 |
sapier |
"Do not unnecessarily use braces where a single statement will do." lol apple guys must have read that sentence ... with known result |
| 01:28 |
hmmmm |
eh |
| 01:28 |
hmmmm |
what style to follow depends on which piece of code you're working on |
| 01:29 |
hmmmm |
if it's old stuff it's probably better to have it fit in with the rest of that weird "if() \n {" style |
| 01:29 |
sapier |
actually it seems to depend on the one checking it's mood |
| 01:29 |
hmmmm |
the "irrlicht style" I guess you can call it |
| 01:30 |
hmmmm |
the more consistent style on the other hand would be the K&R derivative |
| 01:30 |
sapier |
I'm just annoyed because of wasting so much time on changing code style back and forward for any single commit |
| 01:30 |
hmmmm |
you don't need to |
| 01:30 |
sapier |
unless I want to rebase them in about 2 years I obviously have to |
| 01:31 |
hmmmm |
we went over this 500 times.... ShadowNinja stop being such a pendant w.r.t. code style |
| 01:31 |
hmmmm |
grrr |
| 01:31 |
hmmmm |
I just don't think so much effort should be put into something so trivial |
| 01:31 |
hmmmm |
as long as it's understandable and consistent, that's good enough |
| 01:32 |
sapier |
I don't have a problem with him being pedantic as long as there's a way to decide how it's supposed to be |
| 01:32 |
hmmmm |
I'd prefer for things to match up though, and the majority of the code on the internet (aside from GNU) do something close to K&R |
| 01:32 |
hmmmm |
seems to do something close* |
| 01:33 |
hmmmm |
a lot of my own code isn't conformant either |
| 01:33 |
hmmmm |
i start function bodies with the bracket on the same line as the signature |
| 01:34 |
hmmmm |
but i'm not going to go around explicitly changing things unless it needs to be modified at some point |
| 01:38 |
sapier |
I try to change it around the lines I change ... but knowing how it's expected to be would be usefull |
| 01:39 |
hmmmm |
i'll agree the current "code style guidelines" is just a list of things that pissed me off |
| 01:39 |
hmmmm |
and it could be done much better |
| 01:39 |
hmmmm |
and more complete |
| 01:40 |
hmmmm |
but i'm not doing it because i have so many better things to do in life |
| 01:40 |
sapier |
imho for some things it causes more confusion then clarification |
| 01:40 |
hmmmm |
what, for example? |
| 01:40 |
sapier |
>>Use your best judgement for C++-specific syntax.<< |
| 01:40 |
hmmmm |
oh that |
| 01:41 |
hmmmm |
well we kinda standardized on some C++ specific syntax, right? |
| 01:41 |
hmmmm |
class scope identifiers aren't indented |
| 01:41 |
hmmmm |
for loops with very long iterator type declarations go on separate lines |
| 01:42 |
hmmmm |
err the type declaration goes on a different line* |
| 01:42 |
sapier |
yes that seems to match code (at least for those locations I checked) |
| 01:43 |
hmmmm |
do initializer lists the way they are everywhere else |
| 01:43 |
sapier |
meaning indention 1 |
| 01:43 |
hmmmm |
that is, like Foobar() : \n\tfoo(blah),\n\tbar(53),\n\tbaz("asdfg")\n{ |
| 01:44 |
sapier |
btw original code seems to have "public:" indented 1 level |
| 01:44 |
hmmmm |
hmmm |
| 01:44 |
hmmmm |
we don't want that though do we |
| 01:44 |
hmmmm |
because it's the same sort of lexeme as a goto statement and we certainly don't indent things after a goto |
| 01:44 |
hmmmm |
so I guess that's a change for the better |
| 01:45 |
sapier |
for me it's fine both ways |
| 01:45 |
hmmmm |
more indendation isn't necessarily better anyway |
| 01:45 |
hmmmm |
I used to double indent switch statements but it always seemed inconsistent and the linux kernel code doesn't do that either |
| 01:46 |
sapier |
old code did have { on same line as class guess that's why it had to be indented |
| 01:47 |
hmmmm |
well as we're discussing this, point out any guidelines you don't think are correct |
| 01:47 |
hmmmm |
class definition order is always public, protected, private |
| 01:47 |
hmmmm |
but visibility keywords aren't very often used to begin with |
| 01:48 |
hmmmm |
i always thought visibility restriction was just a way to annoy people when a certain abstraction turns out to be inefficient |
| 01:48 |
sapier |
"Don't use initializer lists unless absolutely necessary" I don't think thats a reasonable suggestion for c++ code |
| 01:48 |
hmmmm |
why not |
| 01:48 |
hmmmm |
the only real benefit they have is static initialization of subclasses |
| 01:49 |
sapier |
yes and compiler is able to check for order of initialization if you use them |
| 01:49 |
hmmmm |
order of initialization shouldn't be important though |
| 01:50 |
hmmmm |
if it is, don't you think it's something that should be done explicitly rather than implicitly? |
| 01:50 |
hmmmm |
that's a big problem I have with C++, is that implicit ways of doing things are preferred |
| 01:50 |
hmmmm |
hidden is bad |
| 01:51 |
sapier |
it's not hidden in a initializer list |
| 01:51 |
sapier |
it's just the way meant to be done in c++ |
| 01:51 |
sapier |
thus you're able to use all those mechanisms modern compilers and check tools provide to verify it's correct |
| 01:52 |
hmmmm |
static analyzers should be able to pick up on the same things though |
| 01:52 |
hmmmm |
if they are functionally identical |
| 01:53 |
sapier |
and the last thing g_ and m_ prefixes ... ok globals should be avoided anyway so it's not really relevant, but imho prefixing member variables with m_ makes code way more readable |
| 01:53 |
hmmmm |
by initializer lists being implicit, I mean it's not part of the function body saying "here these are the actions being performed upon execution" |
| 01:53 |
hmmmm |
yeah but |
| 01:53 |
hmmmm |
where do you draw the line |
| 01:54 |
sapier |
of course the one writing it knows which variables are members and which aren't, but if you just read code it's quite hard to see |
| 01:54 |
hmmmm |
like v3f, those members don't have m_ |
| 01:54 |
hmmmm |
structs are classes |
| 01:55 |
hmmmm |
i think it can be hard to tell when something stops becoming a data storage structure and rather a logical grouping of functions |
| 01:55 |
hmmmm |
which could lead to inconsistency |
| 01:55 |
sapier |
I usually use m_ notations for classes having a "longer" livetime |
| 01:56 |
sapier |
if a object is usually temporary only I don't need to know if it's a member or not |
| 01:56 |
hmmmm |
my justification for m_ not being necessary is that you're usually looking at code inside of a function body |
| 01:56 |
hmmmm |
if the function body doesn't contain any locals by that name, then it has to be a member |
| 01:56 |
hmmmm |
but the problem is |
| 01:56 |
hmmmm |
that only works if functions are managable in size |
| 01:56 |
sapier |
think about functions in game or guiFormspecMenu ... there are functions bigger then a single screen |
| 01:57 |
hmmmm |
minetest has way too many 2000 line functions going on |
| 01:57 |
hmmmm |
alright |
| 01:57 |
hmmmm |
so then that settles it, m_ should be used for members that have a longer lifetime...? |
| 01:57 |
sapier |
I just had this case where I didn't know if "imagesize" is a local variable or a member stored ;-) |
| 01:57 |
hmmmm |
doesn't your IDE show you where it's declared |
| 01:58 |
sapier |
of course ... go to declaration ... different file, completely out of scope ;-) |
| 01:59 |
sapier |
it's not about that information not beeing present, but just not being obvious |
| 01:59 |
hmmmm |
yea |
| 01:59 |
hmmmm |
I guess what I don't like about it is that what would that mean the mapgen code would look like |
| 01:59 |
hmmmm |
all weird |
| 01:59 |
hmmmm |
:/ |
| 02:00 |
hmmmm |
prefixing m_ to all the noise buffers |
| 02:00 |
sapier |
maybe something like use m_ for complex persistend classes and without m_ for small usually temporary classes/structs |
| 02:00 |
hmmmm |
you know, about noise buffers |
| 02:01 |
sapier |
no where to look for them? |
| 02:01 |
hmmmm |
I have been wondering if preallocating and keeping these huge chunks of memory alive forever is a good idea |
| 02:01 |
hmmmm |
maybe it's cheaper to keep allocating things every time i want to use them instead of trashing the cache |
| 02:01 |
sapier |
maybe we should just remove that g_ m_ suggestion and don't suggest anything at all ;-) |
| 02:01 |
hmmmm |
yeah that's a good idea |
| 02:01 |
hmmmm |
let's remove that suggestion |
| 02:02 |
hmmmm |
so initializer lists, I don't like them because they're too C++y |
| 02:02 |
hmmmm |
so *I* discourage them |
| 02:03 |
hmmmm |
but there are reasons to use them |
| 02:03 |
sapier |
as we already have the rule to follow the existing conventions anyone adding a new parameter to a m_ class should add m_ members too while adding to non m_ classes should be done without m_ too |
| 02:03 |
hmmmm |
can't you argue the same for using enums instead of #defines though |
| 02:03 |
hmmmm |
yeah agreed with that |
| 02:03 |
sapier |
well I usually use enums instead of defines |
| 02:03 |
hmmmm |
that's the rule above all |
| 02:04 |
hmmmm |
be consistent |
| 02:04 |
sapier |
because enums provide type checking while defines don't |
| 02:04 |
hmmmm |
I don't like enums instead of defines because now it's "type safe" and passing the values around in a generic int type cause type punning warnings |
| 02:05 |
sapier |
that type checking is about avoiding mistakes ;-) of course if you're very carefull you don't need it ... but I am not carefull enough to rely on this for myself |
| 02:06 |
hmmmm |
yea, I can see the theoretical benefits of very strong typing but at the same time it turns out to be more of a nuisance in practice |
| 02:07 |
sapier |
yes if rules are checked you have to follow the rules that's the result |
| 02:07 |
hmmmm |
how could you possibly screw up so bad that you'll store an unrelated constant in some variable |
| 02:07 |
sapier |
but I don't think we need a rule for enums |
| 02:07 |
hmmmm |
i can't acutally come up with a single case where that's helped |
| 02:07 |
sapier |
there are good reasons for both |
| 02:08 |
sapier |
switch case checking |
| 02:08 |
hmmmm |
this is something like the yoda comparisons |
| 02:08 |
ShadowNinja |
hmmmm: I disagree with the struct double-indenting. You've changed your mind too? |
| 02:08 |
sapier |
if you provide a enum and do a switch case compiler will tell you about missing cases |
| 02:08 |
hmmmm |
if (5 == bar) { <--- theoretically beneficial, but strange and never actually helped anybody in real life |
| 02:08 |
hmmmm |
ShadowNinja, I don't like double indenting structs now because it takes up too much space |
| 02:09 |
hmmmm |
linux kernel style has it right |
| 02:09 |
hmmmm |
me double indenting structs is just an old habit of mine |
| 02:09 |
hmmmm |
sapier: yeah, which is annoying ;) |
| 02:09 |
hmmmm |
a lot of times you don't want to handle all of the cases |
| 02:10 |
sapier |
sometimes it's helpfull too |
| 02:10 |
sapier |
especially for switch cases where default is something like assert ;-) |
| 02:11 |
ShadowNinja |
Enums are good, not only because of type checking but because they contain a logical choice of values. And they auto-increment. |
| 02:11 |
sapier |
I think we shouldn't add a rule about enums to coding style rules |
| 02:11 |
hmmmm |
you can logically group together numerical constants without enums |
| 02:12 |
hmmmm |
the only benefit they have is the typing and that can be annoying |
| 02:12 |
hmmmm |
along with the compiler warnings |
| 02:12 |
hmmmm |
it's all about avoiding annoyances where C++ thinks it's helping but it's not |
| 02:13 |
sapier |
that's your personal opinion hmmmm ;-) |
| 02:13 |
hmmmm |
C++ is overzealous with typing, i believe, to the point where it drives people insane |
| 02:13 |
sapier |
you know all those languages who thought they could live without explicite typing are about to add it recently? ;-) |
| 02:14 |
hmmmm |
that's way different |
| 02:14 |
hmmmm |
C typing I think is optimal |
| 02:14 |
hmmmm |
(i mean that level of type-safety, not the type system itself) |
| 02:15 |
sapier |
in c everyone used void* pointers to pass data ... that's not type-safety at all ;-) |
| 02:15 |
hmmmm |
you can't set a void pointer to a non-pointer value |
| 02:15 |
hmmmm |
aside from NULL |
| 02:15 |
hmmmm |
but whatever |
| 02:16 |
sapier |
but I haven't run into the enum/define issue by now so I don't think we need a rule ... :-) |
| 02:16 |
sapier |
actually you can't set a void pointer to function pointer too ... yet most time it works |
| 02:16 |
hmmmm |
people who use void * to pass data are asking for a problem because it would definitely cause a justified compiler warning and could potentially result in an overflow if it so happens that the type is greater than the maximum address type on that machine |
| 02:17 |
hmmmm |
doesn't POSIX say something about that |
| 02:17 |
hmmmm |
the C standard is that void * shall be large enough to store an address to any data type |
| 02:17 |
sapier |
don't know but within c standard function and data pointers are different data types |
| 02:18 |
hmmmm |
i believe, not certain though, that POSIX says function pointers can be stored in void pointers |
| 02:18 |
sapier |
possible |
| 02:18 |
hmmmm |
relying on posix I think is okay |
| 02:18 |
sapier |
I'd not be sure about that |
| 02:18 |
hmmmm |
it's very difficult to write posix-free code |
| 02:19 |
sapier |
e.g. for some 32/64 bit mixed mode architectures data and function pointers really have different size |
| 02:19 |
hmmmm |
especially when your code has to do semi-complex things |
| 02:19 |
hmmmm |
regardless |
| 02:19 |
hmmmm |
I don't know of a situation where anybody would mix and match function and data pointers |
| 02:20 |
sapier |
didn't linux add something like that last year? function pointers 32bit and data pointers 64bit? |
| 02:20 |
hmmmm |
i haven't heard of it |
| 02:20 |
hmmmm |
it's sure possible though.. |
| 02:23 |
sapier |
ew X32 ABI: 64-bit mode with 32-bit pointers |
| 02:23 |
sapier |
that one |
| 02:24 |
sapier |
hmm not exactly it's just using 64bit registers |
| 02:25 |
sapier |
but 32bit pointers for everything |
| 02:25 |
ShadowNinja |
Minetest data pointers for functions, but only because lua_pushlightuserdata takes a void* and LuaJIT_setmode(LUAJIT_MODE_WRAPCFUNC) uses it as a function. |
| 02:26 |
sapier |
yes it's not an issue |
| 02:26 |
sapier |
unless we default to luajit ;-) |
| 02:27 |
hmmmm |
it could be an issue of truncation if a function pointer happens to be bigger than a data pointer |
| 02:28 |
ShadowNinja |
Could a function pointer point to a completely different memory area that shares addresses with the regular memory area? |
| 02:29 |
hmmmm |
huh? all von neumann architectures do that |
| 02:30 |
sapier |
nx flag could cause issues ... but not sure about it as it's a pointer only and not the actual code |
| 02:33 |
sapier |
But something completely different, I intend to merge #1200, #1332, #1302 and #1304 soon so please check and add additional comments if there's something not already mentioned |
| 02:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/1200 -- Add support for exiting formspecs by doubleclicking outside by sapier |
| 02:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/1332 -- Small cleanup of hud add/remove code by sapier |
| 02:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1302 -- Add daemon support for linux like operating systems by sapier |
| 02:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1304 -- Fix inventory items blinking on item preloading by sapier |
| 02:34 |
sapier |
and now I need to get some sleep good night ;-) |
| 02:34 |
|
sapier left #minetest-dev |
| 03:21 |
|
kahrl_ joined #minetest-dev |
| 03:36 |
|
Exio4 joined #minetest-dev |
| 05:27 |
|
rsiska joined #minetest-dev |
| 05:44 |
|
Hunterz joined #minetest-dev |
| 05:53 |
|
OldCoder joined #minetest-dev |
| 06:29 |
|
darkrose joined #minetest-dev |
| 06:36 |
|
jin_xi joined #minetest-dev |
| 07:09 |
|
kaeza[PC] joined #minetest-dev |
| 08:12 |
|
emptty joined #minetest-dev |
| 08:34 |
|
restcoser joined #minetest-dev |
| 09:01 |
|
vifino joined #minetest-dev |
| 09:04 |
|
sapier joined #minetest-dev |
| 09:24 |
|
PilzAdam joined #minetest-dev |
| 09:51 |
|
smoke_fumus joined #minetest-dev |
| 10:03 |
|
rubenwardy joined #minetest-dev |
| 10:11 |
|
CraigyDavi joined #minetest-dev |
| 10:24 |
|
emptty joined #minetest-dev |
| 10:31 |
|
_rubenwardy_ joined #minetest-dev |
| 10:32 |
|
_rubenwardy_ joined #minetest-dev |
| 10:42 |
celeron55 |
what is this supposed to mean? "quand tu peut joué a minetest avec moi" |
| 10:42 |
celeron55 |
i guess it's something completely useless but i can't be sure because google translate can't make any sense out of it |
| 10:49 |
|
LemonLake joined #minetest-dev |
| 10:49 |
VanessaE |
joué I take as a UTF-8 encoding mismatch, looks like google is trying to translate it as "On what day can I meet you to play Minetest" |
| 10:50 |
VanessaE |
(strange question, either way) |
| 10:51 |
|
grrk-bzzt joined #minetest-dev |
| 10:53 |
VanessaE |
yeah, that should be Joué --> "When you can have minetest Played with me" |
| 11:12 |
|
grrk-bzzt joined #minetest-dev |
| 11:13 |
|
Exio4 joined #minetest-dev |
| 11:27 |
|
Jordach joined #minetest-dev |
| 11:35 |
|
NakedFury joined #minetest-dev |
| 11:49 |
|
Megaf joined #minetest-dev |
| 11:59 |
|
proller joined #minetest-dev |
| 12:01 |
|
ImQ009 joined #minetest-dev |
| 12:03 |
* Megaf |
should read teh backlog where sapier and hmmm are saying things about Linux Kernel |
| 12:14 |
|
rubenwardy joined #minetest-dev |
| 12:14 |
|
proller joined #minetest-dev |
| 12:46 |
|
diemartin joined #minetest-dev |
| 12:56 |
|
hmmmm joined #minetest-dev |
| 13:05 |
|
CraigyDavi joined #minetest-dev |
| 13:18 |
|
Garmine joined #minetest-dev |
| 13:49 |
|
ImQ009_ joined #minetest-dev |
| 13:52 |
|
grrk-bzzt joined #minetest-dev |
| 13:53 |
|
werwerwer_ joined #minetest-dev |
| 13:57 |
|
Zeitgeist_ joined #minetest-dev |
| 14:23 |
|
grrk-bzzt joined #minetest-dev |
| 14:30 |
|
LemonLake joined #minetest-dev |
| 14:39 |
|
ImQ009 joined #minetest-dev |
| 14:41 |
|
BrandonReese joined #minetest-dev |
| 15:05 |
|
ImQ009_ joined #minetest-dev |
| 15:09 |
|
EvergreenTree joined #minetest-dev |
| 15:17 |
|
Hunterz joined #minetest-dev |
| 15:21 |
|
vifino joined #minetest-dev |
| 15:34 |
|
Zeitgeist_ joined #minetest-dev |
| 15:54 |
|
zat joined #minetest-dev |
| 15:57 |
|
Hunterz joined #minetest-dev |
| 16:09 |
sapier |
#1343 extends fstk to be usable for in game menus too |
| 16:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/1343 -- Add support for using fstk for in game menus by sapier |
| 16:13 |
Megaf |
sapier; !! You messed up with the linking again!? |
| 16:13 |
Megaf |
http://paste.debian.net/102590/ |
| 16:13 |
|
us`0gb joined #minetest-dev |
| 16:13 |
sapier |
I didn't change linking |
| 16:14 |
sapier |
actually I haven't merged anything for a few days ;-) |
| 16:14 |
|
emptty joined #minetest-dev |
| 16:15 |
Megaf |
So who messed up that? |
| 16:16 |
Megaf |
$ git pull |
| 16:16 |
Megaf |
Already up-to-date. |
| 16:16 |
sapier |
those error message point at some sort of data corruption |
| 16:17 |
sapier |
e.g. broken temporary files (did you do a make clean yet?) |
| 16:17 |
|
zat joined #minetest-dev |
| 16:18 |
sapier |
broken ram or broken flash (I guess you're on a flash device as usual) are other possible reasons ... or just out of memory due to make -j X |
| 16:39 |
|
ImQ009 joined #minetest-dev |
| 16:45 |
|
zat joined #minetest-dev |
| 17:24 |
|
LemonLake joined #minetest-dev |
| 17:24 |
|
Calinou joined #minetest-dev |
| 17:26 |
|
LemonLake joined #minetest-dev |
| 17:26 |
|
diemartin joined #minetest-dev |
| 17:33 |
LemonLake |
hi every buddy |
| 17:34 |
LemonLake |
I posted #1345 if you wanna check it out |
| 17:34 |
ShadowBot |
https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags |
| 17:35 |
Calinou |
that's an issue, not a PR |
| 17:35 |
Calinou |
not many people will care ;) |
| 17:35 |
Calinou |
variables are other_player_name, not otherPlayerName |
| 17:36 |
LemonLake |
sfan5 told me to post it |
| 17:36 |
Calinou |
(convention in Lua and C++) |
| 17:36 |
sapier |
hmm could be quite a lot of changes for a feature that less important |
| 17:36 |
LemonLake |
it doesn't matter, it was just an example |
| 17:36 |
Calinou |
(for Minetest, especially) |
| 17:36 |
Calinou |
yeah |
| 17:36 |
LemonLake |
sapier, how would it be a lot of changes? |
| 17:36 |
Calinou |
I would like nametag hiding, so that you can also make the player skin transparent = invisible player (can be used by admins) |
| 17:36 |
LemonLake |
^ |
| 17:36 |
Calinou |
could also have “spectatorâ€Â feature: attach invisible player to another player |
| 17:37 |
Calinou |
so, I'm all for it |
| 17:37 |
LemonLake |
Cal, can you comment on that? |
| 17:37 |
LemonLake |
:D |
| 17:37 |
sapier |
nametags are shown on client thus server has to tell clients what to hide and what not |
| 17:37 |
LemonLake |
It does the same with hud though so I don't see it being the biggest deal |
| 17:37 |
sapier |
hud is active player only |
| 17:38 |
sapier |
while that flag would be bound to generic entities |
| 17:38 |
sapier |
almost generic entities |
| 17:38 |
Calinou |
commented |
| 17:38 |
Calinou |
(may not be very useful though) |
| 17:38 |
LemonLake |
thanks |
| 17:38 |
Calinou |
“Additionally, allow name tag colour changing (RGBA).†|
| 17:39 |
Calinou |
eg. per-privilege colouring of nametags |
| 17:39 |
LemonLake |
Actually, yeah |
| 17:39 |
sapier |
not sure how much of work would be necessary but feels like more than obviously visible |
| 17:39 |
LemonLake |
I like the sound of RGBA |
| 17:39 |
Calinou |
This could allow stuff like colouring name tags based on privileges, or darkening the name tags of dead players. |
| 17:39 |
LemonLake |
sapier, it shouldn't be too too much |
| 17:39 |
sapier |
ok I'm waiting for someone to implement it ;-) |
| 17:39 |
|
Hunterz joined #minetest-dev |
| 17:39 |
LemonLake |
:D |
| 17:41 |
BrandonReese |
I would be happy if player name tags didn't show through opaque objects |
| 17:41 |
LemonLake |
That would require a lot of calculation |
| 17:43 |
BrandonReese |
The name tag would probably have to be made an entity or something |
| 17:43 |
|
Piggybear87 joined #minetest-dev |
| 17:43 |
LemonLake |
eww |
| 17:43 |
sapier |
entities are only loaded within very short range around player |
| 17:44 |
LemonLake |
^ |
| 17:44 |
LemonLake |
Except players |
| 17:44 |
LemonLake |
they're always loaded |
| 17:47 |
|
RealBadAngel joined #minetest-dev |
| 17:47 |
RealBadAngel |
hi sapier |
| 17:47 |
LemonLake |
RealBadAngel: Opinion on #1345? |
| 17:47 |
RealBadAngel |
ive tried x86 build, and it is behaving a bit weird |
| 17:47 |
ShadowBot |
https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags |
| 17:48 |
RealBadAngel |
sapier, day/night cycle is broken, changes are almost instant and it flickers like hell |
| 17:49 |
Calinou |
BrandonReese, by default, they should, else it makes collaboration a pain ;) |
| 17:50 |
RealBadAngel |
LemonLake, could be useful for specific games, yes |
| 17:50 |
RealBadAngel |
and i agree with Calinou on additions |
| 17:50 |
BrandonReese |
It should be an option like unlimited transfer distance |
| 17:51 |
LemonLake |
RealBadAngel: Would you know anyone who would actually add it? |
| 17:51 |
RealBadAngel |
sapier, and it happens in both singleplayer and on server (like Vanessa's) |
| 17:52 |
RealBadAngel |
LemonLake, propably most of us (devs). question is who's table is empty atm ;) |
| 17:53 |
LemonLake |
If you could pass it on to some other devs (because it's an issue so most people wouldn't see it) I would be so grateful |
| 17:53 |
RealBadAngel |
i do have several ongoin projects, so i wont start again for sure |
| 17:54 |
BrandonReese |
LemonLake if player_unlimited_transfer_distance is false, players also disapear like other entities base don active_object_send_range_blocks |
| 17:54 |
LemonLake |
So either a nametag RGBA thing, settable for different players like I said (only certian players can see it for e.g.) |
| 17:54 |
LemonLake |
I know, BrandonReese |
| 17:54 |
LemonLake |
That's why I don't use it |
| 17:54 |
RealBadAngel |
hell, this reminds me one thing |
| 17:54 |
RealBadAngel |
such a change will need lotsa settings |
| 17:54 |
RealBadAngel |
tables with visibility from one to another |
| 17:55 |
LemonLake |
True# |
| 17:55 |
RealBadAngel |
which means: WE DO NEED LUA API FOR STORING MODS DATA! |
| 17:55 |
LemonLake |
^^^ |
| 17:55 |
LemonLake |
Yes! |
| 17:55 |
LemonLake |
You should comment that on the post |
| 17:55 |
RealBadAngel |
basic things first |
| 17:59 |
sapier |
RealBadAngel: any idea what's reason for it? |
| 18:05 |
|
werwerwer joined #minetest-dev |
| 18:09 |
RealBadAngel |
sapier, not yet |
| 18:10 |
RealBadAngel |
i was just testing it before i left to work, no diggin in the code at all |
| 18:10 |
RealBadAngel |
also another problem |
| 18:11 |
RealBadAngel |
"theres same application already installled but with another sign" |
| 18:11 |
RealBadAngel |
or something like that |
| 18:11 |
sapier |
yes debug/release |
| 18:11 |
sapier |
just uninstall the old version |
| 18:11 |
RealBadAngel |
thats the point |
| 18:11 |
RealBadAngel |
one should be able to update just |
| 18:12 |
sapier |
you will be able to update once it's signed with a real key |
| 18:12 |
RealBadAngel |
ah ok |
| 18:13 |
sapier |
well it's a real key right now too but debug/release versions are signed with different keys by definition |
| 18:13 |
RealBadAngel |
last version i tried wasnt flashing |
| 18:14 |
sapier |
"flashing" as of ? |
| 18:14 |
RealBadAngel |
in this sun/moon is is changing in like 1s cycle |
| 18:14 |
RealBadAngel |
so lighting goes nuts |
| 18:14 |
sapier |
isn't there some ancient bug telling a similar thing? |
| 18:14 |
sapier |
are we talking about master or android port right now? |
| 18:15 |
Megaf |
sapier: Linking CXX executable ../bin/minetestserver |
| 18:15 |
Megaf |
[100%] Built target minetestserver |
| 18:15 |
RealBadAngel |
i tried your x86 build, on android-x86 kitkat |
| 18:15 |
Megaf |
real 76m31.243s |
| 18:15 |
Megaf |
worked now |
| 18:15 |
sapier |
ah :-) wow it did start? |
| 18:15 |
LemonLake |
Megaf: Welcome to using a raspberry pi |
| 18:15 |
Megaf |
sorry? |
| 18:15 |
sapier |
more then an hour? wow :) |
| 18:16 |
sapier |
you're really patient megaf |
| 18:16 |
RealBadAngel |
or a masochist ;) |
| 18:16 |
|
emptty joined #minetest-dev |
| 18:17 |
sapier |
RealBadAngel: maybe we'll be able to find that ancient bug on android x86 instead of the original location ;-) |
| 18:17 |
Megaf |
sapier: nah, I just do a make, then I start cooking the lunch, then we eat lunch, then I bring my love to work, then I come home, then I go to work, then I work and then it's compiled! |
| 18:17 |
Megaf |
to her job* |
| 18:18 |
Megaf |
So I don't have to wait :P |
| 18:20 |
ShadowNinja |
sapier: You leak functions into the global environment in fstk. |
| 18:21 |
sapier |
you're not talking about the interface functions supposed to be global are you? ;-) |
| 18:21 |
ShadowNinja |
sapier: And it seems like fstk should be an implementation detail, at least until formspecs are redone. |
| 18:21 |
ShadowNinja |
sapier: They should be in core. |
| 18:22 |
sapier |
it's a library not core |
| 18:22 |
ShadowNinja |
Nothing other than generic utility functions that aren't specific to Minetest should be global. |
| 18:23 |
sapier |
a little bit late to notice |
| 18:25 |
ShadowNinja |
Little else is global. |
| 18:25 |
ShadowNinja |
Builtin did leak a bit last I checked though. |
| 18:25 |
LemonLake |
ShadowNinja, is your todo list busy? |
| 18:29 |
kaeza |
speaking of that, /me should rebase #1324 |
| 18:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/1324 -- Sort commands and privs alphabetically in `/help. by kaeza |
| 18:29 |
kaeza |
err... not that one |
| 18:29 |
|
Krock joined #minetest-dev |
| 18:29 |
kaeza |
this one https://github.com/minetest/minetest/pull/1341 |
| 18:30 |
ShadowNinja |
LemonLake: Yes. Why? |
| 18:30 |
LemonLake |
Dang |
| 18:30 |
LemonLake |
#1345 |
| 18:30 |
ShadowBot |
https://github.com/minetest/minetest/issues/1345 -- Lua feature to hide player nametags |
| 18:31 |
sapier |
no need to mention once an hour ;-P |
| 18:31 |
LemonLake |
Sorry, just trying to spread the word |
| 18:31 |
LemonLake |
Normally it'd be just ignored |
| 18:31 |
|
nore joined #minetest-dev |
| 18:33 |
RealBadAngel |
hi nore |
| 18:33 |
Krock |
sapier, is the ~15s long lag while saving the map a feature? |
| 18:33 |
nore |
hi |
| 18:33 |
Krock |
hi nore |
| 18:33 |
RealBadAngel |
nore, ive included mg in technic_game 2.0 |
| 18:33 |
RealBadAngel |
but.... |
| 18:33 |
sapier |
don't know but could be players instead of map Krock |
| 18:33 |
RealBadAngel |
where the fuck are moretrees? :) |
| 18:34 |
Krock |
sapier, well that lag only happens all 2-5 minutes, that's within the map save intrval |
| 18:34 |
RealBadAngel |
nore, also we do have to talk about microblocks |
| 18:34 |
sapier |
ok so not on shutdown |
| 18:35 |
RealBadAngel |
i want l-systems trees to use them |
| 18:35 |
Krock |
sapier, there it takes a while, too. |
| 18:35 |
sapier |
what os, hardware and database backend are you using? |
| 18:35 |
|
PenguinDad joined #minetest-dev |
| 18:35 |
Krock |
Windows Vista x64, dual core 1.4GHz CPU, leveldb |
| 18:35 |
sapier |
try sqlite backend |
| 18:36 |
Krock |
I don't want that level corruption again. so nope. |
| 18:36 |
Krock |
s/level/world |
| 18:37 |
sapier |
well leveldb keeps a lot of data in memory till it's necessary to be flushed by some time |
| 18:37 |
Krock |
sapier, so a higher save interval would solve that? |
| 18:37 |
sapier |
sqlite keeps data in sync permanently so it's most likely not affected |
| 18:37 |
sapier |
maybe |
| 18:37 |
ShadowNinja |
SQLite3 is pretty stable. |
| 18:38 |
Krock |
sapier, and I guess there's no work around which wouldn't cause a corruption? |
| 18:38 |
sapier |
wonder if you'd run better using sqlite if you reduce save interval for leveldb |
| 18:38 |
Krock |
example: new thread |
| 18:38 |
sapier |
no |
| 18:38 |
sapier |
I wonder why you expect map corruption for what I know sqlite is way more tested then leveldb |
| 18:39 |
Krock |
sapier, I posted examples of it multiple times. re-generation of chunks |
| 18:39 |
sapier |
I'd expect leveldb to cause more issues then sqlite |
| 18:40 |
Krock |
yes sure but it (almost) never will reach a file size limit |
| 18:41 |
sapier |
possible ... but if it's freezing each couple of minutes that's not helpfull too ;-) |
| 18:41 |
LemonLake |
How can I see the 7 char commit ID on github? |
| 18:41 |
Krock |
sapier, well then.. freeze is still better than need to backup every day for the case, it could corrupt somewhen |
| 18:42 |
sapier |
ok |
| 18:42 |
Krock |
sapier, lemme show you a build which haven't had such problems |
| 18:43 |
Krock |
*grabbs link* |
| 18:43 |
Krock |
https://forum.minetest.net/viewtopic.php?p=131204#p131204 |
| 18:43 |
RealBadAngel |
btw, which backend could be capable of storing blobs? |
| 18:44 |
RealBadAngel |
leveldb or sqlite? |
| 18:44 |
Krock |
sapier, also this one: https://forum.minetest.net/viewtopic.php?p=132682#p132682 |
| 18:44 |
sapier |
Krock didn't it have the issue or was the map smaller by that time? ;-) |
| 18:45 |
Krock |
sapier, can 50 MB cause such a difference? |
| 18:45 |
Krock |
*50 MB more/additional/whatever |
| 18:45 |
sapier |
sometimes but I don't know about the internals of leveldb |
| 18:47 |
sapier |
I don't know of any relevant changes within map backend the last months so we don't even have a hint where to look at |
| 18:48 |
Krock |
sapier, crazy idea: could it be possible to split the sqlite file into 10 or 20? |
| 18:48 |
Krock |
could it be faster? |
| 18:48 |
* Krock |
feels some <.< around |
| 18:48 |
sfan5 |
lolwat |
| 18:49 |
sfan5 |
there is no way 10 or 20 files will be faster than one |
| 18:49 |
sapier |
most likely not but you'd have to ask someone knowing minetests database backend better then me |
| 18:49 |
Krock |
sfan5, well, isn't it harder to search something within 100mb than in a 10mb file? |
| 18:50 |
sfan5 |
no |
| 18:52 |
Krock |
sfan5, that means, sqlite stores the "start reading at" positions at the beginning, so it gets easier than fetch every single row until found |
| 18:52 |
|
werwerwer joined #minetest-dev |
| 18:52 |
ShadowNinja |
RealBadAngel: Both of them are designed to store BLOBs. |
| 18:52 |
sfan5 |
fetch every single row until right row found would be very inefficent |
| 18:52 |
sfan5 |
I don't think sqlite3 does it like that |
| 18:53 |
sfan5 |
otherwise sqlite3 would be very very slow |
| 18:53 |
Krock |
sfan5, so it's better than I thought |
| 18:53 |
Calinou |
LemonLake, click on commit |
| 18:53 |
Calinou |
at the right |
| 18:53 |
Krock |
let's hope for a fast migrate and no lags.. |
| 18:54 |
Krock |
</ thread closed > |
| 18:55 |
LemonLake |
Sorry, calinou? |
| 18:56 |
LemonLake |
Where did my issue go?? ø.ø |
| 18:57 |
LemonLake |
Calinou, what commit? |
| 18:57 |
Calinou |
https://github.com/minetest/minetest/issues/1345 |
| 18:57 |
Calinou |
LemonLake, you asked <LemonLake> How can I see the 7 char commit ID on github? |
| 18:57 |
LemonLake |
I figured out that the 7 chars is just the shortened SSH |
| 18:58 |
Calinou |
TIL: “Our official line length limit is 90 characters†|
| 18:58 |
Calinou |
so that'll be the guideline for my mods |
| 18:59 |
LemonLake |
My issue isn't on the issues list |
| 18:59 |
Calinou |
builtin uses 4-tabs however… |
| 19:00 |
Calinou |
https://github.com/minetest/minetest/pull/1341#issuecomment-44471878 |
| 19:00 |
Calinou |
LemonLake, I see it: https://github.com/minetest/minetest/issues?state=open |
| 19:00 |
Calinou |
at the top |
| 19:00 |
Calinou |
sort by Recently Updated |
| 19:00 |
LemonLake |
What kind of repository was I on ø.ø |
| 19:01 |
LemonLake |
Oh i had a label filter (facepalm) |
| 19:02 |
Calinou |
https://github.com/minetest/minetest/pull/1328 → does this kill ceiling torches with fire? |
| 19:02 |
Calinou |
please keep ceiling torches, if you merge this |
| 19:02 |
|
tomreyn joined #minetest-dev |
| 19:10 |
|
Hunterz joined #minetest-dev |
| 19:25 |
|
CraigyDavi_ joined #minetest-dev |
| 19:25 |
|
CraigyDavi joined #minetest-dev |
| 19:49 |
|
Robby joined #minetest-dev |
| 19:59 |
VanessaE |
don't merge 1328, that's a dead issue imho. |
| 20:05 |
|
Krock left #minetest-dev |
| 20:06 |
Calinou |
he says he's not using Minecraft textures, but I doubt it |
| 20:06 |
Calinou |
he already used them in mods |
| 20:08 |
ShadowNinja |
#1346 |
| 20:08 |
ShadowBot |
https://github.com/minetest/minetest/issues/1346 -- Only keep players loaded while theyre connected by ShadowNinja |
| 20:11 |
CraigyDavi |
ShadowNinja, so it does not load all player files and store then up as ram as it used to? |
| 20:13 |
ShadowNinja |
CraigyDavi: Yep. |
| 20:14 |
CraigyDavi |
That's great! Now I don't have to keep deleting player files :) |
| 20:17 |
|
catninja joined #minetest-dev |
| 20:20 |
|
us`0gb joined #minetest-dev |
| 20:22 |
|
Amaz_ joined #minetest-dev |
| 20:25 |
|
proller joined #minetest-dev |
| 21:14 |
|
kaeza joined #minetest-dev |
| 21:30 |
|
kahrl joined #minetest-dev |
| 21:46 |
ShadowNinja |
sapier: Trying to find the async bug: valgrind: the 'impossible' happened: |
| 21:46 |
sapier |
meaning? |
| 21:47 |
ShadowNinja |
VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting |
| 21:47 |
sapier |
lol seems someone is really messing up memory |
| 21:47 |
sfan5 |
you should try to debug valgrind |
| 21:47 |
sfan5 |
if gdb crashes you're out of luck |
| 21:49 |
ShadowNinja |
It did dump a bunch of Conditional jump or move depends on uninitialised value(s) warnings though... |
| 21:50 |
ShadowNinja |
More than 1000 different errors detected. I'm not reporting any more. Final error counts will be inaccurate. Go fix your program! Haha. |
| 21:50 |
VanessaE |
wait, you crashed valgrind itself? O_O |
| 21:52 |
ShadowNinja |
Yes, something's broken so badly that valgrind gets killed apparently. |
| 21:52 |
VanessaE |
how the... I don't even... |
| 21:53 |
ShadowNinja |
Some of the errors are in OpenSSL. |
| 21:54 |
ShadowNinja |
A lot of them actually. |
| 21:54 |
sapier |
ignore the conditional jumps they're most likely irrelevant |
| 21:58 |
ShadowNinja |
http://sprunge.us/ATeD?foo |
| 21:58 |
ShadowNinja |
Most of the errors are in OpenSSL or CURL. |
| 21:59 |
ShadowNinja |
Lots in JSON-CPP too. |
| 22:09 |
ShadowNinja |
The only errors seem to be deep in Lua or unrelated. |
| 22:11 |
ShadowNinja |
sapier: Have you poked inspected this crash? Because I still don't have any idea what's causing it, unless it's that Lua's internally broken with threads. |
| 22:13 |
sapier |
a single lua instance never may be used from different threads that's crucial but for what I know we follow that rule .. don't we? |
| 22:22 |
ShadowNinja |
I believe so... |
| 22:23 |
ShadowNinja |
LuaJIT apparently has a non-threadsafe allocator though. |
| 22:29 |
sapier |
yes but that's not relevant as long as we work on different lua states |
| 22:32 |
ShadowNinja |
Even with different states. |
| 22:32 |
sapier |
that'd be new |
| 22:32 |
sapier |
malloc is threadsafe |
| 22:32 |
ShadowNinja |
LuaLanes protects LuaJIT's allocator because of that. It uses seperate states. |
| 22:34 |
sapier |
sorry a little bit more details |
| 22:35 |
sapier |
I don't think it's a generic issue as it did work with comparable thread changes |
| 22:35 |
sapier |
still others use multiple lua instances from multiple thread too so this is actually a well tested usecase |
| 22:35 |
|
ImQ009 joined #minetest-dev |
| 22:43 |
sapier |
I see a lot of graphics memory corruption lately maybe that's related too |
| 22:43 |
sapier |
haven't seen that issue for quite some time |
| 22:43 |
ShadowNinja |
https://github.com/LuaLanes/lanes/blob/master/src/lanes.c#L1568 |
| 22:45 |
sapier |
for what I understand that's just relevant if you use a single state from different threads ... our issue is independent from luajit anyway |
| 22:47 |
ShadowNinja |
LuaLanes uses a seperate state for each thread. LuaThread is what uses one state, it requires a patched core though. And yes, this isn't the issue, but it could be an issue even if it isn't the current one. |
| 22:49 |
sapier |
for luajit maybe but I don't see a way how luajit could mess up it's own memory unless they use global variables internaly ... |
| 23:33 |
|
jin_xi joined #minetest-dev |
| 23:40 |
ShadowNinja |
\o/ I fixed the async crash with some help from sapier. |
| 23:41 |
LemonLake |
popping* |
| 23:45 |
ShadowNinja |
Comments on #1149? |
| 23:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1149 -- Add AppData file by davidgumberg |
| 23:46 |
VanessaE |
yay :) |
| 23:52 |
ShadowNinja |
PilzAdam: ^ Does that look good now? |
| 23:53 |
PilzAdam |
does the order of <project_license> matter? |
| 23:58 |
ShadowNinja |
PilzAdam: Doesn't seem like it, but I can easily ammend it. |
| 23:58 |
|
BrandonReese joined #minetest-dev |
