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: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: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 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/blog/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) 02:55 Jordach we've got a large problem: builddaft made it into the apple app store - https://forum.minetest.net/viewtopic.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] 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()? 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/hugo.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/minetest-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 09:02 sfan5 celeron55: maintainers for each subsystem is ok with me, I'm only afraid this might slow down development generally 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: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 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:24 sapier as far as I know the "completely new" option wasn't suggested by anyone 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 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:27 sapier thanks ... so I'm the bad guy :-) 10:27 sapier no problem ;-) 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 celeron55 and i doubt anyone knows here 10:28 celeron55 we should be doing what the community wants in the end 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 celeron55 sapier: it's a 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 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 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 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 celeron55 it's irrelevant? i'm kind of okay if it is, but it has implications 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 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 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 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: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: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/irrlicht/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:31 thexyz don't forget that you'll have to patch irrlicht http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&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/freeminer/issues/10#issuecomment-30752049 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 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 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: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_17SExposedVideoDataEPNS_2io11IFileSystemE, but the function it creates is _ZN3irr5video18createOGLES2DriverERKNS_27SIrrlichtCreationParametersEPNS_2io11IFileSystemEPNS0_15IContextManagerE 16:56 sfan5 try ogles1, the ogles2 driver does not work (atleast on iOS) 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 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/celeron55/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:57 iqualfragile yo! how is release-stuff going? 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: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: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/commit/25b1cca4150a9f78b05b98afee71a97fd052df71 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: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 celeron55 also i think it's time to check if some other organizational structure would work better than the current one 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 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:09 VargaD_ Happy new year