--- Log opened Sat Jul 16 00:00:24 2016
20160716 00:02:38-!- Greg-Boggs [~greg_bogg@50.248.194.193] has joined #wesnoth-dev
20160716 00:05:49< tad_> > set type=a > wesnoth.org. Server:		ns1.jexiste.fr. Address:	54.77.149.22#53  ** server can't find wesnoth.org: SERVFAIL
20160716 00:06:10< tad_> Well, now I know who's nameserver is wonky
20160716 00:07:24< Jfault> isn't it down for everyone?
20160716 00:07:25-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20160716 00:11:31-!- Duthlet [~Duthlet@dslb-188-106-029-177.188.106.pools.vodafone-ip.de] has quit [Quit: leaving]
20160716 00:14:32< celticminstrel> Yes, but Rhonda also mentioned jexiste, so I assume there's something about it.
20160716 00:24:34-!- Jfault [~sci@2601:98a:4201:9810:45e4:e6cd:e814:b3f9] has quit [Ping timeout: 250 seconds]
20160716 00:31:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160716 00:46:15< gfgtdf> is there a way i can acess the wiki now? i mean i can get to wesnoth.org by just typing the ip adress in the browser but i dont know how to acess subsomains.
20160716 00:47:00< celticminstrel> The wiki maps to /wiki, but then it redirects back to the subdomain, so I suspect the answer is no.
20160716 00:48:46< celticminstrel> If you find a way, though, I'd like to know.
20160716 00:49:01< celticminstrel> The DNS issue interrupted my wiki updates.
20160716 01:05:34-!- Greg-Boggs [~greg_bogg@50.248.194.193] has quit [Remote host closed the connection]
20160716 01:06:34-!- Jfault [~sci@2601:98a:4201:9810:45e4:e6cd:e814:b3f9] has joined #wesnoth-dev
20160716 01:11:31-!- Greg-Boggs [~greg_bogg@50.248.194.193] has joined #wesnoth-dev
20160716 01:27:45-!- gfgtdf [~chatzilla@x4e3693e9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 47.0/20160604131506]]
20160716 01:28:49< Rhonda> You can use the hosts file.
20160716 01:30:52-!- Jfault [~sci@2601:98a:4201:9810:45e4:e6cd:e814:b3f9] has quit [Ping timeout: 250 seconds]
20160716 01:32:05-!- Greg-Boggs [~greg_bogg@50.248.194.193] has quit [Remote host closed the connection]
20160716 01:44:57-!- Shiki [~Shiki@141.39.226.227] has quit [Quit: Verlassend]
20160716 01:49:17-!- Bonobo [~Bonobo@ppp118-210-92-241.lns20.adl2.internode.on.net] has quit [Ping timeout: 258 seconds]
20160716 01:49:49-!- Bonobo [~Bonobo@2001:44b8:254:3200:e599:25c2:22c4:eab6] has joined #wesnoth-dev
20160716 01:54:16-!- Bonobo [~Bonobo@2001:44b8:254:3200:e599:25c2:22c4:eab6] has quit [Ping timeout: 250 seconds]
20160716 01:54:35-!- Greg-Boggs [~greg_bogg@50.248.194.193] has joined #wesnoth-dev
20160716 01:54:55-!- Greg-Boggs [~greg_bogg@50.248.194.193] has quit [Remote host closed the connection]
20160716 01:58:18-!- Jfault [~sci@2601:98a:4201:9810:45e4:e6cd:e814:b3f9] has joined #wesnoth-dev
20160716 02:00:38-!- Greg-Boggs [~greg_bogg@50.248.194.193] has joined #wesnoth-dev
20160716 02:10:18-!- Greg-Boggs [~greg_bogg@50.248.194.193] has quit [Remote host closed the connection]
20160716 02:26:23-!- irker642 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160716 02:28:39< Aginor> hmm
20160716 02:29:44< Aginor> what do people think of https://github.com/wesnoth/wesnoth/pull/697? worth merging?
20160716 02:30:00-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160716 02:35:17< vultraz> sure
20160716 02:36:18-!- Jfault [~sci@2601:98a:4201:9810:45e4:e6cd:e814:b3f9] has quit [Ping timeout: 250 seconds]
20160716 02:49:10-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160716 03:00:14 * celticminstrel has no idea what Rhonda said.
20160716 03:21:46< celticminstrel> vultraz: What crash was I looking for?
20160716 03:25:57< celticminstrel> Was it the exit crash, or do I need to do something specific?
20160716 03:26:03-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20160716 03:26:19< celticminstrel> ...okay then.
20160716 03:47:31-!- Kwandulin [~Miranda@p200300760F2D81419071A261E8077D7F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160716 03:58:13-!- Bonobo [~Bonobo@2001:44b8:254:3200:e883:69c5:9d0a:5f35] has joined #wesnoth-dev
20160716 04:22:47-!- hk238 [~kvirc@t224.ip7.netikka.fi] has joined #wesnoth-dev
20160716 04:30:24-!- Kwandulin [~Miranda@p200300760F2D81419071A261E8077D7F.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20160716 04:31:53-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 04:32:51-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20160716 04:33:03-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds]
20160716 04:39:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 04:39:14-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20160716 04:45:00-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 04:56:42-!- Appleman1234 [~Appleman1@KD036012044130.au-net.ne.jp] has joined #wesnoth-dev
20160716 05:12:35-!- Greg-Boggs [~greg_bogg@2601:602:9501:18d:20a4:825e:3289:f532] has joined #wesnoth-dev
20160716 05:17:10-!- celticminstrel is now known as celmin|sleep
20160716 05:29:53-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160716 05:30:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 05:50:13-!- Nobun [~nobun@5.170.110.1] has joined #wesnoth-dev
20160716 05:53:44-!- vultraz [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160716 05:53:58-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160716 05:53:59-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160716 06:12:35-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160716 06:12:36-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Read error: Connection reset by peer]
20160716 06:15:01< shadowm> celmin|sleep: Pulled.
20160716 06:17:55< shadowm> celmin|sleep: What Rhonda means: http://www.inmotionhosting.com/support/website/how-to/how-to-edit-your-hosts-file-on-a-mac
20160716 06:18:36-!- Nobun [~nobun@5.170.110.1] has quit [Ping timeout: 250 seconds]
20160716 06:19:01< shadowm> The IP address is 144.76.5.6 and the hostnames you'll probably need include wesnoth.org www.wesnoth.org forums.wesnoth.org wiki.wesnoth.org.
20160716 06:20:18< shadowm> For Windows users like gfgtdf (although hopefully this will be rectified before any of them get a chance to read this), just open/create %SystemRoot%\system32\drivers\etc\hosts with Notepad and do the exact same thing, it's the same format.
20160716 06:20:33< shadowm> And for Linux or BSD users it's /etc/hosts/ of course.
20160716 06:23:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160716 06:23:22-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 06:30:48-!- Kwandulin [~Miranda@p200300760F2D81419071A261E8077D7F.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160716 06:35:58-!- Nobun [~nobun@5.170.104.26] has joined #wesnoth-dev
20160716 06:38:19-!- Kwandulin [~Miranda@p200300760F2D81419071A261E8077D7F.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160716 06:48:17-!- ggeneral [~anton@nat58.opti.net.ua] has joined #wesnoth-dev
20160716 06:54:08-!- Bonobo [~Bonobo@2001:44b8:254:3200:e883:69c5:9d0a:5f35] has quit [Ping timeout: 250 seconds]
20160716 06:54:48-!- Nobun1 [~nobun@5.170.105.209] has joined #wesnoth-dev
20160716 06:55:12-!- Nobun [~nobun@5.170.104.26] has quit [Ping timeout: 276 seconds]
20160716 06:56:48-!- Nobun1 is now known as Nobun_1
20160716 07:02:16-!- Greg-Boggs [~greg_bogg@2601:602:9501:18d:20a4:825e:3289:f532] has quit [Remote host closed the connection]
20160716 07:03:22< Aginor> celmin|sleep: exit crash
20160716 07:05:17-!- irker452 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160716 07:05:17< irker452> wesnoth: Andreas Löf wesnoth:master d55e88428098 / src/ (display.cpp events.cpp video.cpp video.hpp): Hacky fix for the flickering when a screen is fully redrawn. https://github.com/wesnoth/wesnoth/commit/d55e88428098fa8c6d20e0de676e3b201fd521e3
20160716 07:05:17< irker452> wesnoth: Andreas Löf wesnoth:master aa58d83b4500 / src/ (display.cpp events.cpp video.hpp): Use RAII instead of lock->unlock directly. https://github.com/wesnoth/wesnoth/commit/aa58d83b4500bd697ef1efcea1406fe5f9318322
20160716 07:05:18< irker452> wesnoth: Andreas wesnoth:master b2f86b6b0750 / src/ (display.cpp events.cpp video.cpp video.hpp): Merge pull request #697 from wesnoth/flickerfix https://github.com/wesnoth/wesnoth/commit/b2f86b6b0750d3eb7d8dfdc92f7fe86408438792
20160716 07:07:36-!- Nobun_1 [~nobun@5.170.105.209] has quit [Quit: Salve a tutti]
20160716 07:08:18-!- Nobun [~nobun@5.170.105.209] has joined #wesnoth-dev
20160716 07:10:05< irker452> wesnoth: Andreas Löf wesnoth:master 14c0c4487d9b / changelog: Update changelog https://github.com/wesnoth/wesnoth/commit/14c0c4487d9b803677e455c5d4a442ec35d17424
20160716 07:11:00< vultraz> Aginor: any more ideas for what to try with the crash?
20160716 07:12:11< Nobun> vultraz: the crash happen in some detailed situation or is it random?
20160716 07:12:52< vultraz> Nobun: it seems random
20160716 07:13:05< vultraz> it happens when I quit the game, that much is consistent
20160716 07:13:07< vultraz> but
20160716 07:13:18< vultraz> not every time
20160716 07:13:25< vultraz> not every time with the same change
20160716 07:13:30< vultraz> Aginor doesn't get it
20160716 07:14:04< Nobun> vultraz: oh... bad situation... it seems a memory allocation error... in that case the only solution is trying to use a debugger and hope to be lucked to find where the actual issue is
20160716 07:15:12< Nobun> but I have very limited experience on using gdb to be helpful... 
20160716 07:16:23< Aginor> vultraz: you need to narrow down where, which I think you have already
20160716 07:16:36< vultraz> something to do with cycle_focus
20160716 07:16:38< Aginor> vultraz: we know it's the global event handler, when code is exited
20160716 07:17:00< Aginor> vultraz: cycle focus? last night it was remove_handler
20160716 07:17:23< Aginor> vultraz: or did that change?
20160716 07:17:25< Nobun> however, as long as the problem mainly happens on quitting game, perhaps we could hope that the problem is located on finalizing the game (perhaps something SDL related?)...
20160716 07:17:46< vultraz> Aginor: I think the crash goes away if you remove the call to cycle_focus in remove_handler
20160716 07:17:48< Aginor> Nobun: no, it's not.
20160716 07:17:50< vultraz> I can test that again to be sure
20160716 07:18:31< Aginor> vultraz: please do, and make sure that you have the leave_global int eh preferences destructor
20160716 07:18:33< Nobun> vultraz: Aginor: the crash happen on the last git snapshot on master branch?
20160716 07:18:35< Aginor> https://sourceware.org/gdb/onlinedocs/gdb/TUI.html
20160716 07:18:57< Aginor> Nobun: no, Vultraz-event_handling_fixes
20160716 07:19:15< Aginor> I spent about an hour last night trying to reproduce the issue to no avail
20160716 07:19:52< Aginor> so either it's platform dependant, compiler optimisation/compiler dependant or vultraz didn't give me the right repro steps
20160716 07:20:03< Nobun> well... I will try to, but don't expect anything (I'm a noob compared to all of you :))
20160716 07:20:19< Aginor> Nobun: are you developing on linux or windows?
20160716 07:21:09< Nobun> I never developed cpp code on wesnoth (I maintain python3 wmlxgettext) but I'm on linux (ubuntu 14.04 LTS 64bit)
20160716 07:21:21< vultraz> I'm on Windows 10
20160716 07:22:09< Aginor> Nobun: tell me if you manage to reproduce it, you should(?) be able to give me a binary+corefile that I can toss into gdb to investigate
20160716 07:22:23-!- Kwandulin [~Miranda@p200300760F2D814129A3897E99001EE8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160716 07:22:39< Nobun> Aginor: I will try, I don't guarantee anything
20160716 07:24:14< Aginor> vultraz: when you succeed, can you please share exact, and the simplest possible, steps to reproduce?
20160716 07:25:15< vultraz> The simplest steps are to start game, press the quit button
20160716 07:27:40-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160716 07:27:56< Nobun> sorry for noob question: but I don't remember how to checkout to an upstream branch
20160716 07:28:43< Aginor> Nobun: do you have a remote set up to wesnoth repo?
20160716 07:31:14< Nobun> I have a wesnoth fork (where I can add things with push origin) and I have a upstram (linking to wesnoth/wesnoth) where I can update my local repository with the updates on wesnoth/wesnoth
20160716 07:31:35< Aginor> ok
20160716 07:32:27< Aginor> Nobun: do "git branch upstream/Vultraz-event_handling_fixes" and it should give you a local branch of upstream
20160716 07:32:49< vultraz> god DAMMIT
20160716 07:32:58< vultraz> now it DOES crash with cycle_focus commented out
20160716 07:33:18< Aginor> vultraz: debug or release build?
20160716 07:33:24< vultraz> debug
20160716 07:33:29< vultraz> or wait
20160716 07:33:34< vultraz> I think it might be release
20160716 07:33:51< vultraz> oh, codeblocks switched back
20160716 07:33:54< vultraz> wrong build
20160716 07:33:55< Nobun> thank Aginor: I tried checkout instead of branch :P
20160716 07:34:11< vultraz> yeah the release build crashes
20160716 07:34:19< Aginor> Nobun: yeah
20160716 07:34:24< Aginor> Nobun: sorry
20160716 07:34:33< Aginor> I'm tired at the moment
20160716 07:34:49< Aginor> I spent a good chunk of the afternoon chopping firewood
20160716 07:36:47< vultraz> say what?
20160716 07:36:57< Aginor> /home/andreas/projects/wesnoth-master/src/xBRZ/xbrz.cpp:590:17: warning: ‘*((void*)& result +8)’ may be used uninitialized in this function [-Wmaybe-uninitialized]
20160716 07:37:01< Aginor> that's new
20160716 07:37:12< Aginor> I think we can thank gcc6 fr that
20160716 07:38:40-!- travis-ci [~travis-ci@ec2-54-196-107-26.compute-1.amazonaws.com] has joined #wesnoth-dev
20160716 07:38:41< travis-ci> wesnoth/wesnoth#9801 (master - b2f86b6 : Andreas): The build has errored.
20160716 07:38:41< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145178098
20160716 07:38:41-!- travis-ci [~travis-ci@ec2-54-196-107-26.compute-1.amazonaws.com] has left #wesnoth-dev []
20160716 07:39:16< Aginor> hmm
20160716 07:39:22< vultraz> im testing with a release build since the bloody debug build takes 2 minuets a pop to link
20160716 07:39:22< Aginor> that's a WML test timing out
20160716 07:39:27< vultraz> as opposed to 10 seconds
20160716 07:39:47< Aginor> vultraz: just chillax :)
20160716 07:40:01< Aginor> vultraz: and still compile with -g
20160716 07:40:11< Aginor> vultraz: using scons?
20160716 07:40:24< vultraz> tdm gcc 
20160716 07:40:28< vultraz> and codeblocks
20160716 07:43:02< Aginor> hmm
20160716 07:43:15< Aginor> compiling wesnoth sure makes me think about getting that new i7 :D
20160716 07:43:32< vultraz> likewise
20160716 07:43:47< vultraz> new laptop, specifically 
20160716 07:44:02< Nobun> lol
20160716 07:44:14< vultraz> giff i7 and nvidia :P
20160716 07:44:30< Nobun> I have a i3 so it would require 2 hours, more or less
20160716 07:44:53< vultraz> I weep for you
20160716 07:44:57< Nobun> currently I'm building   scons build=debug
20160716 07:45:35< Aginor> andreas@goddess:~/projects/wesnoth-master/cbuild$lscpu | grep "Model name"
20160716 07:45:35< Aginor> Model name:            AMD FX(tm)-8120 Eight-Core Processor
20160716 07:45:36< vultraz> grrrr
20160716 07:45:48< vultraz> every time I do something that stops it crashing, it crashes again the next time :|
20160716 07:46:02< Aginor> andreas@goddess:~/projects/wesnoth-master/cbuild$lspci | grep "VGA"
20160716 07:46:02< Aginor> 01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)
20160716 07:46:19< vultraz> how can something crash one time and then not the other
20160716 07:46:35< Aginor> vultraz: memory used after freeing it
20160716 07:47:01< Aginor> the values might have been preserved, or migth not
20160716 07:47:17< Nobun> vultraz: memory allocation bugs is the most frustrating thing to fix
20160716 07:47:46< Aginor> vultraz: https://sourceforge.net/p/valgrind4win/wiki/DevelopmentEnvironment/
20160716 07:48:30-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160716 07:48:44< vultraz> aw dammit
20160716 07:48:49< vultraz> i clicked rebuild instead of build ;_;
20160716 07:49:41< Aginor> vultraz: do you give scons any -j parameters?
20160716 07:49:47< Aginor> Nobun: do you?
20160716 07:49:54< Nobun> In my little gdb experience, I notice that the debugger often gives you some results that seems to point the problem, but the problem is somewhere else... so you should to watch around the code to understand why the code crashes at the point(s) reported by gdb
20160716 07:50:15< Nobun> Aginor: no j parameters
20160716 07:50:47< Aginor> also print values of the variables at the time of the crash so that you know which illegal value caused the thing to crash
20160716 07:50:48< vultraz> Aginor: I'm not using scons
20160716 07:50:52< vultraz> but yes, I use all 4 cores
20160716 07:50:58< Aginor> Nobun: they doing -j<corecount>
20160716 07:51:11< Aginor> Nobun: that'll speed up your build significantly
20160716 07:51:19< Nobun> yeah... but in my case I don't spare so much time using -j
20160716 07:51:22< vultraz> it's ~20 minutes for a full rebuild
20160716 07:51:26< Nobun> I have only 2 cores
20160716 07:51:29< Aginor> I'm being summoned here now
20160716 07:51:44< Aginor> post coredumps if you want me to look at them
20160716 07:51:46< vultraz> Nobun: virtual cores count
20160716 07:52:08< Aginor> Nobun: -j<core+hyperthreads>
20160716 07:52:19< vultraz> ^
20160716 07:52:30< vultraz> so like, I have a dual-core i5, but I can use j4
20160716 07:53:04< Nobun> hmm don't know what is the max -j value I could use... but I have i3 so It should be -j2 at max
20160716 07:54:02< vultraz> is it single-core?
20160716 07:54:12< vultraz> it's usually coresx2
20160716 07:54:36< Nobun> hmm I don't remember... it should have 2 cores
20160716 07:54:44< vultraz> then use j4
20160716 07:54:49< Nobun> but I'm not sure
20160716 08:02:19-!- Nobun [~nobun@5.170.105.209] has quit [Ping timeout: 252 seconds]
20160716 08:03:23-!- Nobun [~nobun@5.170.114.106] has joined #wesnoth-dev
20160716 08:03:51< Nobun> sorry but -j4 freezed my pc and I had to force the reboot
20160716 08:05:37< Nobun> I'm currently using -j2
20160716 08:11:09< shadowm> You could have a million CPUs and -j10000000 isn't going to do you any good if you have less RAM than the amount needed by that many concurrent compiler instances.
20160716 08:12:07-!- travis-ci [~travis-ci@ec2-54-158-206-180.compute-1.amazonaws.com] has joined #wesnoth-dev
20160716 08:12:08< travis-ci> wesnoth/wesnoth#9802 (master - 14c0c44 : Andreas Löf): The build has errored.
20160716 08:12:08< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145178395
20160716 08:12:08-!- travis-ci [~travis-ci@ec2-54-158-206-180.compute-1.amazonaws.com] has left #wesnoth-dev []
20160716 08:12:40< shadowm> There are other possible causes for your system "freezing" when running make/scons with a naïve -j amount, but excessive thrashing (paging processes out to swap on disk storage due to running out of RAM) is the most common.
20160716 08:13:08< shadowm> For Wesnoth and -j4 you'll need at least 6 GiB of RAM, I estimate.
20160716 08:14:23< shadowm> And yes, the exact amount of memory needed for the compiler obviously depends greatly on the program you're compiling.
20160716 08:15:39< shadowm> (Now, if you experience issues when maxing out your CPU(s) regardless of memory usage that's a different issue I can't help you with.)
20160716 08:17:29-!- ggeneral [~anton@nat58.opti.net.ua] has left #wesnoth-dev []
20160716 08:18:48< vultraz> Aginor: 
20160716 08:18:50< vultraz> ok
20160716 08:18:58< vultraz> I appear to have reached a place where it consistently does not crash
20160716 08:19:28< Nobun> shadowm: my RAM is 4GB, infact
20160716 08:19:45< shadowm> Yeah, that's bad. I was already struggling with -j2 four years ago.
20160716 08:20:10< shadowm> *when I was using a laptop with only 4 GiB.
20160716 08:20:39< vultraz> Aginor: I'm going to uncomment code until I find out what makes it crash again
20160716 08:21:03-!- Kwandulin [~Miranda@p200300760F2D814129A3897E99001EE8.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160716 08:21:15< Nobun> however, after all, compiling wesnoth requires a lot of time... but not so much time like compiling qt on windows VM (wich requires more than an entire day)
20160716 08:21:22< Nobun> :P
20160716 08:22:09< shadowm> Well, with those specs, yeah, maybe.
20160716 08:22:29< shadowm> I remember compiling Qt 4.6 on a Windows XP VM in under an hour.
20160716 08:23:31< vultraz> Aginor: I think I have it
20160716 08:23:46< vultraz> well
20160716 08:23:53< Nobun> shadowm qt5.6 is a lot more huge than qt 4.8
20160716 08:23:56< shadowm> I don't remember if that was on my laptop (4 GiB, crummy low end CPU w/o virtualization extensions) or my desktop (16 GiB, Intel Core i7 3770) though.
20160716 08:24:03< shadowm> Ah, well, that could be a thing.
20160716 08:24:59< Nobun> and moreover it require a lot of time more if you try to build on VM instead of on actual OS
20160716 08:25:07< vultraz> Aginor: ok, so it seems leave_global is the problem 
20160716 08:25:51< vultraz> Aginor: if I comment out the call to leave_global in the sdl_handler destructor AND the preferences::base_manager destructor you asked me to add, the game runs fine
20160716 08:25:56< vultraz> and exists file
20160716 08:25:57< vultraz> fine*
20160716 08:26:24< Nobun> vultraz: where is leave_global coded?
20160716 08:27:05< shadowm> Nobun: Purportedly having a CPU (and virtualization solution) that supports CPU virtualization instructions should eliminate most of the overhead though.
20160716 08:27:36< vultraz> Nobun: https://github.com/wesnoth/wesnoth/blob/Vultraz-event_handling_fixes/src/events.cpp#L263
20160716 08:28:12< shadowm> At least here, building Wesnoth on a Windows 8.1 VM doesn't take considerably longer than doing it on the Linux host -- maybe around 3-5 more minutes.
20160716 08:28:37< shadowm> And that's mostly because the VM doesn't have as many threads allocated to it as the host can provide.
20160716 08:29:44< Nobun> vultraz: global_context.remove_handler(this);
20160716 08:29:48< shadowm> But then again, the VM has plentiful RAM alloted for the task, because I've got enough room for it without disrupting host activity.
20160716 08:30:03< Nobun> this line could be the problem, but I'm not sure
20160716 08:30:06< shadowm> And we already established that Wesnoth is a memory hog when compiling.
20160716 08:31:10< Nobun> I'm not sure, since I don't know wesnoth code / SDL... but it is possible that you could try to free a NULL pointer when the pointer only contains pointers wich were all previously de-allocated
20160716 08:31:38< Nobun> s/NULL pointer/ empty pointer
20160716 08:32:46< vultraz> hm
20160716 08:33:01< vultraz> my logging is handler.size() in the context destructor is giving me widly different results..
20160716 08:33:06< vultraz> wildly ..
20160716 08:39:11< vultraz> Nobun: that seems to be the problem line
20160716 08:39:29< vultraz> Nobun: I appear to have been misled, since it appears this line: 
20160716 08:39:31< vultraz> std::cerr << "handlers size is " << event_contexts.back().handlers.size() << std::endl;
20160716 08:39:33< vultraz> (which I have locally)
20160716 08:39:47< vultraz> also causes the crash if the line you mentioned is commented out
20160716 08:39:52< vultraz> s crash
20160716 08:39:54< vultraz> a crash
20160716 08:45:13< Aginor> vultraz: yes, I've been telling you that leave_global is the problem since yesterday :) The question is why.
20160716 08:47:24< Aginor> vultraz: can you plese add logging when the destructor is called for a context?
20160716 08:47:52< Aginor> it'll allow us to rule out that the context is destroyed before the leave_global call is made
20160716 08:47:58< vultraz> what?
20160716 08:49:08< vultraz> ok
20160716 08:49:42< Aginor> vultraz: I'm wondering if the global context is destroyed before that other handler, hence causing a crash when the list is interacted with
20160716 08:50:49< Rhonda> Oh, finally!  DNS works again.
20160716 08:51:01< vultraz> yay!
20160716 08:51:14< Rhonda> (not sure since when, I just checked in again :))
20160716 08:51:30< Nobun> vultraz: there is a thing I don't understand of your code
20160716 08:51:49< Nobun> line 267
20160716 08:52:09< vultraz> ask Aginor about that line
20160716 08:52:40< Nobun> when you iterate sdl_handler_vector it seems you seek for another sdl_handler_vector for every member in the root sdl_handler_vector
20160716 08:52:50-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160716 08:53:01< Aginor> Nobun: a sdl_handler may have child handlers, when the parent leaves so should the children
20160716 08:53:35< Nobun> but the problem is
20160716 08:53:50< Nobun> the mostly child handler is itself a sdl_handler?
20160716 08:54:08< Aginor> they all have to be sdl_handler
20160716 08:54:12< Nobun> ok
20160716 08:54:47< Nobun> and, internally, what a sdl_handler is?
20160716 08:55:10< Nobun> ah wait
20160716 08:55:31< Nobun> I perhaps understood why the code fails, but I don't know if my idea make sense
20160716 08:55:58< Nobun> ah no xD
20160716 08:56:07< Nobun> sorry for changing my mind so many times xD
20160716 08:56:19 * Nobun continues thinking...
20160716 08:56:57< Aginor> Nobun: yesterday vultraz was saying that it's inside the call to https://github.com/wesnoth/wesnoth/blob/Vultraz-event_handling_fixes/src/events.cpp#L272 that's failing
20160716 08:57:10< Aginor> vultraz: do you have a fresh stack trace to share?
20160716 08:57:18< Aginor> that will cut down on speculation
20160716 08:57:34< Aginor> vultraz: or are you in the middle of compiling?
20160716 08:59:39< Nobun> lol... on my side it fails compiling
20160716 09:02:15-!- Kwandulin [~Miranda@p200300760F2D81418DBC0D3C7CDDF6B5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160716 09:03:31< Nobun> a question:   what   sdl_handler_vector members = handler_members();   actually do?
20160716 09:04:17< Aginor> Nobun: how?
20160716 09:04:18< Nobun> I mean... handler_members() ... I don't understand how it can list the correct list of handlers on the current tree level
20160716 09:04:25< Aginor> Nobun: pastebin the compile error
20160716 09:05:06< Aginor> Nobun: they're not managed through the context, they may be managed within the inhereting class
20160716 09:05:22< vultraz> Aginor: http://pastebin.com/qbGhgAxy
20160716 09:05:41< Nobun> Aginor: http://dpaste.com/3NYEB5H
20160716 09:05:53< Nobun> Aginor: this could explain the issue
20160716 09:05:57< vultraz> Aginor: actually, wait a sec
20160716 09:06:03< vultraz> forgot to add a log line
20160716 09:06:24< Nobun> becouse handler_members() is recursively called by any nested level on any recursive call
20160716 09:06:35< vultraz> Aginor: http://pastebin.com/qbGhgAxy updated paste
20160716 09:06:51< Nobun> so you cannot be sure that you are correctly listing the correct list of the expected tree level
20160716 09:07:21< vultraz> Aginor: I don't have a stacktrace sorry
20160716 09:07:28< vultraz> I'll need to update the debug build
20160716 09:07:33< vultraz> been testing using release
20160716 09:07:46< Nobun> don't know if my idea makes sense
20160716 09:22:18-!- VultCave [~chatzilla@124.109.10.167] has joined #wesnoth-dev
20160716 09:22:51-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 240 seconds]
20160716 09:23:26-!- VultCave is now known as vultraz
20160716 09:24:04-!- vultraz [~chatzilla@124.109.10.167] has quit [Changing host]
20160716 09:24:04-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160716 09:24:43< vultraz> gah, now it's not crashing :|
20160716 09:26:52< vultraz> which is annoying, since I can't get a trace..
20160716 09:31:49< Aginor> Nobun: I'm not sure I follow your resoning. The code assumes that there's no circular dependencies. A sdl_handler doesn't keep track of what is joined into a context, only which it's "children" may be. The bit that's crashing doesn't have any "children" (unless someone's added them behind my back)
20160716 09:32:11< Aginor> vultraz: can you do a release build but add -g to the cflags?
20160716 09:32:24< Aginor> or cxxflags to be more specific
20160716 09:32:25< vultraz> I updated the debug build already
20160716 09:32:31< vultraz> but neither are crashing now :|
20160716 09:32:34< Aginor> ok
20160716 09:32:47< Aginor> we need to fix Nobun's compile error too
20160716 09:32:57< Nobun> Aginor: I try to explain better my idea
20160716 09:33:00< Aginor> looks like he doesn't have the same version of splice as us
20160716 09:33:21< Aginor> I also need to leave for a whiel again but I'll read up on the backlog when I'm back
20160716 09:34:01< Aginor> Nobun: I'll wait a wee bit to hear you out :)
20160716 09:34:22< Nobun> yeah sorry... since I had to reboot the pc I'm resuming the page where the vultraz code is... wait a moment
20160716 09:35:05< Nobun> the reason of my thinking is  line 265 + line 268
20160716 09:35:12< Aginor> vultraz: can you also add logging to context destructor?
20160716 09:35:17< Aginor> constructor
20160716 09:35:22< vultraz> ok
20160716 09:35:39< Nobun> line 238 tries to call recursively leave_global
20160716 09:35:40< Aginor> and declare a static int that you increment in the destructor, decrement in the destructor?
20160716 09:35:43< Aginor> ie, global
20160716 09:36:05< vultraz> what?
20160716 09:36:07< vultraz> is that to me?
20160716 09:36:11< Aginor> vultraz: yes :)
20160716 09:36:17 * vultraz groans
20160716 09:36:29< Nobun> but leave_global will obtain the vector list every time, at every level of the surface tree, with the function handler_members (on line 265)
20160716 09:36:33< Aginor> vultraz: and print the value in the constructor and destructor after changing it
20160716 09:36:34< vultraz> I'll do it later
20160716 09:36:55< Nobun> so my doubt is... are we sure that handler_members can work correctly in this recursive call?
20160716 09:37:35< Aginor> Nobun: it's not declared as a static variable so each call to the function will push a new one onto the stack
20160716 09:37:57< vultraz> I wonder if there's a problem with the fact that contexts uses a list and other parts of the code uses vectors
20160716 09:38:17-!- mjs-de [~mjs-de@x4e30e18d.dyn.telefonica.de] has joined #wesnoth-dev
20160716 09:38:18< Nobun> Aginor... yes... but the problem is on handler_members() wich I don't know how it work
20160716 09:38:47< Aginor> Nobun: that's held by each object that's referenced though
20160716 09:39:00< Nobun> my doubt is that every time handler_members() is called it looks at a fixed place... I don't see any code in handler_members wich tells me it is looking at the current sdl_handler pointer+
20160716 09:39:52< Aginor> Nobun: this is from yesterday: http://pastebin.com/twSiHUEX
20160716 09:39:56< Aginor> look at line 4
20160716 09:40:48< Aginor> handler_members_ is declared as a part of each sdl_handler in events.hpp, so each instance will contain a unique copy
20160716 09:41:23< Aginor> line 265 can also be written as "sdl_handler_vector members = this->handler_members();"
20160716 09:41:50< Aginor> because the function is implemented as a member function of a class, as seen on line 263
20160716 09:42:26< Aginor> vultraz: I doubt that mixing lists and vectors would be a problem,  if it was, lots of code would crash :)
20160716 09:42:56< Aginor> vultraz: I still suspect it has something to do with the order of which objects are destroyed when they go out of scope
20160716 09:43:20< vultraz> is raii in any way relevant here
20160716 09:43:26< Aginor> http://pastebin.com/qbGhgAxy could be indicative of the context destructor being called before the sdl_handler destructor
20160716 09:43:36< Aginor> vultraz: if it's done wrong, yes :)
20160716 09:44:08< Aginor> problem is, the global scope is declared as a part of the general program memory, it doesn't reside on the stack
20160716 09:44:39< Aginor> I explicitly made it like that to guarantee that it would always be available during the lifetime of the program
20160716 09:45:19< Aginor> but if it's cleaned up before a different object in _exit that relies on it, that'll be a problem
20160716 09:47:15< Aginor> </rant> :)
20160716 09:47:30< Aginor> I'll disappear for an hour or two now
20160716 09:47:33< vultraz> nothing about this is simple :)
20160716 09:49:17-!- lipkab [~the_new_l@87-97-127-133.pool.invitel.hu] has joined #wesnoth-dev
20160716 10:04:53-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160716 10:07:01-!- Nobun [~nobun@5.170.114.106] has quit [Ping timeout: 244 seconds]
20160716 10:10:17-!- irker452 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160716 10:14:14-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160716 10:25:15-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160716 10:26:47-!- Kwandulin [~Miranda@p200300760F2D81418DBC0D3C7CDDF6B5.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds]
20160716 10:30:47-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160716 10:31:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Ping timeout: 264 seconds]
20160716 10:32:28-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160716 10:33:09-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160716 10:35:17-!- stikonas_ is now known as stikonas
20160716 10:45:18-!- Duthlet [~Duthlet@dslb-188-106-027-209.188.106.pools.vodafone-ip.de] has joined #wesnoth-dev
20160716 11:03:35< Aginor> and back
20160716 11:06:02< Aginor> vultraz: still cannot reproduce :/
20160716 11:09:27< vultraz> did not expect you to
20160716 11:09:34< Shiki> Aginor, as far as I got it you try to fix some segfaults?
20160716 11:10:46< Aginor> Shiki: yes, which only vultraz has managed to reproduce so far :/
20160716 11:11:18< Aginor> vultraz: events.cpp:318 is also failing on gcc 4.7
20160716 11:11:31< Aginor> /usr/include/c++/4.7/bits/stl_list.h:1254:7: note:   no known conversion for argument 3 from ‘const const_iterator {aka const std::_List_const_iterator<events::sdl_handler*>}’ to ‘std::list<events::sdl_handler*>::iterator {aka std::_List_iterator<events::sdl_handler*>}’
20160716 11:11:46< Aginor> https://travis-ci.org/wesnoth/wesnoth/jobs/144822543#L1549
20160716 11:11:48< Shiki> I had yesterday one when I had an misspelled ability macro. But I couldn't reproduce it now
20160716 11:12:08< Aginor> Shiki: that's most likely a different one :/
20160716 11:13:32< Aginor> vultraz: I think it's the const_iterator that's the problem
20160716 11:14:10< vultraz> hm?
20160716 11:14:12< Shiki> Hmmm. I will try later If I can reproduce it and post it on gna. It happend only with the git version
20160716 11:14:34< vultraz> Aginor: I made it const to it would work with set_focus
20160716 11:15:17< Aginor> hmm
20160716 11:15:19< Aginor> yes
20160716 11:16:02< vultraz> I guess there's no reason that iterator has to be const
20160716 11:16:08< vultraz> is there?
20160716 11:16:25< Aginor> not really
20160716 11:16:39< Aginor> apart from making it clearer what the intent is
20160716 11:16:55< Aginor> Shiki: if you do manage to reproduce, a stack trace is always helpful :)
20160716 11:17:31< Aginor> vultraz: might make sense to just remove that call to splice
20160716 11:17:37< vultraz> eh?
20160716 11:17:47< vultraz> why?
20160716 11:17:50< vultraz> isn't it necessary?
20160716 11:17:58< Aginor> vultraz: replace the splice call with something that works on gcc 4.7/4.8
20160716 11:18:10< vultraz> GAH :|
20160716 11:18:18< vultraz> *compatibility*
20160716 11:18:49< vultraz> Aginor: one thing at a time
20160716 11:19:39< Aginor> handlers.push_back(*foc); handlers.erase(foc); //handlers.splice(handlers.end(), handlers, foc);
20160716 11:20:37< vultraz> building with an iterator instead of a const_iterator
20160716 11:23:24< Aginor> not to be annoying, but I like my version better ;)
20160716 11:23:48< vultraz> why?
20160716 11:24:30< vultraz> plus, I think celmin|sleep said splice was more performance friendly. 
20160716 11:24:35< vultraz> i may be mistaken
20160716 11:27:46< Aginor> it wouldn't at all surprise me if it is
20160716 11:28:18< Aginor> although erase at an iterator should be O(1), and so should push_back
20160716 11:30:24< Aginor> Unlike other standard sequence containers, list and forward_list objects are specifically designed to be efficient inserting and removing elements in any position, even in the middle of the sequence.
20160716 11:30:36< Aginor> I think that implies O(1)
20160716 11:39:32< vultraz> ok, it's not crashing
20160716 11:39:37< vultraz> but it was also not crashing before..
20160716 11:39:56< Aginor> vultraz: const_iter vs iter should have no effect at all on crashing
20160716 11:40:17 * vultraz glares
20160716 11:40:54< vultraz> then why did you just imply such above!
20160716 11:41:50< Aginor> vultraz: I did not. I was talking about a compile error in certain versions of gcc.
20160716 11:42:18 * vultraz groans
20160716 11:43:19< vultraz> either way, it hasn't crashed in awhile now
20160716 11:43:22< vultraz> dunno why
20160716 11:43:27< vultraz> I'm certain nothing has been fixed
20160716 11:43:43< Aginor> what does "git diff" tell you?
20160716 11:44:32< vultraz> http://pastebin.com/kyGQVFxk
20160716 11:46:00< Aginor> I think line 130 makes the difference
20160716 11:46:07< Aginor> try commenting it out and do again ;)
20160716 11:48:36< vultraz> after 3 more tries now it's crashing again
20160716 11:48:51< Aginor> good job ;)
20160716 11:49:20< vultraz> restored it and now it's still crashing again
20160716 11:49:25< vultraz> so basically, no change was made :|
20160716 11:49:55< Aginor> sweet
20160716 11:50:08< Aginor> can you please provide stack trace and output?
20160716 11:50:16< Aginor> (this is good)
20160716 11:50:49< vultraz> alright
20160716 11:50:54 * vultraz goes to update debug build
20160716 11:51:12< Aginor> what did the output say in the meanwhile?
20160716 12:01:09-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 12:03:07< vultraz> i didnt check
20160716 12:04:09< vultraz> dammit it won't crash again
20160716 12:05:28-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160716 12:08:23< Aginor> ok
20160716 12:08:43< Aginor> please also uncomment the prints in leave_global
20160716 12:09:21< Aginor> and add that counter I suggested earlier, it'll help ascertain the state even without a debugger
20160716 12:14:13-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160716 12:14:14< vultraz> removed the prefs line and i now have a crash
20160716 12:14:33< Aginor> ok
20160716 12:14:37< vultraz> http://pastebin.com/6vTTqiyM but it's no diffrent than what we've seen
20160716 12:14:46< vultraz> why do you need it again?
20160716 12:14:51< Aginor> what about the printouts?
20160716 12:15:04< vultraz> ill get to those tomorrow
20160716 12:15:09< Aginor> ok
20160716 12:15:15< vultraz> im tired and it's late
20160716 12:15:21< Aginor> yeah
20160716 12:21:04-!- woseshaman_ [5f5beb48@gateway/web/freenode/ip.95.91.235.72] has joined #wesnoth-dev
20160716 12:37:27< Shiki> Aginor, I can't reprocude it (the other bug), I have not the code which caused it, but i have still the coredump .
20160716 12:43:43< Shiki> https://bpaste.net/show/9755a87da45d
20160716 12:52:31-!- prkc [~prkc@catv-80-98-46-199.catv.broadband.hu] has quit [Ping timeout: 240 seconds]
20160716 12:54:14< Shiki> when the addon with the missspelled ability name droped the error, the game crashed after clicking ok
20160716 12:56:37-!- lipkab [~the_new_l@87-97-127-133.pool.invitel.hu] has quit [Ping timeout: 260 seconds]
20160716 13:00:17-!- Samual [~Samual@xonotic/core-team/Samual] has quit [Ping timeout: 250 seconds]
20160716 13:05:54-!- Samual [~Samual@xonotic/core-team/Samual] has joined #wesnoth-dev
20160716 13:06:02-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has joined #wesnoth-dev
20160716 13:07:37-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20160716 13:30:42< celmin|sleep> For the record, it didn't crash on exit for me.
20160716 13:47:13-!- celmin|sleep is now known as celticminstrel
20160716 13:47:19-!- markus_ [~mjs-de@x4e305225.dyn.telefonica.de] has joined #wesnoth-dev
20160716 13:49:18-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160716 13:50:33-!- mjs-de [~mjs-de@x4e30e18d.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20160716 14:08:38< celticminstrel> Something doesn't seem right about the fogging code...
20160716 14:09:14< celticminstrel> I assume [lift_fog] unfogs locations and [reset_fog] does the opposite?
20160716 14:09:30< celticminstrel> But looking at the code it seems like the reverse is true...
20160716 14:09:57< celticminstrel> But I think something like that would have been noticed? So I'm probably missing something...
20160716 14:13:04< celticminstrel> Okay, I think I'm right after all, but on closer inspection the original code was correct.
20160716 14:24:00-!- Kwandulin [~Miranda@p200300760F2D8141E4A5DC368ED5EBB2.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160716 14:24:38-!- lipkab [~the_new_l@87-97-127-133.pool.invitel.hu] has joined #wesnoth-dev
20160716 14:57:34-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160716 15:01:49-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Client Quit]
20160716 15:03:27< celticminstrel> Okay, so all that's left is [message]image_pos and the [role] changes. I'll hold back for now on those.
20160716 15:03:40< celticminstrel> I think the latter might also be missing from the changelog...
20160716 15:03:52< celticminstrel> Oh, no, I did add it, okay.
20160716 15:05:00-!- irker099 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160716 15:05:00< irker099> wesnoth: Celtic Minstrel wesnoth:master b145513db3cd / src/scripting/game_lua_kernel.cpp: Fix some issues with fog control https://github.com/wesnoth/wesnoth/commit/b145513db3cd089ca5819425b5cd1468f94196d1
20160716 15:09:39-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has joined #wesnoth-dev
20160716 15:39:00-!- travis-ci [~travis-ci@ec2-54-82-136-49.compute-1.amazonaws.com] has joined #wesnoth-dev
20160716 15:39:01< travis-ci> wesnoth/wesnoth#9804 (master - b145513 : Celtic Minstrel): The build passed.
20160716 15:39:01< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/145223880
20160716 15:39:01-!- travis-ci [~travis-ci@ec2-54-82-136-49.compute-1.amazonaws.com] has left #wesnoth-dev []
20160716 15:48:55-!- Duthlet [~Duthlet@dslb-188-106-027-209.188.106.pools.vodafone-ip.de] has quit [Quit: leaving]
20160716 15:51:13-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160716 15:59:53-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160716 16:02:45-!- Shiki [~Shiki@141.39.226.227] has quit [Remote host closed the connection]
20160716 16:04:35-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has joined #wesnoth-dev
20160716 16:35:26-!- lipkab [~the_new_l@87-97-127-133.pool.invitel.hu] has quit [Quit: Leaving]
20160716 16:37:03-!- edgrey [~edgrey@178.204.212.94] has quit [Remote host closed the connection]
20160716 16:37:26-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 16:37:50-!- edgrey [~edgrey@178.204.212.94] has quit [Read error: Connection reset by peer]
20160716 16:39:12-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 16:39:24-!- edgrey [~edgrey@178.204.212.94] has quit [Remote host closed the connection]
20160716 16:41:43-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 16:45:59-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20160716 16:46:47-!- edgrey [~edgrey@178.204.212.94] has quit [Remote host closed the connection]
20160716 16:47:12-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 16:52:52-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160716 16:55:59< celticminstrel> vultraz: Thoughts on recent 661 discussion?
20160716 17:06:05-!- ancestral [~ancestral@75-168-183-92.mpls.qwest.net] has quit [Quit: ancestral]
20160716 17:41:27-!- Kwandulin [~Miranda@p200300760F2D8141E4A5DC368ED5EBB2.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160716 17:44:08-!- markus_ is now known as mjs-de
20160716 17:57:32-!- trewe [~trewe@2001:8a0:d108:4c01:40df:5325:3776:ac34] has joined #wesnoth-dev
20160716 18:01:20< celticminstrel> Does anyone have any idea what the cause of all those UI messages are in the console? Things like "we missed an event" and stuff.
20160716 18:05:05-!- irker099 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160716 18:14:36-!- JyrkiVesterinen [~JyrkiVest@87-100-161-228.bb.dnainternet.fi] has joined #wesnoth-dev
20160716 18:27:23-!- Shiki [~Shiki@141.39.226.227] has joined #wesnoth-dev
20160716 18:34:41-!- irker883 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160716 18:34:41< irker883> wesnoth: gfgtdf wesnoth:master 1d168bce9a4b / data/lua/on_event.lua: fixup on_event.lua https://github.com/wesnoth/wesnoth/commit/1d168bce9a4b15f464bdf51b22b6d20b0e4c9881
20160716 18:59:52< celticminstrel> I'm thinking it might be good to try implementing FormulaAI in Lua purely as a test for the formula bridge API... though it would also require some additions on the AI side to work.
20160716 19:00:29-!- hk238 [~kvirc@t224.ip7.netikka.fi] has quit [Quit: http://www.kvirc.net/ 4.9.1 Aria]
20160716 19:00:31-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has joined #wesnoth-dev
20160716 19:33:48< celticminstrel> (Some of those AI additions would be to the Lua AI API though, so that would be beneficial...)
20160716 19:59:32< bumbadadabum> uhh when did we stop putting variation info in the unit wml
20160716 20:01:11< celticminstrel> Hm?
20160716 20:01:56-!- gfgtdf [~chatzilla@x4e32b78c.dyn.telefonica.de] has joined #wesnoth-dev
20160716 20:03:13< bumbadadabum> celticminstrel: I used the data of unit.variation[0].usage to store something (hacky as fuck but there was no better way at the time)
20160716 20:03:31< bumbadadabum> and that info isn't there anymore
20160716 20:03:36< celticminstrel> Uhh. What.
20160716 20:04:08< gfgtdf> bumbadadabum: thats intentional, those vriation data bloated the savefiles a lot, (assuming you had multiple corpses)
20160716 20:04:11< celticminstrel> I don't think that's really a problem... that sounds like unsupported behaviour anyway... you should put your extra data in variables...
20160716 20:04:17< gfgtdf> bumbadadabum: you can get that data by [store_unit_type]
20160716 20:04:24< bumbadadabum> gfgtdf: ahhh
20160716 20:04:25< bumbadadabum> thank you
20160716 20:04:34< bumbadadabum> celticminstrel: yes but they aren't inherent to the unit type
20160716 20:04:42< bumbadadabum> I needed to store data in the unit type not unit itself
20160716 20:04:46< celticminstrel> Uh, unit variables. It's per unit.
20160716 20:04:51< celticminstrel> Oh, right, okay.
20160716 20:05:27< bumbadadabum> gfgtdf: that tag is in 1.12 as well, right?
20160716 20:05:37< gfgtdf> bumbadadabum: i think so
20160716 20:06:36< gfgtdf> bumbadadabum: actuall you can afaik store any data in unit type, in one of my addons i have a [unit_type] [data] that contains most of the data use in my lua code
20160716 20:07:20< gfgtdf> bumbadadabum: with store_unit_type (or the lua equivaleint wesnoth.unit_types)
20160716 20:09:00< bumbadadabum> and that will be in the unit itself?
20160716 20:09:11< bumbadadabum> (tbh Espreon wrote this code in 2012 things probably changed since then)
20160716 20:09:22< celticminstrel> Can you get that data from Lua though?
20160716 20:09:25< bumbadadabum> I'll not do a rewrite right now since it's very low priority but thanks for the tip
20160716 20:09:36< celticminstrel> ie, is there a .__cfg option?
20160716 20:09:38< bumbadadabum> I'll probably rewrite it in lua at some point
20160716 20:11:51< gfgtdf> bumbadadabum: no it wont be in the unti itself
20160716 20:12:27< gfgtdf> celticminstrel: yes lua unti type has a __Cfg otion, (and since lua type userdata only supports some few toplevel attributes you usuakyl always have to use __cfg)
20160716 20:17:56-!- edgrey [~edgrey@178.204.212.94] has quit [Remote host closed the connection]
20160716 20:20:21-!- edgrey [~edgrey@178.204.212.94] has joined #wesnoth-dev
20160716 20:21:41-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20160716 20:26:24-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20160716 20:40:59-!- trewe [~trewe@2001:8a0:d108:4c01:40df:5325:3776:ac34] has quit [Quit: quit]
20160716 20:44:53< irker883> wesnoth: gfgtdf wesnoth:master 2825a9d84d77 / src/scripting/game_lua_kernel.cpp: add __cfg getter to lua attack userdata https://github.com/wesnoth/wesnoth/commit/2825a9d84d772398b4a3377d7a9676504e5a0fda
20160716 21:00:09-!- iceiceice [~chris@wesnoth/developer/iceiceice] has joined #wesnoth-dev
20160716 21:53:26-!- JyrkiVesterinen [~JyrkiVest@87-100-161-228.bb.dnainternet.fi] has quit [Quit: .]
20160716 22:02:56< vultraz> celticminstrel: what discussion?
20160716 22:07:18< iceiceice> i really hope travis-ci will do something with this: https://github.com/travis-ci/travis-ci/issues/6300
20160716 22:10:10-!- mjs-de [~mjs-de@x4e305225.dyn.telefonica.de] has quit [Remote host closed the connection]
20160716 22:11:02< celticminstrel> vultraz: Go look?
20160716 22:11:17< vultraz> oh
20160716 22:11:20< vultraz> my email was scrolled down
20160716 22:11:23< vultraz> I have emails
20160716 22:26:58< vultraz> hmm
20160716 22:27:43< vultraz> celticminstrel: could you elaborate on the issue a little?
20160716 22:28:42-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160716 22:29:27-!- edgrey [~edgrey@178.204.212.94] has quit [Remote host closed the connection]
20160716 23:01:48-!- molt [~molt@dynamic-213-198-235-143.adsl.eunet.rs] has quit [Quit: Leaving]
20160716 23:05:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20160716 23:06:11-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160716 23:17:52-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has joined #wesnoth-dev
20160716 23:19:38-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has left #wesnoth-dev []
20160716 23:22:06-!- mattsc [~mattsc@wesnoth/developer/mattsc] has joined #wesnoth-dev
20160716 23:27:35< vultraz> oh, there's mattsc 
20160716 23:27:42< vultraz> didn't someone want mattsc 
20160716 23:28:43< mattsc> Hi vultraz
20160716 23:28:55< mattsc> Nah, that must be a mistake.  Nobody could possibly want anything from me.  Or at least not anything useful.
20160716 23:29:21< celticminstrel> vultraz: What do you want me to elaborate on?
20160716 23:29:39< celticminstrel> vultraz: Also, if that was me, he already responded yesterday.
20160716 23:29:44< mattsc> vultraz: I already replied to celticminstrel yesterday though (which is probably what you remember)
20160716 23:29:48< celticminstrel> mattsc: Does your presence mean you now have time?
20160716 23:29:58< vultraz> celticminstrel: what is | in the generators again?
20160716 23:30:10< mattsc> celticminstrel: a little time, yes; a lot, no.
20160716 23:30:11< celticminstrel> It's alternation. Same as in a regular expression.
20160716 23:30:51< celticminstrel> Separates alternate possibilities.
20160716 23:31:49-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 252 seconds]
20160716 23:32:22< vultraz> celticminstrel: ok, and the issue is that | is also the variable pipe?
20160716 23:32:33< celticminstrel> Yes, $var|
20160716 23:32:43< celticminstrel> It's optional, but not in constructs like $var|marsh
20160716 23:34:52< vultraz> wasn't the | in generators introduced just recently?
20160716 23:35:07< celticminstrel> Yes, but it would be weird to replace it with a different character.
20160716 23:35:14< celticminstrel> That meaning of the character is quite widespread.
20160716 23:35:46< celticminstrel> I'd also note that replacing it with a common punctuation character is unacceptable, as that would interfere with any attempt to use the CFG generator on a sentence scale.
20160716 23:36:53< celticminstrel> (I think that rules out ()/-:;'",.&%$#?!@ )
20160716 23:37:20< vultraz> sentence scale?
20160716 23:37:29< celticminstrel> Using it to generate sentences, rather than names.
20160716 23:37:49< vultraz> We can do that?
20160716 23:37:57< celticminstrel> Yeah, sure. Why not?
20160716 23:38:07< celticminstrel> It's even in the wiki example.
20160716 23:38:14< vultraz> Ok, then here's a solution
20160716 23:38:19< vultraz> double pipe: ||
20160716 23:38:28< celticminstrel> Funny thing - I thought of that too a few moments ago.
20160716 23:38:31< celticminstrel> Post it, then?
20160716 23:39:11< celticminstrel> It would still interfere with variable substitution, but I think that level of interference can be tolerated.
20160716 23:39:26< celticminstrel> (It would mean you can't do things like $var$i||thing)
20160716 23:39:40< celticminstrel> (Using $i to determine which $varXXX to use)
20160716 23:41:29< vultraz> that's kinda dirty anyway
20160716 23:41:53< celticminstrel> I don't really agree that it's dirty, but it's something that I would not expect to be commonly wanted.
20160716 23:42:31< celticminstrel> (And if someone really does want it, they could probably jigger it so that the $i is in the middle instead of at the end - eg $var$i|_|thing )
20160716 23:43:12< celticminstrel> Actually, I bet they could also do it by putting $i in a nonterminal by itself.
20160716 23:43:28< celticminstrel> Then you'd have $var{index}|thing
20160716 23:43:40< celticminstrel> So the final output would still be $var$i||thing
20160716 23:45:18-!- irker883 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160716 23:45:47< mattsc> celticminstrel: sorry to interrupt your current discussion, but I’ll be gone again soonish
20160716 23:46:06< celticminstrel> mattsc: Did you find time to look over any wiki pages?
20160716 23:46:11< mattsc> I’ve now looked through all the changes you made until yesterday and they look good to me.
20160716 23:46:24< celticminstrel> Ah, okay, nice. I didn't expect that to be so fast.
20160716 23:46:26< mattsc> I hope you’re not asking me whether what you’re doing is complete.
20160716 23:46:38< celticminstrel> I don't think I was asking that.
20160716 23:46:40< mattsc> Well, I looked at the diffs, mostly.
20160716 23:47:06< mattsc> Sometimes I read some of the stuff around it for context, but generally I did not reread the whole pages.
20160716 23:47:10< celticminstrel> More detailed comments on the aspects section in Wesnoth AI Framework might be nice, if you have time. It doesn't have to be now, though.
20160716 23:47:30< celticminstrel> I wasn't really expecting you to reread the whole pages.
20160716 23:52:03-!- prkc [~prkc@gateway/vpn/privateinternetaccess/prkc] has quit [Ping timeout: 264 seconds]
20160716 23:52:05< mattsc> celticminstrel: hmm, I just noticed that I missed some of the changes from July 14, incl. a couple of the big changes to the AI Framework page.
20160716 23:52:18< mattsc> Sorry for that, my mistake ...
20160716 23:52:20< celticminstrel> Ah...
20160716 23:52:54< mattsc> I’ll check that out a little later (tomorrow, probably).  Any particular things you want me to pay attention to?
20160716 23:53:21< celticminstrel> I don't recall anything else other than the aspects section I already mentioned.
20160716 23:53:46< mattsc> okay
20160716 23:54:13< mattsc> Btw, I very much like some of those new features you’ve added.
20160716 23:54:23< celticminstrel> Hm?
20160716 23:54:28< mattsc> There are others I don’t care so much about, but I bet somebody else will.  ;)
20160716 23:56:03< mattsc> Now, are there going to be people who’ll actually use all this?
20160716 23:56:24< celticminstrel> I'm not sure?
20160716 23:56:28-!- woseshaman_ [5f5beb48@gateway/web/freenode/ip.95.91.235.72] has quit [Ping timeout: 250 seconds]
20160716 23:56:28< celticminstrel> Probably?
20160716 23:56:39< celticminstrel> Assuming there are people who used all the stuff that was already there before.
20160716 23:57:45< mattsc> Well, the aspects etc., yeah, definitely.  I guess I meant writing new AIs ...
20160716 23:58:34< mattsc> I want to go back to some of that, but I’m kind of at a loss at my current project and don’t really have ideas for simpler AIs or partial AIs.
20160716 23:58:58< mattsc> Fortunately, I haven’t had time anyway, so I don’t need to worry about that.  :P
--- Log closed Sun Jul 17 00:00:14 2016