Minetest logo

IRC log for #minetest-dev, 2015-01-27

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

All times shown according to UTC.

Time Nick Message
00:00 MichaelRpdx joined #minetest-dev
00:02 kaeza joined #minetest-dev
00:31 shadowzone joined #minetest-dev
00:41 MichaelRpdx joined #minetest-dev
00:50 MichaelRpdx joined #minetest-dev
01:03 shadowzone joined #minetest-dev
01:05 troller joined #minetest-dev
01:22 troller joined #minetest-dev
01:33 MichaelRpdx joined #minetest-dev
01:54 Miner_48er joined #minetest-dev
01:58 NakedFury joined #minetest-dev
02:14 shadowzone joined #minetest-dev
02:29 DFeniks joined #minetest-dev
02:32 deltib joined #minetest-dev
02:33 diemartin joined #minetest-dev
03:26 Zeno` joined #minetest-dev
04:41 Miner_48er joined #minetest-dev
04:57 blaaaaargh joined #minetest-dev
05:23 selat joined #minetest-dev
05:40 alexxss joined #minetest-dev
06:12 jasonjayr joined #minetest-dev
06:28 leat joined #minetest-dev
06:37 diemartin joined #minetest-dev
06:41 Hunterz joined #minetest-dev
07:03 TriBlade9 joined #minetest-dev
07:13 ImQ009 joined #minetest-dev
07:21 hmmmm ugh
07:22 hmmmm does anybody have objections to placing object files into src/CMakeFiles/<target>.dir/<cmake_build_type> subdirectory?
07:22 hmmmm this way you don't have to recompile the whole thing when you change the build type
07:24 TriBlade9 I approve?
07:49 nrzkt joined #minetest-dev
07:49 nrzkt Hello all !
07:52 hmmmm smooth day to night transition seems like it's broken again
07:55 nrzkt #2209 #2212 and #2214 need to be merged !
07:55 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul
07:55 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
07:55 ShadowBot https://github.com/minetest/minetest/issues/2214 -- Performance improvement -> Craftdef.cpp: Improve loop and mathematics for CraftDefinitionShaped::check by nerzhul
08:24 kilbith joined #minetest-dev
08:29 gregorycu joined #minetest-dev
08:53 FR^2 joined #minetest-dev
09:05 DFeniks joined #minetest-dev
09:13 rubenwardy joined #minetest-dev
09:42 rubenwardy Is this a mistake? https://github.com/minetest/minetest_game​/blob/master/mods/default/nodes.lua#L895
09:47 nrzkt i don't see anything special
09:48 rubenwardy What does "buildable_to" mean?
09:48 rubenwardy Oh, nevermind
10:29 prozacgod joined #minetest-dev
11:04 jin_xi joined #minetest-dev
11:32 roniz joined #minetest-dev
11:59 T4im joined #minetest-dev
12:01 kilbith kahrl_, what are you waiting to merge 2185 ?
12:10 kahrl_ kilbith: end of the feature freeze
12:11 Zeno` joined #minetest-dev
12:12 Zeno` smooth day/night is broken?
12:22 Zeno` kahrl_, what are your opinions on #2212
12:22 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
12:23 Zeno` it (the problem) obviously needs to be address, and the PR seems to do that
12:24 Zeno` It was merged before (in a different format) that caused old maps to fail loading. This PR addressed that issue
12:24 Zeno` addresses*
12:33 kilbith kahrl_: your PR is not a feature, but a fix
12:48 Zeno` #2209 is fine
12:48 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul
12:50 kilbith 50000% faster ? :p
12:51 ImQ009 joined #minetest-dev
12:53 kahrl_ kilbith: yeah but the issue has been there for like forever, so there is no need to hurry
12:53 kahrl_ so in that sense it's really more like a feature
12:54 kahrl especially since graphics fixes have a tendency to always cause new bugs on different drivers :/
12:54 Zeno` 2212 seems ok though
12:55 kahrl Zeno`: without having thought all the consequences through (compatibility is hard), I tend to agree
12:56 Hunterz vote for issue #1072
12:56 ShadowBot https://github.com/minetest/minetest/issues/1072 -- Clientside prediction needs to be improved
12:58 Zeno` does anyone have an old world they can test with #2212 merged?
12:58 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
12:58 kahrl Zeno`: about # 2212, I don't understand why the check is mapblock.cpp is removed
12:59 kahrl s/is/in
12:59 nrzkt kahrl
12:59 nrzkt if you look at handling of _INIT packet
13:00 nrzkt it sets client->setPendingSerializationVersion(deployed);
13:00 nrzkt and it's the version passed into MapBlock
13:00 kahrl yeah
13:00 nrzkt then if we check at init
13:00 kahrl so clients can't trigger a SerializationError anymore
13:00 nrzkt the version isn't modified elsewhere
13:00 nrzkt :)
13:01 nrzkt then PR is good
13:01 kahrl but some coder in the future might accidentally cause something to pass in a version < 24
13:01 nrzkt this commits mustn't be accepted
13:01 kahrl this check signals that this is a severe error
13:01 nrzkt we need to manage the version properly
13:01 kahrl nrzkt: your first PR about this was accepted too, so...
13:01 nrzkt i'm working on networking rework and it' unacceptable to have a protocol version < now
13:02 nrzkt yes. But it modify a production value
13:02 Zeno` I accepted that first PR without looking at all the side-effects
13:02 nrzkt here we have an alternate value
13:02 Zeno` I do know that I had issues about a month ago with supporting version 0 of the protocol (when it's pretty pointless)
13:02 nrzkt i don't know that version may be different than serialization, it's not clean in code, but i must be clear for 1.0.0 release
13:03 nrzkt here we accept client serial version != map serial version
13:03 nrzkt but i think for 1.0.0 we must break those things and use a migration mode
13:03 nrzkt maintain 2 years old version is a pain
13:04 kahrl there isn't a "map serial version"
13:04 kahrl every mapblock is its own version
13:04 nrzkt okay, i understand better now
13:04 nrzkt i think we must have a conversion mode for next release, and we mustn't keep there old maps which block the minetest evolution
13:04 kahrl what's a pain about it? most of the cruft is in deSerialize_pre22 and doesn't need to be touched
13:05 Zeno` As I said yesterday, I think the main thing for 0.4.12 is to close the potential DoS
13:05 nrzkt no for this feature freeze.
13:05 nrzkt this fix the DoS, or i'll use it on many servers :p
13:05 Zeno` a client connecting with incorrect version should NOT "crash" the server
13:06 kahrl I think coding a migration layer is more work than simply updating the serialization code
13:06 kahrl and it causes more work for every user too
13:06 Zeno` so what is the easiest way to avoid the crash *right now*? Even if it's not the best way?
13:06 nrzkt it's the only way Zeno
13:07 nrzkt if we don't handle the input the DoS is easy
13:07 kahrl Zeno`: I vote for # 2212 without the check in mapblock.cpp removed
13:07 kahrl assuming that works in all the cases
13:07 nrzkt it's impossible that test match
13:07 kahrl nrzkt: yeah. It's defensive code
13:07 nrzkt please audit the code instead of telling this
13:08 nrzkt a stupid test which stay there and add cpu cycles and 1 year later stay there and nobody knows why.
13:08 Zeno` nrzkt, add a comment: TODO: This condition can never be true; review this code
13:08 kahrl and who will do the audit?
13:08 nrzkt ME
13:08 Zeno` just so that it can be merged during the feature freeze
13:08 nrzkt now, do it
13:08 kahrl ok, it can be removed after the audit
13:08 Zeno` after the feature freeze larger changes can be made
13:09 nrzkt it's not a larger thing
13:09 kahrl assuming you promise to audit every future change to serialization versions too ;)
13:09 nrzkt i tell you that there is code to remove, after the release everybody forget this
13:09 Zeno` it's erring on the side of caution
13:09 Zeno` your first PR after feature freeze can be to delete it
13:09 Zeno` and I'll merge it myself :P
13:09 nrzkt i know what i am doing, i'm very conservative with code
13:10 Zeno` yep, not debating that
13:10 kahrl meh, what's a few cycles versus writing to disk or sending stuff over the network
13:10 nrzkt in fact, CPU cycle vs ... nothing is clear
13:10 nrzkt look at the code, look at version input
13:10 Zeno` This is only for a few days
13:10 nrzkt now i'm doing audit for you in live.
13:10 nrzkt client->setPendingSerializationVersion(deployed);*
13:10 Zeno` Surely you will not forget before next week :)
13:11 nrzkt clientiface.h: /* set expected serialization version */
13:11 nrzkt void setPendingSerializationVersion(u8 version)
13:11 nrzkt { m_pending_serialization_version = version; }
13:11 nrzkt later in the code:
13:11 nrzkt void confirmSerializationVersion()
13:11 nrzkt { serialization_version = m_pending_serialization_version; }
13:12 nrzkt we now have RemoteClient->serialization_version (u8)
13:13 gregorycu "which is dumb, because not even spread_light uses 8% of the CPU time; but a single map lookup did?"
13:13 gregorycu there was another issue where adding a callback to "cache" the enable_fog led to reducing the main (cleint) game loop by 8%
13:13 gregorycu If the profiler reports that 8% of the time is being spent there, 8% of the time is getting spent there
13:14 gregorycu It doesn't have to make sense, it's just cold hard facts
13:14 gregorycu @ Zeno`
13:14 nrzkt ok then
13:15 nrzkt void Server::SendBlockNoLock(u16 peer_id, MapBlock *block, u8 ver, u16 net_proto_version)
13:15 nrzkt which is called by void Server::SendBlocks(float dtime)
13:15 nrzkt uses as argument 2: client->serialization_version
13:15 nrzkt line 3924 (server.cpp)
13:16 nrzkt then if client->serialization_version is used, and it's verified and set to a value >= 24 in _INIT it's impossible to match this try
13:16 nrzkt then this is DEAD CODE
13:16 nrzkt CQFD.
13:16 nrzkt if forget to say: SendBlockNoLock call lock->serialize(os, ver, false); which is the function we are looking for
13:17 nrzkt now stop discuss about cutting the thing, you have the demonstration.
13:17 kahrl ok, please don't do any audits
13:18 kahrl because you missed other places that call MapBlock::serialize
13:18 nrzkt tell me
13:18 kahrl no I won't, I don't have time to audit
13:18 nrzkt my grep doesn't show nothing.
13:18 kahrl there's an obvious one in map.cpp
13:19 nrzkt right
13:19 nrzkt u8 version = SER_FMT_VER_HIGHEST_WRITE;
13:19 nrzkt block->serialize(o, version, true);
13:19 nrzkt it's good.
13:19 Zeno` gregorycu, what is the time complexity of a map lookup?
13:20 gregorycu Are you talking theory, when we have actual statistics?
13:20 Zeno` I am talking theory
13:20 gregorycu O(logn)
13:20 nrzkt joined #minetest-dev
13:21 Zeno` ok, what it the time complexity of, say, unspreadLight()?
13:21 gregorycu The time complexity?
13:21 kahrl so assuming we remove the check
13:21 Zeno` yeah
13:21 Zeno` in big-O notation
13:21 kahrl where is the documentation for serialize() that documents the precondition version >= 24?
13:22 gregorycu O(n^3)
13:22 Zeno` what I am suggesting is that your empirical data is either wrong or you're misinterpreting it
13:22 gregorycu ...
13:22 gregorycu Neither are those are true
13:22 gregorycu Firstly, the latter happens in a different thread
13:22 gregorycu And only when emerging, or light changes
13:23 nrzkt thanks kahrl
13:23 kahrl nrzkt: btw, are you saying we should remove all assert() calls from minetest?
13:23 kahrl because they are surely dead code
13:23 Zeno` you're saying that a single map lookup consumes 8% of the CPU in the loop
13:23 Zeno` well, they kind of are
13:23 Zeno` kahrl, that's my next mission heh
13:23 nrzkt no kharl, asserts are good to prevent some coding error
13:24 gregorycu A map lookup, and a conversion from a string to a bool
13:24 gregorycu Yes
13:24 nrzkt if you look at my networking PR i'm using it to prevent packet reading error in the new stream interface :)
13:24 gregorycu About 4% each
13:24 kahrl nrzkt: right
13:24 Zeno` 4% each of TOTAL program time?
13:24 gregorycu The render loop, which standing still is about 90% of the application
13:25 kahrl nrzkt: so can we agree to document version >= 24 as a precondition, remove the if and instead add an assert that verifies the precondition?
13:25 Zeno` if that's the case please add // precondition to then end of the assert
13:25 T4im asserts are supposed to be dead code… they shall error the moment they are accidentally not anymore :P
13:26 gregorycu It was 8% of the 90% (or about 7.2% overall)
13:26 nrzkt if you want, but i think it's useless, the programming error is handled
13:26 Zeno` so I don't have to recheck it when I removed the redefinition of assert
13:26 nrzkt maybe a comment ?
13:26 Zeno` s/removed/remove
13:26 Zeno` A comment is fine
13:26 kahrl nrzkt: compatibility code is very hard as we've seen a lot in the past, I think an actual assert is needed
13:27 nrzkt in fact kahrl assert was already here
13:27 nrzkt because this error trigger and assert on servers
13:27 nrzkt trigger an*
13:27 nrzkt and it's why i handle it
13:27 kahrl yeah but that's fixed now, isn't it
13:28 kahrl I mean with the rest of 2212
13:28 nrzkt of course, because we are handling the packet input, then the exception/assert can be removed because condition is verified and handled
13:28 gregorycu Zeno`: I'm glad I could clear this up for you, now I'm going to go back to ignoring you
13:28 Zeno` gregorycu, I'm not sure you understand
13:29 Zeno` gregorycu, and what, please, have I done to so greatly offend you?
13:29 nrzkt in fact the new SER_FMT_CLIENT_VER_LOWEST guarantee a compatibility to old mapblocks which are using SER_FMT_CLIENT_VER_LOWEST
13:29 nrzkt SER_FMT_VER_LOWEST* (2nd occurence)
13:30 Zeno` gregorycu, If you will not discuss pull requests with me or other devs (unless you choose to) then your pull requests are useless
13:31 gregorycu I have updated #2156 as per comments
13:31 ShadowBot https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu
13:32 Zeno` gregorycu, is there a reason it's not static?
13:33 Zeno` look, if you can't answer the question I'll just close it
13:34 nrzkt then kahrl, #2212 is right ?
13:34 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
13:35 kahrl nrzkt: I don't see the assert you mean
13:36 Zeno` closed
13:38 kahrl nrzkt: neither do I see any comment about the precondition
13:38 nrzkt in fact kahl, i don't found it too, it's just assert(0) when it's triggered
13:38 nrzkt no code line :(
13:38 nrzkt but i can trigger it on you server, give me an IP and i connect with my modified client and the assert will be triggered
13:39 nrzkt and the exception show
13:39 kahrl 127.0.0.1
13:39 nrzkt xD
13:39 gregorycu For some reason #2156 was closed
13:39 ShadowBot https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu
13:40 kahrl gregorycu: you would know the reason if you hadn't ignored Zeno` :P
13:40 kilbith ^
13:40 gregorycu Apparently: "Closing. Author will not discuss the PR on IRC and therefore questions about it cannot be asked."
13:40 gregorycu I wasn't aware IRC was required to get work merged
13:40 kilbith don't expect your PRs merged if you ignores a concerned core-dev
13:40 kilbith simply as that
13:41 gregorycu There are no concerns mentioned in the PR
13:41 gregorycu (Apart from the ones I've addressed)
13:42 Zeno` gregorycu, why is VoxelManipulator::ContentIgnoreNode not static?
13:42 Zeno` I see no reason for it to have external linkage
13:43 Zeno` ok, that settles it then I guess :/
13:43 nrzkt gregorycu ?
13:43 nrzkt are you ignoring Zeno on IRC ?
13:43 gregorycu Yes?
13:43 gregorycu Yes
13:44 nrzkt then you can't discuss with minetest PR merger
13:44 nrzkt it's why your PR is blocked
13:44 gregorycu I'll respond to any concerns he has in the PR
13:44 gregorycu I just find him a frustrating person to speak to, so it's best this way
13:44 nrzkt he ask you: gregorycu, why is VoxelManipulator::ContentIgnoreNode not static?
13:44 gregorycu It is...
13:45 gregorycu You don't have to be a go-between, I'm sure if has concerns, he'll address them in the PR
13:47 crazyR joined #minetest-dev
13:48 nrzkt gregory: const MapNode VoxelManipulator::ContentIgnoreNode = MapNode(CONTENT_IGNORE); in voxel.cpp
13:49 shadowzone joined #minetest-dev
13:49 gregorycu Yeah...
13:49 Zeno` look, I won't open it again
13:49 gregorycu It's declared static, therefore it is static
13:49 gregorycu I'm pretty sure it's a compile error to put static there too
13:49 Zeno` If gregorycu wants stuff merged he has to discuss things
13:49 Zeno` and it's not declared static at all
13:49 gregorycu (And not required, I'll check)
13:50 Zeno` so it has external linkage for no apparent reason at all
13:50 Zeno` err
13:50 Zeno` wait, the code has changed since the other day
13:50 Zeno` oh well
13:50 nrzkt :)
13:50 gregorycu error C2720: 'VoxelManipulator::ContentIgnoreNode' : 'static ' storage-class specifier illegal on members
13:50 nrzkt he said he changes the code
13:51 Zeno` pity it cannot be discussed :)
13:51 nrzkt but i think your browser cache is wrong Zeno
13:51 nrzkt :)
13:51 nrzkt greg, Zeno i opened to discussion if you unignore him :
13:52 Zeno` all he had to say was "hey, look! I changed it since the other day"
13:53 Zeno` but, no, he had to ignore me
13:53 gregorycu It's quite alright nrzkt, there are many people, I'm not sure he should be closing PRs for no technical reason
13:53 gregorycu And indeed, closing them without reading comments
13:53 Zeno` there is no technical reason now. It's a political reason
13:54 Zeno` And it was, really, a political reason why I made it WIP as well
13:54 Zeno` If devs cannot ask questions then *shrug*
13:54 nrzkt in fact minetest devel can go faster if political goes to trash
13:54 nrzkt :p
13:54 Zeno` not by ignoring people with though :/
13:54 nrzkt minetest is not a profit enterprise
13:55 nrzkt ofc Zeno
13:55 Zeno` I don't even know why he ignored me in the first place
13:55 Zeno` in the last few weeks I've rebased his commits, fixed his broken repo, tutored him in git usage, etc, etc
13:56 Zeno` makes no sense
13:56 Zeno` I've done nothing but support him
13:57 Zeno` so, at this point my response to him is "ok, if that's the way you want it, then fuck you"
13:59 Zeno` All I can think of is that I denied one of his PRs because it caused a deadlock on Linux
13:59 shadowzone Whose?
14:00 Zeno` Since that comment he's been nothing but aggressive towards me :/
14:00 kahrl wasn't that me who was concerned about that?
14:01 kahrl why isn't he ignoring me instead then?
14:01 kahrl shadowzone: gregorycu's
14:01 shadowzone Oh
14:02 shadowzone I've never even had a PR merged or even considered, so he should just settle down.
14:02 gregorycu You guys are talking about me, I can sense it somehow, kahrl, I don't have a problem with you
14:02 gregorycu And I'm settled, but removing frustrating elements out of my life, I've streamlined my process
14:03 shadowzone Well that was uneventful, took apart my tablet plugged the battery and plugged it back in, nothing.
14:03 kahrl gregorycu: yes we are, you can read it in the logs (see topic), but you'd have to read Zeno's comments (the horror!)
14:03 gregorycu I'd rather not, would defeat the purpose you see
14:03 kahrl gregorycu: see, and Zeno` is removing frustrating elements out of his life by closing your PRs
14:04 gregorycu I wasn't aware the minetest repo was his plaything to satisfy his life enjoyment
14:05 kahrl neither is it yours
14:06 gregorycu No, it's not. But I'm the one contributing to it, not the one closing legitimate PRs
14:06 shadowzone To be honest, I never expect my PRs to get merged and if they do Hooray, but I really don't expect them to.
14:06 kahrl what is legitimate about it if its author doesn't want to discuss it?
14:07 shadowzone I don't say "Merge this merge that, why'd you close that?"  My dad who develops apps n stuff told me "if they don't like it work harder and make something they will like"
14:07 gregorycu I am quite willing, I'm responding to comments in PRs...
14:08 kilbith shadowzone: #minetest-dev is not a place to talk about your life, your feelings and other anedoctic things...
14:08 shadowzone Okay
14:11 kahrl gregorycu: well, if you arbitrarily want to make the conversation about your PR inefficient by limiting it to github, then so be it
14:12 gregorycu A conversation can't happen if the PRs get closed, they are off peoples' radars before there is a chance to look at them.
14:13 gregorycu It's not arbitrary, I'm more than willing to discuss these things with people
14:13 kahrl except the people that actually care?
14:14 kahrl you can always ask Zeno to open it again, he's here, you know
14:15 gregorycu Zeno` made a mistake in closing it, or at least I assume so, as there is no legitimate reason specified in the PR
14:15 gregorycu I'm sure he will come to his senses without my prompting
14:17 kahrl let's stop spamming the channel with this stupid BS now
14:17 gregorycu Ok
14:19 kahrl let's rather fix the segfault in sqlite3_finalize when the singleplayer server rejects the singleplayer client (because of on_prejoinplayer for example)
14:20 nrzkt #2212 is poping again for netherstorm
14:20 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
14:20 nrzkt where are we kahrl ?
14:22 kahrl nrzkt: I'm having trouble testing it because of what I just mentioned
14:25 Zeno` gregorycu, although I haven't reviewed it properly, yet another time, the PR probably has no outstanding *technical* issues
14:25 Wayward_One joined #minetest-dev
14:25 Zeno` night all
14:25 shadowzone joined #minetest-dev
14:30 kahrl #2219
14:30 ShadowBot https://github.com/minetest/minetest/issues/2219 -- Singleplayer segfaults if server rejects client
14:30 nrzkt kahrl you want an assert ?
14:30 kahrl nrzkt: yes
14:30 nrzkt ok, but after release i explode it :p
14:30 nrzkt right ? :)
14:30 kahrl why?
14:32 nrzkt because it's useless, but if you want to be sure for this release, we made it
14:33 kahrl it's not useless
14:33 nrzkt on next release if nobody has assert it's because it's useless :)
14:34 kahrl nrzkt, you assume everyone keeps everything about the minetest source code in mind at all times
14:34 kahrl nrzkt: and that nobody ever makes mistakes
14:35 nrzkt nobody musn't do mistake, but reviews are there to don't have those mistakes
14:35 kahrl Zeno reviewed your first PR and still pushed it
14:36 gregorycu Mistakes happen, and two people can make the same mistake, even two smart people
14:36 nrzkt you are right, but we forget the input into map.cpp, as you said
14:36 gregorycu Code reviews are not perfect
14:36 nrzkt ofc
14:38 nrzkt #2209 can be reviewed ? it's more and more simpler
14:38 ShadowBot https://github.com/minetest/minetest/issues/2209 -- Little performance improvement: use getPlayer(peer_id) instead of getPlayer(playername) by nerzhul
14:38 nrzkt and doesn't trigger asserts or exceptions :)
14:39 kahrl nrzkt: after the release
14:39 nrzkt can you use milestones on github ? it will be better to manage project with milestones no ?
14:40 kahrl sure, we have milestones
14:40 nrzkt then PR will not be abandonned because milestone MUST be reached for release
14:40 nrzkt https://github.com/minetest​/minetest/milestones/0.4.12
14:40 kahrl it's not a guarantee
14:41 nrzkt milestones must be uses properly to manage the release engineering, it help the developer to focus their effort
14:41 kahrl the decision to start a feature freeze is done without regards to whether there are open PRs in the milestone
14:42 kahrl and if the devs who know about the topic of the open PRs are not around before and during the feature freeze, they won't be merged
14:42 nrzkt why not be agile, creating a milestone with a maximum date (for example every 6 months), do a feature freeze 1 month before release
14:43 nrzkt and do efforts on cleaning up bugfix PR and resolve issues in this month and then release ?
14:43 casimir joined #minetest-dev
14:43 nrzkt milestone is here for that. In minetest it's... nothing
14:43 kahrl I don't know what "agile" means anymore
14:43 nrzkt sorry it's a french term
14:43 nrzkt do you know ITIL ?
14:43 kahrl it's thrown around a lot in software engineering and everyone means something different by it
14:44 kahrl do you mean we should do scrums every morning?
14:44 kahrl because that won't happen :P
14:44 gregorycu Standups are a great waste of manhours
14:44 nrzkt no, i mean the project must be more organized in term of release engineering
14:44 gregorycu When the person leading them doesn't know how to do them
14:44 nrzkt a release date must be set months before, not days before
14:45 kahrl I don't know ITIL
14:45 nrzkt ok
14:45 kahrl well there was some discussion about release engineering
14:45 kahrl it evolved into bikeshedding about version numbers :P
14:45 nrzkt agile = development based on little modifications reviewed by many people and frequent releases (6 month max)
14:46 Wayward_One joined #minetest-dev
14:46 nrzkt version numbering is difficult to handle
14:46 nrzkt because there are many ways.
14:47 nrzkt I think there must be real branches in minetest. 1.0 (which is after 0.4.12 if i correctly follows) must add a new devel cycle with a branching model for compat
14:47 nrzkt old things must stay in 0.4.x branch, where minetest dev provide and backport fixes
14:47 kahrl the problem with setting release dates a long time in advance is that you don't know if the people who can do the release will be available at the time
14:48 kahrl it happens to some extent with 0.4.11
14:48 kahrl happened*
14:48 nrzkt it's not a problem
14:48 kahrl it will be worse if it's done several months in advance
14:49 nrzkt feature freeze stop the innovation and we fix problems. If the dev are not available and needed fixes are critical, stay in FF a little bit more. Release must be stopped if the problem is blocking
14:49 nrzkt but not if all milestone blocking fixes have been done
14:49 CraigyDavi joined #minetest-dev
14:53 nrzkt kahrl, #2212 updates as you like
14:53 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
14:58 kahrl nrzkt: I think making branches during feature freeze was one of the ideas in the release engineering discussion
14:58 kahrl not sure what happened to it, as I said, it devolved
14:58 nrzkt maybe minetest project need hands
14:59 nrzkt and then i could help into release engineering (it's my job)
14:59 kahrl I think you should talk to hmmmm about it, he was the one who proposed it IIRC
15:00 nrzkt no problem, it's interesting. I don't thing minetest can evolve if minetest code get three years old compat
15:01 kahrl three years is nothing
15:01 kahrl other software has compatibility layers for decades worth of stuff and still manages to evolve
15:02 nrzkt we aren't X11
15:02 nrzkt we are a game
15:02 nrzkt compat with three years old client is bad for innovation
15:02 kahrl I don't mean compatibility with clients
15:02 kahrl but for maps it is important
15:03 nrzkt ofc course
15:03 nrzkt when release was finished and my network rework done i will look at map store
15:03 nrzkt if you said it's a version per mapblock maybe there is something to do
15:04 OldCoder joined #minetest-dev
15:04 nrzkt we cannot let old map, and thinking about an upgrading process is important in a rolling developpement
15:04 nrzkt development*
15:04 shadowzone joined #minetest-dev
15:06 kahrl I don't see the point of forcing every user to do some extra stuff each release
15:06 kahrl when a little piece of code in the engine can do it incrementally
15:07 nrzkt maintenance of the code
15:07 kahrl (in fact, I hate how every web application on the planet forces me to babysit its upgrade process and can't deal with an old DB schema on its own)
15:08 nrzkt i'm using ~50 free & opensource web applications and upgrading it. Each application has an upgrade process. Why ? because of schema modification, new features, performance improvements...
15:09 nrzkt i understand your conservative mind, but if the map needs new features, then upgrade it. Old code can be remove and there is less maintain to do on it
15:09 kahrl mapblock serialization is changed so rarely nowadays that I don't see how it is a huge maintenance burden
15:09 nrzkt if it's not changed, why not then
15:10 nrzkt but why not migrate old users to have a convergent model ?
15:10 kahrl they are
15:10 kahrl incrementally as the map is loaded
15:10 nrzkt this permit in the future to improve mapblock serialization by removing old stuff
15:11 nrzkt i do'nt talk about new records, but oldest
15:11 kahrl I sometimes download maps from the 0.3 era and check them out
15:12 nrzkt i agree with you for this core
15:12 kahrl if I had to keep around old builds for that or go through a length migration process, I wouldn't
15:12 kahrl lengthy*
15:12 kahrl so that would decrease my enjoyment of the game
15:12 kahrl and I'm sure it would for others too
15:12 nrzkt and if a developper propose a patch to migrate old database structures ?
15:13 kahrl what would be the difference to how it is now?
15:13 nrzkt what is the problem with changing serialization to unify methods ?
15:13 nrzkt the different is that the algo will be must simpler to maintain
15:13 kahrl you would still have the same migration code, just in a different place
15:13 kahrl how would it be simpler?
15:13 nrzkt migration code is a simple code call in one point sometimes. Managing different mapblocks is called many times
15:14 hmmmm joined #minetest-dev
15:14 nrzkt add new mapblock format need a new ugly condition to manage, think about old mapblock version etc... if you add a migrating mode you don't think about old mapblock versions, you only think current and migrate users to current one time.
15:14 SopaXorzTaker joined #minetest-dev
15:17 kahrl well, I still don't get how you would get around having to write deserialization code for every past serialization version
15:17 kahrl which is pretty much the only semi-difficult thing about it
15:18 nrzkt it's an idea, doing it will be a little more difficult, yes, but when it's done, you don't have to do it another time :)
15:19 kahrl you will, every time you change the version you have to add code to handle the "new" old version
15:20 nrzkt old course
15:20 nrzkt ofc*
15:21 nrzkt but, in fact, it's only a code move. You move deserialize from core to updater, you read, modify and serialize with new format (which is the current), and remove old serialize format from core.
15:21 T4im schema migration frameworks exists for that, that are able to transform old schemata to the newest before import… but I'm not aware of open source implementations for c/c++ :/
15:21 nrzkt it needs a little more devel process but permit to have a homogeneous db
15:23 nrzkt T4im, this works very well for PgSQL, MySQL, Sqlite, but for Redis and leveldb, don't know
15:23 nrzkt forum is down
15:24 kahrl schema migration doesn't really work in this case, as the changes usually affect the compressed blob
15:26 kahrl something like #1845 would be the only exception to that
15:26 ShadowBot https://github.com/minetest/minetest/issues/1845 -- Split block position into separate fields in SQLite3 database by ShadowNinja
15:37 celeron55 < nrzkt> forum is down <- noted
15:38 hmmmm https://github.com/minetest/minetest/pull/1845
15:38 hmmmm I'm not a huge fan of this
15:38 hmmmm you either change all databases or one
15:38 hmmmm or none i mean
15:39 hmmmm the point is to have a consistent scheme across each because the only difference between the databases is their interface, not the data contained
15:39 Zeno` joined #minetest-dev
15:40 hmmmm what would be better imo would be to fix the "position hash" thing to pack the 12-bit block position values into a 36 bit integer using bitwise airthmetic, not that odd factor/addition thing that currently exists
15:41 hmmmm what currently exists seems more difficult to me to prove that it's one-to-one
15:42 celeron55 i'm voting for this change
15:42 fz72 joined #minetest-dev
15:42 celeron55 shadowninja's one, i mean
15:42 celeron55 i've been asking for it for like years
15:42 hmmmm why would you want to change sqlite but none of the others though
15:42 hmmmm that is so inconsistent
15:42 celeron55 well for example redis is maintained by sfan5 on the terms that it can be dropped if nobody is willing to update it when needed
15:42 celeron55 we just don't have a /contrib/ directory for it
15:42 hmmmm is redis bad or something?
15:43 celeron55 no, it's just generally unnecessary
15:43 hmmmm i'll agree with that.  but i thought it was supposed to be the fastest of the three
15:43 celeron55 it has a different architecturer so it cannot be compared (it needs a separate database server)
15:43 celeron55 -r
15:44 celeron55 or, can, but doing it is relatively pointless
15:44 gregorycu joined #minetest-dev
15:44 celeron55 i mean, when it's useful, it's useful because of its architecture, not because of speed
15:45 kaeza joined #minetest-dev
15:46 celeron55 and the only program that is ever going to support all of these at once is going to be MT itself as long as we don't publish a library for doing it, in which case it's the library
15:46 gregorycu hmmmm: I addressed your concerns with #2156, are you able to confirm and +1 ?
15:46 ShadowBot https://github.com/minetest/minetest/issues/2156 -- Optimise MapBlockMesh functions by gregorycu
15:47 Zeno` gregorycu, I've asked you to speak to me for 3 days
15:47 Zeno` you will not answer
15:48 Zeno` If you refuse to talk to people why should the PR be trusted?
15:48 kahrl nrzkt: I'm okay with #2212 now. I would prefer to have a comment in mapblock.h about the precondition version >= SER_FMT_CLIENT_VER_LOWEST, and perhaps keep the comment in .cpp that <24 won't work because of dynamic node IDs, but both of these aren't strictly necessary
15:48 ShadowBot https://github.com/minetest/minetest/issues/2212 -- Fix a crash (assert) when client set serial version < 24 in INIT and by nerzhul
15:49 Zeno` If I merge the PR and something goes wrong, how can it be discussed?
15:49 Zeno` This is silly
15:50 kahrl perhaps the comment about <24 can be moved above the definition of SER_FMT_CLIENT_VER_LOWEST
15:50 nrzkt ok kahrl, i'm releasing our product at work, then i cannot doing it now, can this be done at merge by you or Zeno ?
15:51 kahrl sure
15:51 Zeno` yeah, I'm ok with that
15:51 Zeno` I can't merge atm (in Windows ;3)
15:51 Zeno` but if kahrl is happy then I agree
15:51 nrzkt thanks !
15:52 hmmmm gregorycu, I don't think I can unless you address Zeno`'s concerns
15:53 hmmmm sorry (:
15:53 gregorycu What are those?
15:53 hmmmm I don't know, whatever he's asking
15:53 gregorycu He wants me to talk to him in IRC, I think he is lonely or something
15:53 hmmmm Did you put him on ignore or something?
15:53 gregorycu Yes
15:53 hmmmm That's not very friendly
15:53 gregorycu No, he isn't
15:53 gregorycu err... neither is putting him on ignore
15:53 hmmmm =/
15:54 Zeno` Show me once where I was not friendly :/
15:54 hmmmm I think it's childish but whatever.  Zeno, did you post your concerns on github??
15:54 hmmmm in the PR
15:54 Zeno` I cannot in good faith reopen that PR when I am put on ignore for no apparent reason
15:54 Zeno` hmmmm, I have :)
15:54 Zeno` also in the logs
15:55 hmmmm well
15:55 hmmmm there's no real way of communicating between both of you
15:55 Zeno` nope
15:55 celeron55 gregorycu: 17:48:41 <+Zeno`> If you refuse to talk to people why should the PR be trusted? 17:49:42 <+Zeno`> If I merge the PR and something goes wrong, how can it be discussed?
15:55 gregorycu You probably want me to address those two points
15:55 celeron55 gregorycu: kill the ignore right now, Zeno` is a core developer
15:56 hmmmm a level of communication is expected with the rest of the team
15:56 kahrl nrzkt, Zeno`: https://gist.github.com/kahrl/7a4584b58164545d3288
15:56 gregorycu Is IRC a requirement to contribute?
15:56 kahrl okay to push?
15:57 nrzkt okay
15:57 Zeno` kahrl, looking
15:57 celeron55 gregorycu: it kind of is, unless you refuse to use IRC altogether
15:57 Zeno` kahrl, yeah I think this is ok. The preconditions are now documented and the assert is there
15:57 gregorycu So, if I leave IRC and don't return, can I get my PR reopened?
15:57 hmmmm it isn't, but cowboy coding is frowned upon
15:58 gregorycu I am willing to listen to everybodies concerns about my code
15:58 celeron55 gregorycu: at least state in your pull requests and issues if you are on IRC, but do not want to discuss it on IRC
15:58 celeron55 people assume that if you are here, you are willing to discuss things here
15:58 hmmmm ughg
15:58 ShadowNinja hmmmm: About the SQLite3 pull: The other DBs are KV stores, so they'll have to be done in a different way.  If they work with binary keys I'd enode the position into a string and use that as the key insteak of the current ASCII-decimal-hash format.
15:59 gregorycu I can do that
15:59 kahrl nrzkt, Zeno`: pushing now
16:00 nrzkt ok, thanks you, i will not crash 0.4.12 servers next week :D
16:00 shadowzone joined #minetest-dev
16:00 hmmmm I have like real work todo
16:00 hmmmm so i'll talk more about this later
16:00 celeron55 gregorycu: i can respect that as long as you make it clear; IRC is terrible sometimes
16:02 gregorycu I have updated the specific PR in question. I've already been miscategorised once about what was/wasn't said on IRC, so I'd just prefer to be clear.
16:02 Zeno` There are logs
16:02 Zeno` You can read them, gregorycu
16:04 Zeno` #2219... yikes
16:04 ShadowBot https://github.com/minetest/minetest/issues/2219 -- Singleplayer segfaults if server rejects client
16:05 Zeno` game_has_run = true ... is that correct?
16:05 * Zeno` looks at main.cpp
16:09 fz72 hey there, question: why is #2211 closed and not merged? There is fix merged but nogosang said that this fix doesn't work correctly
16:09 ShadowBot https://github.com/minetest/minetest/issues/2211 -- Fix map_meta.txt error when loading a new world (last try) by ngosang
16:10 toshiba_ joined #minetest-dev
16:10 shadowzone joined #minetest-dev
16:11 werwerwer joined #minetest-dev
16:11 kahrl ok, before I push, I loaded an old version (around ser ver 20) to make sure it can be loaded
16:12 kahrl indeed it could, so I'm pushing for real now
16:12 Zeno` :)
16:13 nrzkt :p
16:15 selat joined #minetest-dev
16:18 MinetestForFun joined #minetest-dev
16:21 shadowzone joined #minetest-dev
16:28 ImQ009 joined #minetest-dev
16:32 nrzkt go back home, see u later
16:45 fz72 I can confirm what nogosang said. I tested it. Who is kwolekr in IRC?
16:47 exio4 fz72, hmmmm
16:47 PilzAdam joined #minetest-dev
16:47 fz72 thanks exio4
16:48 ShadowNinja hmmmm: https://github.com/minetest/minetest​/commit/eeea454bff0cfcda495c20029a02​46f63f14393e#commitcomment-9462726
16:48 hmmmm ShadowNinja:  That IS a fix.
16:49 ShadowNinja hmmmm: Create to worlds with different mapgens, load the first world, see second mapgen.
16:49 ShadowNinja two*
16:49 hmmmm ShadowNinja:  I am aware of this.  It is absolutely not related in any manner to the bug solved by that commit.
16:50 ShadowNinja hmmmm: It is related because the map_meta.txt should always exist.
16:50 hmmmm ShadowNinja:  Says who?
16:50 ShadowNinja hmmmm: Me?
16:50 hmmmm map_meta.txt is a set of parameters.  If the file doesn't exist, it's equivalent to there being no parameters specified in an existing map_meta.txt.
16:50 ShadowNinja Otherwise you don't know what the mapgen's supposed to be.
16:51 hmmmm It falls back onto the defaults.  This is the SAME exact behavior as every other configuration file.
16:51 ShadowNinja You just have to guess from the main settings.
16:51 kilbith joined #minetest-dev
16:51 kaeza joined #minetest-dev
16:52 hmmmm If you don't know what the mapgen is supposed to be, it defaults to whatever is set in the current working global settings.
16:52 ShadowNinja hmmmm: I think it should be required becuase otherwise you'll make worlds with multiple mapgens whenever someone updates the defaults.
16:52 fz72 hmmm: https://github.com/minetest/minetest/pull/2184
16:53 hmmmm ShadowNinja:  That's nonsense.  This does not affect anybody in that manner in reality.
16:53 hmmmm ShadowNinja:  map_meta.txt gets created and populated with the mapgen parameters when it does start generating map.  The behavior you stated in your last line is expected and wanted.
16:53 ShadowNinja hmmmm: It's not a common bug, but it's a bug nontheless.
16:53 hmmmm ShadowNinja:  And I recently decided that Minetest not having dishwashing functionality is a bug.
16:54 PilzAdam hmmmm, why is the user prompted to select a mapgen at creation time then?
16:54 ShadowNinja hmmmm: Yes, it's populated then, but it has to be populated on creation.
16:54 PilzAdam move the dialog to first startup then
16:54 hmmmm PilzAdam:  Because somebody else did that who doesn't understand the mapgen system.
16:54 PilzAdam move the dialog then
16:54 ShadowNinja hmmmm: Don't be unreasonable.
16:54 hmmmm PilzAdam:  I did not advocate creating a mapgen selection dialog.
16:54 PilzAdam remove it then
16:54 ImQ009 joined #minetest-dev
16:54 PilzAdam but don't keep it this broken state
16:55 hmmmm PilzAdam:  It's not broken.
16:55 hmmmm If you don't like the interface provided, let's talk about changing the interface.
16:55 ShadowNinja It should be at creaton, like every other volel sandbox game.
16:55 hmmmm But don't tell me that it's bugged when it isn't
16:55 PilzAdam it does not work the way users expect it; so it's broken
16:55 hmmmm That's the most ridiculous argument I've ever heard
16:56 hmmmm the users expect some insane things at times.
16:56 Brains Apparently these users here can't agree what the expectation is...  Users must be broken.
16:56 hmmmm Not that this particular expectation is insane, but if you were to say in general that users are always right, then you're living in a fairyland
16:56 fz72 I think nobody wants to see this dialog. So whats wrong with nosang's PR? He fixed that problem!
16:56 hmmmm I was not aware of this PR at all until you pasted it here.
16:56 ShadowNinja The customer is always right!  :-P
16:57 hmmmm ShadowNinja:  Stores stopped respecting that phrase.
16:57 PilzAdam when it comes to GUI then the user is always right
16:57 PilzAdam since the GUI is created for the user, not the other way round
16:57 hmmmm But the user is only one user, not the majority of users
16:57 hmmmm One user can't speak for everybody
16:58 PilzAdam every single person here thinks that it's wrong, except hmmmm
16:58 * Brains will disagree just on principle.
16:58 hmmmm Fine.  I'll populate a map_meta.txt on initializeWorld() using the current working settings.'
17:00 Brains Hrm, forums and wikis are down...
17:01 PilzAdam hmmmm, cool
17:02 hmmmm But the point is that commit is not wrong at all in what it does
17:02 hmmmm It simply does not solve something different you somehow mistakenly believe is related
17:04 hmmmm PilzAdam:  What's up with backend = sqlite3 being hardcoded?
17:04 PilzAdam hm?
17:04 fz72 hmmmm: That's true, but #2184 got closed for this reason
17:04 ShadowBot https://github.com/minetest/minetest/issues/2184 -- Fix map_meta.txt error when loading a new world by ngosang
17:05 hmmmm fz72:  I did not close that.
17:05 Zeno` I closed it
17:05 Zeno` because the issue seemed to be resolved in a sensible manner
17:06 hmmmm I don't like the throwing of an exception if map_meta.txt is not found
17:06 hmmmm changing it to infostream is sort of dumb
17:06 ShadowNinja hmmmm: SQLite3 is curreltly a hard dep, unlike the other DBs (it's also used for rollback).
17:07 hmmmm when is a game's minetest.conf override loaded?
17:07 hmmmm wondering if this is the wrong approach.  I want to capture the state of the configuration at the point just before mods get run
17:08 sfan5 :/
17:08 sfan5 ShadowNinja: why does your pull add static_cast's to database-redis.cpp
17:09 sfan5 it uses the libhiredis C interface
17:09 sfan5 static_cast will do exactly the same as now
17:09 sfan5 (feel free to correct me, my source for this is an answer on stackoverflow)
17:10 hmmmm I agree C style casts should probably be used there
17:10 PilzAdam sfan5, typing more, useless letters helps you memorize routines while coding and ultimately makes you a better programmer
17:10 hmmmm it's the least-weird thing and it gets the correct intended behavior
17:12 hmmmm C++ Standard, 5.4.5
17:13 exio4 PilzAdam, didn't know programming was more about memorizing and less about logic and data dependencies/flow
17:13 PilzAdam exio4, the point of programming is obviously the typing
17:13 sfan5 PilzAdam: oh, i see, does this mean we should also use variable names like this_variable_stores_the_amount_of_ite​ms_the_player_has_in_the_current_slot?
17:14 PilzAdam why would there be so much flamewars about tabs vs. spaces if it wasn't about the typing?
17:14 * hmmmm blinks
17:14 hmmmm PilzAdam wasn't being sarcastic?
17:14 hmmmm I'm confused
17:15 exio4 now I don't know what is sarcasm and what isn't :)
17:16 hmmmm Is it just me or does filesys.cpp absolutely suck?  Everything done there is done in an overcomplicated, ridiculous manner
17:22 SopaXorzTaker joined #minetest-dev
17:31 electrodude512 joined #minetest-dev
17:39 Hunterz joined #minetest-dev
17:45 hmmmm just noticed an issue where you can't run minetest under valgrind on freebsd
17:45 hmmmm how do the other OSes work where the correct intended executable path is retrieved?
17:46 hmmmm can't rely on /proc/self/exe like linux since procfs is optional
17:50 Calinou joined #minetest-dev
18:01 Wayward_One joined #minetest-dev
18:06 shadowzone joined #minetest-dev
18:12 kilbith kahrl: you've forgot to close 2212 after merged
18:20 SopaXorzTaker joined #minetest-dev
18:25 rubenwardy joined #minetest-dev
18:25 Player_2 joined #minetest-dev
18:31 nrzkt joined #minetest-dev
18:35 nrzkt Network rework on packet writing is in a good way, writer is fully operational ! Now i can convert every Send to new NetworkPacket
18:42 NakedFury joined #minetest-dev
18:43 Krock joined #minetest-dev
18:48 shadowzone joined #minetest-dev
18:49 MinetestForFun joined #minetest-dev
18:49 kahrl kilbith, thanks
18:54 iqualfragile joined #minetest-dev
18:55 Krock joined #minetest-dev
18:57 exio4_ joined #minetest-dev
18:57 y joined #minetest-dev
19:04 Vexyl joined #minetest-dev
19:09 Fadi joined #minetest-dev
19:20 electrodude512 joined #minetest-dev
19:25 shadowzone joined #minetest-dev
19:25 shadowzone__ joined #minetest-dev
19:25 shadowzone_ joined #minetest-dev
19:27 exio4_ joined #minetest-dev
19:29 n4x joined #minetest-dev
19:33 ImQ009 joined #minetest-dev
19:38 Player_2 joined #minetest-dev
19:44 nrzkt #freeminer ?
19:44 nrzkt rocket launch done :p
19:48 nrzkt left #minetest-dev
19:59 est31 !g rocket launch
19:59 ShadowBot est31: https://www.kennedyspacecenter.com​/events.aspx?type=rocket-launches | Find out what rocket launches are taking place at Kennedy Space Center Visitor Complex. Launch date, time and viewing opportunities are subject to change.
20:06 Fury joined #minetest-dev
20:11 NakedFury joined #minetest-dev
20:22 Tesseract joined #minetest-dev
20:30 PilzAdam it seems like everyone just forgot / ignored that the 0.4.11 build for ubuntu 12.04 failed: https://launchpadlibrarian.net/193537189/b​uildlog_ubuntu-precise-i386.minetest_0.4.1​1-0ppa1~ubuntu12.04.1_FAILEDTOBUILD.txt.gz
20:30 PilzAdam sfan5, it seems to be related to the redis backend; could you look at it?
20:31 sfan5 how did you come to that conclusion
20:31 sfan5 anyway
20:31 VargaD_ joined #minetest-dev
20:31 sfan5 that build fail is leveldb related
20:31 sfan5 libsnappy/libleveldb/both are/is broken in ubuntu 12.04
20:32 sfan5 this is also the reason why the travis build download a custom leveldb build
20:32 PilzAdam oh, yes, mixed up leveldb and redis
20:33 PilzAdam does anyone know how to configure the launchpad build to not compile with leveldb, so we can get a working build?
20:33 gregorycu joined #minetest-dev
20:34 sfan5 PilzAdam: isn't there some sort of build script you can change?
20:34 PilzAdam celeron55, who was the guy that recently changed the launchpad build scripts to include more optional stuff?
20:36 PilzAdam seems like it could be changed here: http://bazaar.launchpad.net/~minetestdevs​/minetest-c55/packaging/view/head:/rules
20:37 sfan5 huh
20:37 sfan5 hm
20:39 celeron55 PilzAdam: i don't know
20:39 PilzAdam do you know how to edit the rules file?
20:40 PilzAdam another way would be to build with revno:22, but it would lack freetype and gettext
20:40 celeron55 you have to use the package manager
20:40 celeron55 called bazaar, that launchpad wants to use
20:40 celeron55 lol i mean version control program
20:40 celeron55 not package manager
20:41 celeron55 because... i guess the world needs more version control systems
20:41 sofar git is soooo bad ;^)
20:42 celeron55 bazaar is the ultimate NIH of VCSes just like Mir is the ultimate NIH of windowing systems
20:42 celeron55 both pretty much by ubuntu
20:42 celeron55 it's stupid
20:42 sofar out of curiosity, what OS's do most core MT devs use to develop?
20:42 sfan5 Linux
20:42 celeron55 various gnu/linux distributions
20:43 sofar I know why they did MIR - purely to enable android drivers
20:44 * sofar works on linux distributions for Intel... hence my question
20:50 celeron55 do you want a more specific answer? you'll need to set up a poll for that
20:51 celeron55 for us it's simply a matter of allowing anyone to use any distro they like
20:56 Amaz joined #minetest-dev
21:06 sofar oh no, I figured most would be on Linux, so, I got my answer
21:10 iqualfragile joined #minetest-dev
21:14 younishd joined #minetest-dev
21:35 electrodude512 joined #minetest-dev
21:54 acerspyro joined #minetest-dev
21:57 Anchakor joined #minetest-dev
22:01 selat joined #minetest-dev
22:11 Bajouca joined #minetest-dev
22:24 Miner_48er joined #minetest-dev
22:49 peacock486 joined #minetest-dev
22:52 est31 If anyone wants to discuss #2220 in irc not on github, I'm around :)
22:52 ShadowBot https://github.com/minetest/minetest/issues/2220 -- add wait_clicked and texture_waiting to formspec button or image_button
23:01 CraigyDavi joined #minetest-dev
23:03 Taoki joined #minetest-dev
23:06 blaise joined #minetest-dev
23:09 shadowzone joined #minetest-dev
23:13 Taoki joined #minetest-dev

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