Minetest logo

IRC log for #minetest-dev, 2013-12-31

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

All times shown according to UTC.

Time Nick Message
00:01 VargaD sapier: I like the MutexedQueue changes, but I would remove the exception in the long run
00:02 sapier it may be necessary if someone doesn't actually know if there's something in that queue but can't wait for it
00:03 VargaD I would take the object in reference and return false when it is empty and we can't wait
00:03 VargaD it is just bad (and very slow) to use exception for control flow
00:04 sapier that's why I wouldn't do it that way too
00:04 sapier no idea why exceptions are used as normal control flow throughout minetest
00:05 VargaD it can be used, sometimes, but not in performance critical code
00:05 VargaD a multi threded general propose queue shouldn't use it that way
00:05 sapier right now that one is only used in single consumer environments where you can check the queue before but that's not a variant I'd encourage to use
00:07 VargaD I know, your change is OK for now, it does slove the performance problem
00:17 proller saving 31336 players files took 108 seconds IN SERVER THREAD
00:17 sapier wow :-)
00:18 VargaD thats a lot of players
00:18 ShadowBot joined #minetest-dev
00:19 diemartin joined #minetest-dev
00:19 VargaD how much players do you have at a time?
00:20 proller online max?
00:21 VargaD yes, what is the max your server could handle?
00:21 PilzAdam proller, if you want to fix that then fix the operator == for inventory
00:21 proller maybe 100+
00:22 proller xyz record - 81
00:22 proller but lot of lags from locking
00:22 proller and connection.cpp becomes crazy
00:24 proller minetest without mods can 20-30
00:34 proller my opinion: in current state - development must be problem-oriented to solve most annoying things first
00:39 RealBadAngel joined #minetest-dev
00:40 sapier could you be more precise about locking and connection.cpp?
00:41 RealBadAngel does anybody know where's the code that displays players names ingame? i mean nicks over player models
00:42 proller code must contain 0 of JMutexAutoLock
00:43 proller locks can be only inside containers
00:43 proller exceps some special places
00:44 proller containers must be inherited from std::[map, vector, ....]
00:44 proller maybe find good NIH
00:45 sapier lol
00:46 proller server step must be split into 5-10 threads for every action
00:47 sapier you know none of the std types is threadsafe?
00:47 VargaD isn't it bad practive to inherit std containers?
00:47 us_0gb joined #minetest-dev
00:47 VargaD there are a lot of linking issues on windows
00:48 proller sapier, "inherited from" and have same interface, but be thread safe
00:48 sapier and if you had a look for my udp fixes you'd have seen I moved all lock to their containers
00:49 sapier yet it's a tradeoff if the more fine granular you do locking the more time you spend in os doing the locking
00:51 sapier without resonable benchmark it's hard to find the sweet spot
00:51 VargaD if you need to make atomic change in more than one data strcture it isn't useful to have to locks in the data structures
00:51 proller also blocks must have per-block locking
00:52 VargaD moving locks to containers should be that hard rule
00:52 thexyz sapier: define threadsafe
00:52 sapier I guess I suggested this months ago
00:52 sapier threadsafe ... any function is callable at any time by different threads without messing up internal data
00:55 VargaD s/should/shouldn't
00:57 thexyz I still don't understand you but I'd like to point out that it's perfectly fine to read from std containers from multiple threads so long as no one is writing
00:57 sapier yes but how do you want to be sure noone is writing in that very moment?
00:58 thexyz that's what readers-writer locks exist for
00:58 sapier ok and now a more specific explanation how to do that in c++?
00:59 sapier as far as I know we have semaphores and mutexes commonly available
00:59 thexyz how to use pthread in c++ or what? anyway, that's going too far away because we probably will be able to solve all our performance issues without them
01:00 sapier I'd be glad to have a lightweight lock available but as far as I know we haven't correct me if I'm wrong
01:00 thexyz and for windows you can just use mutex in place of that since no one runs servers on windows anyway
01:00 VargaD thexyz: it is still lock just readers writers lock
01:01 thexyz am I saying it isn't?
01:01 sapier I use mutex for locking but they aren't quite what I'd call lightweight
01:01 thexyz of course rwlock will have more overhead
01:02 VargaD are you sure that currently in minetest the main problem is the locks?
01:02 thexyz it depends on whether we read more than write
01:02 thexyz from more threads
01:02 thexyz VargaD: yes, and single threaded model
01:02 thexyz I had a feeling that everything thinks it's under an envlock
01:02 sapier thexyz you allways talk about your famous rwlock can you explain to me what you're talking about?
01:03 thexyz what exactly do you want from me?
01:03 thexyz I'm just saying that it should be considered
01:03 sapier I want to know what you're talking about?
01:03 thexyz sure thing http://en.wikipedia.org/wiki​/Readers%E2%80%93writer_lock
01:04 VargaD minetest use a thin layer that hides platform differences and that doesn't have readers writes lock implementation
01:04 VargaD so first we need to implement it, or use a library that already has
01:04 sapier so you throw some random generic concept in and expect us to know what you want?
01:04 VargaD that was the problem with the monitor
01:05 thexyz no, I expect you to try to use your brain, to be honest
01:05 thexyz and as I have already said this is definitely not the main problem
01:05 thexyz just something to consider
01:05 sapier I don't have your brain I don't know your ways of thinking ;-)
01:05 thexyz I'm sure you have some brain
01:05 VargaD calm down, we need to work together :)
01:05 thexyz so you could use some way of thinking
01:06 VargaD first we need to have a readers writers lock implementation
01:06 thexyz fir we need to separate our threads
01:07 VargaD and have a place where we can replace lock with readers writes lock
01:07 sapier no I don't have some brain ... that's why I'm leaving that discussion right now ... just throwing in something you may have read somewhere without even looking if it isn't already done that way (at some places) is useless
01:07 sapier that rwlock is nothing more/less than a special way of using mutexes
01:07 thexyz yeah, sure, because you of course know better whether I just read about it somewhere
01:07 thexyz anyway!
01:08 sapier I hate it if ppl randomly throw in design patterns without REALY thinking about what they're good for
01:08 VargaD of course rwlock can be implemented with mutex, actually it is implemented with mutex
01:08 sapier it's just a design pattern not a special lock
01:09 sapier most experienced programmers use it without even thinking about how it's called ;-)
01:09 thexyz yeah, sure
01:10 sapier and yes usually design patterns are usefull ... that's why someone did the work writing them down
01:10 thexyz this could be useful in map since we read more often that write
01:10 thexyz if you want some examples
01:11 VargaD yes
01:11 sapier I usually don't look for where I could add a pattern but look at a problem and find a solution for it
01:11 thexyz that's how it happened for me that time
01:11 thexyz but since you're the head of server/client/env now it seems I'll leave that for you to decide
01:12 thexyz and network stuff too
01:12 PilzAdam the subsystem thing isnt approved yet, I guess
01:12 sapier I'll not stick to tcp/udp if someone has a good suggestion
01:12 thexyz but if someone has a suggestion you'll just tell them it's worse than tcp/udp
01:12 sapier and PilzAdam is right too
01:12 thexyz but of course you're not stick to it
01:12 sapier no I wont
01:13 sapier in fact I plan to evaluate enet too
01:13 sapier as second alternative to tcp
01:13 VargaD thexyz: it just means the he will be responsible for that subsystem, he accepts possible your pull request
01:14 VargaD a veteran blizzard devloper has writtem his thoughts about game network libraries it might be wort to read it: http://www.codeofhonor.com/blo​g/choosing-a-game-network-lib
01:16 sapier interesting
01:16 thexyz yeah well network library isn't the main problem compared to the nih syndrome at least
01:17 thexyz I'm fine with that suggested subproject separation thing, at least it's going to be fun this way
01:17 sapier guess you're not docmatic on insisting to use a external lib for anything ;-)
01:18 thexyz when I talk about rwlock I usually mean it in the following way: "hey you probably don't know about this thing which it's possible to make a great use of in our code"
01:19 sapier lets first decide who really will be responsible for this until then discussion is wast of time
01:19 thexyz because as we've figured out, that's true and you didn't know about it
01:19 RealBadAngel so, anybody know where i can find the code for showing players nicks above their models?
01:19 sapier ok thexyz I may have missunderstood your intentions about rwlock
01:20 sapier there are lots of crazy pieces of code in there trust me I've seen creepy things on fixing connection.cpp ... and looking at the diff there's not a single beeing left on same position
01:20 sapier +line
01:21 sapier e.g. passing return value by exception ....
01:21 sapier I haven't removed all of it but it should be done
01:22 PilzAdam RealBadAngel, content_cao.cpp:1015
01:23 VargaD Good night, it is getting quite late here...
01:24 RealBadAngel PilzAdam, thx
01:43 Sokomine i'm still unable to play with latest git on redcrabs server. thought that problem got solved?
01:44 Sokomine (the map data is not shown - there's only grey fog)
01:48 sapier left #minetest-dev
02:10 Miner_48er joined #minetest-dev
02:20 kvitkovski joined #minetest-dev
02:54 Jordach joined #minetest-dev
02:55 Jordach we've got a large problem: builddaft made it into the apple app store  - https://forum.minetest.net/vie​wtopic.php?pid=123648#p123648
03:00 ShadowNinja Someone find their DCMA form.
03:06 VanessaE RealBadAngel: oh PLEASE PLEASE fix that font :)
03:09 RealBadAngel font?
03:12 VanessaE [12-30 20:17] <RealBadAngel> so, anybody know where i can find the code for showing players nicks above their models?
03:13 RealBadAngel ah that, i was lookin for that for another reason
03:13 VanessaE oh ok
03:14 RealBadAngel im tryin to display distance to waypoints on HUD
03:17 RealBadAngel lookin for easy way to calculate screen position of visible waypoint
03:17 RealBadAngel and cant find anything usable
03:46 kahrl RealBadAngel: camera.getCameraNode()->getViewMatrix() and getProjectionMatrix()?
03:58 bas080 joined #minetest-dev
04:02 RealBadAngel Kahrl, in Lua
04:03 RealBadAngel if those matrices could be exposed to Lua it would be easy
04:07 RealBadAngel i need it for single point, if waypoint is in player view range, get screen coords to display there distance to that point
04:18 kahrl RealBadAngel: the server doesn't even know the client's fov so good luck
04:31 RealBadAngel i do have, position, camera look dir, distance to the point
04:31 RealBadAngel it should be something like this: http://freespace.virgin.net/hu​go.elias/routines/3d_to_2d.htm
04:54 kahrl RealBadAngel: maybe you can adapt isBlockInSight and just use a fixed fov (like the block sending code does anyway)
04:56 RealBadAngel kahrl, good idea
04:58 RealBadAngel anyway HUD api is incosistent, when defining HUD element "position" field is used
04:59 RealBadAngel but when changing element theres no such field, but "pos"
04:59 RealBadAngel trying to change "postion" field, results in setting "number" field to 0
05:00 kahrl there was an issue about that
05:00 kahrl pull request, in fact
05:00 kahrl #1060
05:00 ShadowBot https://github.com/minetest/minetest/issues/1060
05:01 RealBadAngel definitely thats it
05:01 RealBadAngel it has to be merged
05:02 kahrl iirc there was some controversy about compatibility
05:02 RealBadAngel theres nothing like compability there, its just broken
05:03 kahrl I'm not sure, I didn't follow that discussion
05:03 RealBadAngel it took me an hour to find out why my code is not working
05:03 RealBadAngel api doc uses "position"
05:04 RealBadAngel setting the hud element uses "postion"
05:04 RealBadAngel why changing should use "pos" ??
05:04 RealBadAngel its just a bug
05:05 RealBadAngel not to mention that try to use "position" changes some other field instead of desired one
05:06 VanessaE so this hasn't been merged yet......why?
05:06 kahrl RealBadAngel: how does that happen?
05:07 kahrl VanessaE: http://irc.minetest.ru/minet​est-dev/2013-12-21#i_3507720
05:07 ShadowNinja I agree that that should be changed now. (But my working dir is full and I'm busy ATM)
05:08 kahrl ok, so let's merge it
05:08 kahrl RealBadAngel: do you want to do it?
05:08 VanessaE and herein lies the root problem you were trying to figure out.  Little shit like that ^^^ should simply have been merged, and if it breaks something, just fix those things?>
05:08 VanessaE s/you /you guys, earlier, /
05:11 kahrl why does hud_change default to HUD_STAT_NUMBER anyway?
05:12 RealBadAngel kahrl, i cant atm
05:12 kahrl RealBadAngel: I'll do it
05:20 nore joined #minetest-dev
05:36 OldCoder joined #minetest-dev
06:00 OldCoder joined #minetest-dev
06:36 smoke_fumus joined #minetest-dev
06:39 OldCoder joined #minetest-dev
07:11 darkrose joined #minetest-dev
08:41 nore joined #minetest-dev
08:55 mrtux joined #minetest-dev
09:02 sfan5 celeron55: maintainers for each subsystem is ok with me, I'm only afraid this might slow down development generally
09:05 Calinou joined #minetest-dev
09:43 sapier joined #minetest-dev
09:46 Evolykane joined #minetest-dev
09:46 sapier sfan5 can you explain why you are afraid it could slow down development?
09:48 sfan5 there need to be more people to get something merged
09:48 sfan5 more -> a specific core dev vs. 2 core devs
09:49 sapier true, but right now it's hard to find two core devs beeing interested enough to merge something ... with maintainers there is someone beeing responsible, no matter if that special pull interessts her/him or not
09:50 sapier so in common case she/he does at least have to comment "no because of ..." or "fix this that and that ..." ... of course that'd be case in an ideal world only, there will be glitches in real world
09:52 sapier but of course your fears might be true too
10:03 proller joined #minetest-dev
10:05 john_minetest joined #minetest-dev
10:15 celeron55 i would gladly remove sapier from server/client/env and low-level network if there was anyone else to put there
10:15 celeron55 but as long as there isn't, then sapier will handle it; i don't like sapier's way of arguing either
10:16 celeron55 probably nobody likes
10:18 john_minetest What is bad about how he changes networking now? I don't know much about networking but what sapier does sounds quite logic to me.
10:18 sapier I'm always open for suggestion how to do it better celeron55 :-)
10:20 celeron55 i fully agree that it's a shitty issue and i'm personally waiting for something that would really poke the balance towards the other
10:22 sapier I don't even know what this could be, all solutions are quite close. some have benefits there others there and none of those issues is free of subjective preference
10:23 john_minetest Would it make sense to implement a completely new protocol that works reasonable fast and keep the old one as compatibility protocol in the server code?
10:24 sapier as far as I know the "completely new" option wasn't suggested by anyone
10:25 john_minetest If the old one is so broken and bad as everybody seems to say, it might be better to make a new one.
10:26 sapier the worst thing about the old one isn't the protocol itself but it's implementation ... yet it's not gonna be perfect on fixed implementation
10:26 john_minetest Also there is still the option of releasing 0.5.0 with a completely new protocol. Since minor versions are not compatible it might be okay.
10:26 proller enet is new
10:26 sapier enet isn't new
10:26 celeron55 in the end i put sapier on those subsystems because i do think sapier can choose it sanely; it's just that people won't like him doing that 8)
10:26 john_minetest Actually not even 0.4.4 to 0.4.8 works properly. So 0.5.0 should be okay if it breaks every old client.
10:27 sapier thanks ... so I'm the bad guy :-)
10:27 sapier no problem ;-)
10:27 john_minetest We need a bad guy to distract from other problems.
10:27 celeron55 so who's on the democracy subsystem? we could ask him to arrange a community voting and see if the community prefers compatibility over cleanliness
10:28 sapier my intention is to keep compatibility to old clients AND initiate transition to a new better protocol
10:28 celeron55 personally i really don't know
10:28 john_minetest Compatibility is overrated.
10:28 celeron55 and i doubt anyone knows here
10:28 celeron55 we should be doing what the community wants in the end
10:28 john_minetest A minor version incremention can break everything and nobody cares. Like in 0.3.x -> 0.4.x
10:29 john_minetest And minecraft does it all the time.
10:29 sapier if you get payed 10 times the money competitiors get payed just because you guarantee compatibility for 20 years you know it isn't overrated ;-)
10:29 john_minetest Nobody complains
10:29 celeron55 sapier: it's a game
10:29 john_minetest We don't get paid. We want a playable game.
10:29 sapier yes so why do you complain if we can have everything? ;-)
10:30 sapier it's common agreement we need to switch to a new better protocol ... that's more then we agreed months ago ... so I see (slow) progress
10:30 celeron55 the thing is, minetest wasn't originally designed for compatibility, making that very messy
10:30 sapier another few months and we may agree to what protocol
10:30 VargaD sapier's networking improvements might improve a lot, ha at least done a fair code cleanup in network code that can a base to further rafactoring
10:30 celeron55 if it was, we'd have no issues whatsoever
10:31 proller sapier, it's a game with 100 active users
10:31 john_minetest If we switch to a new protocol it might slow the server down a lot to keep that backwards compatibility.
10:31 celeron55 VargaD: i like to think it as being away from some other useful work
10:31 sapier yes but just jumping to something new without understanding will just drive us into same issues in some months
10:31 celeron55 john_minetest: that's not an issue; the issue is maintainability
10:32 celeron55 sapier: you've said that enough times already; it's time to figure out whether it's the case or not
10:32 celeron55 saying it doesn't help at all and just pauses the discussion for a moment
10:32 sapier true any idea how to proofe one ore another without waiting 4 years?
10:32 proller sapier, do not touch everything while you not understanding
10:33 john_minetest celeron55: I mentioned maintainability before but it seems that is not a problem to sapier. But maybe I got that wrong. Point is, that servers running with a faster protocol but being slower than before because they maintain compatibility, is not a solution for the speed problem we have to face.
10:33 sapier proller replacing something isn't "not touching" its moreover most extreme case of touching ;-)
10:34 sapier is there any reason to believe compatibility will have reasonable influence to performance?
10:34 celeron55 i already said it likely won't
10:35 sapier maintainability is an issue true... but it's for limited time only as even I want to get rid of the old protocol
10:35 john_minetest If it has no influence then go ahead and maintain compatibility. I was just concerned about that problem but it seems it doesn't exist.
10:35 sapier I only disagree with that hard transition
10:35 celeron55 sapier: well okay; so what is your view on freeminer using an other protocol then?
10:36 john_minetest With a soft transition we would always get people saying "xy doesn't work in this version" because they use the old protocol.
10:36 celeron55 it's irrelevant? i'm kind of okay if it is, but it has implications
10:36 john_minetest If we make a hard transistion it just says "Okay, your client is too old, go away."
10:36 sapier I don't care about freeminer thexyz as well as proller said they don't have any intention to push back any patch ... I won't do work twice because those two fork in incompatible way
10:37 VargaD changing to a protocol nowdays that does not support ivp6 is a mistake
10:37 sapier I'd prefere to have a compatible protocol but if that means reimplementing any of their changes  forgett it
10:37 celeron55 there's at least one real-life example of a project forking incompatibly and the main project still merging everything; it's ffmpeg (the compatible original) and libav (the nasty fork)
10:38 celeron55 i don't know how much work ffmpeg has to do because of that, and those surely are larger projects with commercial interests though
10:38 sapier if there are usefull features and they are mergable I will do that of course, but if merging means doing same work again .... no
10:38 celeron55 VargaD: thexyz's and prollers view on that is that it's trivial to modify enet to support ipv6
10:39 celeron55 they haven't done that though
10:39 sapier I didn't understand this same way celeron55
10:41 celeron55 i guess sapier has a decision there then; i won't argue anymore
10:42 sapier don't expect final decision to be done next few days ... as I guess thexyz won't provide a minetest compatible enet branch for verififcation I guess I need to do this myself
10:43 sapier btw celeron55 you need to declare the subsystem maintainer thing to be active by some time
10:44 VargaD but we also have other choices: POCO C++, Boost ASIO
10:45 sapier as far as I know anything containing the word "boost" is out ... am I wrong about that?
10:45 celeron55 VargaD: those aren't real choices due to various reasons; don't bother :P
10:45 VargaD why? (I'm curious)
10:46 sapier using boost without using it everywhere isn't usefull ... and boost does incompatible code changes all the time ... at least that's what I remember
10:46 celeron55 many of us hate boost; it's made in the exact opposite way of minetest
10:47 celeron55 boost is like another language; you either use it everywhere or not
10:47 celeron55 POCO seems quite obscure and is a similar thing IIRC
10:47 VargaD yes it seems similar
10:47 celeron55 if either of those is used, then a decision should be made to migrate the whole codebase to use the chosen one
10:48 celeron55 = yeah not how, forget it
10:48 celeron55 now*
10:48 celeron55 and as i understand they don't provide any actual protocol
10:48 celeron55 they just wrap TCP and UDP
10:48 celeron55 which sapier's code already does just fine
10:49 sapier I'd not call it "fine" right now
10:49 celeron55 i'm sure it wraps TCP fine
10:49 celeron55 the other part you'd have to do with boost or poco too
10:50 Calinou joined #minetest-dev
10:50 sapier true
10:55 celeron55 oh, and; before taking the subsystem thing into use, i want to hear what hmmmm has to say about it
10:58 celeron55 he doeosn't do really any work anymore, but as long as he is assigned to mapgen, it matters (i wonder who else it could be)
10:59 celeron55 well proller has worked on that stuff; i bet he doesn't want to, or people generally don't want that
11:01 celeron55 i think kahrl would be qualified for anything, but dunno if he wants to
11:02 celeron55 we've accumulated quite many of these people who know stuff but don't want to use their time
11:02 celeron55 our best bet would be to re-motivate them somehow
11:10 werwerwer joined #minetest-dev
11:18 Jordach joined #minetest-dev
11:27 jin_xi joined #minetest-dev
11:31 iqualfragile joined #minetest-dev
12:10 kahrl I could manage one of the smaller subsystems if needed
12:11 kahrl the question would be which one
12:11 kahrl maybe the "black irrlicht magic" subsystem? :P
12:11 VanessaE hah
12:13 sapier kahrl it'd be unfair to count that as volonteering for graphics subsystem isn't it?
12:13 kahrl yes it would ;)
12:19 celeron55 that isn't only about technical issues though; it also involves deciding what looks good and appropriate
12:20 celeron55 but it trust kahrl to ask someone about that!
12:21 celeron55 i'm changing myself to kahrl there; i want to spread these around as much as possible initially
12:22 celeron55 it will result in two things: 1) nobody gets overloaded with work, and 2) it will show faster if there is a built-in problem in this
12:23 Evolykane joined #minetest-dev
12:23 celeron55 s/but it/but i/
12:25 kahrl celeron55: I meant "yes, it would be unfair"
12:25 kahrl I'm kind of terrible at graphics...
12:25 kahrl also the graphics subsystem will probably have the most controversial pull requests, not sure if I have the energy for that
12:25 celeron55 then i'm switching you and me around
12:26 celeron55 now you're on startup/config 8)
12:27 kahrl sounds better :)
12:30 kahrl which subsystem do utility fixes go to? (such as #1054)
12:30 ShadowBot https://github.com/minetest/minetest/issues/1054
12:32 celeron55 i think startup/config
12:32 celeron55 it's kind of the "core of the core"
12:32 kahrl I'd rename it to startup/config/util then
12:33 celeron55 renamed
12:38 celeron55 i propose a new subsystem: android port
12:38 sapier hopefully those core parts don't need to be touched very often
12:39 kahrl for the graphics subsystem, maybe we could ask some people currently outside the dev team (Taoki?)
12:39 celeron55 because someone has to make an android port happen; we can't just let that proprietary project to take hold of all of android
12:40 celeron55 kahrl: i think it's fine that i keep it for now
12:41 kahrl android port would be sfan5... guess that's up to him
12:44 sfan5 what about iOS? Buildcraft is out on iOS too
12:44 celeron55 it too; but it's less important
12:44 VanessaE celeron55: proposal:  Android port happens at the same time as you do whatever it is that is gonna end up breaking compatibility with that illegal fork.
12:45 sfan5 for iOS we would need $99 (dev account) and a proper mac device anyway
12:45 celeron55 VanessaE: maybe
12:45 VanessaE thexyz already made some inroads toward that end
12:45 VanessaE (albeit with freeminer)
12:47 VanessaE the way I figure it, play on the probability of people downloading a program, seeing that it doesn't work anymore, and going "this sucks!" and just uninstalling it.
12:47 VanessaE not knowing it's minetest.  meanwhile, the REAL minetest works fine, sits next to it in the play store, getting all the downloads.
12:47 VanessaE at least until you know who forks it again.
12:47 celeron55 that won't be started before we actually have an android port though
12:47 VanessaE yeah
12:49 celeron55 sfan5: donations will easily cover that once it's ready
12:49 celeron55 i mean, the $99
12:49 celeron55 (a device is a problem though)
12:50 celeron55 but ios isn't important compared to android
12:50 kahrl is it legal to distribute LGPL code via itunes now?
12:51 celeron55 as far as i know, apple doesn't care and users don't care
12:51 celeron55 some zealots may care
12:53 kahrl I just remember that VLC story
13:00 thexyz yes, and the problem was is that some dev was against it
13:00 thexyz err, s/is//
13:00 thexyz both apple and other devs didn't care
13:11 celeron55 i wonder if porting to sailfish would be easy
13:11 ImQ009 joined #minetest-dev
13:12 celeron55 all the other stuff is probably easily available, but i don't know if irrlicht can open up a window on it, as it uses wayland
13:12 sfan5 sdl2 has recently gained support for wayland and irrlicht can use sdl
13:12 celeron55 and the android port of irrlicht has probably many unnecessary changes
13:13 celeron55 does regular irrlicht contain opengl ES support?
13:13 sfan5 no
13:14 celeron55 does the android port compile to regular gnu/linux?
13:14 celeron55 (as sailfish is)
13:14 celeron55 it'd need ES version of irrlicht that runs on gnu/linux...
13:15 sfan5 I'm pretty sure it does
13:15 celeron55 i actually happen to have the jolla phone (which sucks as a phone but is a fun toy); it runs buildcraft just fine
13:16 sfan5 but it'd require changing some things because it currently uses #if(n)def __ANDROID__
13:17 ImQ009 joined #minetest-dev
13:22 celeron55 where's the newest version of irrlicht's android port available?
13:22 celeron55 is it https://gitorious.org/irrlichtandroid?
13:24 proller https://svn.code.sf.net/p/ir​rlicht/code/branches/ogl-es
13:27 sfan5 the one on gitorious is inofficial
13:27 celeron55 that svn one looks more familiar
13:28 sfan5 the makefile of the ogles one does not work
13:28 sfan5 it expects you to either use Xcode (iOS) or use the NDK (Android)
13:28 proller but it contain lot of WTF defines and very hard to compile under linux/arm
13:28 sfan5 http://dev.minetest.net/Android << contains the makefile I used for building without NDK
13:29 EvergreenTree joined #minetest-dev
13:29 EvergreenTree joined #minetest-dev
13:31 thexyz don't forget that you'll have to patch irrlicht http://irrlicht.sourceforge.net/fo​rum/viewtopic.php?f=7&amp;t=49410
13:32 thexyz and there's some work here https://github.com/xyzz/freeminer/tree/android
13:32 thexyz and todo https://github.com/freeminer/freemi​ner/issues/10#issuecomment-30752049
14:00 PilzAdam joined #minetest-dev
14:03 celeron55 hmm, does this support es2 at all
14:03 celeron55 there's no es1 on this thing
14:04 celeron55 oh yeah it does
14:31 darkrose joined #minetest-dev
14:31 darkrose joined #minetest-dev
14:35 daswort joined #minetest-dev
14:58 Zeitgeist_ joined #minetest-dev
15:30 hmmmm joined #minetest-dev
15:39 ImQ009 joined #minetest-dev
15:54 OldCoder joined #minetest-dev
16:07 smoke_fumus|2 joined #minetest-dev
16:08 nyuszika7h joined #minetest-dev
16:09 Calinou joined #minetest-dev
16:24 salamanderrake joined #minetest-dev
16:31 kaeza joined #minetest-dev
16:32 RealBadAngel joined #minetest-dev
16:35 OldCoder joined #minetest-dev
16:42 sfan5 celeron55: do you know of a way to add linking flags at the end of the linker command without cmake touching them?
16:47 celeron55 sfan5: how does it touch them?
16:47 sfan5 it removed -Wl,-Bstatic
16:48 celeron55 no way i guess; you need to configure it to not remove those
16:48 celeron55 uh... maybe
16:48 NakedFury joined #minetest-dev
16:48 celeron55 what does that even do?
16:49 sfan5 I need to link libcrystax statically
16:49 sfan5 (because that is not a standard lib on android)
16:50 celeron55 if you have a .a file of it (or similar static library file), just give that to the linker
16:50 celeron55 it's how static linking is usually done
16:50 celeron55 just like any object file
16:51 celeron55 hmm
16:51 celeron55 like TARGET_LINK_LIBRARIES(foo libcrystax.a)
16:51 sfan5 I'm not sure but I think it didn't work when I used the .a
16:51 sfan5 I'll try after cmake finishes building
16:52 celeron55 if it doesn't work, you could try something like this http://www.cmake.org/pipermail/​cmake/2009-February/026777.html
16:52 sfan5 I have two ways to put linker flags at the front of the linker now
16:52 celeron55 it'll make your build system totally unportable and hated by everyone though
16:52 OldCoder joined #minetest-dev
16:53 celeron55 i'm having fun time with building irrlicht for sailfish
16:53 celeron55 i raped the build system completely and now it turns out the code is actually broken for X11+ES2 combination 8)
16:55 celeron55 it builds code that wants to use _ZN3irr5video18createOGLES2DriverERKNS_​27SIrrlichtCreationParametersERNS0_17SE​xposedVideoDataEPNS_2io11IFileSystemE, but the function it creates is _ZN3irr5video18createOGLES2DriverERKNS​_27SIrrlichtCreationParametersEPNS_2io​11IFileSystemEPNS0_15IContextManagerE
16:56 OldCoder joined #minetest-dev
16:56 sfan5 try ogles1, the ogles2 driver does not work (atleast on iOS)
16:56 OldCoder joined #minetest-dev
16:56 celeron55 sfan5: sailfish doesn't support ogles1
16:56 sfan5 :O
16:56 sfan5 linking to the .a does not work
16:56 kahrl joined #minetest-dev
16:56 sfan5 but statically linking to the .so works *confused look*
16:56 celeron55 or, hmm
16:57 celeron55 maybe ogles2 is backwards compatible enough... i guess i'll have to see
16:57 celeron55 sfan5: how does it not work
16:58 sfan5 Error(dlopen): Cannot load library: soinfo_relocate(linker.cpp:976): cannot locate symbol "___runetype" referenced by "libminetest.so"...
16:58 celeron55 (but this thing doesn't have ogles1 headers at all; i'll have to try replacing the references to those with references to es2 headers)
16:58 sfan5 ^ output of small program I wrote to load the library
16:59 sfan5 I guess I'm out of luck
16:59 sfan5 I tried all ways
17:04 sfan5 I added double quotes and now the linker says '' dl: No such file or directory ''
17:04 sfan5 wtf cmake
17:05 celeron55 did you see my link?
17:05 sfan5 yes
17:05 sfan5 already tried that
17:05 sfan5 ooh
17:06 celeron55 have you tried something involving separate_arguments()
17:06 sfan5 no
17:07 sfan5 set(PLATFORM_LIBS -landroid -llog -Wl,-Bstatic -lcrystax -Wl,-Bdynamic ${CMAKE_DL_LIBS}) -> cmake touches my flags
17:07 sfan5 set(PLATFORM_LIBS -landroid -llog "-Wl,-Bstatic -lcrystax -Wl,-Bdynamic" ${CMAKE_DL_LIBS}) -> cmake doesn't touch them
17:08 sfan5 I don't understand why cmake does this, but it works..
17:08 celeron55 you might have to create a custom command like how i once implemented a precompiled header: https://gist.github.com/cel​eron55/d4e5dac516742442babe
17:09 celeron55 you can grab all the parameters that go in regular linking but construct the final command yourself
17:09 celeron55 but if that already works, then whatever
17:11 celeron55 looks like sailfish doesn't have everything in es1 that irrlicht wants
17:11 celeron55 for example glClientActiveTexture seems to be missing
17:12 celeron55 umm... wait what
17:12 sfan5 can't you compile libGLESv1 for sailfish?
17:12 sfan5 WTF cmake
17:12 celeron55 i guess i can just define that and hope that it's actually found in some library
17:13 sfan5 if the double quotes include a normal lib at the front it puts it 2 times into the linker command
17:13 celeron55 there's a header for doing exactly that; glext.h irrlicht itself
17:13 celeron55 +in
17:13 sfan5 if the double quotes don't include a normal lib at the front it puts it once into the linker command
17:13 celeron55 (umm... but that's not a wise one to use now)
17:18 celeron55 bah, no, this es1 isn't going to work
17:28 Weedy_lappy joined #minetest-dev
17:57 iqualfragile yo! how is release-stuff going?
18:02 jin_xi joined #minetest-dev
18:05 john_minetest seems 0.4.9 has to wait for a few months
18:07 VargaD_ joined #minetest-dev
18:11 smoke_fumus joined #minetest-dev
18:23 ShadowNinja So a section maintainer can decide how much approval is needed (this simple fix can be merged, this controversial change will need agreement from a few other devs)?  And should I add tags for the sections on GitHub?
18:24 book` joined #minetest-dev
18:45 Zeitgeist_ joined #minetest-dev
18:45 Zeitgeist_ joined #minetest-dev
18:57 celeron55 ShadowNinja: i'm waiting for comments from hmmmm
18:57 ShadowNinja Alright.
18:58 celeron55 we should probably decide some ways of working on github
18:58 celeron55 eg. add a comment "subsection x" or "subsections x, y, z" to all pull requests and issues
18:59 celeron55 or maybe with tags... dunno
19:03 ShadowNinja Tags would be better, comments are really for discussion and, well, comments.
19:17 khonkhortisan joined #minetest-dev
19:44 hmmmm a "section maintainer"?
19:44 hmmmm we need to clearly define sections first of all
19:45 hmmmm if you'd like to formalize that
19:45 hmmmm but it's starting to look a bit like the way the Linux kernel is maintained, no? :)
19:45 hmmmm no, I want 0.4.9 to be out very soon(tm)
19:46 hmmmm the christmas launch was a failure because I guess of me, and so is the new year's release
19:46 hmmmm it doesn't need to be though
19:46 hmmmm if the current master is in a stable state we can release
19:46 hmmmm we need multiple people working on it in order to make a release though..
19:48 ShadowNinja We need the serverlist fixed first. /me makes a issue
19:48 hmmmm also, thank you pilzadam for removing the FPS from the window name
19:49 hmmmm you must assume that any UI operations are very slow... I'll be willing to bet the reason why that was problematic is because it added to a UI operation queue and waited on it
19:50 hmmmm (that's on Windows, anyway)
19:51 hmmmm for Xfce I bet it's implemented like...
19:51 sapier did anyone already investigate the serverlist issue?
19:51 hmmmm gtk_threads_enter(); gtk_window_set_title(blahblah); gtk_threads_exit();
19:52 sapier I've read multiple ppl writing about it but by now noone (including me) seemed to be really interested enough to investigate
19:52 ShadowNinja sapier: No.
19:52 sapier guess everyone thought someone else would do it ;-)
19:52 ShadowNinja The fix worked for Vanessa, but not for me.
19:52 sapier do you know what's wrong? any error in communication? curl/non-curl?
20:01 hmmmm https://github.com/minetest/minetest/commi​t/25b1cca4150a9f78b05b98afee71a97fd052df71
20:01 john_minetest sapier: Which problem?
20:04 sapier the serverlist problem shadowninja has
20:05 sapier hmmmm that one isn't added yet?
20:05 hmmmm well
20:05 hmmmm I just added it now, it was sitting for a week
20:05 sapier oops
20:06 ShadowNinja I haven't run it with --info and my server's busy now...
20:09 hmmmm so do you guys want to make a release tonight?
20:10 sapier without shadow validating this one is fixed?
20:10 hmmmm I'm sure that'll happen soon...
20:10 hmmmm but I mean we should make sure people who do the debian repo updating and windows compiling etcetera are ready
20:12 sapier tonight? it's less then 3 hours to 2014 here :-) I do have some fireworks to burn down :-)))
20:12 hmmmm grggrg
20:13 sapier the real smoky ones ;-)
20:13 hmmmm alright, we'll do it 'whenever' then
20:13 hmmmm it's new year's somewhere in the world on the hour
20:13 sapier but as far as I know I've been not that much involved in release by now
20:13 hmmmm I need to get more involved with minetest in general.... I've been fading away it's like
20:14 hmmmm and there's so much that needs to get done
20:16 us_0gb joined #minetest-dev
20:35 celeron55 hmmmm: i have selected the "subsystems" based on what things can be relatively easily pointed to consist of certain files
20:35 celeron55 some things are bound to overlap, but not much
20:36 celeron55 but, you agree to the overall idea?
20:36 celeron55 do you agree to be responsible for the mapgen?
20:36 celeron55 what that means is that you have to ultimately decline or accept changes to it
20:39 celeron55 (you were pre-selected because you know the mapgen best)
20:39 hmmmm why does it have to be formalized?  what's wrong with the way things are right now?
20:40 celeron55 partially this is a solution to the "proller problem" where stuff gets infinitely ignored from the contributor's standpoint
20:41 hmmmm to speak freely
20:42 hmmmm a lot of proller's stuff was ignored on purpose because it was just too much of a headache
20:42 celeron55 of course it was
20:42 hmmmm really poor design and everything, you'd have to spend just as much time as you would coding it yourself to get it the right way
20:42 celeron55 but when the next proller comes, this gives much more incentive to just turn him down before it becomes bad
20:43 sapier1 joined #minetest-dev
20:43 celeron55 also i think it's time to check if some other organizational structure would work better than the current one
20:43 EvergreenTree joined #minetest-dev
20:43 EvergreenTree joined #minetest-dev
20:43 hmmmm if you move into this subsystem maintainer model then it'd be a different organizational structure
20:44 celeron55 that's what i just said
20:44 hmmmm no, you said it as if they were two separate things
20:44 hmmmm one follows the other directly
20:44 celeron55 there was a huge amount of talk about this in the past 24 hours; read the logs if interested
20:44 hmmmm ehhhhh
20:44 hmmmm log reading....
20:44 sapier1 *smile* the good old communication problem again
20:45 celeron55 "ehh.... doing anything"
20:45 hmmmm I'll work on it over the next couple hours I guess
20:45 hmmmm well yeah
20:45 celeron55 we'll put the stuff in a wiki in the upcoming days if nothing serious comes to block this
20:45 celeron55 (it's obvioysly bad to just refer to some log)
20:46 sapier1 I guess noone has an idea who is padding active object messages with 4 null bytes prior transmission? ;-)
20:47 Calinou joined #minetest-dev
20:47 sapier1 not all of course that'd be too easy just some of them
21:10 sapier1 hmm seems that bug is in master too it just doesn't cause anything without an additional bug I made in tcp implementation
21:10 sapier1 I found mine but no idea where the second one is
21:58 specing Is it possible for the client to "detect" that a placed/digged block hasn't been "confirmed" by the server?
21:59 specing I'm assuming that when someone places a block, the action gets sent to the server which then provides some form of feedback to the client, am I right?
22:02 specing Would it be possible to visually tag these blocks so that you know not to rely on them being there
22:02 specing It would help at bridge-building immensely
23:02 john_minetest HAPPY NEW YEAR!
23:09 VargaD_ Happy new year
23:49 djdduty_ joined #minetest-dev

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