| Time |
Nick |
Message |
| 00:34 |
|
Taoki joined #minetest-dev |
| 01:16 |
|
Taoki_1 joined #minetest-dev |
| 02:13 |
|
hmmmmm joined #minetest-dev |
| 02:38 |
|
OldCoder joined #minetest-dev |
| 02:39 |
|
Zeno` joined #minetest-dev |
| 02:45 |
Tesseract |
Something something #1606 something something |
| 02:45 |
ShadowBot |
https://github.com/minetest/minetest/issues/1606 -- Add mod security by ShadowNinja |
| 02:51 |
|
cheapie_ joined #minetest-dev |
| 02:52 |
|
chrisf_ joined #minetest-dev |
| 02:52 |
est31 |
o_O |
| 02:52 |
|
kahrl joined #minetest-dev |
| 02:59 |
Tesseract |
Zeno`, kahrl: +/- 1 on mod security ^ ? |
| 03:01 |
Tesseract |
0.5 (or a nonsensical version jump) is coming up, so compat is officially not an issue, and it's 99% compatible anyway. |
| 03:01 |
Tesseract |
Also, 99% of internet stats are made up. |
| 03:01 |
Tesseract |
:-P |
| 03:02 |
est31 |
so the standard way to use an insecure function is to check whether a function is nil, and do request_insecure_environment() otherwise? |
| 03:03 |
est31 |
Isn't it better to make request_insecure_environment() return sth when mod security is disabled, and the mod isn't listed? |
| 03:03 |
est31 |
ah ok |
| 03:03 |
est31 |
its only a doc isse |
| 03:03 |
est31 |
issue* |
| 03:04 |
Tesseract |
est31: No. `ins_env=_G if req_ins_env then ins_env = req_ins_env() end if not ins_env then error() end ins_env.ins_func()` |
| 03:04 |
Tesseract |
At least that's how I did it for the IRC mod. |
| 03:04 |
Tesseract |
It doesn't really matter exactly how you do it. |
| 03:05 |
Tesseract |
And if you don't care about compat that gets about 3 lines shorter. |
| 03:05 |
est31 |
yes |
| 03:06 |
Tesseract |
(mod compat with old Minetest) |
| 03:06 |
est31 |
doc should feature that though |
| 03:06 |
est31 |
https://github.com/minetest/minetest/pull/1606/files#diff-e62796adc1d9474bfa497540cf203d47R98 |
| 03:06 |
Zeno` |
I'm not a modder so I don't feel qualified enough to yay or nay on this commit. BUT from memory my main concern when this was first opened was that there be an ability to bypass the mod security and this is now possible. So I have no objections any more either |
| 03:07 |
Zeno` |
Network, apparently, will be broken soon as well so I agree that the two should be merged at the same time |
| 03:08 |
Zeno` |
If there's going to be disruption anyway :) |
| 03:08 |
Tesseract |
Zeno`: I don't claim that it's perfectly secure, I can't really know for sure. But I know of no holes, and something is better than nothing IMO (as long as you're not claiming perfect security). |
| 03:09 |
Zeno` |
I meant a way for the modder to explicitly bypass it -- and you've added that feature, so all is well |
| 03:10 |
Tesseract |
Zeno`: The only mod that's really affected is the IRC mod. The two others just need a few lines of compat code. |
| 03:10 |
Zeno` |
yep |
| 03:10 |
Zeno` |
I'll +1 it but I'd prefer if another dev +1's it as well (for something this big) |
| 03:11 |
Tesseract |
(and that only needs users to change a setting, in adition to the compat code) |
| 03:11 |
Zeno` |
what doth kahrl think? |
| 03:12 |
Zeno` |
Now (around about) is certainly the time to merge it |
| 03:12 |
Zeno` |
I can't wait for the flurry of "bug" reports :D |
| 03:14 |
Zeno` |
https://github.com/minetest/minetest/issues/2274#issuecomment-73924800 |
| 03:14 |
Zeno` |
I'll merge that in a second |
| 03:15 |
est31 |
http://irc.minetest.ru/minetest-dev/2015-02-11#i_4151665 |
| 03:16 |
est31 |
1,2, or 3? |
| 03:16 |
est31 |
Tesseract, Zeno` ^ |
| 03:17 |
Zeno` |
I think live with the warning |
| 03:17 |
Zeno` |
Option 2 isn't that bad either... since it's bundled and we don't modify it (AFAIK) |
| 03:18 |
est31 |
btw its this change https://github.com/minetest/minetest/pull/2290/files#diff-597e4a4ad36b3232059614f27748f932R576 |
| 03:19 |
Tesseract |
I vote 2 or 3. |
| 03:19 |
Tesseract |
We don't need the warnings since we don't touch that code. |
| 03:20 |
Zeno` |
Yep, so (2) is probably the best solution |
| 03:20 |
est31 |
The first warning that got fixed did help |
| 03:21 |
Zeno` |
help? |
| 03:21 |
est31 |
it pointed out that the cmake file is wrong |
| 03:21 |
est31 |
and now, on posix systems, we don't use tmpnam anymore |
| 03:23 |
Zeno` |
yep, so that should stay |
| 03:25 |
est31 |
ok, apparently you can selectively remove warnings, gonna do that instead |
| 03:26 |
* VanessaE |
peeks in |
| 03:47 |
est31 |
what's weird, I've removed all -W* stuff from src/lua/CMakeLists.txt |
| 03:47 |
est31 |
and still the warning is shown |
| 03:47 |
est31 |
even added -Wno-empty-body |
| 04:03 |
|
crazyR joined #minetest-dev |
| 04:41 |
|
Hunterz joined #minetest-dev |
| 04:46 |
est31 |
ok, the cmake scripts are broken |
| 04:46 |
Zeno` |
excellent work :D |
| 04:47 |
est31 |
as it seems, this only works when I actually remove the -Wall from the src/CMakeLists.txt |
| 04:48 |
est31 |
at least it adds the warning again when I only add the wall to the one in src/lua |
| 04:58 |
|
Miner_48er joined #minetest-dev |
| 04:59 |
est31 |
Meh, dont want anymore. |
| 04:59 |
est31 |
dunno how to fix that, sorry |
| 05:00 |
est31 |
if you dont like the change of *comment positions*, then we will have to live with the warning. |
| 05:00 |
est31 |
so whats your position? |
| 05:02 |
Zeno` |
it's not ideal having the warnings there but it's a third party package so *shrug* |
| 05:03 |
Zeno` |
how did your patch fix the empty body warning anyway? |
| 05:03 |
Zeno` |
that's not the Lua warning I get either heh |
| 05:04 |
Zeno` |
I only get loadlib.c:76:21: warning: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] |
| 05:05 |
Zeno` |
which is, of course, a pedantic warning |
| 05:08 |
est31 |
My package fixed the warning by proper identation |
| 05:08 |
est31 |
see this one: |
| 05:08 |
est31 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62184#c4 |
| 05:09 |
Zeno` |
yeah I always put ; on it's own line. Didn't know indentation mattered though :/ |
| 05:11 |
Zeno` |
I still don't get why indenting the whole line should suppress the warning. That's bizarre |
| 05:12 |
est31 |
because this way the compiler thinks the line after that way is idented. |
| 05:13 |
est31 |
and then it thinks that the ; might have got there by accident |
| 05:13 |
Zeno` |
https://github.com/est31/minetest/blob/master/src/lua/src/lauxlib.c why doesn't line 570 generate the warning? |
| 05:14 |
est31 |
because the line following it has the same identation level |
| 05:15 |
Zeno` |
but line 576 is your fix (add indentation) and line 577 doesn't have the same indentation level after the fix (it did before) |
| 05:16 |
Zeno` |
I think gcc needs to fix their warning personally |
| 05:16 |
est31 |
ok, I'll move the while two to the left |
| 05:20 |
Zeno` |
ahh ok... it was originally 3 to the left |
| 05:21 |
Zeno` |
that makes more sense |
| 05:21 |
Zeno` |
(as to why the warning was emitted) |
| 05:21 |
est31 |
I can move it if it makes sense (meaning if you accept it then) |
| 05:22 |
Zeno` |
I didn't say I was going to merge it. I brought it up because I was curious as to how it fixed the warning :) |
| 05:25 |
Zeno` |
est31, what version of gcc do you use (out of curiosity as well) |
| 05:28 |
est31 |
4.9.1-16ubuntu6 |
| 05:32 |
est31 |
perhaps its also because of something else in the patch |
| 05:33 |
est31 |
will you merge it when I remove this second warning fix completely? |
| 05:37 |
|
chrisf joined #minetest-dev |
| 05:43 |
Zeno` |
If another dev agrees |
| 05:53 |
est31 |
ok removed it you can make your +1 |
| 05:56 |
est31 |
better warning message... |
| 05:57 |
est31 |
commit* |
| 06:00 |
Zeno` |
yep I'm fine with that. Lua does not come with cmakelists.txt anyway |
| 06:01 |
est31 |
ok a github +1 too? |
| 06:01 |
Zeno` |
yep |
| 06:02 |
est31 |
fine |
| 06:02 |
est31 |
:) |
| 06:04 |
Zeno` |
Tesseract, are you ok with #2290 now? |
| 06:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/2290 -- Fix gcc warning for lua by est31 |
| 06:05 |
Zeno` |
actually I think he's already said that bit was fine. So I'll merge in 10 minutes unless someone objects |
| 06:11 |
* Tesseract |
+1 |
| 06:15 |
Zeno` |
Pushed (I changed the commit message, est31) |
| 06:23 |
|
jin_xi joined #minetest-dev |
| 06:23 |
est31 |
lol is this still valid https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L17-19 |
| 06:40 |
|
selat joined #minetest-dev |
| 06:40 |
|
Hunterz joined #minetest-dev |
| 06:46 |
|
nrzkt joined #minetest-dev |
| 06:57 |
nrzkt |
oh, no warning on compilation for lua mkstemp, good est31 |
| 07:44 |
|
selat joined #minetest-dev |
| 07:53 |
|
Megaf joined #minetest-dev |
| 07:56 |
|
puhfa joined #minetest-dev |
| 08:15 |
|
oleastre joined #minetest-dev |
| 08:18 |
|
nrzkt joined #minetest-dev |
| 08:20 |
|
ImQ009 joined #minetest-dev |
| 08:22 |
|
chchjesus joined #minetest-dev |
| 08:25 |
kahrl |
BlockMen is back :) https://github.com/minetest/minetest/pull/2295 |
| 08:28 |
VanessaE |
*gasp* |
| 08:29 |
nrzkt |
it's good or a problem ? don't know the history :) |
| 08:29 |
est31 |
so, just to make, sure I'm not doing work in vain since 1.5 hrs, could you comment #2275? |
| 08:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2275 -- lua_api.txt should have a since field for every function |
| 08:29 |
kahrl |
as far as I'm concerned, good :) |
| 08:30 |
est31 |
I have started with version 0.4.7 is that early enough? |
| 08:30 |
VanessaE |
how much you wanna bet he'll be confused as all fuck about the changes in the development model? :) |
| 08:31 |
kahrl |
est31: additions to the wiki are always welcome |
| 08:32 |
est31 |
Is lua_api.txt too verbose then? |
| 08:32 |
kahrl |
probably so |
| 08:32 |
kahrl |
haven't thought about it too much |
| 08:34 |
est31 |
there will be e.g. a (>=0.4.8) added |
| 08:36 |
est31 |
the wiki is broken |
| 08:37 |
est31 |
I wont fix it |
| 08:38 |
nrzkt |
i think wiki must be update, especially for this versioning in API |
| 08:38 |
est31 |
so you dont object to it being in lua_api.txt? |
| 08:39 |
nrzkt |
i don't know for the lua_api.txt, i prefer wiki instead of flat files for those things |
| 08:42 |
est31 |
Tesseract, you labeled it, and didnt close it, what do you think? |
| 08:53 |
|
kilbith joined #minetest-dev |
| 08:55 |
est31 |
can any core dev give their +1 to #2225 ? |
| 08:55 |
ShadowBot |
https://github.com/minetest/minetest/issues/2225 -- Fix for getCraftRecipes implementation is very slow by gregorycu |
| 08:56 |
nrzkt |
hmmmm is on the thread |
| 08:58 |
est31 |
? |
| 08:58 |
nrzkt |
kwoelr is hmmmm |
| 08:59 |
nrzkt |
erf my 0.4.11 stable has crashed by assert: |
| 08:59 |
nrzkt |
In thread 805406800: |
| 08:59 |
nrzkt |
Debug stacks: |
| 08:59 |
nrzkt |
DEBUG STACK FOR THREAD 805406400: |
| 08:59 |
nrzkt |
#0 int main(int, char **) |
| 08:59 |
nrzkt |
#1 Dedicated server branch |
| 08:59 |
nrzkt |
#2 void dedicated_server_loop(Server &, bool &) |
| 08:59 |
nrzkt |
(Leftover data: #3 void Server::step(float)) |
| 08:59 |
nrzkt |
DEBUG STACK FOR THREAD 805408400: |
| 08:59 |
nrzkt |
#0 virtual void *ServerThread::Thread() |
| 08:59 |
nrzkt |
#1 void Server::Receive() |
| 08:59 |
nrzkt |
(Leftover data: #2 void Server::SendBlocks(float)) |
| 08:59 |
nrzkt |
(Leftover data: #3 void Server::SendTimeOfDay(u16, u16, f32)) |
| 08:59 |
nrzkt |
(Leftover data: #4 void ItemStack::serialize(std::ostream &) const) |
| 08:59 |
nrzkt |
(Leftover data: #5 void ServerMap::loadBlock(std::string *, v3s16, MapSector *, bool)) |
| 09:00 |
nrzkt |
DEBUG STACK FOR THREAD 807432400: |
| 09:00 |
nrzkt |
#0 virtual void *CurlFetchThread::Thread() |
| 09:00 |
nrzkt |
DEBUG STACK FOR THREAD 807432800: |
| 09:00 |
nrzkt |
#0 virtual void *EmergeThread::Thread() |
| 09:00 |
nrzkt |
(Leftover data: #1 MapBlock *ServerMap::loadBlock(v3s16)) |
| 09:00 |
nrzkt |
(Leftover data: #2 void ServerMap::loadBlock(std::string *, v3s16, MapSector *, bool)) |
| 09:00 |
nrzkt |
(Leftover data: #3 void ItemStack::deSerialize(std::istream &, IItemDefManager *)) |
| 09:00 |
nrzkt |
/wrkdirs/usr/ports/games/minetest/work/minetest-minetest-be358c0/src/util/pointer.h:279: void SharedBuffer<unsigned char>::drop() [T = unsigned char]: Assertion '(*refcount) > 0' failed. |
| 09:02 |
* VanessaE |
looks at nrzkt |
| 09:02 |
est31 |
is it by chance main.cpp:882: int main(int, char**): Assertion '0' failed |
| 09:02 |
VanessaE |
[02-12 04:06] * nrz2 VEVn (nrz2VE-Vanilla) has left #minetest <--- that's your crash? |
| 09:03 |
nrzkt |
no no :p this is a crash on my own server |
| 09:03 |
VanessaE |
oh ok |
| 09:03 |
nrzkt |
it's not a problem on the client :) |
| 09:03 |
* VanessaE |
closes the ssh session that she was just about to open to check the server's log :P |
| 09:03 |
|
oleastre joined #minetest-dev |
| 09:06 |
VanessaE |
and with that, I'm off to bed. :) |
| 09:06 |
VanessaE |
night |
| 09:06 |
nrzkt |
what does everybody think about #2285 ? could you reply to it |
| 09:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/2285 -- No damage in creative mode |
| 09:06 |
nrzkt |
good night |
| 09:07 |
kilbith |
i'm thinking about replace those checkboxes by a dropdown |
| 09:07 |
kilbith |
exclusive modes |
| 09:24 |
|
proller joined #minetest-dev |
| 09:24 |
|
ImQ009 joined #minetest-dev |
| 09:41 |
nrzkt |
clang reports two unused variables: #2296 if nobody cares i merge tomorrow |
| 09:41 |
ShadowBot |
https://github.com/minetest/minetest/issues/2296 -- Remove unused variables to make clang happy by nerzhul |
| 09:46 |
est31 |
gcc reports those too |
| 09:46 |
est31 |
at least the post one |
| 10:03 |
|
Zeno` joined #minetest-dev |
| 10:16 |
|
DFeniks joined #minetest-dev |
| 10:18 |
Megaf |
nrzkt: Hi there, welcome to the team |
| 10:19 |
Megaf |
or is not him? |
| 10:19 |
Megaf |
nevermind |
| 10:19 |
Megaf |
I know we have a new core developer, who is he? |
| 10:19 |
Zeno` |
nrzkt |
| 10:19 |
est31 |
where did you use him? |
| 10:19 |
Zeno` |
aka nazgul aka black rider |
| 10:20 |
nrzkt |
hi Megaf, thanks |
| 10:20 |
Zeno` |
it's not really nazgul but nazgul is easy to remember |
| 10:20 |
Megaf |
Ok, so I'm not mistaken |
| 10:20 |
Zeno` |
lol :) |
| 10:20 |
Zeno` |
I'll be back later |
| 10:20 |
nrzkt |
nrztk is ner'zhul but nrz is already taken then i add Kael'Thuzad suffix=> nrzkt |
| 10:21 |
nrzkt |
yes i'm a wow gamer |
| 10:22 |
nrzkt |
est31 what's the problem ? |
| 10:22 |
nrzkt |
#2275 |
| 10:22 |
ShadowBot |
https://github.com/minetest/minetest/issues/2275 -- lua_api.txt should have a since field for every function |
| 10:23 |
|
selat joined #minetest-dev |
| 10:23 |
est31 |
if devs think the version doc shouldn't be added, this should be respected. |
| 10:25 |
est31 |
I'm just trying to find a way to get feedback for changes I'm doing, not that they get rejected when they are finished. |
| 10:25 |
|
leat joined #minetest-dev |
| 10:28 |
Megaf |
we could use github for documentation control too |
| 10:28 |
Megaf |
put the docs on git.io |
| 10:28 |
nrzkt |
http://dev.minetest.net/Translation isn't deprecated ? |
| 10:28 |
Megaf |
or github.io |
| 10:29 |
nrzkt |
#2052 is fine for me, but util/update-po.sh does many changes, not only on cz |
| 10:29 |
est31 |
like http://rubenwardy.com/minetest_modding_book/lua_api.html ? |
| 10:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2052 -- Update czech translation by JakubVanek |
| 10:33 |
est31 |
I think its wrong to maintain two different repos for documentation .. the wiki and the lua_api.txt. Best would be to have one, which autogenerates the wiki and a shorter api doc |
| 10:34 |
nrzkt |
i think everything must be on the wiki, this also permit to have a page history |
| 10:35 |
est31 |
git has histories too |
| 10:35 |
est31 |
wiki has the problem that you dont have the overview |
| 10:35 |
kahrl |
using exclusively the wiki would be fine if there was a way to attach wiki changes to pull request |
| 10:35 |
nrzkt |
yes but it's less userfriedly for mod developper and community, i think |
| 10:35 |
kahrl |
s |
| 10:36 |
nrzkt |
PR < 100, yeah ! |
| 10:50 |
|
chchjesus joined #minetest-dev |
| 10:54 |
|
gregorycu joined #minetest-dev |
| 10:57 |
nrzkt |
kahrl #2295 is ok for you ? |
| 10:57 |
ShadowBot |
https://github.com/minetest/minetest/issues/2295 -- Fix gettext on MSVC by BlockMen |
| 10:57 |
kahrl |
Haven't really looked at it yet |
| 10:57 |
gregorycu |
celeron55: template <typename T> struct InferenceDisabler { typedef T type }; template <typename T> void Foo(typename InferenceDisabler<T>::type arg); Foo(5); // error Foo<int>(5); ok |
| 10:58 |
est31 |
^ ? |
| 10:58 |
|
casimir joined #minetest-dev |
| 10:59 |
gregorycu |
There was a discussion on how to disable type inference for templated functions, I believe this is the clearest way |
| 10:59 |
est31 |
oh ok |
| 11:00 |
gregorycu |
What was wrong with pipeworks? |
| 11:01 |
est31 |
when |
| 11:01 |
gregorycu |
You got thanked, less than 24 hours ago for fixing pipeworks |
| 11:02 |
est31 |
ah that one, there was a regression, you placed a locked chest, and it wasnt registered to you as owner |
| 11:02 |
est31 |
was done by HEAD^ |
| 11:03 |
|
ImQ009_ joined #minetest-dev |
| 11:04 |
gregorycu |
est31, do you have shaders turned on? |
| 11:13 |
|
est31 joined #minetest-dev |
| 11:13 |
|
est31 joined #minetest-dev |
| 11:16 |
|
ImQ009 joined #minetest-dev |
| 11:16 |
gregorycu |
Oops |
| 11:16 |
gregorycu |
est31, do you have shaders turned on? |
| 11:17 |
est31 |
why |
| 11:17 |
est31 |
no |
| 11:17 |
|
JakubVanek joined #minetest-dev |
| 11:18 |
gregorycu |
That was my next question |
| 11:19 |
gregorycu |
I'm trying to see there are many people suffering from a performance issue with shaders |
| 11:21 |
est31 |
ok |
| 11:23 |
|
jin_xi joined #minetest-dev |
| 11:26 |
gregorycu |
Simple optimisations and it goes from 80fps to 120fps |
| 11:30 |
nrzkt |
i haven't seen performance issues on shader because my machine is too powered, but improving FPS could be great |
| 11:31 |
gregorycu |
Actually |
| 11:31 |
gregorycu |
This type of perf issue has nothing to do with your graphics card |
| 11:32 |
gregorycu |
Probably |
| 11:32 |
gregorycu |
Out of interest, what is the difference between your FPS with shaders turned on and off? |
| 11:33 |
nrzkt |
i can try at work now, because i have a intel GPU |
| 11:33 |
|
book` joined #minetest-dev |
| 11:34 |
gregorycu |
What do you mean? |
| 11:34 |
nrzkt |
the FPS/shader issue will be shown |
| 11:35 |
gregorycu |
I don't understand |
| 11:35 |
gregorycu |
It's possible that more powerful graphics cards are more affected by this |
| 11:37 |
|
DFeniks_ joined #minetest-dev |
| 11:38 |
celeron55 |
most systems do get slightly lower performance when shaders are enabled |
| 11:39 |
celeron55 |
some don't, and some very old ones go unplayably slow |
| 11:39 |
gregorycu |
Yep, it's the degree of the performance degradation that I'm interested in |
| 11:39 |
gregorycu |
I wouldn't call 120 -> 80 slight |
| 11:40 |
gregorycu |
In fact, that's shaders, vs shaders with less constant updates |
| 11:40 |
celeron55 |
can you define the test setup |
| 11:40 |
celeron55 |
what settings? |
| 11:40 |
celeron55 |
and how much to let the world load and so on |
| 11:41 |
celeron55 |
getting consistent results takes a bit of effort |
| 11:41 |
gregorycu |
No options on the left, or middle, shaders, bumpmapping, normalmaps and occlusion turned on |
| 11:41 |
nrzkt |
with my intel GPU: no shader: 60fps constant, with: 60 but sometimes lower to 40. |
| 11:42 |
gregorycu |
You have frame limiting turned on, don't you? |
| 11:42 |
gregorycu |
I look at an island, wait until the map loads (the frame rate to settle) |
| 11:42 |
gregorycu |
It's the same island, I don't touch the mouse while it loads |
| 11:42 |
celeron55 |
my intel on linux also caps to 60 while minetest is configured at 120/240 |
| 11:42 |
celeron55 |
it'd probably require fullscreen to go further but that'll probably just mess things up so i won't even try |
| 11:42 |
gregorycu |
What is 120/20 ? |
| 11:42 |
gregorycu |
240 |
| 11:43 |
gregorycu |
Max frame rates? |
| 11:43 |
celeron55 |
fps_max = 240 |
| 11:43 |
celeron55 |
wanted_fps = 120 |
| 11:43 |
gregorycu |
Ok |
| 11:43 |
|
FR^2 joined #minetest-dev |
| 11:43 |
celeron55 |
those values make it run uncapped at most times |
| 11:43 |
kilbith |
or /set -n fps_max 0 |
| 11:44 |
celeron55 |
don't use -n |
| 11:44 |
celeron55 |
has calinou spread that to every person in this community? |
| 11:44 |
gregorycu |
I have a 4 line change to limit the number of settings updates |
| 11:44 |
gregorycu |
err... shader updates |
| 11:44 |
kilbith |
yes, the tip comes from Calinou |
| 11:44 |
gregorycu |
If people try this, we can see if other people benefit from this improvement |
| 11:44 |
celeron55 |
tell everyone to not use -n unless absolutely required; it's designed to make people not typo their settings |
| 11:44 |
celeron55 |
with -n it will add new settings |
| 11:45 |
celeron55 |
without -n it will check that it's an existing setting |
| 11:45 |
gregorycu |
Anyone game enough to try? |
| 11:46 |
sfan5 |
"vblank_mode=0 ./minetest" |
| 11:46 |
sfan5 |
run minetest like that to disable the forced vsync on intel |
| 11:46 |
JakubVanek |
yep |
| 11:46 |
JakubVanek |
to vblank_mode |
| 11:47 |
celeron55 |
seems to do the trick |
| 11:47 |
gregorycu |
If anyone is keen: https://gist.github.com/gregorycu/5704c5bf1d2266193976 |
| 11:47 |
gregorycu |
(this is not a solution, just a test to see if other people are affected by the same performance hit) |
| 11:47 |
celeron55 |
so to everyone doing this test: set your viewing range to be locked to a value where the game loads terrain in a reasonable amount of time |
| 11:47 |
celeron55 |
so that you are measuring the fpses at a constant draw distance |
| 11:48 |
celeron55 |
(for me 200 is a good value for testing) |
| 11:48 |
gregorycu |
I'm excited about potential 50% perf improvement for pretty much no work |
| 11:51 |
sfan5 |
w/o shaders: 100 fps w/ shaders: 80 fps |
| 11:51 |
celeron55 |
50 with shaders, 70 without shaders, with shaders with patch varies between 60-70 |
| 11:51 |
kahrl |
nrzkt: did you want to close #1148? |
| 11:51 |
ShadowBot |
https://github.com/minetest/minetest/issues/1148 -- Please include Lithuanian translation (lt.po) from http://translate.minetest.ru/projects/minetest/core/ |
| 11:52 |
celeron55 |
(the variance might come from the GPU getting heated up and throttling) |
| 11:52 |
celeron55 |
so yes, there's a measurable difference |
| 11:53 |
gregorycu |
Ok, that's good enough for me |
| 11:56 |
Megaf |
nrzkt: est31: I think all doc should be in a git wiki, |
| 11:57 |
gregorycu |
I think you're quite likely to get higher variance at greater fps |
| 11:57 |
gregorycu |
(More data getting sent) |
| 12:06 |
est31 |
Megaf, what does c55 think? other devs? |
| 12:06 |
Megaf |
I can't see why not use the git's built in wiki |
| 12:07 |
Megaf |
^ celeron55 |
| 12:07 |
Megaf |
kahrl: ^ |
| 12:07 |
Megaf |
Opinions on using git's wiki as only doc? |
| 12:07 |
celeron55 |
there is no wiki in git |
| 12:07 |
celeron55 |
do you mean github |
| 12:07 |
Megaf |
yep |
| 12:08 |
celeron55 |
it's too cramped |
| 12:08 |
celeron55 |
it's meant for smaller amounts of documentation than what minetest uses |
| 12:08 |
Megaf |
https://help.github.com/articles/about-github-wikis/ |
| 12:09 |
Megaf |
I think it's just perfect |
| 12:09 |
gregorycu |
The other option is to store it in source control, and use a tool to populate the wikis |
| 12:10 |
Megaf |
I believe we should give a try to github wiki thing and see how it looks |
| 12:10 |
Megaf |
if it doesn't look ok, than we just move on |
| 12:11 |
celeron55 |
you haven't given even one good reason to use it over what there currently is |
| 12:11 |
celeron55 |
also, in my opinion minetest's download must come with a compact reference documentation |
| 12:12 |
celeron55 |
it saves the day when your internet is broken for whatever stupid reason |
| 12:12 |
gregorycu |
Just a text file? |
| 12:12 |
|
PilzAdam joined #minetest-dev |
| 12:13 |
celeron55 |
lua_api.txt works fine for that purpose; it also works fine for the purpose of having a canonical documentation which can be updated with reasonable effort when coding the actual implementation |
| 12:13 |
gregorycu |
PilzAdam: You wanna help out a brother with something? |
| 12:13 |
celeron55 |
if a wiki is the canonical documentation, then people are likely to just not update it with the code |
| 12:13 |
Megaf |
and what about having the documentation in HTML4? Then it could be included in minetest and the very same file could be used on a site |
| 12:13 |
gregorycu |
Why 4? What about 4.1? |
| 12:13 |
est31 |
the documentation is already in markdown |
| 12:14 |
Megaf |
4.x* |
| 12:14 |
Megaf |
I mean, not HTML5 to be lighter |
| 12:14 |
celeron55 |
no this sounds like change for the sake of change |
| 12:14 |
est31 |
thats the problem I think. The doc only gets updated when sb codes the implementation. |
| 12:14 |
gregorycu |
If this is an issue, maybe an github issue is best, I don't know what problems we are trying to solve |
| 12:14 |
celeron55 |
what real-world problem are you solving? |
| 12:15 |
est31 |
PRs should only be merged when both wiki and lua_api.txt have sufficiant docs |
| 12:16 |
est31 |
thats my issue -- a missing good resource for the lua api |
| 12:16 |
est31 |
neither wiki nor lua_api.txt fulfill this requirement |
| 12:16 |
est31 |
wiki is outdated and incomplete |
| 12:16 |
celeron55 |
you don't solve that by forcing more friction into development; you solve that by having people who maintain the extended documentation |
| 12:16 |
est31 |
lua_api is just too concise |
| 12:17 |
gregorycu |
Do you mean dense? |
| 12:17 |
est31 |
no, dense means everything is there |
| 12:17 |
est31 |
but honestly I've tried to code only with the lua_api doc, and I've failed |
| 12:17 |
celeron55 |
there's no way on earth that lua_api.txt could be extended so much that everyone would be happy with the extent of information in there |
| 12:17 |
gregorycu |
You mean concise in a negative sense, I don't understand what you mean? |
| 12:17 |
celeron55 |
it requires a wiki |
| 12:17 |
est31 |
Ive ended up either inspecting source or copying from other mods |
| 12:17 |
celeron55 |
and there's no way developers would write that much information either |
| 12:18 |
celeron55 |
these are practical constraints |
| 12:18 |
gregorycu |
concise: giving a lot of information clearly and in a few words; brief but comprehensive. |
| 12:18 |
gregorycu |
too concise? |
| 12:18 |
gregorycu |
Did you mean terse? |
| 12:18 |
Megaf |
there could be a wiki, wherever you want, and it could be converted to html and that covnersion included in minetest. So there will be only one thing to maintain and update |
| 12:19 |
gregorycu |
I actually have an idea |
| 12:19 |
Megaf |
or at least som articles of it |
| 12:19 |
gregorycu |
(Strange isn't it) |
| 12:19 |
est31 |
they shouldnt write full examples and so on, just a sane api documentation with what is returned, when its returned, what the params are, and which minetest version supports the functionality |
| 12:19 |
celeron55 |
wiki-only docs will create huge issues when different versions of minetest |
| 12:19 |
gregorycu |
Some sort of markup which is checked in (like lua_api) which populates the wiki, however, additions can be made to the wiki |
| 12:19 |
celeron55 |
with the single canonical file which gets updated along with the code, the docs always match the code when you pull a version |
| 12:19 |
celeron55 |
it has infinite upsides |
| 12:20 |
celeron55 |
gregorycu: something like that could possibly work |
| 12:20 |
est31 |
I also think that its great to have a single place to get an overview, and I also think that better doc should be bundled with minetest |
| 12:20 |
gregorycu |
The best sites are the ones with documentation, followed by user comments |
| 12:21 |
est31 |
you can then auto-generate the wiki from the bundled doc |
| 12:21 |
gregorycu |
Where user comments are discussions about the API |
| 12:21 |
gregorycu |
Examples etc. |
| 12:21 |
celeron55 |
gregorycu: yes, when it's done like that, the official doc can be quite short |
| 12:21 |
est31 |
I also think I used "I also think" too often :) |
| 12:22 |
celeron55 |
but it does require someone to implement the automation |
| 12:23 |
celeron55 |
but every change requires someone to create something |
| 12:23 |
gregorycu |
lol |
| 12:25 |
celeron55 |
anyway, so, i mean, feel free to try something, but there are reasons why things have been done the way they are |
| 12:25 |
celeron55 |
don't go too idealistic because that rarely works |
| 12:28 |
est31 |
current api doc is already helping alot |
| 12:31 |
gregorycu |
thanks, I wrote it myself |
| 12:31 |
est31 |
? |
| 12:33 |
est31 |
and I guess there are more important issues to be resolved |
| 12:34 |
est31 |
but some devs already object to me adding *version* documentation to lua_api.txt |
| 12:34 |
celeron55 |
hmm what would that looks like? |
| 12:35 |
est31 |
a simple (>=0.4.7) after the function name, or in its own line when the function name is a headline. |
| 12:35 |
celeron55 |
with that tight format adding those to every function and field gets hard to read fast |
| 12:35 |
est31 |
and when a param got added (param >=0.4.7) |
| 12:35 |
|
gregorycu_ joined #minetest-dev |
| 12:35 |
celeron55 |
when most of the time they aren't important |
| 12:36 |
est31 |
they are important when you want to know which version your mod supports minimum |
| 12:36 |
gregorycu_ |
hmm... |
| 12:36 |
gregorycu_ |
can't you just annotate? |
| 12:36 |
gregorycu_ |
Or whatever the git version of that is? |
| 12:36 |
est31 |
? |
| 12:37 |
gregorycu_ |
"annotate" allows you to see when a line was added in source control |
| 12:37 |
gregorycu_ |
What commit did it |
| 12:37 |
est31 |
you mean git blame? |
| 12:37 |
gregorycu_ |
Well, added or changed |
| 12:37 |
est31 |
that doesnt work unfortunately |
| 12:37 |
celeron55 |
the information can be gotten that way, yes; it's not very accessible though |
| 12:37 |
gregorycu_ |
So negative |
| 12:37 |
JakubVanek |
i'm not fan of microsoft but their .NET documentation on MSDN is really good |
| 12:37 |
est31 |
you want to change the doc later on |
| 12:38 |
est31 |
alot of ppl did typo fixes and so on |
| 12:38 |
est31 |
then some people move whole sections |
| 12:38 |
celeron55 |
JakubVanek: they probably have an entire documentation team working on it, we can't aim for the same |
| 12:38 |
est31 |
and so on |
| 12:38 |
|
neoascetic joined #minetest-dev |
| 12:38 |
celeron55 |
the problem is |
| 12:38 |
gregorycu |
We don't need a whole team |
| 12:38 |
gregorycu |
Our API isn't that massive |
| 12:39 |
JakubVanek |
i meant just documentation style |
| 12:39 |
celeron55 |
if lua_api.txt is split to more files (so that it can be more verbose), we probably have to ditch markdown because nothing else than github actually supports links to other pages in markdown |
| 12:39 |
gregorycu |
Give us an example page |
| 12:39 |
celeron55 |
and html is kind of crappy |
| 12:40 |
est31 |
so we can render the markdown with a github compatible renderer? |
| 12:40 |
celeron55 |
you have to be careful to not make the build process horrible so that it actually ends up in buildsd |
| 12:40 |
JakubVanek |
https://msdn.microsoft.com/en-us/library/system.console.writeline(v=vs.110).aspx |
| 12:40 |
celeron55 |
builds* |
| 12:40 |
neoascetic |
doesn't bitbucket support links to relative pages? |
| 12:40 |
JakubVanek |
oh there aren't any examples on that page |
| 12:41 |
JakubVanek |
https://msdn.microsoft.com/en-us/library/system.net.sockets.tcpclient(v=vs.100).aspx |
| 12:41 |
celeron55 |
how about something like https://readthedocs.org/? |
| 12:43 |
est31 |
yes. mt already has sth like that http://rubenwardy.com/minetest_modding_book/lua_api.html |
| 12:43 |
neoascetic |
jekyll may be used for the docs |
| 12:43 |
celeron55 |
it only does a part of the process and doesn't even allow user comments, though |
| 12:43 |
est31 |
its basically lua_api.txt rendered into html |
| 12:43 |
est31 |
we could bundle that |
| 12:44 |
est31 |
every now and then (at least every release) sb does a "update bundled doc" commit |
| 12:45 |
celeron55 |
that's messy |
| 12:46 |
neoascetic |
why write lua api description by our hands? if we have lua api, we may use some kind of docstrings for lua and generate it |
| 12:46 |
kahrl |
since when does rubenwardy's lua_api.html have a scrollbar under every piece of monospace text |
| 12:47 |
celeron55 |
kahrl: it's always broken in different ways; come back some other day and it will have some other interesting surprise 8) |
| 12:47 |
est31 |
:) |
| 12:47 |
JakubVanek |
i agree with neoascetic, documentation generated from comments above functions would be good |
| 12:47 |
est31 |
ok ran out of ideas :) |
| 12:47 |
JakubVanek |
something like javadoc |
| 12:48 |
celeron55 |
MT's lua API is defined partly in C++ and partly in Lua, so that'll take some integration work from the generator side |
| 12:48 |
celeron55 |
it's probably impossible to generate for some parts |
| 12:49 |
celeron55 |
and also, if the point was that we want more examples and stuff, then that's not a solution for it |
| 12:49 |
celeron55 |
that will result in *less* examples, not *more* |
| 12:49 |
celeron55 |
i'd ditch that idea |
| 12:49 |
est31 |
yea |
| 12:49 |
|
Zeno` joined #minetest-dev |
| 12:49 |
celeron55 |
maybe maintain a html documentation in place of lua_api.txt could workr |
| 12:50 |
celeron55 |
with careful use of CSS it might be humanly possible to edit for people that don't want to manage the style |
| 12:50 |
neoascetic |
MT's wiki for developers not maintained at all, regardless it has one page per each API method |
| 12:50 |
celeron55 |
and html supports links so that solves the issue of one huge file |
| 12:50 |
est31 |
make it html only so that people dont have to generate it from some markdown? |
| 12:51 |
celeron55 |
that's what i mean |
| 12:51 |
celeron55 |
no generating of anything, ever |
| 12:51 |
neoascetic |
it is not question about how it should look like, but about who will maintain this documentation |
| 12:51 |
celeron55 |
if it's in place of lua_api.txt, then it will work like lua_api.txt has worked |
| 12:51 |
neoascetic |
open wiki format in this case would be more handy |
| 12:52 |
sfan5 |
i know this would make it more complicated, but why not generate HTML out of some "description"? this would solve the problem of people not wanting to work with e.g. CSS styles |
| 12:52 |
celeron55 |
open wiki is a problem because then it's not in sync with the implementations and requiring developers to go write documentation in some other place than where they commit the code is extremely annoying |
| 12:52 |
est31 |
we could save the double effort of having to change the doc at lua_api and the wiki |
| 12:52 |
est31 |
also it messes up with the PR workflow |
| 12:53 |
celeron55 |
sfan5: i think just using very simple html solves the issue better than using generators |
| 12:54 |
sfan5 |
it probably will |
| 12:54 |
neoascetic |
non-generated documentation may be out of sync too |
| 12:54 |
celeron55 |
no classes, no anything, and a CSS file that does its best to style every kind of tag properly |
| 12:54 |
celeron55 |
but this still has the problem that there is no place for user comments |
| 12:54 |
celeron55 |
with a wiki there is |
| 12:55 |
celeron55 |
but given that currently the wiki is out of date at the user comment side too, i guess user comments are not important |
| 12:56 |
est31 |
generation by javascript? |
| 12:56 |
celeron55 |
and a special site can be created much later if needed |
| 12:56 |
celeron55 |
est31: what do you mean |
| 12:56 |
celeron55 |
having a html page which actually contains markdown, but also runs a javascript to turn it into html? 8) |
| 12:57 |
est31 |
html is unchanged, doc goes to markdown file, opening the html |
| 12:57 |
celeron55 |
you can't open other files using javascript if you open the file locally |
| 12:57 |
est31 |
results in js converting the md to html |
| 12:57 |
celeron55 |
at least chromium will disallow that unless you start it up with a special command line option |
| 12:58 |
celeron55 |
s/open the file/open the html file containing the javascript/ |
| 12:58 |
est31 |
I think thats only for XMLHTTPRequest |
| 12:59 |
celeron55 |
that's the only way for javascript to open a file for custom reading |
| 12:59 |
neoascetic |
may I ask? why approach with open wiki didn't work? how it is differs from html-based docs? |
| 12:59 |
celeron55 |
neoascetic: not in sync with pull requests and the regular development flow |
| 13:00 |
neoascetic |
i. e. docs will lie in the repo, right? |
| 13:00 |
celeron55 |
in my opinion still the best solution could be a wiki into which a base documentation from the code repository is updated, and which users can extend |
| 13:00 |
est31 |
https://www.dartlang.org/articles/embedding-in-html/ |
| 13:00 |
celeron55 |
which gregorycu suggested |
| 13:00 |
est31 |
something like that shouldnt be blocked by chrome |
| 13:00 |
est31 |
more testing needed though |
| 13:01 |
sfan5 |
est31: what code do you want to embed into the docs? |
| 13:01 |
est31 |
md->html parsing code |
| 13:02 |
neoascetic |
github pages with jekyll may be used for this... |
| 13:02 |
sfan5 |
we didn't want a html page that dynamically parses markdown |
| 13:03 |
est31 |
thats only for ppl that have downloaded mt and dont want to convert ("build") it |
| 13:03 |
est31 |
to actual html |
| 13:03 |
neoascetic |
yeah, md is pretty readable |
| 13:03 |
est31 |
its an alternative to using html |
| 13:03 |
celeron55 |
the problem is that md's links are unusable |
| 13:04 |
neoascetic |
I would prefer open docs in Vim instead of browser |
| 13:04 |
celeron55 |
for most people |
| 13:04 |
est31 |
I doubt this will result in something productive :( |
| 13:04 |
neoascetic |
do we have too many API methods for single page? |
| 13:05 |
neoascetic |
I would prefer single-page documentation |
| 13:05 |
celeron55 |
they fit in lua_api.txt with the current verbosity, but if we want to add more information about them (version infromation, examples, whatever), the page becomes way too big |
| 13:05 |
est31 |
I wanted to add a feature (introduced version), it was declined |
| 13:05 |
celeron55 |
that's the base issue here |
| 13:05 |
est31 |
yes |
| 13:08 |
celeron55 |
or, not necessarily way too big, but way too big for many users probably, because again, md's in-page links neither work for most users |
| 13:08 |
celeron55 |
hmm, could that still be reasonable |
| 13:09 |
celeron55 |
it would become like tens of thousands of lines in the future years |
| 13:09 |
celeron55 |
now it's thousands |
| 13:11 |
celeron55 |
maybe if it would be split into like 10 main sections as separate files |
| 13:11 |
est31 |
most packages I know have some automatic step in building docs |
| 13:11 |
celeron55 |
then for the web it could be built into html or just viewed on github |
| 13:11 |
celeron55 |
and it would still be relatively usable when viewed as .md files in a local repo |
| 13:11 |
Zeno` |
What is the new directory structure and where was it discussed? |
| 13:12 |
celeron55 |
nobody has proposed any structure |
| 13:12 |
Zeno` |
#2277 suggests it has |
| 13:12 |
ShadowBot |
https://github.com/minetest/minetest/issues/2277 -- Main.cpp cleanup: Move ClientLauncher and InputHandlers to dedicated files by nerzhul |
| 13:12 |
neoascetic |
do we need this docs for previous versions? |
| 13:12 |
celeron55 |
it would probably be something like doc/lua_api/hud.md, doc/lua_api/somethingelse.md and so on |
| 13:12 |
celeron55 |
Zeno`: oh you refer to some other discussion |
| 13:13 |
celeron55 |
neoascetic: users need, and developers need matching documentation when checking out a certain git version |
| 13:14 |
celeron55 |
at least in my opinion |
| 13:14 |
neoascetic |
I think readthedocs in this case will be the best solution |
| 13:15 |
neoascetic |
http://bootstrap-datepicker.readthedocs.org/en/release/ |
| 13:15 |
neoascetic |
for example |
| 13:15 |
neoascetic |
version selector in the footer |
| 13:15 |
celeron55 |
where is that generated from |
| 13:15 |
neoascetic |
https://github.com/eternicode/bootstrap-datepicker/tree/master/docs |
| 13:17 |
celeron55 |
the overall sturcture is quite like what i said (about 10 files) |
| 13:17 |
celeron55 |
so that could be fed to readthredocs with reasonable results |
| 13:17 |
celeron55 |
altough, it's prefectly readable on github too |
| 13:19 |
neoascetic |
build and uploading to readthedocs may be done in automatic way with travis-ci |
| 13:19 |
est31 |
https://read-the-docs.readthedocs.org/en/latest/webhooks.html |
| 13:19 |
celeron55 |
so does someone have thoughtful comments about splitting lua_api.txt to about 5-10 parts and then allowing people to make them more verbose? |
| 13:20 |
neoascetic |
est31 this even better |
| 13:21 |
neoascetic |
anyway, we need some way to keep this info synced with the code |
| 13:21 |
celeron55 |
the way is the same as before: manually checking that whenever someone changes the lua api implementation, the commit must also update the documentation |
| 13:21 |
celeron55 |
it has worked reasonably well in my opinion |
| 13:22 |
neoascetic |
great then |
| 13:22 |
celeron55 |
only the wiki is considerably out of date |
| 13:22 |
neoascetic |
do we need it in this case? |
| 13:22 |
neoascetic |
I think Disqus comments or something else may be placed to readthedocs pages |
| 13:23 |
celeron55 |
the API docs in the wiki probably become obsolete if this turns out well |
| 13:24 |
celeron55 |
someone has to still draw a line in the verbosity though - i mean, rubenwardy's page is essentially a book about minetest modding |
| 13:24 |
celeron55 |
the internal docs probably should be less verbose than that |
| 13:24 |
est31 |
yes |
| 13:26 |
celeron55 |
it's very easy to go more verbose; i mean, the lua api already is almost equally long if you add any kind of examples about anything |
| 13:27 |
celeron55 |
i don't know what rubenwardy's intention is; if he's not wanting to make an actual printed book, he might want to switch to the internal docs in place of that one |
| 13:28 |
neoascetic |
I want docs about Engine itself be available with approach, not only lua docs |
| 13:29 |
Zeno` |
Why is there a rush to have #2277 merged? |
| 13:29 |
ShadowBot |
https://github.com/minetest/minetest/issues/2277 -- Main.cpp cleanup: Move ClientLauncher and InputHandlers to dedicated files by nerzhul |
| 13:29 |
|
luizrpgluiz joined #minetest-dev |
| 13:29 |
celeron55 |
neoascetic: we have doxygen for that |
| 13:29 |
Zeno` |
we discussed this yesterday and agreed that no harm could come from waiting |
| 13:29 |
celeron55 |
it's not properly usable for the lua interface |
| 13:30 |
Zeno` |
It's not that I disagree with the commit (I like it)... but, I just don't understand the urgency |
| 13:30 |
celeron55 |
and it's different in nature anyway (the other one is a public api while the other one is just internal implementation details) |
| 13:30 |
neoascetic |
I want something like on dev wiki with diagrams, images, etc. I guess it isn't available with doxygen |
| 13:31 |
luizrpgluiz |
hello, how do I get the 0.4.12-dev version? |
| 13:31 |
est31 |
I dont think its a rush zeno, its an attempt by nerzhul to make shorter PR lifetimes. |
| 13:32 |
Zeno` |
est31, no it's not. It's something that is, in essence, cosmetic and there has been no chance for all devs to have input |
| 13:32 |
|
ImQ009 joined #minetest-dev |
| 13:33 |
JakubVanek |
git clone https://github.com/minetest/minetest.git; git checkout freeze-0.4.12 |
| 13:33 |
JakubVanek |
^ luizrpgluiz |
| 13:35 |
Zeno` |
est31, how can it hurt leaving that PR just a little bit? It doesn't add or fix anything |
| 13:36 |
est31 |
so when it doesnt add, then its very simple? |
| 13:36 |
celeron55 |
if you define how long it should wait for comments, then it's fine |
| 13:36 |
celeron55 |
leaving it for an unknown time is bad |
| 13:37 |
Zeno` |
I said yesterday that maybe leaving it for 4 or 5 days would be good to give it a chance to be discussed |
| 13:37 |
celeron55 |
i don't think anyone has the energy to discuss it though |
| 13:37 |
Zeno` |
hmm |
| 13:37 |
celeron55 |
i at least don't want to even see it anymore (no matter if it's merged or not) |
| 13:38 |
est31 |
how is that meant |
| 13:39 |
Zeno` |
Like I said, I agree with the commit. I just don't see why it *must* be merged today |
| 13:39 |
celeron55 |
i mean it's really just bikeshedding and if it will wait for comments, just comment to that to it and let it be; nobody wants to see the matter of whether it should wait for comments to be discussed because it's just wasting everyone's time |
| 13:40 |
luizrpgluiz |
can someone pass me the changelog development minetest? on additions and bug fixes? |
| 13:40 |
celeron55 |
http://dev.minetest.net/Changelog |
| 13:40 |
celeron55 |
you should learn to use google |
| 13:40 |
kilbith |
luizrpgluiz: with a coffee with that ? |
| 13:41 |
luizrpgluiz |
forgot to mention, it would be the changelog github because I can read the feature they are testing |
| 13:43 |
celeron55 |
kilbith: lol |
| 13:49 |
Zeno` |
ok, if it's not worth discussing then I agree that #2277 should be merged |
| 13:49 |
ShadowBot |
https://github.com/minetest/minetest/issues/2277 -- Main.cpp cleanup: Move ClientLauncher and InputHandlers to dedicated files by nerzhul |
| 13:50 |
Zeno` |
it makes things neater |
| 13:50 |
nrzkt |
kahrl, yes i would want to close it, files are present no ? #1148 (sorry i went lunch) |
| 13:50 |
Zeno` |
and is something that should have been done already anyway. |
| 13:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/1148 -- Please include Lithuanian translation (lt.po) from http://translate.minetest.ru/projects/minetest/core/ |
| 13:50 |
Zeno` |
nrzkt, merge :p |
| 13:50 |
luizrpgluiz |
how long before the official release of 0.4.12? |
| 13:51 |
Zeno` |
"When it's ready"? :D |
| 13:52 |
celeron55 |
luizrpgluiz: nobody knows, it ended up being a bit of a mess |
| 13:52 |
celeron55 |
i decided we'll just get back to development and 0.4.12 is released on the side, if it is at all |
| 13:53 |
luizrpgluiz |
but what kind of confusion celeron55? |
| 13:53 |
celeron55 |
some bug that i haven't cared to look into at all |
| 13:54 |
nrzkt |
ok Zeno` i merge it, (sorry 2 hours of IRC cross conversations to decode xD) |
| 13:55 |
nrzkt |
celeron55 you mean 0.4.12 will be released soon ? :) |
| 13:56 |
celeron55 |
i don't know, i won't be doing it |
| 13:56 |
JakubVanek |
please wait with #2052, i'm doing last review |
| 13:56 |
ShadowBot |
https://github.com/minetest/minetest/issues/2052 -- Update czech translation by JakubVanek |
| 13:56 |
nrzkt |
Ok Jakub |
| 13:56 |
nrzkt |
for translations, how we merge it properly ? |
| 13:56 |
celeron55 |
hmmmm probably has some idea about 0.4.12 |
| 13:56 |
nrzkt |
i saw there is the update-po.sh, but does it needs to be run at each PR merge ? |
| 13:56 |
celeron55 |
does Zeno` know anything about it? |
| 13:56 |
Zeno` |
About what? |
| 13:57 |
JakubVanek |
i already ran it and then called checkout -- to other languages |
| 13:57 |
JakubVanek |
^ nrzkt (util/updatepo.sh) |
| 13:58 |
nrzkt |
comments for #2240, #2181 and #2285 ? |
| 13:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/2240 -- Fix occlusion by mamoit |
| 13:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/2181 -- Fix .zip extraction by ngosang |
| 13:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/2285 -- No damage in creative mode |
| 13:58 |
Zeno` |
If you're talking about the main.cpp PR then of course I do. I refactored main() to not be 2000 lines in one function and I've also been looking at the PR for the last two days |
| 13:58 |
celeron55 |
Zeno`: i mean 0.4.12 |
| 13:58 |
nrzkt |
yes JakubVanek it's what i say, must i run it after merge or not ? |
| 13:58 |
Zeno` |
oh that |
| 13:58 |
Zeno` |
I think it's a Windows hold-up? |
| 13:58 |
nrzkt |
because when i tested your PR there was 2-4K modifications on all PO |
| 13:59 |
Zeno` |
I don't know. Blockmen has a PR though to fix some gettext() issues |
| 13:59 |
nrzkt |
Zeno` i merge 2277 now |
| 13:59 |
Zeno` |
I think the Windows thing was the hold up. But I don't know 100% |
| 14:00 |
JakubVanek |
nrzkt: yes for other languages (they're not updated), nothing will happen to czech |
| 14:00 |
JakubVanek |
because it already contains all strings |
| 14:01 |
celeron55 |
it would probably be a good idea if someone would take the task of making 0.4.12 releaseable and telling when it is (and/or what needs to be done before it is) |
| 14:01 |
nrzkt |
tell me when your PR will be ready, i reviewed it seems very good |
| 14:06 |
Zeno` |
nobody is assigned to releasing 0.4.12? |
| 14:06 |
celeron55 |
not really, unless you count hmmmm who turned quite inactive again |
| 14:06 |
Zeno` |
nrzkt, #2181 looks good |
| 14:06 |
ShadowBot |
https://github.com/minetest/minetest/issues/2181 -- Fix .zip extraction by ngosang |
| 14:07 |
celeron55 |
i think he practically dropped it |
| 14:07 |
Zeno` |
I agree with PA that #2285 is a bug |
| 14:07 |
ShadowBot |
https://github.com/minetest/minetest/issues/2285 -- No damage in creative mode |
| 14:08 |
Zeno` |
I don't know about the occlusion fix... I'd need to look at the code more |
| 14:09 |
|
shadowzone joined #minetest-dev |
| 14:09 |
Zeno` |
celeron55, I don't know how the release process works. I assume it involves making "official" binaries for supported platforms? |
| 14:09 |
|
shadowzone joined #minetest-dev |
| 14:09 |
celeron55 |
http://dev.minetest.net/Releasing_Minetest |
| 14:09 |
celeron55 |
this is mostly up to date |
| 14:10 |
celeron55 |
but more important than that process is making sure that it's ready for release |
| 14:10 |
shadowzone |
Good morning/afternoon/evening everbody! |
| 14:10 |
celeron55 |
then that process is trivial to execute |
| 14:10 |
nrzkt |
hello shadowzone |
| 14:11 |
celeron55 |
so the concern is that it should compile and work on all platforms where the release is going to be built for |
| 14:11 |
Zeno` |
I'll look at the freeze branch tomorrow and cherry pick any committed fixes I guess |
| 14:11 |
Zeno` |
I'm pretty sure the Windows build was the main hold up |
| 14:12 |
celeron55 |
go ask some windows build person whether it's working properly |
| 14:12 |
celeron55 |
i guess that'll be enough for it then |
| 14:13 |
Zeno` |
yeah, waiting on more feedback regarding #2295 |
| 14:13 |
ShadowBot |
https://github.com/minetest/minetest/issues/2295 -- Fix gettext on MSVC by BlockMen |
| 14:13 |
Zeno` |
Krock has built the latest HEAD so his input would be nice also |
| 14:14 |
celeron55 |
then if it seems to be ok for release, you can hilight me if you don't want to go through the release process yourself |
| 14:14 |
celeron55 |
hmmmm is known to be able to do it properly too (i guess he can do it if he's around at the time) |
| 14:14 |
shadowzone |
*highlight* Sorry, I felt like I should correct that. So, pardon me. |
| 14:15 |
Zeno` |
I'll highlight it because I cannot seem to build with mingw (I need to use TDM-GCC for some reason) |
| 14:15 |
celeron55 |
i don't have a working mingw setup either |
| 14:15 |
shadowzone |
Is Mingw windows? |
| 14:16 |
celeron55 |
(i'd just ask some regular windows builder to make a build) |
| 14:16 |
shadowzone |
I have windows. |
| 14:16 |
celeron55 |
the windows build details on that page are probably outdated anyway |
| 14:20 |
Zeno` |
mingw is windows and can also be cross-compiled, shadowzone |
| 14:20 |
Zeno` |
it just doesn't work for me and I don't know why |
| 14:21 |
shadowzone |
Zeno`, when I get to my desk, I could try it. |
| 14:21 |
Zeno` |
if you like :) |
| 14:27 |
|
BlockMen joined #minetest-dev |
| 14:31 |
luizrpgluiz |
someone has issues where the link has the days of development minetest? |
| 14:34 |
|
nrzkt joined #minetest-dev |
| 14:35 |
BlockMen |
can someone confirm gettext works fine on linux with #2295? |
| 14:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/2295 -- Fix gettext on MSVC by BlockMen |
| 14:35 |
nrzkt |
i test it now |
| 14:37 |
BlockMen |
thx |
| 14:39 |
nrzkt |
what do you need exactly ? it seems translations are working |
| 14:40 |
BlockMen |
thats all, actually. just wanted prevent breaking it the other way round |
| 14:43 |
BlockMen |
fine with mergin then, nrzkt? |
| 14:44 |
nrzkt |
seems good for me. Zeno` do you agree ? |
| 14:49 |
|
CraigyDavi joined #minetest-dev |
| 14:51 |
Zeno` |
BlockMen, save me some time. What was the memory leak? |
| 14:52 |
|
luizrpgluiz left #minetest-dev |
| 14:53 |
BlockMen |
Zeno`, not releasing tmp in wstrgettext |
| 14:53 |
nrzkt |
in previous version return directly |
| 14:53 |
Zeno` |
also... memset(buffer, 0, sizeof(buffer)); ... what is sizeof(wchar_t)? |
| 14:54 |
Zeno` |
I rather see this as ARRLEN (or whatever the macro in utils/ is called which should do sizeof(buffer) / sizeof(*buffer)) |
| 14:54 |
Zeno` |
err * |
| 14:55 |
Zeno` |
so maybe the macro is not so good, but sizeof(wchar_t) is still important |
| 14:55 |
Zeno` |
actually scratch that... I'm tired :/ |
| 14:58 |
Zeno` |
looks ok to me |
| 14:59 |
Zeno` |
const wchar_t* tmp = wgettext(text.c_str()); --> const wchar_t *tmp = wgettext(text.c_str()); |
| 15:04 |
BlockMen |
changed. when do i use this new "ok" thing? |
| 15:04 |
Zeno` |
and ok thing? |
| 15:04 |
Zeno` |
err ok thing? |
| 15:04 |
est31 |
+1 i guess |
| 15:05 |
BlockMen |
some commits have now <commitmsg>. ok @<coredev> |
| 15:05 |
Zeno` |
oh that was a temporary mistake |
| 15:05 |
|
SopaXorzTaker joined #minetest-dev |
| 15:06 |
BlockMen |
ic. then im pushing now |
| 15:06 |
Zeno` |
just let me check one thing? |
| 15:06 |
BlockMen |
k. |
| 15:06 |
nrzkt |
sorry BlockMen, i used openbsd method for validation :) |
| 15:08 |
fireglow |
"<coredev>@" |
| 15:09 |
nrzkt |
yes, the method, not the syntax :p |
| 15:09 |
nrzkt |
:q |
| 15:10 |
Zeno` |
BlockMen, +1 |
| 15:10 |
Zeno` |
go for it :p |
| 15:12 |
BlockMen |
done |
| 15:16 |
|
proller joined #minetest-dev |
| 15:25 |
Zeno` |
can someone look at the freeze branch? |
| 15:25 |
Zeno` |
I'm 99.9999999999% sure I pushed properly but github is displaying a strange thing to me |
| 15:26 |
nrzkt |
? |
| 15:26 |
Zeno` |
just see if the history looks right I guess |
| 15:26 |
Zeno` |
I dunno why github is wanting me to compare and pull request :/ |
| 15:27 |
Zeno` |
very strange |
| 15:28 |
Zeno` |
maybe it (github) wants me to compare to master... *shrug* |
| 15:29 |
Zeno` |
https://github.com/minetest/minetest/tree/freeze-0.4.12 looks fine to me anyway |
| 15:29 |
PilzAdam |
celeron55, I have a question about the freeze branches: will the commit in the freeze branch be tagged on release? or will it be merged to stable-0.4 and then tagged? how will future freeze branches be merged to stable then, if we don't have a linear history anymore? |
| 15:30 |
Zeno` |
I personally think the branch should be renamed and also have tags |
| 15:30 |
* Zeno` |
is afk |
| 15:31 |
Zeno` |
dammit BlockMen! I was watching something on utube and now doing all that I've closed firefox |
| 15:32 |
BlockMen |
Zeno`, hmm? |
| 15:32 |
BlockMen |
what did i do? |
| 15:32 |
Zeno` |
nothing I guess. Don't worry ;) (I was joking) |
| 15:33 |
nrzkt |
i agree with Zeno`. Using a stable branche with tags is proper |
| 15:33 |
BlockMen |
Zeno`:P |
| 15:33 |
nrzkt |
BlockMen, Zeno`, review on #2169 please |
| 15:33 |
ShadowBot |
https://github.com/minetest/minetest/issues/2169 -- Minor fixes in translations by ngosang |
| 15:35 |
JakubVanek |
nrzkt: PR #2052 is ready |
| 15:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/2052 -- Update czech translation by JakubVanek |
| 15:35 |
nrzkt |
ok, i review and merge |
| 15:36 |
JakubVanek |
updatepo.sh will be needed also after merging #2169 |
| 15:36 |
BlockMen |
nrzkt, #2169 seems ok. |
| 15:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/2169 -- Minor fixes in translations by ngosang |
| 15:36 |
ShadowBot |
https://github.com/minetest/minetest/issues/2169 -- Minor fixes in translations by ngosang |
| 15:39 |
nrzkt |
after 2169 => 24 files changed, 8263 insertions(+), 5265 deletions(-) arg |
| 15:39 |
nrzkt |
argh |
| 15:39 |
nrzkt |
does somebody update this file sometimes ? |
| 15:39 |
Zeno` |
Tesseract does I think |
| 15:40 |
nrzkt |
i let him doing that, i only merge the PR |
| 15:40 |
|
DFeniks joined #minetest-dev |
| 15:40 |
Zeno` |
Don't take my word for it though :) |
| 15:40 |
|
twoelk joined #minetest-dev |
| 15:44 |
celeron55 |
PilzAdam: the freeze branch won't exist forever so it must be the commit on the stable branch |
| 15:44 |
celeron55 |
and using merge commits on the stable branch is probably a good idea(?) |
| 15:45 |
celeron55 |
this is new to me too so i'm not exactly sure |
| 15:45 |
celeron55 |
there's probably some best way of doing itt |
| 15:45 |
celeron55 |
it* |
| 15:45 |
nrzkt |
i'm using a pull from feature freeze to stable at work it works well |
| 15:46 |
|
SudoAptGetPlay joined #minetest-dev |
| 15:46 |
nrzkt |
but we must be careful if we do a commit on master which must be backported to stable |
| 15:48 |
nrzkt |
#2052 and #2169 have been merged, thanks |
| 15:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2052 -- Update czech translation by JakubVanek |
| 15:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2169 -- Minor fixes in translations by ngosang |
| 15:50 |
|
Vexyl left #minetest-dev |
| 16:05 |
BlockMen |
sfan5, whats your opinion on https://github.com/minetest/minetest_game/pull/420? |
| 16:06 |
sfan5 |
looks good, BlockMen |
| 16:08 |
|
Wayward_One joined #minetest-dev |
| 16:11 |
|
shadowzone joined #minetest-dev |
| 16:11 |
|
hmmmm joined #minetest-dev |
| 16:14 |
|
SopaXorzTaker joined #minetest-dev |
| 16:18 |
|
Krock joined #minetest-dev |
| 16:19 |
BlockMen |
sfan5, PilzAdam : fine with closing game#382 ? |
| 16:19 |
ShadowBot |
https://github.com/minetest/minetest_game/issues/382 -- Update nodes.lua by TheShadowZone12 |
| 16:20 |
sfan5 |
yup |
| 16:20 |
PilzAdam |
yes |
| 16:20 |
shadowzone |
Go ahead, it's been open and idle for a while, just close it. |
| 16:26 |
|
MinetestForFun joined #minetest-dev |
| 16:29 |
|
crazyR joined #minetest-dev |
| 16:34 |
|
zat joined #minetest-dev |
| 16:36 |
|
ImQ009 joined #minetest-dev |
| 16:41 |
BlockMen |
PilzAdam, minetest_game maintainer rule changed: 50% present maintainers or at least 2 have to agree http://dev.minetest.net/minetest_game_Development |
| 16:41 |
BlockMen |
~tell nore minetest_game maintainer rule changed: 50% present maintainers or at least 2 have to agree http://dev.minetest.net/minetest_game_Development |
| 16:41 |
|
rubenwardy joined #minetest-dev |
| 16:41 |
ShadowBot |
BlockMen: O.K. |
| 16:41 |
BlockMen |
~tell Tesseract minetest_game maintainer rule changed: 50% present maintainers or at least 2 have to agree http://dev.minetest.net/minetest_game_Development |
| 16:41 |
ShadowBot |
BlockMen: O.K. |
| 16:45 |
|
roniz joined #minetest-dev |
| 16:46 |
rubenwardy |
I sugges the title for #2291 is changed to "Engine API for Mobs". |
| 16:46 |
ShadowBot |
https://github.com/minetest/minetest/issues/2291 -- Idea : C++ Mobs. |
| 16:47 |
nrzkt |
done |
| 16:47 |
rubenwardy |
Awesome |
| 16:47 |
|
SudoAptGetPlay joined #minetest-dev |
| 16:48 |
BlockMen |
PilzAdam, why? https://github.com/minetest/minetest_game/blame/master/mods/default/nodes.lua#L1101 |
| 16:48 |
BlockMen |
those were ment to be overrideable |
| 16:49 |
PilzAdam |
https://github.com/minetest/minetest/blob/master/doc/lua_api.txt#L1689 |
| 16:49 |
PilzAdam |
they are overrideable |
| 16:50 |
nrzkt |
rubenwardy, it's not my first priority, but when we fixed some of awaiting PR's and finished the network rework i'll look at this |
| 16:50 |
PilzAdam |
it's the same weird thing with lava and water viscosity: why are some random node fields stored in global variables? |
| 16:51 |
PilzAdam |
everything can be read from minetest.registered_nodes and everything can be overridden by minetst.overide_item |
| 16:51 |
rubenwardy |
Networking is way more important, and general bug catching. |
| 16:54 |
BlockMen |
PilzAdam, so instead overriding one global i have at least to override a whole function and the item itself. |
| 16:54 |
BlockMen |
sorry, but that is no improvment |
| 16:57 |
PilzAdam |
oh, right, it's accessed from a function and not stored in nodedef... |
| 16:58 |
PilzAdam |
how about storing it in the nodedef then? |
| 16:58 |
rubenwardy |
#2299 |
| 16:58 |
ShadowBot |
https://github.com/minetest/minetest/issues/2299 -- Fix minetest.item_eats replace_with_item, fixes #2292 by rubenwardy |
| 16:59 |
|
SudoAptGetPlay joined #minetest-dev |
| 17:00 |
|
proller joined #minetest-dev |
| 17:00 |
rubenwardy |
^ that should go into the feature freeze |
| 17:02 |
est31 |
also, consider #2225 |
| 17:02 |
ShadowBot |
https://github.com/minetest/minetest/issues/2225 -- Fix for getCraftRecipes implementation is very slow by gregorycu |
| 17:02 |
BlockMen |
then you would still need to override the node/item and a function, e.g. for the furnace. some things are better stored in globals |
| 17:02 |
est31 |
not for the freeze but for 5.0 |
| 17:04 |
PilzAdam |
rubenwardy, not a bug |
| 17:04 |
PilzAdam |
BlockMen, no, you would just need to override the field that holds the formspec then |
| 17:04 |
PilzAdam |
since the function would access that field |
| 17:06 |
BlockMen |
so you still need more code. also, even if you were right you broke mod compatibility |
| 17:06 |
BlockMen |
so i will revert it |
| 17:07 |
BlockMen |
or since you are maintainer aswell, feel free to do it |
| 17:07 |
PilzAdam |
is there a mod that is broken? |
| 17:07 |
PilzAdam |
also that field was not documented in game_api.txt |
| 17:07 |
BlockMen |
e.g. the crafting mod(pack) |
| 17:08 |
BlockMen |
and the game_api.txt was generally incomplete (see tree growing functions) |
| 17:08 |
PilzAdam |
hm... I still think it is not the correct way to do this, though |
| 17:08 |
PilzAdam |
also it doesn't really require more code |
| 17:08 |
|
Hunterz joined #minetest-dev |
| 17:09 |
PilzAdam |
minetst.override_item("default:chest", {formspec="lalala"}) is not a lot more than default.chest_formspec = "lalala" |
| 17:10 |
|
SudoAptGetPlay joined #minetest-dev |
| 17:11 |
BlockMen |
wut? you have to override on_construct, not "formspec", so you have to copy everything else in this function just for the formspec |
| 17:11 |
BlockMen |
and furthermore, you broke an existing feature, so it doesnt matter. until we dont break compatibility in general it has to be fixed |
| 17:12 |
PilzAdam |
what I suggested is: don't store the formspec string in the nodedef table instead of a separate variable |
| 17:12 |
PilzAdam |
s/don't// |
| 17:12 |
PilzAdam |
on_construct would access the nodedef field instead, so other mods would only need to override this field |
| 17:12 |
rubenwardy |
It is when it replaces all of the stack, rather than the item which you just ate. |
| 17:13 |
PilzAdam |
it's a cleaner way since the formspec is a part of the chest definition |
| 17:13 |
BlockMen |
doesnt work for furnace, https://github.com/minetest/minetest_game/blob/master/mods/default/furnace.lua#L6 |
| 17:14 |
PilzAdam |
for the furnace it would be a function in the nodedef then |
| 17:14 |
BlockMen |
then add some legacy for the canceled functions |
| 17:15 |
PilzAdam |
hmm... I don't see a good way to do this in a backward compatible way :-/ |
| 17:16 |
PilzAdam |
or is there a way to make the furnace field in the chest nodedef a pointer to default.chest_formspec? |
| 17:16 |
PilzAdam |
Tesseract, ^ ? |
| 17:16 |
Tesseract |
Hmmm? |
| 17:17 |
Tesseract |
furnace = default.chest_formspec? |
| 17:17 |
PilzAdam |
that would copy it |
| 17:18 |
PilzAdam |
it needs to be backward compatible for mods that want to override default.chest_formspec |
| 17:19 |
est31 |
for clarification, the version after 0.4.12 will be called 5.0? |
| 17:20 |
Tesseract |
You could use some setmetatable hackery, but builtin uses setmetatable, so you would have to be carefull with how you did it. |
| 17:21 |
Tesseract |
If mods were using an undocumented API then it's their problem if their mod breaks though. |
| 17:22 |
est31 |
or will it be called 0.5.0 |
| 17:23 |
PilzAdam |
est31, version numbers don't matter |
| 17:23 |
est31 |
so its not decided yet |
| 17:24 |
est31 |
nvm, you are right, they dont matter |
| 17:26 |
BlockMen |
Tesseract, _game had never a documentation, just since 0.4.10 there is a small base for it. now blaming mods using features is nonsense |
| 17:27 |
PilzAdam |
I agree that breaking mods is not good |
| 17:39 |
|
Player_2 joined #minetest-dev |
| 17:42 |
Tesseract |
*shrug* Compat will take 5-20 lines of metatable code. |
| 17:50 |
rubenwardy |
#1843 |
| 17:50 |
ShadowBot |
https://github.com/minetest/minetest/issues/1843 -- Add setting to customise stack max by rubenwardy |
| 17:57 |
Tesseract |
PilzAdam, BlockMen: >30 lines actually: http://pastebin.ubuntu.com/10191415/ |
| 18:04 |
|
Calinou joined #minetest-dev |
| 18:07 |
|
roniz_ joined #minetest-dev |
| 18:15 |
|
nrzkt joined #minetest-dev |
| 18:21 |
|
Robert_Zenz joined #minetest-dev |
| 18:24 |
|
Killer joined #minetest-dev |
| 18:26 |
|
paramat joined #minetest-dev |
| 18:26 |
|
Killer left #minetest-dev |
| 18:35 |
nrzkt |
i'll commit a fix for #1573 directly, including Calinou and Kahrl change (with a little change for french) |
| 18:35 |
ShadowBot |
https://github.com/minetest/minetest/issues/1573 -- Add French line to the .desktop file |
| 18:45 |
|
est31 joined #minetest-dev |
| 18:45 |
|
est31 joined #minetest-dev |
| 18:49 |
|
rubenwardy joined #minetest-dev |
| 19:09 |
|
Robert_Zenz joined #minetest-dev |
| 19:12 |
Tesseract |
celeron55, PilzAdam: For the stable-0.4 non-linearity issue: we could make stable-0.4 a tag that's assigned to the most recent freeze-0.4.x branch. |
| 19:13 |
Tesseract |
I think that would solve that issue. |
| 19:13 |
PilzAdam |
updating tags is not easy |
| 19:13 |
PilzAdam |
since everyone has copies in their local repos |
| 19:14 |
PilzAdam |
an a simple pull does not update the tags |
| 19:14 |
Tesseract |
git pull --tags |
| 19:14 |
Tesseract |
Not all that much harder. |
| 19:14 |
celeron55 |
why does it need to be linear? |
| 19:14 |
PilzAdam |
in order to update tags everyone must explicitly remove the old ones (AFAIK) |
| 19:14 |
Tesseract |
celeron55: Because force-pulling is a pain. |
| 19:14 |
celeron55 |
merges are made for this exact use case |
| 19:15 |
celeron55 |
non-linear merges |
| 19:15 |
Tesseract |
PilzAdam: Hmmm, so same issue, just slightly different. |
| 19:15 |
Tesseract |
Yeah, merges might be best. |
| 19:15 |
celeron55 |
you could of course not want to use merge for it, but it would be dumb because it's made for it |
| 19:16 |
celeron55 |
at least this is how it's looking to me |
| 19:27 |
|
ElectronLibre joined #minetest-dev |
| 19:43 |
|
paramat left #minetest-dev |
| 19:43 |
|
OldCoder joined #minetest-dev |
| 19:51 |
|
VargaD_ joined #minetest-dev |
| 20:04 |
|
ImQ009 joined #minetest-dev |
| 20:21 |
nrzkt |
has anybody experience #2300 ? |
| 20:21 |
ShadowBot |
https://github.com/minetest/minetest/issues/2300 -- SharedBuffer ::drop() [T = unsigned char]: Assertion (*refcount) > 0 failed. |
| 20:26 |
|
ImQ009 joined #minetest-dev |
| 20:27 |
est31 |
no, I had some crashes but not that one |
| 20:28 |
Tesseract |
nrzkt: No, but I think I've heard of that before. |
| 20:29 |
|
JakubVanek joined #minetest-dev |
| 20:44 |
|
Amaz joined #minetest-dev |
| 20:45 |
|
JakubVanek joined #minetest-dev |
| 20:50 |
|
Megal joined #minetest-dev |
| 21:00 |
|
linuxtardis joined #minetest-dev |
| 21:43 |
nrzkt |
assert((*refcount) > 0); failed if refcount <= 0, no ? |
| 21:45 |
nrzkt |
the bug seems simple... in drop() we have this assert and if refcount == 0 we do something, but the assert triggers if refcount == 0... |
| 21:46 |
nrzkt |
no. In fact this is correct because we have the refcount-- before |
| 21:46 |
nrzkt |
but is this possible than one thread use same sharedbuffer as another ? then if one decrement the other trigger the refcount assert ? |
| 21:58 |
* Tesseract |
just got another player at absurd coordinates (-200000+) https://forum.minetest.net/viewtopic.php?f=10&t=7351&p=170032#p170032 |
| 21:59 |
|
proller joined #minetest-dev |
| 22:02 |
est31 |
Tesseract, is the change to the worldedit command I did now ok for you? |
| 22:02 |
est31 |
https://github.com/Uberi/Minetest-WorldEdit/pull/71 |
| 22:03 |
Tesseract |
est31: -> #minetest |
| 22:23 |
|
BlockMen left #minetest-dev |
| 22:48 |
est31 |
#2301 ready for review :) |
| 22:48 |
ShadowBot |
https://github.com/minetest/minetest/issues/2301 -- Fix crash on passing false as value in table to table.copy(t) by est31 |
| 22:57 |
|
ElectronLibre left #minetest-dev |
| 23:41 |
|
luizrpgluiz joined #minetest-dev |
| 23:42 |
luizrpgluiz |
hi |
| 23:49 |
Tesseract |
luizrpgluiz: This is a serious development channel, not a casual chatting channel. If you don't have something helpful to say don't say anything. |
| 23:49 |
|
luizrpgluiz left #minetest-dev |
