| Time |
Nick |
Message |
| 00:00 |
VanessaE |
well just saying, ncurses can behave weirdly under screen :) |
| 00:08 |
|
zat joined #minetest-dev |
| 00:10 |
luizrpgluiz |
I hope you have approval because it would be too bad if you have not ncurses :9 |
| 00:10 |
luizrpgluiz |
:( |
| 00:11 |
JohnnyComeL8ly |
Yeah. |
| 00:11 |
|
zat joined #minetest-dev |
| 00:18 |
luizrpgluiz |
est made a good upgrade to minetest, hope it can work very well on Linux and Windows |
| 00:20 |
hmmmm |
PilzAdam: can't you just use 1 for number of emerge threads? |
| 00:21 |
hmmmm |
I realize there is a bit more serverthread lag this way but it's unavoidable |
| 00:21 |
hmmmm |
this isn't fixable until the entire game's locking is changed |
| 00:22 |
|
Miner_48er joined #minetest-dev |
| 00:34 |
|
Supertanker2 joined #minetest-dev |
| 01:05 |
est |
okay ShadowNinja updated my pr to address your remarks |
| 01:24 |
|
luizrpgluiz left #minetest-dev |
| 01:27 |
|
paramat joined #minetest-dev |
| 01:29 |
paramat |
will merge game#681 game#600 soon |
| 01:29 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/681 -- Fire: Add 'permanent flame' node by paramat |
| 01:29 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/600 -- Remove unused TNT & torch textures by CraigyDavi |
| 01:53 |
|
Taoki_1 joined #minetest-dev |
| 01:53 |
est |
dangit, I had enough of colorless gcc errors |
| 01:54 |
est |
I update after I've finished my commit |
| 01:54 |
hmmmm |
est, what's your opinion on the "none" logging level? |
| 01:54 |
hmmmm |
do you think that's an okay name or would you rather it changed? |
| 01:55 |
est |
irrlicht has the same, its ok for me. |
| 01:55 |
hmmmm |
right now to the developer's perspective it doesn't make sense (whereas it would to the end user because the meaning is inverted for debug_log_levels) |
| 02:05 |
hmmmm |
can I push this already? https://github.com/kwolekr/minetest/commit/c56d7fe0eba7905b0a63c4a1cfe909988653c23d |
| 02:06 |
hmmmm |
I added a usage comment as requested |
| 02:06 |
est |
LGTM |
| 02:07 |
JohnnyComeL8ly |
What does that mean? |
| 02:15 |
JohnnyComeL8ly |
I had a brain fart and I looked it up.. sorry I bothered. :-} |
| 02:15 |
JohnnyComeL8ly |
*and so I looked it up.... |
| 02:28 |
hmmmm |
https://github.com/kwolekr/minetest/commit/688556a5d1910ead2cf06a87af6908110fa9d035 PTAL |
| 02:29 |
est |
well, shrug, okay for me. |
| 02:31 |
|
Lunatrius joined #minetest-dev |
| 03:06 |
paramat |
now merging game 681 game 600 |
| 03:10 |
paramat |
done |
| 03:28 |
est |
hmmmm, somehow casting doesn't work for me |
| 03:28 |
hmmmm |
?? |
| 03:28 |
est |
this commit breaks https://github.com/est31/minetest/commit/d3bcc02558117cab2ba09873dfde9012eebaa9e7 |
| 03:28 |
est |
it creates a crash if you try to chat |
| 03:29 |
est |
and the backtrace includes handleAdminChat |
| 03:30 |
hmmmm |
oh |
| 03:30 |
est |
right in std::string name = evt.nick; |
| 03:30 |
hmmmm |
that's because you're downcasting ChatEventChat/ChatEventNick/etc. to a ChatEvent |
| 03:30 |
hmmmm |
when you push it to the queue |
| 03:30 |
hmmmm |
aren't you getting any kind of warning for that? |
| 03:31 |
est |
I don't think so |
| 03:31 |
hmmmm |
C++ isn't Java or C# - you cannot do what you are doing there |
| 03:31 |
hmmmm |
you need to make it a pointer instead |
| 03:33 |
est |
well, in Java everything is a pointer, no? |
| 03:34 |
hmmmm |
MutexedQueue<ChatEvent *> command_queue; ... |
| 03:34 |
hmmmm |
command_queue.push_back(new ChatEventChat(blah, bla, blah)); |
| 03:34 |
est |
will try |
| 03:34 |
est |
and delete when emptying the queue |
| 03:34 |
hmmmm |
but then that means you need to manage memory |
| 03:35 |
est |
and that it lives on the bad bad heap |
| 03:35 |
hmmmm |
whether or not that's better than simply having all possible fields is up to you |
| 03:35 |
hmmmm |
well ermm |
| 03:35 |
hmmmm |
it is already on the heap lol |
| 03:36 |
hmmmm |
for what it's worth, it might not be that bad to have all the different parameters in the same struct |
| 03:36 |
hmmmm |
a std::string on my platform is only 40 bytes |
| 03:36 |
hmmmm |
and i don't think it allocates memory unless you actually set it to a non-blank string |
| 03:37 |
hmmmm |
the other obvious suggestion, to use a heap, isn't doable here since you have std::string and std::wstring which are non-POD types |
| 03:37 |
hmmmm |
errm |
| 03:37 |
hmmmm |
to use a union* is what I meant to say |
| 03:54 |
|
OldCoder joined #minetest-dev |
| 04:09 |
|
OldCoder joined #minetest-dev |
| 04:23 |
|
OldCoder joined #minetest-dev |
| 04:50 |
|
paramat left #minetest-dev |
| 05:10 |
est |
okay it works now |
| 05:31 |
|
est31 joined #minetest-dev |
| 05:36 |
est31 |
okay hmmmm updated #3292, it should address most of your points, |
| 05:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/3292 -- Add server side ncurses terminal by est31 |
| 05:36 |
est31 |
almost all of them |
| 05:38 |
hmmmm |
unrelated question |
| 05:38 |
hmmmm |
why is settingtypes.txt in builtin? |
| 05:39 |
hmmmm |
also, do I need to update this from now on instead of minetest.conf.example or vice versa? |
| 05:39 |
est31 |
update settingstypes.txt |
| 05:39 |
est31 |
and ask pilzadam to update .conf.example |
| 05:39 |
hmmmm |
ugh |
| 05:39 |
est31 |
its automated |
| 05:39 |
hmmmm |
isn't there some kind of python utility to do this |
| 05:39 |
hmmmm |
there should be |
| 05:39 |
est31 |
no python is ugly |
| 05:40 |
est31 |
there is a lua utility though :) |
| 05:40 |
hmmmm |
err yeah |
| 05:40 |
hmmmm |
lua :) okay |
| 05:40 |
hmmmm |
is it a part of util/? |
| 05:40 |
hmmmm |
annnd the answer is no |
| 05:41 |
est31 |
its in the mainmenu file that handles the setting tab |
| 05:41 |
hmmmm |
we need to get PilzAdam to commit the update script |
| 05:41 |
est31 |
a method |
| 05:41 |
hmmmm |
why... |
| 05:41 |
hmmmm |
ugh |
| 05:41 |
est31 |
well, I guess it has all the parsing |
| 05:41 |
hmmmm |
well whatever |
| 05:42 |
hmmmm |
so let me understand the behavior of getch() |
| 05:42 |
hmmmm |
this blocks for 100 milliseconds, if there is no input available in the buffer |
| 05:42 |
hmmmm |
if there is, it'd get the next char and return it immediately |
| 05:42 |
est31 |
correct |
| 05:42 |
hmmmm |
so it's like poll() i guess |
| 05:42 |
est31 |
idk about poll |
| 05:42 |
hmmmm |
alright, sure, I guess that's fine then |
| 05:43 |
est31 |
but I have confirmed both by behaviour |
| 05:43 |
hmmmm |
lol init_of_curses |
| 05:43 |
hmmmm |
void init_of_curses() { |
| 05:44 |
est31 |
heh |
| 05:44 |
hmmmm |
for (size_t i = 0; i != ARRLEN(list_of_curses); i++) m_curses.push_back(list_of_curses[i]); |
| 05:44 |
hmmmm |
const char *list_of_curses[] = {"FUCK", "SHIT", "PISS", "ASS", "AHHHHHHHHH DAMMIT"} |
| 05:45 |
hmmmm |
and then write a gdb plugin |
| 05:45 |
hmmmm |
on segfault print m_curses[myrand(0, m_curses.size() - 1)] |
| 05:45 |
est31 |
lol |
| 05:46 |
hmmmm |
"IT'S TIME TO START DROPPIN' SOME F-BOMBS!" |
| 05:47 |
hmmmm |
https://www.youtube.com/watch?v=Ol89jfwoPBY |
| 05:48 |
est31 |
dont say fuck too fast or bombs spawn too close and explode right in your face when they collide |
| 06:11 |
|
OldCoder joined #minetest-dev |
| 06:13 |
celeron55 |
umm... here's an email i got: "I have recently come across a strange problem of which i don't know if its just me or if its a bug. When I make a new world and I want it flat, I create the world and go into the map_meta.txt and get rid of all the flags except light and noflat and change noflat to flat. When I load the world, it generates as if i never changed anything but occasionally it will generate flat but with trees and caves (of ... |
| 06:13 |
celeron55 |
... which I supposedly disabled). I have tried doing it in different ways such as loading the world only partially and closing the window before it loads (at 'initializing nodes...') and then changing the map gen but or loading it all the way and doing it (neither of which work). At first i thought that it was the moretrees mod I have but I disabled all the mods and it still did this. Either I'm doing something wrong or this is a ... |
| 06:13 |
celeron55 |
... bug. If there is something else I need to do or something different, please tell me what that is." |
| 06:13 |
celeron55 |
is this PEBCAK? |
| 06:13 |
hmmmm |
yes |
| 06:13 |
celeron55 |
good |
| 06:14 |
celeron55 |
i'm too lazy to answer it then |
| 06:14 |
hmmmm |
this guy should not be modifying map_meta.txt directly anyway |
| 06:14 |
celeron55 |
does there exist a guide anywhere for how those flags are actually supposed to be used? |
| 06:16 |
celeron55 |
i guess this http://wiki.minetest.net/Map_generator/settings |
| 06:18 |
|
OldCoder joined #minetest-dev |
| 06:18 |
|
OldCoder joined #minetest-dev |
| 06:25 |
hmmmm |
hmm |
| 06:26 |
hmmmm |
I don't think I ever did write any official documentation on mapgen parameters in general because I consider them advanced options that you'd really have to understand the algorithm used to generate map to do anything useful with them |
| 06:26 |
hmmmm |
obviously this isn't the case with the simpler things like flat, caves, trees, etc. features |
| 06:27 |
hmmmm |
it's almost the year 2016 and there STILL is no actual "flat" mapgen |
| 06:27 |
hmmmm |
i should remove flat as a flag and make it into its own mapgen perhaps |
| 06:38 |
|
Hunterz joined #minetest-dev |
| 06:43 |
est31 |
okay, fixed a regression and added a note |
| 06:43 |
|
julienrat joined #minetest-dev |
| 06:44 |
|
julienrat left #minetest-dev |
| 06:51 |
est31 |
hmmmm, anything to be done on the ncurses pr before merging? Or do you want to have a look at it first |
| 06:52 |
hmmmm |
uhh looking |
| 06:52 |
hmmmm |
what was the regression btw? |
| 06:52 |
est31 |
I have renamed the variable as you asked and as its meaning was negated I have negated it everywhere but one place |
| 06:52 |
est31 |
so the fix was to negate it there too |
| 06:53 |
hmmmm |
oh |
| 06:54 |
hmmmm |
answer_to_sender needs to be a pointer... |
| 06:54 |
hmmmm |
see the rule about non-const reference parameters |
| 06:54 |
est31 |
whats the point about it |
| 06:54 |
hmmmm |
we went over all this already |
| 06:55 |
hmmmm |
the syntax for a parameter being modified vs. constant is ambiguous |
| 06:55 |
est31 |
it isnt ambiguous |
| 06:55 |
est31 |
if its constant you pass constant reference |
| 06:56 |
hmmmm |
this is already a coding rule |
| 06:56 |
|
OldCoder joined #minetest-dev |
| 06:56 |
est31 |
well its point is that you shouldn't avoid writing const if you can |
| 06:57 |
est31 |
its not to force people to use pointers |
| 06:57 |
hmmmm |
read this: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Reference_Arguments |
| 07:01 |
est31 |
so the only thing that isn't "at google we do it and we are smarter than you" or actually lists an advantage of using references is a single sentence |
| 07:01 |
est31 |
"References can be confusing, as they have value syntax but pointer semantics." |
| 07:02 |
hmmmm |
so your own argument is that "I just decided I don't like this rule, I'm not gonna do it" |
| 07:02 |
est31 |
no it has a point |
| 07:02 |
hmmmm |
the point for the rule is that it's a convention |
| 07:02 |
est31 |
passing non const references as input values is dumb |
| 07:02 |
hmmmm |
the convention is, const ref parameters for inputs, non-const pointers for outputs |
| 07:02 |
est31 |
hmmmm, you often ignore rules yourself, and when I ask you you ignore me. |
| 07:03 |
est31 |
or you change the rule |
| 07:03 |
hmmmm |
like where |
| 07:03 |
est31 |
for example the line limit one |
| 07:03 |
est31 |
I asked you please make the line shorter its too long |
| 07:03 |
hmmmm |
which one |
| 07:03 |
est31 |
you just adjusted the rule to take 4 tabs |
| 07:03 |
est31 |
dont know anymore, look at the logs |
| 07:03 |
hmmmm |
I don't remember anything like that.. |
| 07:04 |
hmmmm |
the rule isn't a hard requirement |
| 07:04 |
est31 |
well this one is neither |
| 07:04 |
hmmmm |
sigh..... |
| 07:04 |
est31 |
there is no point, it would just need additional code |
| 07:06 |
est31 |
I still dont get why references aren't banned completely |
| 07:06 |
est31 |
I mean the argument applies to every use of non-const references |
| 07:08 |
hmmmm |
if I have a std::string parameter and a const std::string & parameter, both of them have the same semantics to the caller |
| 07:09 |
hmmmm |
you have a strong guarantee that the string you pass along is not going to be modified, because it's impossible in fact |
| 07:09 |
hmmmm |
so when I have: std::string foobar, and I pass it along to a function like do_thing(foobar, blah blah ... ); I know that, reference or not, foobar isn't going to change somehow |
| 07:09 |
hmmmm |
however if I type &foobar, hmmm |
| 07:10 |
est31 |
well you can cast it to const pointers everywhere |
| 07:10 |
est31 |
err const references |
| 07:10 |
hmmmm |
huh? I'm not following |
| 07:12 |
est31 |
do_thing((const std::string &)do_not_change_string,change_this_string) |
| 07:12 |
est31 |
and this way its more secure |
| 07:12 |
hmmmm |
why would you do that... |
| 07:12 |
hmmmm |
that's ridiculous |
| 07:13 |
hmmmm |
whenever you actually want to modify a parameter, it's being used as an output, a second return value |
| 07:13 |
hmmmm |
this is the exceptional case |
| 07:13 |
hmmmm |
it's much more common that the parameter being passed won't be modified |
| 07:14 |
est31 |
well okay you convinced me |
| 07:14 |
est31 |
I'll remove the non const reference |
| 07:14 |
hmmmm |
again, look at this from a detached point of view, not your own |
| 07:14 |
hmmmm |
pretend you've never seen this code before |
| 07:14 |
hmmmm |
you have this function you want to use, and you pass these two strings along to it |
| 07:15 |
hmmmm |
all of a sudden one gets modified because you didn't inspect every single side effect of every single function you use first |
| 07:15 |
hmmmm |
and your code now has possibly a subtle bug in it |
| 07:15 |
hmmmm |
bool foobar(const std::string &foobar, std::string &foobaz) is downright dangerous I'd argue |
| 07:17 |
hmmmm |
for what it's worth, I did not just decide on this rule. I proposed it and Zeno` along with a couple others (can't remember) strongly agreed |
| 07:19 |
est31 |
I've removed it see last commit on the branch |
| 07:21 |
hmmmm |
ermm wtf |
| 07:23 |
hmmmm |
you realize you completely broke it right? |
| 07:23 |
est31 |
yea Im fixing |
| 07:26 |
est31 |
pushed fixes |
| 07:26 |
hmmmm |
wtf |
| 07:26 |
hmmmm |
come on stop screwing around with me |
| 07:29 |
est31 |
I know, the GNU people wouldn#t like me returning other stuff than an int |
| 07:29 |
est31 |
but why return a bool and have a pointer in the params, that is only written to if the return value is true? |
| 07:30 |
hmmmm |
because you're leaking memory |
| 07:30 |
hmmmm |
rather blatantly |
| 07:30 |
est31 |
how |
| 07:30 |
est31 |
I do delete it in any case |
| 07:30 |
hmmmm |
where? |
| 07:30 |
est31 |
right after the if |
| 07:30 |
est31 |
I could move it in if you want |
| 07:31 |
est31 |
there is no benefit in delete NULL |
| 07:31 |
hmmmm |
oh I see |
| 07:31 |
hmmmm |
so do you really want to have the ability to send blank lines? just curious |
| 07:34 |
est31 |
I'll make it return a string |
| 07:37 |
est31 |
okay pushed |
| 07:37 |
hmmmm |
great |
| 07:38 |
est31 |
In fact we never would have returned an empty string |
| 07:39 |
est31 |
if the string from the script hook were empty, we'd have returned NULL |
| 07:39 |
hmmmm |
one more thing |
| 07:39 |
hmmmm |
if the console thread throws an exception, the logging outputs won't get readded |
| 07:40 |
hmmmm |
so the error output would never be seen |
| 07:41 |
est31 |
no finally :( |
| 07:42 |
hmmmm |
i think you should add a finally for that macro and put it there |
| 07:42 |
hmmmm |
but not in this same commit |
| 07:45 |
hmmmm |
now what about the macro parameters with no parentheses? |
| 07:46 |
est31 |
what about https://github.com/minetest/minetest/commit/f2c45dd142020f56f71252ddea06880c802cb83d |
| 07:47 |
est31 |
ah you mean parentheses internally, not externally |
| 07:50 |
hmmmm |
yes, that's kind of important... |
| 07:50 |
hmmmm |
consider what would happen if somebody decided to use your macro and they did: |
| 07:51 |
hmmmm |
IS_ASCII_PRINTABLE_CHAR(some_condition ? 'a' : '~'); |
| 07:51 |
est31 |
yeah |
| 07:52 |
est31 |
first I had them then I removed them again because zeno would appear and complain about too many parentheses |
| 07:52 |
hmmmm |
no, parentheses all the time for macro parameters, you don't screw around with macros.. |
| 08:01 |
hmmmm |
you need to return L"" |
| 08:05 |
|
Darcidride joined #minetest-dev |
| 08:06 |
hmmmm |
okay, looks good to me. |
| 08:12 |
est31 |
okay, build fixed |
| 08:13 |
est31 |
hmmmm, is this method to achieve what you asked ok, or should I somehow move the class declaration, e.g. into the header or so? https://github.com/minetest/minetest/pull/3292/files#diff-42a115173bd1d0c211ba295a43271207R89 |
| 08:13 |
hmmmm |
ewww.... |
| 08:14 |
hmmmm |
do you have to declare it right in the function? |
| 08:14 |
hmmmm |
that does work though, yes. |
| 08:16 |
|
nrzkt joined #minetest-dev |
| 08:21 |
est31 |
okay moved it to header |
| 08:24 |
hmmmm |
LGTM +1 |
| 08:24 |
est31 |
nice, thanks! |
| 08:24 |
est31 |
do you think it can be merged? |
| 08:24 |
hmmmm |
wait hold on, this is pretty big, do you have anybody else who wants to take a look at it? |
| 08:25 |
est31 |
well, blockmen has +1ed it, but he has made no comments on the implementation, so I don't think he has really audited the code. |
| 08:26 |
hmmmm |
yeah... a very large part of a code review is to look for errors and bad implementations |
| 08:26 |
hmmmm |
i'm sure if we asked everybody here they'd universally agree that a server console is a good idea |
| 08:27 |
hmmmm |
so a +1 based on the feature concept alone is pretty useless |
| 08:27 |
hmmmm |
I bet I missed some actual bugs here so it's really a good idea to have somebody else take a real look at it too |
| 08:28 |
est31 |
yeah. |
| 08:43 |
nrzkt |
est31 let me looking for it |
| 08:46 |
est31 |
ok |
| 08:46 |
|
CraigyDavi joined #minetest-dev |
| 08:50 |
nrzkt |
some first comments added |
| 08:50 |
|
julienrat joined #minetest-dev |
| 08:50 |
|
julienrat left #minetest-dev |
| 08:51 |
est31 |
does really everything have to be const? |
| 08:51 |
est31 |
I add alot of methods, if they all got const that would be a lot of work |
| 08:53 |
nrzkt |
i looked at many methods and i note those things to be const, no method needs to be const because you modify class content in every method if i have correctly read |
| 08:53 |
nrzkt |
i juste noticed some arguments should be const because this is their essence to be const. |
| 08:53 |
nrzkt |
just* |
| 08:54 |
est31 |
yea I mean that |
| 08:54 |
est31 |
I add a large number of methods |
| 08:54 |
est31 |
or touch their aruments |
| 08:55 |
est31 |
if I made them all const, it would mean a lot of work |
| 08:55 |
nrzkt |
there are not many things to change :) and if you use a good IDE it's very fast to change this :) |
| 08:55 |
nrzkt |
you don't need to make anything const |
| 08:55 |
nrzkt |
just come function arguments i notice |
| 08:55 |
nrzkt |
don't be evil :p |
| 08:55 |
nrzkt |
some* |
| 09:01 |
|
werwerwer joined #minetest-dev |
| 09:01 |
|
PilzAdam joined #minetest-dev |
| 09:03 |
est31 |
PilzAdam, you want to look at the pr as well? |
| 09:04 |
PilzAdam |
ncurses? |
| 09:05 |
est31 |
yup |
| 09:07 |
PilzAdam |
well, I guess the people who already looked that the code know more about whether it's good or not |
| 09:08 |
PilzAdam |
I like the idea, so I can give you a +1/2 |
| 09:08 |
|
Calinou joined #minetest-dev |
| 09:08 |
sfan5 |
i like the idea too |
| 09:08 |
sfan5 |
haven't looked at the code though |
| 09:09 |
PilzAdam |
I'd say merge it now and see if it breaks for someone |
| 09:09 |
PilzAdam |
master isn't stable |
| 09:10 |
PilzAdam |
just be around to fix stuff |
| 09:22 |
|
Megaf_ joined #minetest-dev |
| 09:36 |
nrzkt |
PilzAdam, no |
| 09:36 |
nrzkt |
is this the new idea to break master to see it someone complains ? |
| 09:37 |
PilzAdam |
heh, no |
| 09:37 |
PilzAdam |
that was exaggerated |
| 09:37 |
PilzAdam |
if a pull request sits on it's own for a too long time then it doesn't help anybody |
| 09:38 |
PilzAdam |
if it's stable enough then it should be merged into master so we can get proper testing on it |
| 09:39 |
PilzAdam |
just waiting for bugs to magically appear while the PR is not merged yet is wasted time |
| 09:41 |
nrzkt |
PilzAdam, i agree, but where are the users complaining because they are crying master is not stable and they are using it in prod ? |
| 09:41 |
nrzkt |
like VanessaE two month ago :s |
| 09:42 |
PilzAdam |
if people use the dev branch in production then it's their fault |
| 09:42 |
PilzAdam |
release builds are stable; we don't promise anything else |
| 09:42 |
est31 |
it is good to have as many people as possible to test the dev branch |
| 09:42 |
PilzAdam |
also, it's not like the dev branch regularly breaks |
| 09:43 |
nrzkt |
PilzAdam, i agree with you, but some core devs spit on me months ago when i said master is a dev branch not the production.... |
| 09:43 |
PilzAdam |
who? |
| 09:44 |
nrzkt |
hmmmm for example |
| 09:45 |
nrzkt |
but i don't care about master stability, for me master is a dev branch, but i only notice somes cry because of master stability two month ago and now it seems we can do anything on it. It's not logical. Maybe it's time to have a rule for master |
| 09:48 |
PilzAdam |
Totally official rule for master branch stability from now on: "The master branch is a development branch. It is intended and should be used for testing. We try to keep it stable enough, so people can test it." |
| 09:50 |
PilzAdam |
btw, any plans for the next release date? |
| 09:50 |
PilzAdam |
it seems there is no milestone on github yet |
| 09:51 |
est31 |
I don't think it should be made issue based |
| 09:51 |
est31 |
it should rather be made time based |
| 09:51 |
est31 |
e.g. we say we release twice a year |
| 09:52 |
Calinou |
twice a year is probably not enough, we're a game, not a GNU/Linux distribution |
| 09:52 |
est31 |
perhaps we can substract one month, thats in average the time a release gets stalled |
| 09:52 |
PilzAdam |
the original plan was to release every month |
| 09:52 |
Calinou |
quarterly releases sound much better |
| 09:52 |
est31 |
Calinou, releases have ~4 weeks of stability freezes |
| 09:52 |
est31 |
that would totally stop development |
| 09:52 |
PilzAdam |
release discussions are always fun, because everyone has great ideas and in the end nothing changes anyway |
| 09:52 |
est31 |
I mean you could commit nothing to master during that time |
| 09:53 |
PilzAdam |
feature freezes are supposed to be only 1 week |
| 09:53 |
Calinou |
games feel dead if they don't have regular releases |
| 09:53 |
est31 |
haha |
| 09:53 |
Calinou |
also, the freeze could be 2 weeks only |
| 09:53 |
Calinou |
again, this is just a game |
| 09:53 |
Calinou |
nobody really makes money on it |
| 09:53 |
est31 |
still its taken very seriously |
| 09:54 |
Calinou |
PilzAdam, still better than those "Let's rename Minetest to Minetest Game!" ideas |
| 09:54 |
PilzAdam |
I'd say, release every 2 to 3 months with a feature freeze of 1 week |
| 09:55 |
PilzAdam |
but actually provide rc builds in the feature freeze |
| 09:55 |
PilzAdam |
I mean real official rc builds with posts in the news forums |
| 09:55 |
Calinou |
Minecraft was released once per month in its Beta period |
| 09:55 |
Calinou |
it felt extremely active, and players loved it |
| 09:55 |
Calinou |
it was nearly rolling release |
| 09:55 |
est31 |
we are not minecraft |
| 09:55 |
est31 |
we release code the moment we develop |
| 09:55 |
est31 |
its no over the wall development |
| 09:57 |
est31 |
but yeah I do agree with PilzAdam even changing the smallest thing about releases will terribly upset a small group of people, so therefore everybody does simply the same than before |
| 10:01 |
|
cib0 joined #minetest-dev |
| 10:09 |
nrzkt |
est31, PilzAdam , Calinou i propose 3 months release per year. 2 months + 1 week of dev: 3 weeks for stability |
| 10:10 |
PilzAdam |
3 weeks feature freeze is way too long |
| 10:10 |
PilzAdam |
I'd say make it 1 week, with the option to make it longer if serious problems arise |
| 10:10 |
nrzkt |
PilzAdam, 1 week isn't because every dev is not aware in one week. 2 is sufficient |
| 10:10 |
est31 |
man, feature freeze doesnt go with "weeks" |
| 10:10 |
est31 |
I have tried precisely that |
| 10:10 |
est31 |
but hmmm reverted my version commit |
| 10:10 |
est31 |
hours after it was commited to the repo |
| 10:11 |
est31 |
I have announced the release date one month before |
| 10:11 |
est31 |
I have waited one month |
| 10:11 |
est31 |
but it got reverted |
| 10:11 |
est31 |
even though we were already multiple weeks in feature freeze |
| 10:11 |
nrzkt |
est31, maybe you should have support from other core devs ? :) |
| 10:12 |
nrzkt |
and the feature freeze should be more relevant, with less absence ? :) |
| 10:12 |
est31 |
then hmmm started flagging all kinds of issues as "blocker" |
| 10:12 |
est31 |
and even got issues like that "multi second lag" one |
| 10:12 |
nrzkt |
blocker issues for a release should be done at the FF start |
| 10:13 |
est31 |
PilzAdam, you realize that that issue wont be fixed within a week? |
| 10:13 |
est31 |
I mean you cant even specify when it is resolved |
| 10:14 |
PilzAdam |
there shouldn't be open "blocker" issues when we enter the feature freeze |
| 10:14 |
est31 |
man, it |
| 10:14 |
PilzAdam |
it should be all release-ready then |
| 10:14 |
nrzkt |
PilzAdam, the blocker issues are there for beeing fixed for release no ? |
| 10:15 |
est31 |
but the main problem of this whole "lets set a date" or "2 weeks for this" or "all X months" stuff is that you can't do it if on the other hand you guarantee that these issues get fixed before release |
| 10:19 |
est31 |
You know, I have asked paramat once whether I can release in one month |
| 10:19 |
est31 |
he said it wasn't enough he'd rather have two months |
| 10:19 |
est31 |
so I've said ok, lets have two months |
| 10:19 |
est31 |
a bit later he said that now he has to do everything in a haste |
| 10:20 |
est31 |
because the release was so soon |
| 10:20 |
est31 |
and his feedback was the _only_ feedback I've received about a release date |
| 10:21 |
est31 |
even if it was failed eventually |
| 10:22 |
est31 |
releasing is no fun |
| 10:23 |
est31 |
if anybody wants to do it, ok, but I don't want to be release manager again |
| 10:23 |
est31 |
PilzAdam, you want to be the release manager for 0.4.14? |
| 10:24 |
PilzAdam |
I would do it, but I can't promise that I have enough time |
| 10:24 |
PilzAdam |
IRL and stuff |
| 10:43 |
|
technics joined #minetest-dev |
| 11:07 |
|
proller joined #minetest-dev |
| 12:02 |
|
cib joined #minetest-dev |
| 12:25 |
|
DFeniks joined #minetest-dev |
| 12:52 |
|
crazyR joined #minetest-dev |
| 13:01 |
|
AnotherBrick joined #minetest-dev |
| 13:21 |
|
zat joined #minetest-dev |
| 13:32 |
|
luizrpgluiz joined #minetest-dev |
| 13:35 |
|
Darcidride joined #minetest-dev |
| 13:39 |
|
Samson1 joined #minetest-dev |
| 14:57 |
|
julienrat joined #minetest-dev |
| 14:57 |
|
julienrat left #minetest-dev |
| 14:59 |
|
rubenwardy joined #minetest-dev |
| 15:05 |
|
hmmmm joined #minetest-dev |
| 15:12 |
|
cib0 joined #minetest-dev |
| 15:36 |
|
Amaz joined #minetest-dev |
| 16:54 |
|
Krock joined #minetest-dev |
| 16:58 |
|
luizrpgluiz left #minetest-dev |
| 16:59 |
|
Darcidride_ joined #minetest-dev |
| 17:13 |
|
Gael-de-Sailly joined #minetest-dev |
| 17:18 |
|
kilbith joined #minetest-dev |
| 17:19 |
|
cib0 joined #minetest-dev |
| 17:20 |
kilbith |
is there a way to hide those spammy errors ? https://lut.im/78KsAzXRCA/3SzQYcwdFvBTEJU7.png |
| 17:20 |
kilbith |
1) it happens frequently on every servers whenever there's an entity on sight |
| 17:20 |
kilbith |
2) there only was one boat around on this screenshot |
| 17:20 |
kilbith |
3) the error flooding is endless |
| 17:24 |
hmmmm |
whose server are you on? |
| 17:24 |
kilbith |
VoidPixel, Raw Land, and another i don't remenber |
| 17:25 |
kilbith |
the last was VoidPixel |
| 17:25 |
VanessaE |
users on my servers occasionally report the same errors. |
| 17:26 |
hmmmm |
VanessaE, after destroying the pipeworks that had thousands of items in it, did you see that error anymore? |
| 17:27 |
VanessaE |
hmmmm: I personally have not seen it since, but I recall at least one report of that error on my "Basic" server. the only entities there are item frames, pedestals, signs (all three of which are immobile), and carbone_mobs. |
| 17:27 |
hmmmm |
yeah I saw it on OldCoder's server too |
| 17:27 |
hmmmm |
and now there's this VoidPixel one that seems to be having it often |
| 17:27 |
hmmmm |
I'm gonna take a closer look at these servers soon |
| 17:28 |
kilbith |
thanks |
| 17:34 |
kilbith |
811, 4, -560 at VoidPixel is a good place for catching them |
| 17:35 |
hmmmm |
I can't do any diagnosis with a client alone |
| 17:36 |
hmmmm |
are you the owner of that server? |
| 17:36 |
kilbith |
nope |
| 17:39 |
|
Player2 joined #minetest-dev |
| 17:40 |
hmmmm |
hmm |
| 17:40 |
hmmmm |
well |
| 17:41 |
hmmmm |
I need to work with the owner of that server or OldCoder since he has the same problem quite frequently on his own server |
| 17:41 |
hmmmm |
the key difference between you two and VanessaE is that your problem is readily replicatable |
| 17:41 |
kilbith |
i'll put the admin in contact with you |
| 17:42 |
hmmmm |
ok |
| 17:42 |
hmmmm |
is the admin of that server technically inclined, do you know? |
| 17:43 |
|
Robert_Zenz joined #minetest-dev |
| 17:43 |
hmmmm |
like if I tell him to modify the source would he be able to do that and compile it |
| 17:44 |
kilbith |
no idea of his technical skill but he can compile |
| 17:44 |
hmmmm |
okay then |
| 17:44 |
|
luizrpgluiz joined #minetest-dev |
| 17:47 |
|
nrzkt joined #minetest-dev |
| 18:04 |
|
Darcidride joined #minetest-dev |
| 18:40 |
|
asl97 joined #minetest-dev |
| 18:48 |
|
younishd joined #minetest-dev |
| 19:04 |
|
ElectronLibre joined #minetest-dev |
| 19:19 |
|
cib_ joined #minetest-dev |
| 19:24 |
|
celeron55 joined #minetest-dev |
| 19:28 |
|
luizrpgluiz left #minetest-dev |
| 19:44 |
|
kilbith left #minetest-dev |
| 19:44 |
|
H-H-H joined #minetest-dev |
| 19:46 |
|
est31 joined #minetest-dev |
| 19:58 |
|
paramat joined #minetest-dev |
| 20:04 |
paramat |
hmmmm i can start work on a flat mapgen, mgv5/v7 don't support 'flat' and would be messy if they did. a dedicated mapgen can use the biome API, can have a simple parameter for terrain level, and spflags for optional biomes and decorations |
| 20:06 |
paramat |
the 'trees' flag does not affect mgv5/v7, perhaps it can toggle all decorations in those |
| 20:07 |
est31 |
nrzkt, are these all places where I should put const? or is it needed somewhere else too? |
| 20:12 |
est31 |
I just don't want to put const to every param of every method, because that's what it seems you want |
| 20:33 |
|
Puma_rc left #minetest-dev |
| 20:38 |
celeron55 |
uh what |
| 20:39 |
celeron55 |
we do not have a code style that requires const for any parameters except for references |
| 20:39 |
celeron55 |
the fact that C++ has the wrong default constness isn't a reason to spam all code with so much const that it's unreadable |
| 20:41 |
celeron55 |
so in this case whatever nrzkt is saying is most definitely wrong |
| 20:42 |
|
CraigyDavi joined #minetest-dev |
| 20:51 |
hmmmm |
paramat: yeah not only terrain level but what about cave level and so on |
| 20:51 |
paramat |
ok |
| 20:52 |
hmmmm |
the "flat" parameter came from a time where there was only v6 and v7, and it made more sense to have one with the new and the old biome systems |
| 20:59 |
|
crazyR joined #minetest-dev |
| 21:03 |
nrzkt |
celeron55, const parameters are not anoying if they are correctly used. Maybe some should changes their glasses |
| 21:04 |
celeron55 |
hmmmm: what do you say about this |
| 21:05 |
hmmmm |
adding const qualifiers to parameters where they are obviously not needed at all is kind of... dumb |
| 21:07 |
celeron55 |
yeah; the thing is, const is actually *needed* on parameters that are not copied; otherwise it's not *needed* |
| 21:08 |
celeron55 |
i.e. it will not worsen the interface |
| 21:09 |
hmmmm |
it's bad because it's weird |
| 21:09 |
celeron55 |
as i said, everything should be const by default, but isn't because C++ is based on C which is based on not enough real programming experience |
| 21:09 |
hmmmm |
developers already have too much to think about, they don't need more mental load thanks to constructs that are non-standard and have no utility whatsoever |
| 21:10 |
hmmmm |
i take it you've jumped onto the Rust train |
| 21:10 |
est31 |
and even rust allows modifications |
| 21:11 |
est31 |
by default |
| 21:11 |
hmmmm |
personally I won't even look at a language or whatever until it's 10 years old |
| 21:11 |
est31 |
I dont even know whether it has such a concept |
| 21:11 |
celeron55 |
hmmmm: this doesn't have anything to do with rust |
| 21:11 |
est31 |
well it has read only references |
| 21:11 |
est31 |
(which are the default) |
| 21:12 |
hmmmm |
I thought you had to explicitly specify "mutable" |
| 21:12 |
est31 |
if you create a reference that you want to edit later on you have to say "mut" |
| 21:12 |
hmmmm |
right, that's only for references though |
| 21:12 |
est31 |
but the built in types like i32 or so they all get copied |
| 21:12 |
hmmmm |
for parameters passed by value, why would you ever care about its constness |
| 21:12 |
est31 |
and are modifyable, at least I think |
| 21:13 |
est31 |
I don't think its a good thing to expose the fact whether you edit a passed value in the internal implementation of your method |
| 21:13 |
celeron55 |
true; it doesn't belong to the interface |
| 21:15 |
celeron55 |
not that C++ allows you to make clean interfaces in the general case but in this case it kind of does |
| 21:16 |
celeron55 |
hmmmm: i think nrzkt's idea is that you don't then accidentally modify the value that you wanted to stay constant during the execution of the function |
| 21:16 |
nrzkt |
this is one idea yes, make the code robust |
| 21:17 |
nrzkt |
what users want ? robust code or readable for newbie code ? |
| 21:17 |
hmmmm |
so you're saying it's pro if you spam "const" everywhere in totally inappropriate places? |
| 21:17 |
hmmmm |
wtf man |
| 21:17 |
celeron55 |
i have to say that i have probably almost never stumbled upon a bug caused by a parameter being modified mid-way in a function |
| 21:17 |
nrzkt |
hmmmm, another time, like every day you are saying something that i don't said |
| 21:18 |
hmmmm |
for what it's worth |
| 21:18 |
hmmmm |
I am a professional working in the industry, and I don't make parameters const that are not references or pointers |
| 21:18 |
hmmmm |
I guess my code is newbie though |
| 21:18 |
hmmmm |
:| |
| 21:19 |
celeron55 |
as if others in here weren't professionals :P |
| 21:19 |
nrzkt |
i don't care you work in industry. Linus Torvalds and some OpenBSD developers are not in the industry and they are better than you to make good code. |
| 21:19 |
hmmmm |
freaking interns screwing everything else |
| 21:19 |
nrzkt |
this is a non argument |
| 21:19 |
nrzkt |
(and i don't said those mentioned developpers said we should make all const :) ) |
| 21:19 |
hmmmm |
nrzkt: so why don't you contribute to the linux kernel by adding const to all the parameters |
| 21:20 |
nrzkt |
i don't contribute to linux kernel |
| 21:20 |
hmmmm |
I'm sure they'll be happy with your contribution because you're a pro and they are newbs |
| 21:20 |
nrzkt |
the only patch for kernel i provide is for FreeBSD kernel a little sysctl added to the nfs driver to make something customizable :p |
| 21:20 |
celeron55 |
staying on the topic, i would like to leave the choice in this matter to the author of each function; you can try to persuade anyone you want with any reasons you want, but they don't have to comply with anyone |
| 21:21 |
nrzkt |
celeron55, no problem for me, i only point the constness is a good thing to do if you have time :) |
| 21:22 |
hmmmm |
are you going to tell people to use yoda comparisons next? *shivers* |
| 21:22 |
nrzkt |
i think you are waiting SW VII too much :p |
| 21:22 |
PilzAdam |
how to dev: 1) take an keyword from the programming language of your choice 2) start fighting over it's usage 3) start insulting people |
| 21:24 |
nrzkt |
PilzAdam, i suggest to use java instead of C++ for MT because every industry use it and there are many bloated jars to use :p |
| 21:25 |
celeron55 |
PilzAdam: i'm just using this channel as a warm-up to actually developing one of my smaller projects! |
| 21:26 |
est31 |
okay, seems I were wrong, rust does have all function params immutable by default |
| 21:26 |
PilzAdam |
celeron55, if you read any ideas that you have for that project here then you should reconsider that idea |
| 21:26 |
est31 |
and you have to make them mutable with "mut" |
| 21:34 |
|
paramat left #minetest-dev |
| 21:54 |
nrzkt |
https://lut.im/CPAC0Ddd6e/vAKKEuo3f7wDYjMH.png |
| 21:54 |
nrzkt |
is that normal ? |
| 21:56 |
est31 |
no |
| 21:56 |
est31 |
I think however that bug should have been recently fixed by hmmmm |
| 21:56 |
nrzkt |
this night ? |
| 21:56 |
est31 |
some u32 prng stuff |
| 21:56 |
nrzkt |
it's the seed problem ? |
| 21:56 |
hmmmm |
sounds to me like it's a corrupted set of mapgen params. |
| 21:57 |
hmmmm |
told you guys to not tough map_meta.txt |
| 21:57 |
nrzkt |
i didn't modified it |
| 21:58 |
nrzkt |
i removed the whole world and recreate it |
| 21:58 |
hmmmm |
touch* i meant |
| 21:58 |
nrzkt |
and i show you this pic :p |
| 21:58 |
hmmmm |
well what are your map_meta.txt params then? |
| 21:58 |
hmmmm |
because they're obviously corrupt |
| 21:58 |
nrzkt |
rm -Rf ~/.minetest/worlds/mapgenv6 |
| 21:58 |
nrzkt |
and started a new map :) |
| 21:59 |
hmmmm |
you might've messed up your mapgen param overrides in your config file then |
| 21:59 |
nrzkt |
i will look at this, else there are the newly created world things: http://pastie.org/10514543 |
| 22:01 |
hmmmm |
maybe one of your mods are messing it up |
| 22:01 |
nrzkt |
it's the default game |
| 22:04 |
|
kilbith joined #minetest-dev |
| 22:04 |
kilbith |
i got the same issue two weeks ago (default game, untouched map_meta) : http://irc.minetest.ru/minetest-dev/2015-10-17#i_4426712 |
| 22:05 |
hmmmm |
dunno I'm trying out the same params and it seems fine to me |
| 22:05 |
kilbith |
unless if it has been touched behind my back |
| 22:06 |
hmmmm |
well I can't reproduce |
| 22:11 |
nrzkt |
hmmmm, can "LuaPerlinNoiseMap::LuaPerlinNoiseMap(NoiseParams *params, int seed, v3s16 size)" be the problem because seed is a int ? |
| 22:11 |
hmmmm |
what does that have to do with the mapgen |
| 22:12 |
hmmmm |
that's for mods only |
| 22:12 |
nrzkt |
don't know i'm not mapgen aware |
| 22:12 |
kilbith |
i put a dollar on the new setting tab as suspect |
| 22:12 |
nrzkt |
kilbith, can be possible, i merged them in my local tree today |
| 22:13 |
nrzkt |
but it seems i have the same problem with dedicated server |
| 22:13 |
nrzkt |
and dedicated server didn't use the setting tab |
| 22:15 |
|
crazyR joined #minetest-dev |
| 22:17 |
rubenwardy |
I find it quite hard to find things in the new settings tree |
| 22:20 |
|
Player2 joined #minetest-dev |
| 22:28 |
nrzkt |
very strange, it seems my mapgenv7 on the new world is a fractal mapgen... |
| 22:34 |
|
proller joined #minetest-dev |
| 23:06 |
|
paramat joined #minetest-dev |
| 23:09 |
paramat |
hmmmm i'd like to merge this later #3302 , is tested. i have plans for creating patches of bare stone in deserts by setting 'depth top' to 0 and using filler noise to reduce 'filler depth' to 0 in places |
| 23:09 |
ShadowBot |
https://github.com/minetest/minetest/issues/3302 -- Mgfractal: Add filler depth noise by paramat |
| 23:11 |
paramat |
meh jenkins checks are failing, ignoring |
| 23:33 |
|
AnotherBrick joined #minetest-dev |
| 23:33 |
|
Fixer joined #minetest-dev |
| 23:51 |
|
AnotherBrick joined #minetest-dev |
