| Time |
Nick |
Message |
| 00:08 |
|
VanessaE joined #minetest-dev |
| 00:17 |
|
VanessaE joined #minetest-dev |
| 02:18 |
|
SpeedProg1 joined #minetest-dev |
| 03:13 |
VanessaE |
is there a particular reason that map saves use aliased node names? I mean, if I alias some old node "foo:bar" to "abc:def", why is it saved as "abc:def"? |
| 04:18 |
|
loggingbot_ joined #minetest-dev |
| 04:18 |
|
Topic for #minetest-dev is now Minetest core development and maintenance. Chit-chat goes to #minetest. Consider this instead of /msg celeron55. http://irc.minetest.ru/minetest-dev/ http://dev.minetest.net/ |
| 05:03 |
|
TB`oFF|Vibe-X joined #minetest-dev |
| 06:06 |
|
ShadowNinja joined #minetest-dev |
| 06:24 |
|
troller joined #minetest-dev |
| 06:29 |
|
iqualfragile joined #minetest-dev |
| 07:04 |
|
kahrl joined #minetest-dev |
| 07:05 |
kahrl |
hmmm: many distro maintainers despise bundled libraries and want to use system libraries if at all possible |
| 07:06 |
kahrl |
there are a couple blog posts that explain the issues, for example http://blog.flameeyes.eu/2009/01/bundling-libraries-for-despair-and-insecurity |
| 09:34 |
|
darkrose joined #minetest-dev |
| 09:50 |
|
darkrose joined #minetest-dev |
| 09:50 |
|
darkrose joined #minetest-dev |
| 10:25 |
|
jin_xi joined #minetest-dev |
| 10:32 |
|
proller joined #minetest-dev |
| 11:07 |
|
proller joined #minetest-dev |
| 11:56 |
celeron55 |
about bundling libraries in minetest: minetest bundles libraries for the sole reason of compilability on windows, EXCEPT for Lua, which is bundled to keep the version and build options of Lua consistent between different builds of Minetest |
| 11:57 |
celeron55 |
(in addition to the first reason, of course) |
| 11:58 |
celeron55 |
jthread makes the false impression of being much more than what it is to someone who hasn't looked at it's source, which makes package maintainers angrier than they should for modifying it |
| 11:58 |
celeron55 |
it should be renamed if it is to be modified |
| 11:58 |
celeron55 |
hmmmm: ^ |
| 11:59 |
celeron55 |
libjsoncpp or whatever that was simply should not be modified, as shouldn't sqlite3 and lua either |
| 12:43 |
|
iqualfragile joined #minetest-dev |
| 12:58 |
|
troller joined #minetest-dev |
| 13:03 |
|
proller joined #minetest-dev |
| 13:30 |
|
Taoki[mobile] joined #minetest-dev |
| 14:00 |
|
troller joined #minetest-dev |
| 14:06 |
|
proller joined #minetest-dev |
| 14:10 |
|
hmmmm joined #minetest-dev |
| 14:36 |
|
Alfino joined #minetest-dev |
| 15:48 |
|
iqualfragile joined #minetest-dev |
| 15:53 |
|
Jordach joined #minetest-dev |
| 15:53 |
|
Jordach joined #minetest-dev |
| 15:53 |
|
PilzAdam joined #minetest-dev |
| 16:31 |
|
rubenwardy joined #minetest-dev |
| 16:35 |
|
iqualfragile joined #minetest-dev |
| 16:39 |
|
SpeedProg joined #minetest-dev |
| 16:41 |
PilzAdam |
hmmmm, dont rewrite history |
| 16:41 |
PilzAdam |
its better to create a new commit |
| 16:55 |
hmmmm |
why not |
| 16:56 |
PilzAdam |
because pulling these commits is more complicated |
| 16:56 |
hmmmm |
you're, in effect, rewriting history when you squash commits, and that's perfectly acceptable |
| 16:57 |
hmmmm |
just force |
| 16:57 |
PilzAdam |
squashing commits that are not in the upstream/master branch is fine |
| 16:57 |
hmmmm |
we need to squash some of those stupid weblate commits |
| 16:57 |
hmmmm |
the history is getting flooded with those |
| 16:58 |
PilzAdam |
then we will lose the information about the contributors |
| 16:59 |
VanessaE |
so note them in a changelog somewhere |
| 16:59 |
hmmmm |
does their contribution status really need to be in the git |
| 17:01 |
thexyz |
what's the problem with the history being "flooded"? |
| 17:01 |
hmmmm |
it's unrepresentative of the actual development that's going on |
| 17:02 |
celeron55 |
hmmmm: pulling from a repository the history of which has changed in the commits that you've already pulled is 100% shit |
| 17:02 |
celeron55 |
that is why you never modify history that is older than like 3 minutes |
| 17:02 |
celeron55 |
in a public repo |
| 17:03 |
hmmmm |
i didn't think that many people would pull within that period of less than 8 hours.. |
| 17:03 |
celeron55 |
also see my comments at UTC 12:00 today |
| 17:03 |
hmmmm |
nevermind that, what's done is done, if it caused some harm to peoples' clones, it's nothing that can't be fixed without an -f.. and i'm glad i did rewrite history, because it keeps things neater |
| 17:04 |
hmmmm |
i hate it when things are sloppy |
| 17:04 |
celeron55 |
it is sloppy to rewrite history in the upstream repo |
| 17:04 |
celeron55 |
you need to have it perfect before pushing there |
| 17:05 |
hmmmm |
so what do you want to do about the bundled jthread problem? |
| 17:05 |
celeron55 |
either don't modify it, or rename it |
| 17:05 |
celeron55 |
no other options and either is just as fine |
| 17:05 |
hmmmm |
in the same manner as the modifications needed to make json -> jsoncpp? |
| 17:06 |
celeron55 |
if you ask me, the jsoncpp of include in minetest shouldn't be modified at all |
| 17:06 |
celeron55 |
it should be a direct copy of it's upstream |
| 17:06 |
celeron55 |
(except the build system for it) |
| 17:06 |
celeron55 |
(just like lua |
| 17:06 |
celeron55 |
) |
| 17:06 |
hmmmm |
that was causing unforseen problems |
| 17:06 |
celeron55 |
-of |
| 17:06 |
hmmmm |
i do agree that the rename was a hack |
| 17:06 |
celeron55 |
+d |
| 17:08 |
celeron55 |
you simply aren't supposed to mess around with libraries; it's like opening a two meter diameter pipe of shit above your head, freely expressed |
| 17:10 |
hmmmm |
i don't feel like i should take responsibility for jsoncpp though, that's totally proller's stuff. that's his feature which uses it, his inclusion, his modification... |
| 17:10 |
celeron55 |
(in fact, i didn't even expect to need to talk about this stuff; i thought it was 100% obvious to any developer) |
| 17:10 |
celeron55 |
then you just shout at proller for it |
| 17:11 |
hmmmm |
i just did |
| 17:12 |
proller |
jsoncpp have only one modification: |
| 17:12 |
proller |
# -#include <json/json.h> |
| 17:12 |
proller |
# +#include "json/json.h" |
| 17:12 |
hmmmm |
JThread on the other hand, isn't even a library in many distros. I was under the impression that it was just some schmuck's wrapper found on his website, but certain distro package maintainers take these things too seriously and ultimately that's not relevant to me |
| 17:12 |
hmmmm |
you also had to rename the cmake files though. |
| 17:13 |
proller |
everyone can try update jsoncpp : cd src/json/; sh UPDATING |
| 17:13 |
hmmmm |
i want to move it back to json and find the problem where it can't resolve that symbol |
| 17:14 |
hmmmm |
did you actually figure out what the problem with that was, or did you just tell that guy to use the included library? |
| 17:15 |
proller |
i think jsoncpp is good name, look at their svn: https://jsoncpp.svn.sourceforge.net/svnroot/jsoncpp/trunk/jsoncpp/ |
| 17:15 |
proller |
jsoncpp x 3 , json x 0 |
| 17:15 |
hmmmm |
yes, but does that correspond with the system libraries' names? |
| 17:16 |
proller |
problem was strange |
| 17:19 |
hmmmm |
celeron, ultimately i made those decisions because i wanted things to be problem-free as fast as possible. having something not compile fresh from the repository is a pretty big problem. |
| 17:19 |
hmmmm |
and i don't regret them |
| 17:36 |
VanessaE |
which reminds me, offtopic slightly: the debian dependencies in the README need updated; it fails to mention curl (I used libcurl4-gnutls-dev), SM (libsm-dev) and GLu (libglu1-mesa-dev) |
| 17:36 |
VanessaE |
discovered this yesterday after a fresh re-install. |
| 17:51 |
|
Calinou joined #minetest-dev |
| 17:57 |
proller |
btw, i make freebsd port, send it to maintainer, but he busy now |
| 18:19 |
|
Taoki[laptop]_1 joined #minetest-dev |
| 18:28 |
thexyz |
i've updated leveldb patch https://github.com/xyzz/minetest-ru/tree/leveldb though it seems --migrate is broken now |
| 18:28 |
thexyz |
i also get perfomance decrease when using num_emerge_threads > 1, is that ok? |
| 19:02 |
|
proller joined #minetest-dev |
| 19:04 |
|
ShadowNinja joined #minetest-dev |
| 19:23 |
hmmmm |
celeron55, this is kind of an important question, is there a reason why CONTENT_IGNORE is buildable_to? |
| 19:26 |
PilzAdam |
except the one that is mentioned in the comment? |
| 19:27 |
hmmmm |
ah |
| 19:34 |
hmmmm |
so, what do you think, make CONTENT_IGNORE not buildable_to? when is CONTENT_IGNORE ever going to be *accidentally* placed? in any conceivable circumstance, it's a bug with the map generator |
| 19:34 |
hmmmm |
I am wondering what the side effect would be if Map::getNodeMetadata() were to fail when attempting to place a block |
| 19:35 |
PilzAdam |
I still would like to now why the placing code gets ignore |
| 19:35 |
PilzAdam |
*know |
| 19:36 |
hmmmm |
because it needs to emerge the block, it hasn't been generated though, so it creates a blank block (filled with CONTENT_IGNORE) |
| 19:38 |
PilzAdam |
I once got the bug in a mapblock that was already generated for a long time |
| 19:40 |
hmmmm |
no, hold on a minute, that's wrong.. it passes false to create_blank, and i don't see any "WARNING: Map::blah Block not found" |
| 19:41 |
hmmmm |
which means that at that point, block must have been non-null. which means that emergeBlock must have succeeded, even with create_blank = false |
| 19:42 |
hmmmm |
which means that getBlockNoCreateNoEx() succeded and the block it got wasn't a dummy, or loadBlock() must have succeeded |
| 19:43 |
hmmmm |
loadBlock would never get CONTENT_IGNORE unless it was generated that way, or it was the boundary of something that was just generated.... |
| 19:49 |
hmmmm |
so if it were getBlockNoCreateNoEx() that returned a blank block that was created by another emergeBlock(), that would work, but that's impossible because getBlockNoCreateNoEx() is called right before emergeBlock, and if that were the thing returning the blank block, then emergeBlock would never be called |
| 19:50 |
hmmmm |
so it must be so that loadBlock loaded a block full of CONTENT_IGNOREs from the disk |
| 19:50 |
hmmmm |
it is logically impossible any other way |
| 19:54 |
hmmmm |
it's much more difficult to determine the root cause. |
| 22:05 |
|
iqualfragile joined #minetest-dev |
| 22:30 |
|
iqualfragile joined #minetest-dev |
| 22:39 |
|
iqualfragile joined #minetest-dev |
