Time |
Nick |
Message |
00:57 |
|
Gary__ joined #minetest-dev |
00:57 |
|
Gary__ left #minetest-dev |
01:20 |
paramat |
trivial game#714 will merge later |
01:20 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/714 -- Default/trees: Clean-up 'can grow' function by paramat |
01:49 |
paramat |
now merging game 714 |
01:55 |
paramat |
done |
02:12 |
|
paramat left #minetest-dev |
02:13 |
|
crazyR_ joined #minetest-dev |
02:36 |
|
Warr1024 joined #minetest-dev |
02:38 |
|
Player2 joined #minetest-dev |
02:38 |
|
Player-2 joined #minetest-dev |
05:54 |
hmmmm |
https://github.com/kwolekr/minetest/commit/27eed1389b8bece41950c53b47acffb3bb0c83ee |
05:54 |
hmmmm |
PTAL |
06:27 |
|
paramat joined #minetest-dev |
06:27 |
paramat |
seems okay can't see any mistakes |
06:38 |
|
Hunterz joined #minetest-dev |
06:48 |
|
leat joined #minetest-dev |
06:56 |
hmmmm |
https://github.com/kwolekr/minetest/commit/a8cb7ad29aff5b3f9ae67e02c12b3a093e8234aa |
06:56 |
hmmmm |
PTAL |
06:58 |
hmmmm |
this is pretty much due to nerzhul ^ |
07:06 |
|
paramat left #minetest-dev |
07:12 |
|
kaeza joined #minetest-dev |
07:44 |
|
nrzkt joined #minetest-dev |
08:02 |
|
Darcidride joined #minetest-dev |
08:05 |
|
julienrat joined #minetest-dev |
08:10 |
|
julienrat joined #minetest-dev |
08:10 |
|
julienrat left #minetest-dev |
08:15 |
|
nrzkt joined #minetest-dev |
09:03 |
|
OldCoder joined #minetest-dev |
09:03 |
|
PilzAdam joined #minetest-dev |
09:42 |
|
DFeniks joined #minetest-dev |
10:26 |
|
Calinou joined #minetest-dev |
11:00 |
|
rubenwardy joined #minetest-dev |
11:24 |
|
CraigyDavi joined #minetest-dev |
12:01 |
PilzAdam |
did nobody notice that the current HEAD does not build? |
12:01 |
nrzkt |
who broke the build ? |
12:02 |
PilzAdam |
hmmmm |
12:02 |
PilzAdam |
https://github.com/minetest/minetest/commit/27eed1389b8bece41950c53b47acffb3bb0c83ee#diff-a408137ced7567bc503aa6f6386af956L31 |
12:04 |
nrzkt |
hmmmm please do PR like other devs to make the CI verify the commits ! |
12:05 |
|
proller joined #minetest-dev |
12:06 |
PilzAdam |
or at least try to build it locally |
12:33 |
|
Hunterz joined #minetest-dev |
12:38 |
|
proller joined #minetest-dev |
13:03 |
|
AnotherBrick joined #minetest-dev |
13:07 |
|
rubenwardy joined #minetest-dev |
13:30 |
|
Samson1 joined #minetest-dev |
13:31 |
|
DFeniks joined #minetest-dev |
13:40 |
|
nore joined #minetest-dev |
13:54 |
|
zat joined #minetest-dev |
13:55 |
|
H-H-H joined #minetest-dev |
14:13 |
|
julienrat joined #minetest-dev |
14:15 |
|
julienrat left #minetest-dev |
14:44 |
|
Hunterz joined #minetest-dev |
14:48 |
Megaf |
Hi all, minetestserver is not compiling here again |
14:49 |
Megaf |
http://paste.debian.net/plain/318351 |
14:49 |
Megaf |
Help please? |
14:49 |
Megaf |
Latest Irrlicht and latest LuaJit |
14:52 |
PilzAdam |
Megaf, revert to one commit earlier |
14:54 |
Megaf |
ok, known error https://github.com/minetest/minetest/issues/3296 |
14:55 |
PilzAdam |
https://github.com/PilzAdam/minetest/commit/c406438b95e3df181961add56a2511b96bd9d690 |
14:56 |
PilzAdam |
will merge in a few minutes |
14:56 |
Megaf |
Ok, will wait instead of reverting |
14:58 |
Megaf |
nrzkt: you there? Need a :+1 for that ^ |
14:58 |
Megaf |
:P |
15:01 |
|
exoplanet joined #minetest-dev |
15:02 |
|
hmmmm joined #minetest-dev |
15:03 |
PilzAdam |
hmmmm, you broke stuff |
15:03 |
PilzAdam |
but no worries, I got your back |
15:04 |
hmmmm |
oh crap what options were those |
15:05 |
hmmmm |
could you please fix this the right way by adding <algorithm> to the files that actually use CONTAINS() and not basicmacros? |
15:05 |
PilzAdam |
basicmacros uses find |
15:05 |
PilzAdam |
and that needs algorithm AFAIK |
15:06 |
hmmmm |
no, basicmacros does not use algorithm, files that use contains use algorithms |
15:07 |
PilzAdam |
that is poor design if you need to always include header dependencies in the file that includes the header |
15:10 |
hmmmm |
it's either slightly poor design or horribly slow compilation |
15:10 |
PilzAdam |
if you want fast compilation then precompile the headers |
15:11 |
hmmmm |
that's not an option for everybody and it ignores the problem of template code bloat |
15:14 |
|
julienrat joined #minetest-dev |
15:14 |
|
julienrat left #minetest-dev |
15:25 |
|
Lunatrius joined #minetest-dev |
15:26 |
|
proller joined #minetest-dev |
16:01 |
|
luizrpgluiz joined #minetest-dev |
16:02 |
luizrpgluiz |
what kind of developer can participate in minetest? |
16:02 |
PilzAdam |
luizrpgluiz, everyone |
16:03 |
rom1504 |
what are developer kinds ? |
16:03 |
Calinou |
There are 10 kinds of developers in this world: those who understand binary, and those who don't |
16:03 |
luizrpgluiz |
celeron55 participates in game development too? |
16:04 |
PilzAdam |
sometimes |
16:07 |
luizrpgluiz |
I had some ideas for the game would be a little more unlikely to put the game now, such as putting new biomes in the game |
16:15 |
luizrpgluiz |
in the new version, will put more to 0.4.14? |
16:16 |
VanessaE |
there are already enough biomes in the default game if you use mapgen v7 |
16:17 |
|
Player2 joined #minetest-dev |
16:31 |
|
est31 joined #minetest-dev |
16:31 |
est31 |
so, #3292 already has one approval, but I think it should have a second one before merging |
16:31 |
ShadowBot |
https://github.com/minetest/minetest/issues/3292 -- Add server side ncurses terminal by est31 |
16:32 |
est31 |
this is a larger patch |
16:32 |
est31 |
(or a third one, depending on how you count) |
16:45 |
|
JohnnyComeL8ly joined #minetest-dev |
16:47 |
|
julienrat joined #minetest-dev |
16:47 |
|
julienrat left #minetest-dev |
16:56 |
|
zupoman joined #minetest-dev |
16:56 |
|
zupoman joined #minetest-dev |
17:06 |
|
VargaD joined #minetest-dev |
17:06 |
|
rubenwardy joined #minetest-dev |
17:18 |
|
Krock joined #minetest-dev |
17:30 |
|
cib0 joined #minetest-dev |
17:31 |
|
nrzkt joined #minetest-dev |
17:44 |
hmmmm |
I have to take a look at ncurses terminal for sure |
17:44 |
hmmmm |
est31: what is your take on CONTAINS() and #include <algorithm> ? |
17:46 |
|
Gael-de-Sailly joined #minetest-dev |
17:51 |
|
BlockMen joined #minetest-dev |
17:54 |
BlockMen |
is this one needed now or not? https://github.com/BlockMen/minetest/commit/d3a567cf52fcaff57a7a8a9d1611133ec1489bc3 |
17:54 |
BlockMen |
hmmmm ShadowNinja ^ |
18:11 |
|
est31 joined #minetest-dev |
18:14 |
ShadowNinja |
BlockMen: Unless something like that's already been merged, yes. Just make sure that ServerError is caught somewhere when runnning the dedicated server. |
18:14 |
|
Robert_Zenz joined #minetest-dev |
18:14 |
est31 |
hmmmm, about doing #include <algorithm> in basicmacos.h vs doing it in the places it is used, I don't really know. The second option would allow faster compilation, so I guess i'd take that one. |
18:17 |
est31 |
BlockMen, have you seen 768596927458d4d1d4ae7914526311471d242555 |
18:22 |
BlockMen |
est31, so throw ServerError is not enough, i guess? |
18:22 |
est31 |
I guess so |
18:24 |
hmmmm |
yeah me too |
18:24 |
hmmmm |
BlockMen: I really don't know |
18:24 |
hmmmm |
BlockMen: that doesn't change any actual behavior of a mod crashing on a dedicated server |
18:25 |
hmmmm |
that being said, nerzhul's original commit changing that behavior is pretty useless |
18:26 |
hmmmm |
BlockMen: I think I'll approve of your commit though, +1 |
18:27 |
nrzkt |
hmmmm, your commits breaking master too |
18:27 |
nrzkt |
but i agree with this commit if it's necessary |
18:27 |
hmmmm |
nrzkt: the problem is I don't understand why you made the original commit that changed the behavior in the first place |
18:27 |
nrzkt |
can't remember, look at the commit log |
18:27 |
hmmmm |
and I checked, it really doesn't change anything |
18:27 |
hmmmm |
yes, your commit message doesn't explain. |
18:28 |
est31 |
well it does change something |
18:28 |
est31 |
precisely the opposite what blockmen wants to get merged |
18:28 |
hmmmm |
they still abort the application with SIGABRT |
18:28 |
nrzkt |
maybe this was necessary when it was done but some recent refactoring hide this |
18:28 |
hmmmm |
an unhandled exception is SIGABRT, a FATAL_ERROR() is SIGABRT |
18:28 |
est31 |
it is good to have an unified way to exit the server with an error |
18:28 |
est31 |
I use it in my ncurses console |
18:29 |
est31 |
I only have to edit the implementation of FATAL_ERROR() nothing else |
18:29 |
hmmmm |
actually an unhandled exception in the dedicated server will shut down cleanly without a signal |
18:29 |
nrzkt |
if i remember, don't catching error generate a core dump |
18:29 |
hmmmm |
because main() wraps run_dedicated_server() in an exception handler |
18:29 |
nrzkt |
why did we need a core dump for a lua problem |
18:29 |
hmmmm |
you don't |
18:29 |
nrzkt |
if we don't catch this exception then servers will generate core dumps |
18:30 |
nrzkt |
if enabled. Not on many Linuxes but on every BSD/Solaris |
18:30 |
hmmmm |
it is caught in main() like I said |
18:30 |
hmmmm |
FATAL_ERROR() aborts(), yes? |
18:30 |
hmmmm |
that kills the application with SIGABRT |
18:31 |
hmmmm |
ohh |
18:31 |
hmmmm |
I understand what's going on here |
18:31 |
hmmmm |
the UNHANDLED_EXCEPTION_HANDLER internally calls FATAL_ERROR() as well on a caught exception thanks to est's recent change |
18:32 |
hmmmm |
VanessaE must have been running a release build which explains why she did not previously see a lua crash abnormally terminate the dedicated server |
18:33 |
hmmmm |
so VanessaE likes the old behavior better probably because she has it running under gdb |
18:33 |
est31 |
IIRC gdb had these nice tables about what to do when a signal gets caught |
18:34 |
|
OldCoder joined #minetest-dev |
18:35 |
est31 |
https://sourceware.org/gdb/onlinedocs/gdb/Signals.html |
18:43 |
hmmmm |
PTAL https://github.com/kwolekr/minetest/commit/f839bdf553bc8221a3b8efcbc58e26a7e9f3e415 |
18:44 |
kahrl |
hmmmm: does that work? I always thought you had to put those under private: |
18:45 |
kahrl |
(or in C++11, use =delete) |
18:45 |
ShadowNinja |
^ |
18:46 |
est31 |
also, shouldn't basicmacros be put in util? |
18:47 |
hmmmm |
kahrl, yeah they are under private: |
18:47 |
hmmmm |
est31: irrlichttypes.h isn't in util |
18:48 |
kahrl |
ah I see |
18:48 |
est31 |
basicmacros doesnt use a single irrlicht type |
18:48 |
est31 |
its generic, isnt it |
18:48 |
est31 |
so it qualifies for util, no? |
18:48 |
kahrl |
maybe add a comment above the macro that the caller has to ensure it's in private: |
18:49 |
hmmmm |
generic doesn't necessarily mean it needs to go into util |
18:49 |
est31 |
but why have you moved code in util/ back to src/ ? |
18:49 |
est31 |
thats the wrong direction to move |
18:49 |
hmmmm |
because why not? |
18:49 |
hmmmm |
util/ is an extra level of indirection |
18:49 |
est31 |
move stuff to subdirs, not from subdirs |
18:49 |
hmmmm |
because of how fundamental these macros are I'd have to argue they belong in the parent directory |
18:50 |
est31 |
it has to do nothing with fundamentality |
18:50 |
est31 |
in fact, util is more low level than src |
18:50 |
est31 |
src is for the application, util is for the helper stuff |
18:51 |
est31 |
basicmacros consists of helper stuff |
18:51 |
hmmmm |
then why are irrlichtypes_*.h headers in the top source directory? |
18:51 |
hmmmm |
util depends on these defs |
18:51 |
est31 |
well, perhaps they can moved to util as well |
18:51 |
est31 |
or not, idk |
18:53 |
est31 |
also, what was the reason the first place to split out to basicmacros.h? |
18:53 |
est31 |
isn't MAX( a numeric operation? |
18:56 |
|
luizrpgluiz left #minetest-dev |
18:58 |
est31 |
and MIN |
18:58 |
est31 |
ARRLEN is no numeric macro agreed |
18:58 |
est31 |
and contains |
19:00 |
est31 |
but I don't really care about that, I'm sure you had a reason why you did it |
19:03 |
ShadowNinja |
irrlichttypes.h should probably be split into into itself and int_types.h (which would be based on stdint.h). |
19:04 |
ShadowNinja |
Th int_types part should probably be in util. |
19:11 |
ShadowNinja |
I did said split a while ago, but didn't clean it up and prepare it for merging. |
19:17 |
VanessaE |
hmmmm: not a release build, but yet it is running under gdb. maybe I just didn't see the SIGABRT in the past; there was a stderr/stdout redirect screwup in my start-server script (which I've since fixed) -- that plus seeing SIGABRT when I didn't expect it threw me off a bit (doesn't explain why the crash happened in the first place though) |
19:17 |
VanessaE |
s/yet/yes/ |
19:19 |
ShadowNinja |
BlockMen: I think the right way to fix that would be to catch the ServerError properly and print it, and remove the "UNRECOVERABLE ERROR" message to prevent duplicates. |
19:29 |
BlockMen |
ShadowNinja, so basically i need just to remove the msg from my commit now, since "throw ServerError()" prints it already and does not abort(), right? |
19:30 |
|
cib0 joined #minetest-dev |
19:31 |
ShadowNinja |
BlockMen: I think the ServerError results in FATAL_ERROR being called by a catch(...) when running the dediated server (`minetest --server` or `mineestserver`) . You should catch the ServerError and handle it so that that doesn't happen. |
19:31 |
ShadowNinja |
(You should exit, but exit cleanly with an error code) |
19:42 |
BlockMen |
ShadowNinja, catch it where? Sorry, but this area is complete unknown by me :\ |
19:43 |
ShadowNinja |
BlockMen: Probably in run_dedicated_server. |
19:44 |
est31 |
but I guess it needs lots and lots of attention |
19:45 |
est31 |
e.g. we should watch out that we don't kick clients twice |
19:45 |
est31 |
only close the connection |
19:45 |
est31 |
so its easy said, but I guess its more work than it seems |
19:45 |
est31 |
to be really proper |
19:46 |
est31 |
e.g. should we run on_shutdown callbacks? |
19:46 |
est31 |
should we not do it? |
19:46 |
est31 |
e.g. it could save inconsistent state |
19:47 |
est31 |
so basically one has to look at all destructors of classes the server has and judge whether what they do can be done in the case of an async error |
19:47 |
est31 |
which gets us to the question: when are async errors thrown |
19:48 |
est31 |
if c++ unwinds the stack, it runs all destructors |
19:49 |
est31 |
the next thing are future changes |
19:49 |
est31 |
you have to watch out what you do in destructors |
19:49 |
est31 |
and people who review code need to know that |
19:50 |
est31 |
(c++ doesn't run _all_ destructors, only destructors of objects which live on the stack and whose context is left) |
19:52 |
est31 |
so, we basically have to answer following questions: |
19:53 |
est31 |
1. can the map be in an inconsistent state? |
19:53 |
est31 |
2. should it be saved? |
19:53 |
est31 |
3. should we run on_shutdown callbacks? |
19:54 |
VanessaE |
save the map if it's consistent, but don't run lua on_shutdown stuff. |
19:55 |
VanessaE |
(there's the potential, in the latter case, of throwing another error on the way down, which can confuse things) |
20:01 |
|
H-H-H joined #minetest-dev |
20:01 |
|
Player2 joined #minetest-dev |
20:02 |
|
paramat joined #minetest-dev |
20:05 |
BlockMen |
ShadowNinja, ok im out of that. i will happily learn more about that but i think im the wrong person to fix that now. |
20:07 |
paramat |
PilzAdam game#681 is updated and tested, should i merge later? |
20:07 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/681 -- Fire: Add 'permanent flame' node by paramat |
20:08 |
VanessaE |
"It is still usable when fire is disabled." |
20:08 |
VanessaE |
I hope that means it's also properly nerfed |
20:09 |
paramat |
yes it doesn't spread or ignite or remove anything |
20:09 |
VanessaE |
ok |
20:11 |
|
Player2 joined #minetest-dev |
20:11 |
BlockMen |
shouldnt it be called "fake fire" then? |
20:12 |
paramat |
it's closest to maptools' 'permanent fire' because it causes player damage |
20:12 |
PilzAdam |
paramat, it can be merged, IMO |
20:12 |
paramat |
ok |
20:20 |
est31 |
PTAL https://github.com/est31/minetest/commit/96c6eaaf9e92958fb653fc101e04823121943064 |
20:22 |
|
Darcidride joined #minetest-dev |
20:22 |
nrzkt |
est31 please do a pull request |
20:24 |
est31 |
#3297 |
20:24 |
ShadowBot |
https://github.com/minetest/minetest/issues/3297 -- Environment: Time of day fixes and add serverside getter by est31 |
20:24 |
est31 |
nrzkt, ^ |
20:26 |
nrzkt |
creating commits every where without having pull request is a pure pain, please do pull requests :) |
20:26 |
nrzkt |
thanks est31 |
20:27 |
nrzkt |
PR permit to build on many platforms. It should not be avoided |
20:28 |
nrzkt |
at a moment somes spit because master was broken and they need master as a stable branch. Now we see master as a branch which could be broken. What happened ? |
20:29 |
est31 |
nrzkt, your bot is broken |
20:29 |
est31 |
https://jenkins.unix-experience.fr/job/minetest%20-%20FreeBSD%20-%20Official/1768/console |
20:29 |
nrzkt |
gettext ? :o |
20:30 |
nrzkt |
http://pastebin.com/VQUCgkDQ |
20:30 |
nrzkt |
it's installed and the lib is available |
20:31 |
nrzkt |
did somebody change something on the gettext detection ? |
20:32 |
est31 |
I don't recall |
20:36 |
est31 |
so everything builds except freebsd, can I merge? |
20:37 |
nrzkt |
i added some comments |
20:38 |
est31 |
why const here? |
20:38 |
nrzkt |
maybe fix the lower function too |
20:38 |
nrzkt |
timeofday should be protected from modifications |
20:38 |
est31 |
? |
20:38 |
est31 |
its u32 |
20:39 |
est31 |
u32 is atomic |
20:39 |
est31 |
its copied when its returned |
20:39 |
est31 |
if you modify it, the time doesn't get modified |
20:39 |
nrzkt |
const is not for atomic it's to make variable not modifiable |
20:39 |
nrzkt |
yeah i know :) |
20:39 |
nrzkt |
but making it const permit to remove some problems due to incorrect code |
20:40 |
nrzkt |
const is a best practice in many areas to prevent coding errors on variables which don't need to be modified |
20:40 |
est31 |
it does need to be modified |
20:40 |
est31 |
e.g. when I want to split up the time |
20:40 |
est31 |
into minutes and hour |
20:40 |
nrzkt |
split up in another variable not in the got variable |
20:40 |
est31 |
then I do code like |
20:41 |
est31 |
u32 time = getTimeOfDay() |
20:41 |
est31 |
u32 minutes = time % 60; |
20:41 |
nrzkt |
there is no problem due to const there |
20:41 |
est31 |
time -= seconds |
20:41 |
est31 |
u32 hours = time / 60 |
20:42 |
nrzkt |
i see the usage you want |
20:42 |
est31 |
now I do need the -= seconds here because / rounds |
20:42 |
nrzkt |
floor(time/60) ? |
20:43 |
est31 |
well yes |
20:43 |
est31 |
or (time - seconds) / 60 |
20:43 |
est31 |
but I say there are use-cases where having it const makes no sense |
20:43 |
est31 |
but I'll make it inline |
20:43 |
nrzkt |
as you want |
20:44 |
PilzAdam |
<est31> u32 is atomic <- not necessarily |
20:44 |
nrzkt |
est31: ok |
20:44 |
est31 |
well yeah |
20:45 |
est31 |
not atomic in a threading sense |
20:47 |
est31 |
nrzkt, the whole method needs locking |
20:47 |
est31 |
it does m_time_of_day_f += 1.0; |
20:47 |
est31 |
in its last line it does something |
20:47 |
nrzkt |
m_time_of_day_f++ |
20:47 |
nrzkt |
i see |
20:49 |
|
Calinou joined #minetest-dev |
21:13 |
est31 |
okay, is the pr good nrzkt ? |
21:13 |
|
Amaz joined #minetest-dev |
21:15 |
nrzkt |
yes |
21:17 |
|
paramat left #minetest-dev |
21:18 |
est31 |
ShadowNinja, an atomic would work for the getters and setters, but it wouldnt work for stepTimeOfDay I think |
21:22 |
|
CraigyDavi joined #minetest-dev |
21:26 |
ShadowNinja |
est31: Well, use it werever you can. |
21:27 |
est31 |
the values for these different things are inter dependent |
21:27 |
est31 |
and I dont want sb to call setTimeOfDay during stepTimeOfDay execution |
21:27 |
PilzAdam |
hmmmm, https://github.com/minetest/minetest/issues/2145#issuecomment-151648316 seems like mapgen threads kill (server) performance for me |
21:30 |
nrzkt |
est31 it's the goal of atomic |
21:30 |
nrzkt |
you don't need mutexes |
21:31 |
nrzkt |
primitive types can be atomic |
21:32 |
PilzAdam |
ShadowNinja, wchar_t isn't 16 bit |
21:32 |
PilzAdam |
it's 32 |
21:32 |
est31 |
no |
21:32 |
nrzkt |
PilzAdam, it's a problem with locking, server and emerge threads are awaiting each others too many times |
21:32 |
ShadowNinja |
PilzAdam: Hm? |
21:32 |
est31 |
wchar_t is implementation defined PilzAdam |
21:32 |
PilzAdam |
ShadowNinja, https://github.com/minetest/minetest/pull/3298/files#diff-acf4cb47cb3cc77b556b4a87dfc70217R47 this is misleading |
21:32 |
PilzAdam |
est31, every sane implementation makes it utf-32 |
21:33 |
est31 |
What the fuck |
21:33 |
est31 |
you really do this ShadowNinja? |
21:34 |
est31 |
setting f32 to float? |
21:34 |
est31 |
this is totally against specification |
21:34 |
est31 |
these things are implementation defined |
21:34 |
ShadowNinja |
PilzAdam: Hmmm. |
21:36 |
est31 |
windows has 16 bit: https://msdn.microsoft.com/de-de/library/windows/desktop/aa367308%28v=vs.85%29.aspx |
21:38 |
ShadowNinja |
PilzAdam: Fortunately c16 isn't needed. I'll just remove it. |
21:38 |
PilzAdam |
est31, windows isn't sane ;-) |
21:38 |
est31 |
PilzAdam, agreed, still we support it |
21:38 |
ShadowNinja |
est31: I suppose it could technically be something other than IEEE 32-bt float. I'll see if Irrlicht does any better. |
21:39 |
PilzAdam |
est31, http://stackoverflow.com/questions/4383946/conflicts-definition-of-wchar-t-string-in-c-standard-and-windows-implementati see first answer here |
21:39 |
ShadowNinja |
est31: Nope, Irrlicht uses the exact same float typedefs. |
21:39 |
PilzAdam |
wchar_t should hold any character in a single type |
21:40 |
PilzAdam |
so using is as utf-16 is invalid |
21:41 |
PilzAdam |
ShadowNinja, if we don't do it better then why change it? |
21:41 |
PilzAdam |
(and we should do it better, since we serialize this stuff) |
21:42 |
est31 |
our float serialisation is very stability focused |
21:42 |
ShadowNinja |
PilzAdam: Because it's much cleaner. |
21:43 |
ShadowNinja |
est31: That's a very nice way of saying "our float serialization sucks", but I digress. |
21:43 |
PilzAdam |
ShadowNinja, all these Irrlicht namespace stuff seems much less cleaner than the previous workaround |
21:43 |
est31 |
ShadowNinja, well its easy to implement minetest on non IEEE 32-bit compatible platforms |
21:44 |
est31 |
and to implement it so that its fast :) |
21:45 |
PilzAdam |
btw, all platform builds except linux fail |
21:46 |
ShadowNinja |
PilzAdam: I disagree. We used the standard types for u64 only( with old irrlicht), had to include stdint.h for irrTypes.h to work on BSD, imported the irr namespace in its entirety into the global namespace... |
21:47 |
|
luizrpgluiz joined #minetest-dev |
21:47 |
PilzAdam |
if you do a proper f32 definition then it may be worth it |
21:47 |
PilzAdam |
as it is right now, I don't consider it to be good enough to justify the drawbacks |
21:48 |
est31 |
I haven't made an opinion on the other parts of the PR yet |
21:49 |
est31 |
okay can I merge #3297 ? |
21:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/3297 -- Environment: Time of day fixes and add serverside getter by est31 |
21:50 |
est31 |
I originally came there from my ncurses patch, because I want to display the game time in the console |
21:50 |
est31 |
but then I saw in what a messy state the time locking was |
21:51 |
est31 |
so I had to clean up :) |
21:51 |
est31 |
and I dont want to make it part of the ncruses patch because its mostly unrelated. But I want to use its functionality. |
21:53 |
|
Gael-de-Sailly joined #minetest-dev |
21:53 |
ShadowNinja |
est31: Have you addressed nrz's comment? And can you use atomics? |
21:54 |
est31 |
yes, nrz agreed that the lock has to be fully scoped |
21:54 |
est31 |
and about atomics, I don't think they can be used here |
21:54 |
est31 |
perhaps I could use atomics on a new struct object that contains all type variables |
21:55 |
est31 |
but that isnt the scope of my pr |
21:59 |
nrzkt |
if you use mutex, full scope RAII is the better way there, but if atomic is possible, because we are using native float do it |
21:59 |
est31 |
btw about atomics, can you perhaps find out how to add a compare-and-swap atomic operation ShadowNinja ? |
22:00 |
est31 |
well, I could make the variables atomic, but behaviour would break if the step is called multiple times simultaneously |
22:00 |
est31 |
or if set is called while step is running |
22:01 |
est31 |
so no, I can't use atomics |
22:01 |
est31 |
at least not without modifying how the code works |
22:01 |
|
proller joined #minetest-dev |
22:03 |
luizrpgluiz |
for me the est31 did a great job putting the ncurses in minetest, I hope that all developers agree to put in version 0.4.14, it would be very good this update for the game and so help us as a player and server administrator |
22:10 |
est31 |
so I guess ShadowNinja merging is ok? |
22:14 |
luizrpgluiz |
est31: probably he should love you put atomics in the ncurses minetest update package |
22:14 |
|
VanessaE joined #minetest-dev |
22:16 |
luizrpgluiz |
est31: ^_^ |
22:17 |
est31 |
haha |
22:17 |
PilzAdam |
est31, it's good |
22:17 |
est31 |
ncurses uses alot of mutexed queues they can be easily replaced by atomic queues. |
22:17 |
est31 |
okay merging |
22:52 |
Gael-de-Sailly |
What about Autorun #3210 ? |
22:52 |
ShadowBot |
https://github.com/minetest/minetest/issues/3210 -- WoW-style Autorun by duane-r |
23:29 |
luizrpgluiz |
est31: if ncurses is very good for server administrators, because the staff ta finding bad without atomics? |
23:30 |
est31 |
ncurses has nothing to do with atomics |
23:31 |
|
rubenwardy joined #minetest-dev |
23:34 |
luizrpgluiz |
est31: hehe |
23:36 |
VanessaE |
pretty sure ncurses operates at the "compound" level (let alone molecular or atomic) :P |
23:37 |
VanessaE |
(in other words, luizrpgluiz your translator sucks :P ) |
23:39 |
luizrpgluiz |
est31,VanessaE: hehe,google translator ^^ |
23:39 |
VanessaE |
google translator sucks, then |
23:39 |
est31 |
there is nothing better |
23:39 |
VanessaE |
true |
23:39 |
VanessaE |
but it still sucks :P |
23:39 |
luizrpgluiz |
i am brazilian |
23:39 |
est31 |
bing translator is worse |
23:40 |
VanessaE |
doesn't kaeza speak Portuguese also? |
23:40 |
est31 |
funny how the google translator says "the est31" |
23:41 |
luizrpgluiz |
VanessaE: he is Spanish |
23:41 |
* est31 |
confusing translators with nicks |
23:41 |
VanessaE |
well you ARE the one-and-only |
23:41 |
est |
twitter is taken |
23:41 |
VanessaE |
luizrpgluiz: he is from somewhere in South America, Paraguay I think |
23:43 |
luizrpgluiz |
:) |
23:44 |
est |
man, I'd really love rust's enums here: https://github.com/minetest/minetest/pull/3292/files#diff-52aefc89649ac8ebcb0e79777158a43dR34 |
23:44 |
est |
basically I could spare the whole struct |
23:54 |
|
Supertanker2 joined #minetest-dev |
23:57 |
luizrpgluiz |
next daily update minetest for Linux, will have the ncurses? or before will test to see if it works? |
23:58 |
est |
well I need approval first |
23:58 |
VanessaE |
est: I take it you've tested its behavior under screen, tmux, etc? |
23:59 |
est |
no, if you want to do it, you can do it :) |