| Time |
Nick |
Message |
| 01:06 |
|
Taoki joined #minetest-dev |
| 01:12 |
|
SpeedProg joined #minetest-dev |
| 01:30 |
hmmmm |
SegFault22, please take it to #minetest or post on the "feature requests" section of the forums |
| 01:30 |
hmmmm |
this channel is for development discussion only |
| 01:31 |
SegFault22 |
I tried taking it to #minetest, and one of your moderators suggested to take it here. |
| 01:31 |
hmmmm |
welp |
| 01:31 |
SegFault22 |
There is no feature requests section, by the way. |
| 01:32 |
hmmmm |
perhaps the feature Discussion page then |
| 01:33 |
SegFault22 |
That has been tried once before. But seeing the number of people who responded, I now understand that on the forums, I have to do something against the rules/bad for anyone to recognize it... |
| 01:33 |
SegFault22 |
So here is the best, and seemingly only place, for contacting the developers. |
| 01:40 |
|
SegFault22 left #minetest-dev |
| 01:57 |
|
mrtux joined #minetest-dev |
| 02:36 |
|
mrtux joined #minetest-dev |
| 02:37 |
ShadowNinja |
About LuaJIT packaging: I would rather have no libs packaged in Minetest and use dynamic libs. I agree with segfault, but you shouldn't have to register types, just store it as a std::string rather than a enumeration. |
| 02:38 |
ShadowNinja |
I actually tried using the builtin method and was surprised that craft types were hardcoded. |
| 02:38 |
ShadowNinja |
(For a technic machine) |
| 03:41 |
|
SegFault22 joined #minetest-dev |
| 03:46 |
|
SegFault22 left #minetest-dev |
| 04:03 |
|
OldCoder joined #minetest-dev |
| 04:04 |
OldCoder |
This is not yet a bug report. It won't be unless I see a definite pattern. But thought I'd mention that multiple worlds of mine, running git close to current, hang sometimes on Item Definitions load. |
| 04:16 |
|
deltib joined #minetest-dev |
| 04:45 |
Sokomine |
question: why is a map where all the chunks the server sent so much smaller than the map on the server? even though it seems to encompass all the buildings? |
| 04:46 |
Sokomine |
part of it may be underground (with mines), explored but unbuilt territory, air? |
| 04:46 |
VanessaE |
underground. |
| 04:46 |
Sokomine |
it can't be all underground |
| 04:46 |
* Sokomine |
looks frightened |
| 04:46 |
VanessaE |
wanna bet? :) |
| 04:46 |
* Sokomine |
takes picks away from players! :-) |
| 04:49 |
OldCoder |
Sokomine, the other world is online and very nice |
| 04:49 |
OldCoder |
See me in PM or other chanels |
| 04:49 |
OldCoder |
* channels |
| 06:18 |
|
nore joined #minetest-dev |
| 07:14 |
|
proller joined #minetest-dev |
| 08:11 |
|
darkrose joined #minetest-dev |
| 09:30 |
|
proller joined #minetest-dev |
| 09:49 |
nore |
I found a bug: inv:set_size("space crash", 1) for an inventory crashes the server |
| 09:49 |
nore |
with segfault |
| 09:49 |
nore |
(the problem is the space inside the list name) |
| 09:49 |
nore |
any thoughts on this? |
| 09:56 |
nore |
debug_log_level = 4 gives nothing more that the traditionnal: |
| 09:57 |
nore |
10:53:50: ACTION[ServerThread]: singleplayer places node test:crafting_table at (-19,6,23) |
| 09:57 |
nore |
10:53:50: ACTION[ServerThread]: facedir: 2 |
| 09:57 |
nore |
and after that, server crash with segfault |
| 09:57 |
nore |
so, does anyone knows where it comes from? |
| 10:10 |
nore |
ah, and another bug: a negative list size does _not_ crash the server immediately, but when it goes to saving the map, it uses 100% CPU power |
| 10:11 |
nore |
and it seems it uses a lot of RAM too since it was very hard to stop it and after having stopped it, there was still lag |
| 10:14 |
|
Jordach joined #minetest-dev |
| 10:14 |
|
iqualfragile joined #minetest-dev |
| 10:22 |
|
BlockMen joined #minetest-dev |
| 10:23 |
nore |
BlockMen, https://github.com/minetest/minetest/issues/996 |
| 10:24 |
nore |
^ what do you think should be done? |
| 10:31 |
BlockMen |
does it crash in singleplayer for you? |
| 10:32 |
nore |
yes |
| 10:32 |
nore |
the very moment I place the node, I got a segfault |
| 10:33 |
nore |
what OS do you use? it may not be the same as me... |
| 10:34 |
nore |
I guess I should write that in the issue too |
| 10:34 |
BlockMen |
thats strange...first times it worked for me, now it crashes with "bad allocation" |
| 10:34 |
BlockMen |
and win7 64bit |
| 10:34 |
nore |
for me it is Debian... I will write that |
| 10:35 |
BlockMen |
but i had not last git, so i will need to compile first and then test again |
| 10:36 |
nore |
I have found another bug too: a negative list size value will _not_ crash the server (I mean, when there is no space in the name), but at map save, the server eats 100% CPU and RAM |
| 10:36 |
nore |
it was very hard to stop it |
| 10:38 |
|
Jordach joined #minetest-dev |
| 10:40 |
BlockMen |
for me it throws also "bad allocation" but freezes then |
| 10:41 |
nore |
the negative stack count? |
| 10:42 |
nore |
does it freeze your computer? (I had a lot of difficulties to stop it the first time) |
| 10:43 |
nore |
the second time, I did something that killed minetest after 30 seconds (and it was enough to make it eat a lot of RAM) |
| 10:44 |
BlockMen |
yes, the negative list size. it freezes minetest and windows kills the task then |
| 10:44 |
nore |
I guess it is killed because it eats too much RAM or something like that |
| 10:45 |
BlockMen |
i dont think so because it freezes nearly instantly |
| 10:45 |
nore |
anyway, those two bugs need to be fixed (at least a better error message for the first one and a clean crash with error message for the second one) |
| 10:46 |
BlockMen |
yeah, will take a look at it later, need to do other things now |
| 10:46 |
BlockMen |
you made a report for the second one too? |
| 10:47 |
nore |
no, not yet |
| 10:47 |
BlockMen |
*on git |
| 10:47 |
nore |
will do that |
| 11:05 |
|
ImQ009 joined #minetest-dev |
| 11:14 |
|
Calinou joined #minetest-dev |
| 11:41 |
|
Jordach joined #minetest-dev |
| 11:53 |
|
Taoki joined #minetest-dev |
| 11:53 |
|
Jordach joined #minetest-dev |
| 11:59 |
|
Jordach joined #minetest-dev |
| 12:03 |
|
Taoki joined #minetest-dev |
| 12:12 |
|
Jordach joined #minetest-dev |
| 12:45 |
|
EvergreenTree joined #minetest-dev |
| 12:51 |
|
zat joined #minetest-dev |
| 13:02 |
|
jojoa1997 joined #minetest-dev |
| 13:27 |
|
hmmmm joined #minetest-dev |
| 13:54 |
nore |
hmmmm, what do you think of that: https://github.com/minetest/minetest/issues/996 https://github.com/minetest/minetest/issues/997 |
| 13:54 |
nore |
(what should be done?) |
| 14:33 |
|
salamanderrake joined #minetest-dev |
| 14:50 |
|
Ritchie joined #minetest-dev |
| 14:56 |
|
Zeitgeist_ joined #minetest-dev |
| 14:56 |
|
Zeitgeist_ joined #minetest-dev |
| 15:24 |
|
djdduty joined #minetest-dev |
| 15:33 |
|
RealBadAngel joined #minetest-dev |
| 15:43 |
celeron55 |
hmm, i have had this thing stubbornly floating in my head for enough time that i must do something to it |
| 15:43 |
OldCoder |
What thing? |
| 15:47 |
nore |
celeron55, what? |
| 15:50 |
celeron55 |
is anyone whose thoughts i generally tend to approve interested in attempting a from-scratch redesign of the minetest engine, privately with me, with the goal of getting a good understanding of what kind of approaches are possible, what their pros and cons are and how the development of each could possibly work in the future (and publishing the end result)? |
| 15:50 |
celeron55 |
i'm mostly pointing at kahrl, but i understand that kahrl is terribly busy |
| 15:51 |
nore |
I don't understand the engine nor C++ enough, and currently have almost no time, so it can't be me... |
| 15:52 |
nore |
but when you say from-scratch, that would change the whole API/etc too? |
| 15:52 |
Jordach |
celeron55, ask darkrose, she'd help |
| 15:52 |
celeron55 |
it's one of the many questions, and i don't want to start a discussion here because they almost always de-evolve into some kind of shouting competitions |
| 15:54 |
OldCoder |
Here? |
| 15:54 |
OldCoder |
This channel seems quiet |
| 15:55 |
OldCoder |
One thing, celeron55... would such a rewrite be completely backwards compatible? |
| 15:55 |
celeron55 |
it's one of the many questions |
| 15:55 |
OldCoder |
Yes; if it was *not* the project might fail |
| 15:55 |
celeron55 |
well that's one of the many questions too |
| 15:55 |
OldCoder |
People will wish their old worlds to continue |
| 15:55 |
|
jojoa1997 joined #minetest-dev |
| 15:55 |
kaeza |
or maybe not... |
| 15:55 |
OldCoder |
But, then, a rewrite will let folks learn from past mistakes |
| 15:56 |
celeron55 |
yes, one of the many questions! |
| 15:56 |
OldCoder |
Heh. Do not rush. But imagine the possibilities. I assume that it would still be C++ |
| 15:56 |
OldCoder |
Oh, well... Life is not perfect |
| 15:57 |
celeron55 |
there are like infinite possibilities but the question is whether any of them makes any sense |
| 15:57 |
OldCoder |
Perhaps you could design a new language with C as the back-end. The new language could be used to write the core engine. Possibly layers on top of mods as well. |
| 15:58 |
|
Akien joined #minetest-dev |
| 15:58 |
nore |
OldCoder, about the old world thing: it would not be very difficult (compared to the other things to do) to make a map converter... |
| 15:59 |
kaeza |
suddenly: Minetest written in Python 8) |
| 15:59 |
proller |
php ! |
| 16:00 |
celeron55 |
don't get hyped though; the end result likely is that nothing makes sense |
| 16:00 |
proller |
celeron55, also make it really threaded, for using all cores |
| 16:00 |
OldCoder |
nore If that was taken seriously, yes. But I am upgrading worlds right now inside of a consistent framework and everything breaks. Backwards compatibility requires thought. |
| 16:01 |
OldCoder |
Multi-Threaded. celeron55 there is an idea most will agree on. |
| 16:01 |
celeron55 |
proller: this kind of discussion is completely counterproductive; i wish people would just stick to the original question and some thoughtful person would volunteer |
| 16:02 |
OldCoder |
celeron55, You must allow people to dream and to joke if you wish buy-in to the concept |
| 16:02 |
OldCoder |
PHP is pushing it though :-) |
| 16:03 |
OldCoder |
celeron55, Besides this *is* productive... |
| 16:03 |
OldCoder |
You have identified backwards compatible and multi-threaded as concepts. And keep my "new language with C as back end" thought on the table; it might open up new possibilities. |
| 16:04 |
celeron55 |
i already had those in mind and the whoever i would like to thoroughly dig this through would too have had them in mind; it's bringing nothing to the table except hiding my request |
| 16:07 |
celeron55 |
(except that "new language" is nonsense) |
| 16:09 |
proller |
celeron55, can you define short goal? like "threads, physics, speed, ...." |
| 16:09 |
OldCoder |
As you wish, celeron55. Good luck. |
| 16:09 |
celeron55 |
proller: no, because that is the question |
| 16:10 |
proller |
+ sizeof(int) world size |
| 16:13 |
nore |
proller, that is not a good idea because it is architecture-dependent |
| 16:17 |
proller |
okay, 2^32 |
| 16:19 |
proller |
but it not very big problem make with current code |
| 16:24 |
OldCoder |
Why limit to 32 bits? |
| 16:24 |
|
Calinou joined #minetest-dev |
| 16:24 |
nore |
proller, there are problems (float precision, etc.) with Irrlicht when you go too far away |
| 16:24 |
VanessaE |
nore: that's more a problem with how minetest uses irrlicht I guess |
| 16:25 |
proller |
where problems started? if near 2^31 - it not a problem |
| 16:28 |
|
general3214 joined #minetest-dev |
| 16:29 |
general3214 |
Anyone online? |
| 16:30 |
VanessaE |
no. |
| 16:34 |
general3214 |
Oh okay |
| 16:34 |
general3214 |
I'll just not bother VanessaE since VanessaE is not online. |
| 16:34 |
VanessaE |
:P |
| 16:35 |
general3214 |
:D |
| 16:36 |
proller |
celeron55, and maybe something like ogre or... as renderer |
| 16:36 |
general3214 |
What's celeron like? |
| 16:37 |
general3214 |
Wait |
| 16:37 |
thexyz |
this is not the channel for offtopic |
| 16:37 |
general3214 |
Wrong channel |
| 16:37 |
thexyz |
please don't shitpost here |
| 16:37 |
general3214 |
omg these people so sensitive |
| 16:37 |
VanessaE |
general3214: this channel has a fairly strict subject limit. |
| 16:38 |
thexyz |
please stop |
| 16:38 |
general3214 |
I know. I ain't dumb |
| 16:38 |
general3214 |
general3214> Wrong channel |
| 16:42 |
Calinou |
<nore> proller, there are problems (float precision, etc.) with Irrlicht when you go too far away |
| 16:42 |
Calinou |
fix: move mesh around camera instead of moving camera around mesh |
| 16:42 |
Calinou |
(iirc) |
| 16:43 |
Calinou |
floating point precision errors always happe,n |
| 16:43 |
|
EvergreenTree joined #minetest-dev |
| 16:44 |
nore |
Calinou, how do you store object pos then? |
| 16:45 |
Calinou |
don't know that :P |
| 16:45 |
Calinou |
fix is very hard to do |
| 16:47 |
nore |
we would then need fixed point... (and rewrite a lot of things) |
| 17:02 |
|
sapier joined #minetest-dev |
| 17:04 |
general3214 |
Is this channel ONLY about core development, or development in general? |
| 17:04 |
thexyz |
read the topic |
| 17:05 |
general3214|AFK |
I take that as a yes |
| 17:05 |
thexyz |
and be aware that while I personally don't give a shit some people are easily irritated by afk nicknames and the most crazy ones can even kick you for that, I think |
| 17:06 |
|
OWNSyouAll joined #minetest-dev |
| 17:09 |
sapier |
can someone explain to my why recently everyone wants to start from scratch? |
| 17:09 |
thexyz |
read the log |
| 17:10 |
sapier |
I did that's why I ask |
| 17:10 |
thexyz |
it doesn't seem to me that everyone wants to |
| 17:10 |
thexyz |
people are just showing interest |
| 17:10 |
sapier |
is there any major issue that would be fixed by starting from scratch I missed by now |
| 17:11 |
thexyz |
it seems announcing it was not the best idea |
| 17:11 |
nore |
perhaps entity duplication (dunno though) |
| 17:11 |
ShadowNinja |
Speed, perhaps using a better graphics library, better network stack, etc. |
| 17:11 |
sapier |
entity mechanics could be rewritten without rewriting whole minetest ;-) |
| 17:12 |
sapier |
same for most other things ;-) |
| 17:12 |
sapier |
the only benefit a complete rewrite would have is "yes that feature will be added later" ;-) |
| 17:13 |
ShadowNinja |
Anyone have experience with SFML? I've also heard of using just plain OpenGL. |
| 17:14 |
sapier |
dropping irrlicht means rewriting/replacing whole gui too |
| 17:14 |
sapier |
both ingame as well as menu |
| 17:15 |
sapier |
and there is no guarantee our own engine will be faster or more portable than irrlicht my personal bet is it wont be |
| 17:15 |
nore |
on the other hand, there would be only one to rewrite now we have formspec menu... |
| 17:15 |
ShadowNinja |
Yes, and changing v3f and the like too. |
| 17:15 |
sapier |
I guess formspec will be dropped too |
| 17:16 |
sapier |
and our main problem won't be fixed ... lack of parallelism within main game engine core |
| 17:16 |
nore |
perhaps something good to do would be to change all v3s16 types to a POS type with a #define somewhere, so it can easily be changed in the future |
| 17:16 |
nore |
and float pos too, etc |
| 17:16 |
sapier |
it's not a matter of beeing good or not it's just a matter of time to be spent to fix it |
| 17:17 |
ShadowNinja |
nore: There are also constants used in places like position hashing. |
| 17:17 |
|
rubenwardy joined #minetest-dev |
| 17:17 |
sapier |
https://github.com/minetest/minetest/pull/971 what about this one I wont add things that ugly without clear permission of at least 2 core devs |
| 17:17 |
ShadowNinja |
32-bit positions would be wholy incompatible with 16-bit ones. |
| 17:18 |
nore |
ShadowNinja, there should be some world conversion probably then |
| 17:18 |
sapier |
we already have performance issues do you really think increasing complexity will do any better? |
| 17:18 |
ShadowNinja |
nore: Yes, it would probably be mostly runtime incompatabilities though. |
| 17:19 |
ShadowNinja |
sapier: No need for 32-bit positions now. Just discussing it. |
| 17:19 |
sapier |
is that bug already fixed segfault22 discovered? |
| 17:19 |
ShadowNinja |
As for #971 I echo what kwolekr said. |
| 17:20 |
nore |
that's why I suggest a #define POS_TYPE v3s16 ... |
| 17:20 |
nore |
sapier, what bug? |
| 17:20 |
ShadowNinja |
Or typedef. |
| 17:20 |
sapier |
echo what? |
| 17:20 |
nore |
ShadowNinja, what's typedef? |
| 17:21 |
ShadowNinja |
nore: It adds another name for a type, eg size_t is typedefed to something like unsigned int. |
| 17:21 |
sapier |
nore the crash with invalid list sizes |
| 17:23 |
sapier |
ShadowNinja as kwolekr didn't say yes or no what's your oppinion to 971 |
| 17:26 |
ShadowNinja |
sapier: It's awully ugly, and I would really rather have a better option. But if there is no other way... |
| 17:28 |
sapier |
YES or NO ... a maybe is useless ... I'm gonna continue repair my car now if noone has courage to decide by time I'm finished I wont ask again |
| 17:29 |
thexyz |
sapier: unrelated, why do you put /******************************************************************************/ everywhere? I don't remember seeing stuff like that in our code guidelines |
| 17:29 |
thexyz |
it's yes for sure |
| 17:29 |
thexyz |
too bad that's what happens with most of pulls |
| 17:29 |
thexyz |
people who didn't research the subject complain about stuff they contain and can't decide whether to merge it or not |
| 17:29 |
thexyz |
so people who did the research and made pull request eventually burn out |
| 17:30 |
proller |
i'm ready to join all my pulls in one |
| 17:30 |
proller |
now i cant make many things |
| 17:31 |
|
OWNSyouAll joined #minetest-dev |
| 17:31 |
thexyz |
proller: did you see https://github.com/minetest/minetest/pull/895#issuecomment-28129708 |
| 17:32 |
proller |
no problem with abm timers, they increase chance if some calls was missed |
| 17:33 |
proller |
but some every second on_step will be skipped |
| 17:34 |
proller |
but anyway it better than now in master |
| 17:42 |
|
Akien joined #minetest-dev |
| 17:44 |
proller |
idea: improve commiting rules: if pull waits more than [1-2] weeks and have no objections - every core dev can commit it (even pull creator) |
| 17:44 |
|
OWNSyouAll joined #minetest-dev |
| 17:44 |
proller |
no future in current state |
| 18:02 |
|
PilzAdam joined #minetest-dev |
| 18:14 |
|
OWNSyouAll joined #minetest-dev |
| 18:21 |
sapier |
proller not a good idea as any crap can be merged if just enough core devs didn't have time to review |
| 18:23 |
VanessaE |
sapier: to be fair, "just any crap" could be merged anyway, regardless of such a rule. |
| 18:26 |
sapier |
thexyz I added the /**/ because I regularly do this in all of my cpp files to have a chance to find functions ... there's no other function separator defined in coding style so /***/ is as good as any other. I still believe it's way more readyble but if this is the only reason for not merging it I'm gonna remove it |
| 18:27 |
thexyz |
it's not, it's just something I find strange |
| 18:27 |
thexyz |
the pull is OK |
| 18:27 |
sapier |
Ok let me be more precise VanessaE any crap might be merged even more easy ;-) |
| 18:28 |
sapier |
especially if there are many small functions code with /***/ in there is more readable ... at least to me |
| 18:28 |
VanessaE |
actually, there IS a defined separator, unofficially. |
| 18:28 |
PilzAdam |
nore, https://github.com/minetest/minetest/issues/996#issuecomment-28225332 |
| 18:28 |
VanessaE |
it's just that it isn't really written down and it's only been used in a few places - a line of ------- |
| 18:29 |
VanessaE |
(see some of the files in builtin) |
| 18:29 |
sapier |
that's MY separator too for lua code ;-) |
| 18:30 |
sapier |
/***/ variant is ancestor of ----- as comments are -- in lua :-) |
| 18:30 |
|
thexyz_ joined #minetest-dev |
| 18:30 |
sapier |
"best.gir.never.wins..." ?? :-) |
| 18:30 |
|
thexyz_ joined #minetest-dev |
| 18:32 |
sapier |
ok as I now have at least one clear yes vote for 971 I'm gonna count my own vote as second yes and merge in half an hour ... so last chance to veto |
| 18:32 |
PilzAdam |
celeron55, I am very interested in such a rewrite because it would give me the ability to understand the basic concepts of such and engine better |
| 18:32 |
sapier |
ShadowNinja did you merge your lua error handler fixes yet? |
| 18:33 |
PilzAdam |
celeron55, although I dont know if you would benefit from that |
| 18:33 |
sapier |
I suggest forking rewrite to minetest2 |
| 18:35 |
|
proller joined #minetest-dev |
| 18:35 |
|
troller joined #minetest-dev |
| 18:38 |
sapier |
another suggestion for speeding up merges what about assigning pull requests to core devs to review? method of assignment has to be defined. maybe most simple variant credit core devs with lines changed reviews |
| 18:43 |
sapier |
REQUESTING FEATURE FREEZE FOR 0.4.8 RELEASE at end of November anyone agree? |
| 18:44 |
* sfan5 |
agree |
| 18:44 |
sfan5 |
s |
| 18:45 |
sapier |
maybe we could create a integration branch to not stall development while freeze is active |
| 18:46 |
sfan5 |
wouldn't that be messy? |
| 18:46 |
sapier |
no merges during feature freeze should be minor bugfixes onla |
| 18:46 |
sapier |
only |
| 18:47 |
troller |
sapier, something like dev branch - https://forum.minetest.net/viewtopic.php?id=7033 |
| 18:47 |
sapier |
similar yes but with same merge rules as current master |
| 18:48 |
|
Akien joined #minetest-dev |
| 18:49 |
sapier |
I'm not talking about a permanent thing only while feature freeze is active once release is done this branch should be merged to master ... this way we could review merges for next version and don't have to check again after 0.4.8 release |
| 18:49 |
troller |
current rules like for atomic station software |
| 18:49 |
troller |
and result is frozen development |
| 18:50 |
sapier |
imho we'd need a stable as well as development branch ... but that's another issue |
| 18:53 |
PilzAdam |
we have a stable branch |
| 18:53 |
VanessaE |
sapier: agreed, with the proviso that the release be delayed beyond the end of November if some bugs just can't be fixed in time. |
| 18:53 |
sapier |
we do? when was it used last time? |
| 18:54 |
celeron55 |
it has been updated on each release |
| 18:54 |
PilzAdam |
https://github.com/minetest/minetest/tree/stable-0.4 |
| 18:54 |
PilzAdam |
master is our dev branch |
| 18:54 |
sapier |
of course VanessaE End of november would be only "target date" |
| 18:55 |
sapier |
wow didn't even know about that one this is 0.4.7 not 0.4.0? |
| 19:17 |
BlockMen |
i noticed a problem with lvm. after doing a few more calculations i get an "not enough memory" error, even by letting grow a lot saplings. http://pastebin.com/FFVcFyjV |
| 19:17 |
BlockMen |
is there a problem with not released memory? |
| 19:18 |
sapier |
did you check memory usage on your system? asking to be sure it's a out of memory not some "in lua" limitation |
| 19:23 |
sapier |
ok pushing i18n pull request now |
| 19:24 |
sapier |
plz test it I checked linux mingw32 and vs2012 32 bit only hope this is enough |
| 19:27 |
BlockMen |
its stable around ~330mb (minetest) until it uses lvm. then it increases more and more until mem usage 80%+ |
| 19:27 |
sapier |
what are you doing in there? |
| 19:28 |
PilzAdam |
sapier, "/home/adam/Minetest/minetest/src/guiChatConsole.cpp:560:78: warning: ignoring return value of 'int mbtowc(wchar_t*, const char*, size_t)', declared with attribute warn_unused_result [-Wunused-result]" IIRC this was there before your patch too? |
| 19:28 |
BlockMen |
growing 200 saplings |
| 19:29 |
sapier |
I don't remember changeing anything in chatconsole |
| 19:30 |
sapier |
nope changed almost all other gui files but not this one ;-) |
| 19:30 |
PilzAdam |
this seems to be the last warning left (for gcc, that is) |
| 19:31 |
sapier |
sadly I didn't see it I'd have fixed it |
| 19:31 |
sapier |
fixed some other warnings within that patch too |
| 19:34 |
sapier |
is saplings using l-tree? |
| 19:35 |
nore |
sapier, no |
| 19:36 |
sapier |
strange would be more likely to eat up all memory on recursive algorithms |
| 19:37 |
nore |
the strange thing is that I have already used LVM for quite intensive tasks (i.e., reading ~100 4x150x4 areas every 2 seconds) |
| 19:37 |
nore |
and I never had this problem (except when I tried to read a 240x150x140 area) |
| 19:38 |
sapier |
maybe it's a special function triggering the bug, blockmen can you provide code to trigger it? |
| 19:38 |
sapier |
lol I'd not consider that a problem nore just buy a bigger machine if you want to do things like that |
| 19:39 |
nore |
I don't consider it a problem either... anyway, that was badly-written code, I optimized it much after... |
| 19:40 |
nore |
gtg |
| 19:40 |
BlockMen |
sapier, i uses the code from default, so https://github.com/minetest/minetest_game/blob/master/mods/default/functions.lua#L138 |
| 19:41 |
BlockMen |
but i also noticed when using my mines mods, etc. everything that uses lvm and used for a lot of operations/time |
| 19:41 |
sapier |
yes but how do you grow 200 saplings? :-) manually? |
| 19:41 |
BlockMen |
ya, sure. 200 is plant fast (<2min) ;P |
| 19:41 |
BlockMen |
s/plant/plated |
| 19:42 |
sapier |
lol ... I'm gonna try once ;-) |
| 19:43 |
BlockMen |
even if it wont crash...the mem usage increases from ~330mb to ~1,5gb just because of lvm |
| 19:47 |
sapier |
maybe a garbage collection issue? |
| 19:49 |
sapier |
I just planted 250 saplings no noticable memory increase |
| 19:54 |
BlockMen |
well, if it just happen for me then we have no problem :) |
| 19:55 |
sapier |
we have a problem we just need more information and as you're the only one to notice by now it's up to you to find out how to reproduce ;-) |
| 20:00 |
sapier |
https://github.com/minetest/minetest/pull/993 any comment? |
| 20:01 |
PilzAdam |
valgrind anyone? |
| 20:02 |
PilzAdam |
(re that sapling problem) |
| 20:03 |
sapier |
I can't reproduce so blockmen has to do |
| 20:03 |
troller |
sapier, copypaste 8( |
| 20:04 |
sapier |
copypaste? |
| 20:06 |
thexyz |
copypasta indeed |
| 20:07 |
thexyz |
sapier: he's complaining about some blocks of code looking too similar |
| 20:07 |
thexyz |
like, they're exactly same |
| 20:08 |
sapier |
it's json parser what do you expect? |
| 20:08 |
sapier |
yet that's already in master as well as the bugs ;-) |
| 20:09 |
thexyz |
I'd expect maybe a function to which you pass the string? |
| 20:09 |
thexyz |
and this is exactly what happens when you copypasta |
| 20:09 |
thexyz |
you have to fix bugs in multiple places |
| 20:09 |
thexyz |
but meh, I guess you know all of that |
| 20:10 |
sapier |
I do yet someone said to create a better json parser |
| 20:10 |
sapier |
if I remember correctly it was proller |
| 20:11 |
troller |
yes, but... ;) |
| 20:12 |
sapier |
but what? *g* |
| 20:12 |
sapier |
*g* --> :-) |
| 20:12 |
|
werwerwer_ joined #minetest-dev |
| 20:13 |
troller |
in my queue was more important (for me) things |
| 20:14 |
sapier |
I won't write it either so we'll have to stick with current suboptimal version |
| 20:25 |
|
general3214 joined #minetest-dev |
| 20:30 |
|
Miner_48er joined #minetest-dev |
| 20:35 |
|
Akien joined #minetest-dev |
| 20:38 |
|
werwerwer joined #minetest-dev |
| 20:41 |
|
NakedFury joined #minetest-dev |
| 20:52 |
|
bas080 joined #minetest-dev |
| 21:28 |
|
Akien_ joined #minetest-dev |
| 22:06 |
|
zork_ joined #minetest-dev |
| 22:09 |
hmmmm |
celeron, a from-the-ground approach is not a very good one |
| 22:11 |
hmmmm |
the codebase we have today is not just a huge block of code, it's days, weeks, months, and years of labor and knowledge gained |
| 22:11 |
hmmmm |
you say you want to use the knowledge gained from minetest to make the right decisions a second time, but how do you know you're not going to make more bad decisions on other parts? |
| 22:12 |
hmmmm |
also what if much of the knowledge gained only pertains to designs only made because of some root design choices |
| 22:13 |
sapier |
https://github.com/minetest/minetest/pull/993 hmmmm do you agree to this one? |
| 22:13 |
hmmmm |
if you go with something fundamentally different, say for example, executing things on events instead of polling a queue every step, what you have learned might not be very helpful at all |
| 22:14 |
hmmmm |
and then there are things like the modding api that really are decent for what it is and we can't do much better due to the nature of scripting |
| 22:15 |
hmmmm |
don't really understand the point of changing *clients_raw != 0 to clients_raw != "" when you kept the thing to the right of it |
| 22:15 |
sapier |
asString() creates a temporary object |
| 22:15 |
sapier |
thus storing a pointer to a temporary object is quite dangerous ;-) |
| 22:16 |
hmmmm |
oh oh nevermind, you changed that from c_str() |
| 22:16 |
hmmmm |
makes sense |
| 22:16 |
hmmmm |
yeah, what you did looks fine |
| 22:16 |
sapier |
yes done it at other place recently didn't know it's hidden here too |
| 22:16 |
hmmmm |
yes, can't you push things on your own anymore? |
| 22:16 |
sapier |
I can yet I need agreement ;-) |
| 22:17 |
hmmmm |
not so much for a bugfix that you know is going to solve the problem |
| 22:17 |
sapier |
I'm still the new one so I stick to the rules ;-) |
| 22:17 |
hmmmm |
more controversial things like restarting the process under a different locale, that could take agreement I'd say |
| 22:18 |
sapier |
actually I didn't merge it without agreement |
| 22:18 |
hmmmm |
i know you didn't, I was just using that as an example of something that anybody would need a consensus on to merge |
| 22:18 |
sapier |
btw it's only done for silly msvc build ... I strongly discourage building mt with it |
| 22:18 |
hmmmm |
whereas a memory leak fix like above is fine |
| 22:19 |
sapier |
it's more a possible access violation ... most likely it wont cause any harm but the other ones did cause harm on windows |
| 22:20 |
hmmmm |
oh, access violation? hmr |
| 22:20 |
sapier |
actually it's more likely you read crap |
| 22:21 |
hmmmm |
oh, sorry |
| 22:21 |
hmmmm |
I'm not paying enough attention to what I'm reading |
| 22:21 |
sapier |
that pointer is just random space ... ok not exactly random as it's data most likely is still there, but it may have already been reused |
| 22:21 |
hmmmm |
just got back from a day of work |
| 22:22 |
sapier |
oh I see :-) btw I do think same at rewrite thematic ... partial rewrite of components yes but not a complete rewrite |
| 22:22 |
sapier |
and partial can be done within normal development (if there's someone who really cares to do) |
| 22:22 |
hmmmm |
right |
| 22:23 |
hmmmm |
I'd rather work on specific things that need work rather than the clean slate rewrite, e.g. formspec and mainmenu |
| 22:23 |
sapier |
what about the real issues? map/environment locking? *smile* |
| 22:23 |
hmmmm |
right |
| 22:23 |
hmmmm |
we need to really work on that |
| 22:24 |
sapier |
formspec and mainmenu may be suboptimal but missing map/environment locking stops any attempts to gain performance by parallelization |
| 22:25 |
troller |
and dont save not changed new blocks |
| 22:25 |
sapier |
pushing temp object fixes now |
| 22:25 |
troller |
my map 2.6G already 8( |
| 22:25 |
hmmmm |
troller, that would screw up minetestmapper |
| 22:25 |
troller |
minetestmapper dont work on my map too ;) |
| 22:26 |
troller |
then make it adjustable |
| 22:27 |
sapier |
https://github.com/minetest/minetest/issues/997 I consider this to be a blocker issue for 0.4.8 what do you think? |
| 23:04 |
sapier |
https://github.com/minetest/minetest/pull/998 should fix 996 as well as 997 |
| 23:09 |
ShadowNinja |
Actually the mapper thing isn't that important because you usually don't need to see what is in unmodified blocks. |
| 23:10 |
sapier |
ahh Shadow :-) what about your lua errorhandler fixes? |
| 23:14 |
ShadowNinja |
sapier: I don't have agreement for them yet. And there is a small issue that I tried to fix locally... |
| 23:15 |
sapier |
what issue? |
| 23:15 |
ShadowNinja |
sapier: 'throw LuaError("Something")' from a API function causes "ServerError: LuaError: C++ exception." I think LuaJIT is at fault for this. |
| 23:16 |
ShadowNinja |
And Regular LuaError's din't have a traceback anymore. (I added that locally) |
| 23:16 |
ShadowNinja |
s/R/r/ |
| 23:16 |
ShadowNinja |
don't* |
| 23:17 |
ShadowNinja |
I don't know how to compile with non-JIT Lua though... |
| 23:17 |
sapier |
ok they should have tracebacks for sure |
| 23:17 |
sapier |
didn't we have issues with exceptions within lua called functions before? |
| 23:17 |
ShadowNinja |
Put adding the traceback is pointless when you just get "C++ exception" |
| 23:17 |
ShadowNinja |
Yes. |
| 23:17 |
sapier |
of course |
| 23:18 |
sapier |
worst thing is enclosing all lua functions within try catch .... quite a lot of work and no guarantee to work |
| 23:23 |
ShadowNinja |
sapier: This is what I have locally, does it look good? https://gist.github.com/ShadowNinja/7422436 |
| 23:26 |
|
Mallot1 joined #minetest-dev |
| 23:27 |
sapier |
sorry to late to review today I recommend updating your pull request if you think it's better than the current one. |
| 23:27 |
|
sapier left #minetest-dev |
| 23:31 |
|
Taoki joined #minetest-dev |
| 23:46 |
|
zat1 joined #minetest-dev |
