Minetest logo

IRC log for #minetest-dev, 2013-03-07

| Channels | #minetest-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

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

| Channels | #minetest-dev index | Today | | Google Search | Plaintext