--- Log opened Mon Apr 25 00:00:06 2016
20160425 00:31:22-!- nemaara [~nemaara@c-98-224-226-115.hsd1.mi.comcast.net] has joined #wesnoth-dev
20160425 00:31:41-!- irker269 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160425 00:57:17-!- gfgtdf [~chatzilla@x4e3637c6.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.2/20160407164938]]
20160425 00:57:26-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 01:13:16-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Ping timeout: 244 seconds]
20160425 01:15:07-!- aeth [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20160425 01:15:13-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160425 01:20:06-!- nemaara [~nemaara@c-98-224-226-115.hsd1.mi.comcast.net] has quit [Quit: nemaara]
20160425 01:23:14-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160425 02:38:40-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 02:51:16-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Remote host closed the connection]
20160425 03:46:56-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160425 03:47:25-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20160425 03:48:43-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 252 seconds]
20160425 03:48:51-!- wedge010 is now known as wedge009
20160425 03:54:27-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 04:01:37-!- Kwandulin [~Miranda@p200300760F3949BAD4885B395CC4EA0D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160425 04:03:20-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Remote host closed the connection]
20160425 04:48:11-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160425 04:51:58-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 05:00:24-!- exciton_ [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 05:02:10-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20160425 05:03:49-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 260 seconds]
20160425 05:08:49-!- Kwandulin [~Miranda@p200300760F3949BAD4885B395CC4EA0D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160425 05:41:38-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160425 06:02:47-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 06:03:57-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 06:08:56-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Ping timeout: 276 seconds]
20160425 06:14:48-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20160425 06:33:03-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160425 06:33:59-!- ancestral_ [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 06:39:36-!- ancestral_ [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Remote host closed the connection]
20160425 06:44:18-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 06:55:23-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Ping timeout: 250 seconds]
20160425 07:46:14< Soliton> gfgtdf: re 1cfa62ff56a1, did you forget to document why you're creating a memory leak?
20160425 07:53:34< Aginor> Soliton: good spot
20160425 07:55:51-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160425 08:03:05-!- atarocch [~atarocch@151.64.71.4] has joined #wesnoth-dev
20160425 08:05:10-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 08:09:33-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Ping timeout: 240 seconds]
20160425 08:53:04-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 08:57:12-!- exciton_ [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160425 08:57:17-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 08:57:26-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 09:24:25-!- quyet [70898407@gateway/web/freenode/ip.112.137.132.7] has joined #wesnoth-dev
20160425 09:27:14-!- quyet [70898407@gateway/web/freenode/ip.112.137.132.7] has quit [Quit: Page closed]
20160425 09:47:25-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20160425 09:56:25-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160425 10:00:52-!- mjs-de [~mjs-de@x4e30d125.dyn.telefonica.de] has joined #wesnoth-dev
20160425 10:01:03-!- enchi [enchilado@defocus/yummy/enchilado] has quit [Ping timeout: 240 seconds]
20160425 10:03:45-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20160425 10:05:58-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 10:08:45-!- enchi [enchilado@gateway/shell/blinkenshell.org/x-klqqqhdcobimddji] has joined #wesnoth-dev
20160425 10:10:26-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Ping timeout: 250 seconds]
20160425 10:11:08-!- stikonas2 [~stikonas@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160425 10:19:50-!- stikonas [~stikonas@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160425 10:31:04-!- stikonas [~stikonas@wesnoth/translator/stikonas] has quit [Quit: AtomicIRC: The nuclear option.]
20160425 10:33:20-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has joined #wesnoth-dev
20160425 10:40:00-!- prkc [~prkc@179.43.155.34] has joined #wesnoth-dev
20160425 10:50:23-!- stikonas2 [~stikonas@wesnoth/translator/stikonas] has quit [Ping timeout: 244 seconds]
20160425 10:58:07-!- ChipmunkV [~vova@d0017-2-88-172-31-68.fbx.proxad.net] has quit [Quit: ChipmunkV]
20160425 11:05:53-!- Duthlet [~Duthlet@p4FC92AF7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160425 11:14:55-!- enchi [enchilado@gateway/shell/blinkenshell.org/x-klqqqhdcobimddji] has quit [Quit: Reconnecting]
20160425 11:15:01-!- enchi [enchilado@gateway/shell/blinkenshell.org/x-ghipzanvhwqxkiad] has joined #wesnoth-dev
20160425 11:15:08-!- enchi [enchilado@gateway/shell/blinkenshell.org/x-ghipzanvhwqxkiad] has quit [Client Quit]
20160425 11:15:20-!- aeonchild [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20160425 11:16:50-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has joined #wesnoth-dev
20160425 11:20:09< gfgtdf> Soliton: well, this isnt a momory leak, the os will free all memeory of the programmat the end anyway.So it doesn ttmatterw ehther we free at manually at program end
20160425 11:20:51< gfgtdf> Soliton: the reason why such objects areoftennot descuted is that other codemightdepend on themevenin ther dtors
20160425 11:21:18< gfgtdf> Soliton: even in their*
20160425 11:21:39-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160425 11:22:35< gfgtdf> Soliton: soif wewould freeit maually (e.g. using an object instead of pointer +new) it could happpen  that thatobject is destructede before anotherobject that depends on it is descruted.
20160425 11:23:08< gfgtdf> Soliton: in this case this could for example happen if that otherpbject was static and had a tsstring member.
20160425 11:31:59-!- prkc [~prkc@179.43.155.34] has quit [Ping timeout: 276 seconds]
20160425 11:35:12< Soliton> gfgtdf: my point is that you should write that explanation as a code comment or at least in the commit message. i've certainly guessed that you have issues with destruction order but i highly doubt that that is trivially obvious to anyone seeing that apparent memory leak.
20160425 11:36:34< gfgtdf> Soliton: well i actualjustcopied that code from map() 2 lnies above (myfirst verson of that code made map() return a pari<mutex, has_map>
20160425 11:39:32< Soliton> ah, you copied unreadable code thus it is fine. roger.
20160425 11:41:57< Soliton> btw is there a non-zero chance that all the issues with the introduction of threading could possibly lead to not making all wesnoth code thread-safe but to actually removing the threading again?
20160425 11:42:33< Soliton> just wondering if that kind of decision is even on the table.
20160425 11:43:49< zookeeper> so what does all this threading that people have been talking about actually accomplish? my impression was that it's just something like the rendering of the loading screen
20160425 11:46:15-!- prkc [~prkc@catv-89-133-36-138.catv.broadband.hu] has joined #wesnoth-dev
20160425 11:54:25< gfgtdf> Soliton: well yes, that could happen in case that therr appearmore issued elatedto it. but the current implementtion has quitesome advantages that we don't want to give up.
20160425 11:55:35< gfgtdf> Soliton: 1) The loadingcreen is faster, 2) Its now possible to close wesnoth window during loadingscreen, 3) the animations are smoother.
20160425 11:58:15< gfgtdf> the loadingscreen nimations i meant ofc.
20160425 12:03:59< Soliton> well, if random crashes is not enough i think nothing will be. sounds like a no.
20160425 12:05:48< Soliton> i doubt that 1) is true in any significant way, btw.
20160425 12:06:38< zookeeper> at least not because of threading as such
20160425 12:06:48-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 12:06:58< zookeeper> apparently just because it updates the screen less often or something
20160425 12:11:38-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Ping timeout: 276 seconds]
20160425 12:12:00< gfgtdf> Soliton: did randomcrashes appear to you at current master head?
20160425 12:15:43< Soliton> i'm not testing current master head.
20160425 12:17:28-!- prkc [~prkc@catv-89-133-36-138.catv.broadband.hu] has quit [Ping timeout: 252 seconds]
20160425 12:24:03-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has quit [Ping timeout: 240 seconds]
20160425 12:29:16-!- prkc [~prkc@81.17.19.34] has joined #wesnoth-dev
20160425 12:37:50< celticminstrel> I don't think the threading made the loading screen faster, yeah.
20160425 12:38:07< celticminstrel> But #2 is a significant advantage in my opinion.
20160425 12:38:17< celticminstrel> I have no way of telling whether #3 is true.
20160425 12:38:47< zookeeper> well #2 doesn't require threading either
20160425 12:39:03< celticminstrel> This is probably true, yes.
20160425 12:39:18< zookeeper> i'm pretty sure single-threaded applications can be closed :p
20160425 12:39:29< zookeeper> whenever you want, even
20160425 12:39:53< celticminstrel> I can't quite remember, but I thought I was able to close it already before the threading....
20160425 12:40:04< celticminstrel> But for some reason gfgtdf couldn't?
20160425 13:21:48-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 14:29:32-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160425 14:53:23-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has joined #wesnoth-dev
20160425 14:54:02< gfgtdf> celticminstrel: well i and vultraz had the imporession that the gui2 loaingscreen is faster than than old one.
20160425 14:54:56< gfgtdf> celticminstrel: you coudl dimsply have the hui2 loadngscreen withoud threadong but then it wodn show current status, animations or recaly on any inut during loadinscreen
20160425 14:55:03< gfgtdf> gui2*
20160425 14:55:22< celticminstrel> The point is that the speed improvement isn't a result of threading.
20160425 14:55:50< celticminstrel> And I think status and animations could be done without threading, though it might be a bit harder.
20160425 14:56:05< gfgtdf> celticminstrel: hmm no the point is what you compare, i compared the gui2with threadng to the old loadingscren since i think a loaingscreeen that doesnt rect on any input and doesn't show any progress isn't really an option
20160425 14:56:23< celticminstrel> That's not the point at all.
20160425 14:57:01< celticminstrel> Like I said, the point is that the speed improvement was from moving it to GUI2 and not from the threading; the problems that threading solved could have probably been solved in other ways as well.
20160425 14:57:23< gfgtdf> celticminstrel: hmm feel free to try it.
20160425 14:59:24< gfgtdf> and also noone coudl gave me any reason yet against using threading there.
20160425 15:00:32< celticminstrel> Well, I don't have any hard reasons against it either, though as Aginor has pointed out and you have presumably noticed from experience, it can be pretty finicky.
20160425 15:03:10-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 268 seconds]
20160425 15:04:22-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:05:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160425 15:05:28< gfgtdf> until now we could fix all reported related issues rather easily.
20160425 15:09:21-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:10:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160425 15:10:58< Soliton> "Attempt to fix crashes realted to multithreading and std::string" that indeed sounds like a commit message from a dev who is convinced he found the bug and fixed it, easily. :-P
20160425 15:12:46< Soliton> if "we could fix all reported related issues" is the way you measure the value of any code change you'll never find a problem with any change unless it is simply wrong and not technically possible.
20160425 15:14:22-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:22:34< loonycyborg> threads are sure a can of worms of their own. Deadlocks, race conditions, oh my! :P
20160425 15:22:40< gfgtdf> Soliton: well, i am convided that i found the bug and writing that commit wasnt that hard eigher, the reason why i formuate it this was was becasue i was still unsure about whether this is a good fix for this issue, in particual i wasn't sure whether adding threadlocks to tstring constructors would slow things down which would bean i might have to fix it in another way.
20160425 15:23:05< gfgtdf> s/bean/mean
20160425 15:23:25< loonycyborg> They CAN be used properly, but it requires totally different way of thinking about control flow, adds whole new dimension to it
20160425 15:24:59< loonycyborg> And it also seems to me that C++ doesn't provide enough abstractions to catch deadlocks and race conditions
20160425 15:25:13< loonycyborg> so as far as language support you're basically at C level
20160425 15:25:59< gfgtdf> loonycyborg: well its not like those thread interact a lot. bsically the one thread onyl does some file parsing and the other thread waits for ui input and waits for the other thread to finish. Its just some utuity classes the under the hood use sharted resources liek tstring did that caused probelms-
20160425 15:26:10-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit []
20160425 15:26:35< celticminstrel> And some things on the loading thread accessed the event queue.
20160425 15:26:52< celticminstrel> Which is why I had to hack in that "if on main thread, skip pump" rule.
20160425 15:27:58< zookeeper> i guess usually you need to design the interfaces and function call interactions in a thread-sensible way from the get-go. converting non-threaded code by just adding locks and stuff seems tricky and prone to problems... in my so-limited-that-it-doesn't-even-count experience, anyway :>
20160425 15:28:24< celticminstrel> I'd say you're basically right though.
20160425 15:29:00-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160425 15:29:15-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:30:44< gfgtdf> zookeeper: for such things as tstring there are basically2 options: 1) don't use shared resources, 2) use locks/mutexes
20160425 15:31:06< gfgtdf> i still don't really know why shared resoruces are used there in the first place though
20160425 15:31:48< celticminstrel> What's the shared resource again? Some kind of cache?
20160425 15:32:14 * celticminstrel guesses you went with the lock/mutex method.
20160425 15:32:31< gfgtdf> celticminstrel: you know what shared_ptr is ?
20160425 15:32:41< celticminstrel> Eh?
20160425 15:32:59< loonycyborg> I think shared_ptr has some builtin support for threading
20160425 15:33:22< gfgtdf> celticminstrel: shared reoucres in wesnoth reosurcee is similar to shared_ptr but instead it checkw ehther there is a already a ptr object for and equal type an used that then istead
20160425 15:33:27< gfgtdf> loonycyborg: yes it has
20160425 15:33:33-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 240 seconds]
20160425 15:33:49< loonycyborg> at least I remember it provided some guarantees wrt shared counter
20160425 15:33:49< gfgtdf> celticminstrel: in ctor that is
20160425 15:34:16-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:34:32< celticminstrel> So, some kind of cache?
20160425 15:35:01< gfgtdf> celticminstrel: y i went ewith the mutex method for now, but the onyl reason why i kept the shared tstring thing it becasue it assumes that there must be some intention behind it that might be wirthy to keep withotu knowing exactly.
20160425 15:35:03< gfgtdf> celticminstrel: yes
20160425 15:35:19< celticminstrel> Hmm.
20160425 15:35:54< gfgtdf> celticminstrel: unrelated: doy ou know wbaout the creashed related to apply_to=variation in [effect] ?
20160425 15:36:07< gfgtdf> celticminstrel: this code: wesnoth.create_unit({ x=1, y=1, type = "Walking Corpse", side = 1, T.modifications { T.object { T.effect { apply_to="variation", name = "dwarf" } } } }):to_map()
20160425 15:36:15< gfgtdf> celticminstrel: creates an inifilite recursion
20160425 15:37:01-!- exciton [chuck-the-@89.208.170.132] has quit [Read error: Connection reset by peer]
20160425 15:37:21< celticminstrel> Can't you just put "variation='dwarf'" directly in the [unit] table?
20160425 15:37:39< celticminstrel> I'm not sure why that would cause infinite recursion though...
20160425 15:37:51< celticminstrel> What's the loop in the stack trace?
20160425 15:38:03< celticminstrel> ie, the portion of the stack trace that's being repeated.
20160425 15:38:11< gfgtdf> celticminstrel: becasue before your changes to [effect] apply_to=variation/type were ahdnled specially which you mostlikeley removed
20160425 15:38:30< gfgtdf> handled*
20160425 15:38:50< celticminstrel> I'm pretty sure I didn't remove that, at least not on purpose; I know there's still some special handling there, at least.
20160425 15:39:16-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 15:39:19< celticminstrel> Maybe I accidentally removed an 'if(type == 'variation') continue;' type think in unit::add_modification.
20160425 15:39:39< celticminstrel> ^thing
20160425 15:40:47< gfgtdf> celticminstrel: fom looking at the code i'd say the strackace coudol be apply_builtin_effect -> advance_to -> apply_modifications -> apply_builtin_effect didnt text though
20160425 15:40:53< celticminstrel> apply_to=variation passes through the wesnoth.effects table, but it should still be handled last no matter what; if not, I made a mistake.
20160425 15:48:15< gfgtdf> celticminstrel: hmm ok i see what you did
20160425 15:48:33< gfgtdf> celticminstrel: i think your mistak is the no_add == false fahck in line 2160
20160425 15:49:06-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20160425 15:49:13< gfgtdf> mistake* check*
20160425 15:50:51< gfgtdf> celticminstrel: in case 'no_add == true' it apply_to=variation/type shoudl ahve no effect al all
20160425 15:51:30< celticminstrel> Huh? Why would you say that?
20160425 15:51:48-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 276 seconds]
20160425 15:51:48-!- wedge010 is now known as wedge009
20160425 15:53:32-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has joined #wesnoth-dev
20160425 15:54:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 15:56:29< gfgtdf> celticminstrel: becasue no_add is ually used when a new unit is created meaning when the unti already has that object
20160425 15:57:08< celticminstrel> Sounds like a baseless assertion.
20160425 15:57:10< gfgtdf> celticminstrel: like in the code i posted above
20160425 15:57:41< celticminstrel> The code you posted uses no_add?
20160425 15:58:00 * celticminstrel is pretty sure no_add is exposed to the WML API though.
20160425 15:58:22< gfgtdf> celticminstrel: well yes the effect is applied when the unit uis created, in such situation no_add=yes is used (becasue it already has the object)
20160425 15:58:33< gfgtdf> celticminstrel: yes it was eposed to theaml api later
20160425 15:58:47< celticminstrel> I see.
20160425 15:59:07< celticminstrel> That implies that the majority of calls to add_modification actually use no_add.
20160425 15:59:16< celticminstrel> Since most of the time the modification is already present.
20160425 15:59:19< gfgtdf> celticminstrel: yes
20160425 16:02:41< gfgtdf> celticminstrel: this woudl also means that the code in my example above wouldnt change the units variation, which is just veryfied to be teh case on 1.12
20160425 16:03:18< gfgtdf> celticminstrel: this is still anissue specialyl when relgogn games or using unstore_unit.
20160425 16:25:21-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
20160425 16:25:36-!- prkc [~prkc@81.17.19.34] has quit [Ping timeout: 276 seconds]
20160425 16:39:25-!- prkc [~prkc@catv-89-133-36-138.catv.broadband.hu] has joined #wesnoth-dev
20160425 16:47:27< zookeeper> Ravana_, what convinced you that the spritesheet post/account was (going to become) spam?
20160425 16:47:52< zookeeper> i just couldn't tell whether it was that or one of the most cluelessly placed posts i've ever seen
20160425 16:48:45< Ravana_> posting pattern mostly, account created less than 1h before post, and no login after post. though as I left report open I am not completely sure
20160425 16:49:02< Ravana_> and filled in profile
20160425 16:50:20< Ravana_> I expect it act like https://forums.wesnoth.org/memberlist.php?mode=viewprofile&u=141581
20160425 16:51:19< zookeeper> well if you're not sure then better not move to junkyard since that's for accounts getting banned without further assessment
20160425 16:51:51-!- exciton [chuck-the-@89.208.170.132] has quit [Ping timeout: 246 seconds]
20160425 16:53:33-!- exciton [chuck-the-@89.208.170.132] has joined #wesnoth-dev
20160425 16:56:45-!- ancestral [~ancestral@75-168-27-21.mpls.qwest.net] has quit [Quit: i go nstuf kthxbai]
20160425 16:57:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160425 16:59:09-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 17:03:57< Ravana_> I thought of https://forums.wesnoth.org/viewtopic.php?f=16&t=43060 , that was in junkyard for a month.. but yes, it seems these types aren't that likely to post again after one round.. moving
20160425 17:06:05-!- prkc [~prkc@catv-89-133-36-138.catv.broadband.hu] has quit [Ping timeout: 276 seconds]
20160425 17:18:23-!- prkc [~prkc@179.43.134.162] has joined #wesnoth-dev
20160425 17:22:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 17:31:55-!- mjs-de [~mjs-de@x4e30d125.dyn.telefonica.de] has quit [Remote host closed the connection]
20160425 17:42:54-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160425 17:43:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 17:43:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: Connection reset by peer]
20160425 17:44:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 17:45:18-!- Kwandulin [~Miranda@p200300760F394905FD60D69D638E490D.dip0.t-ipconnect.de] has joined #wesnoth-dev
20160425 17:48:22-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 244 seconds]
20160425 17:55:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 17:58:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160425 17:58:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 18:07:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 18:24:42-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20160425 18:30:58-!- prkc [~prkc@179.43.134.162] has quit [Remote host closed the connection]
20160425 18:42:41-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20160425 18:58:39-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 19:01:05-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.2/20160407164938]]
20160425 19:09:31-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20160425 19:09:58-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 19:15:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160425 19:28:19-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 19:30:18-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20160425 19:47:49-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 19:51:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 19:53:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160425 19:54:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 20:19:42-!- mjs-de [~mjs-de@wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20160425 20:37:23-!- Kwandulin [~Miranda@p200300760F394905FD60D69D638E490D.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20160425 20:48:37-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 20:55:51-!- irker187 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20160425 20:55:51< irker187> wesnoth: gfgtdf wesnoth:master 067b2a872f4f / src/units/unit.cpp: fix apply_to=variation/type https://github.com/wesnoth/wesnoth/commit/067b2a872f4f3dd046058ade04646fe01606d9e9
20160425 21:03:09-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20160425 21:04:47-!- mjs-de [~mjs-de@x4e30d125.dyn.telefonica.de] has joined #wesnoth-dev
20160425 21:11:40-!- Greywhind [~Greywhind@c-71-232-29-126.hsd1.ma.comcast.net] has joined #wesnoth-dev
20160425 21:26:12-!- travis-ci [~travis-ci@ec2-54-163-154-44.compute-1.amazonaws.com] has joined #wesnoth-dev
20160425 21:26:13< travis-ci> wesnoth/wesnoth#9326 (master - 067b2a8 : gfgtdf): The build failed.
20160425 21:26:13< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/125676141
20160425 21:26:13-!- travis-ci [~travis-ci@ec2-54-163-154-44.compute-1.amazonaws.com] has left #wesnoth-dev []
20160425 21:33:05-!- atarocch [~atarocch@151.64.71.4] has quit [Remote host closed the connection]
20160425 21:40:28< oldshadowm> gfgtdf: So why haven't yout old anyone about this? https://forums.wesnoth.org/viewtopic.php?p=596105#p596105
20160425 21:40:47< oldshadowm> It's not even in the changelog.
20160425 21:43:24< celticminstrel> I think 1.12.6 is a good idea.
20160425 21:55:48-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has quit [Remote host closed the connection]
20160425 21:58:09-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20160425 22:03:12-!- oldlaptop [~quassel@50-37-53-169.mskg.mi.frontiernet.net] has quit [Remote host closed the connection]
20160425 22:07:27-!- oldlaptop [~quassel@50-37-53-169.mskg.mi.frontiernet.net] has joined #wesnoth-dev
20160425 22:13:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20160425 22:22:37-!- horrowind [~Icedove@2a02:810a:83c0:1c18:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20160425 22:33:02-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20160425 22:43:15-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 276 seconds]
20160425 22:44:30-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 22:44:55-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has joined #wesnoth-dev
20160425 22:46:31< gfgtdf> oldshadowm: dont remember, i also don't rmember why i made that commit in the first place (e.g whether someone reported it or whether i just made it becaue the code looked bad)
20160425 22:47:49< gfgtdf> oldshadowm: you meant about that commit or about the forume report ?
20160425 22:48:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Read error: No route to host]
20160425 22:48:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20160425 22:49:35-!- Appleman1234 [~Appleman1@KD036012037207.au-net.ne.jp] has quit [Ping timeout: 250 seconds]
20160425 22:58:54-!- ancestral [~ancestral@63.92.240.233] has joined #wesnoth-dev
20160425 23:33:06-!- gfgtdf [~chatzilla@x4e3688ec.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.2/20160407164938]]
20160425 23:43:07-!- Duthlet [~Duthlet@p4FC92AF7.dip0.t-ipconnect.de] has quit [Quit: leaving]
20160425 23:45:14-!- ancestral [~ancestral@63.92.240.233] has quit [Quit: i go nstuf kthxbai]
20160425 23:46:45-!- Appleman1234 [~Appleman1@KD036012035161.au-net.ne.jp] has joined #wesnoth-dev
20160425 23:48:55-!- mjs-de [~mjs-de@x4e30d125.dyn.telefonica.de] has quit [Remote host closed the connection]
20160425 23:55:56-!- irker187 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20160425 23:56:27-!- skyfaller [~skyfaller@wikipedia/Skyfaller] has joined #wesnoth-dev
--- Log closed Tue Apr 26 00:00:22 2016