--- Log opened Thu Mar 30 00:00:21 2017
20170330 00:24:33-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 00:24:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 00:25:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 01:10:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 01:11:43< vultraz_iOS> indeed crazy
20170330 01:11:44-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 01:12:30-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has joined #wesnoth-dev
20170330 01:12:59< vultraz_iOS> but ill save it as a shared_ptr.
20170330 01:13:09< vultraz_iOS> in fact, I can probably save as reference
20170330 01:14:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds]
20170330 01:14:45< celticminstrel> vultraz_iOS: Uhh, I don't think I'd recommend that.
20170330 01:14:54< vultraz_iOS> why?
20170330 01:15:12< celticminstrel> Because a reference doesn't hold ownership.
20170330 01:15:40< celticminstrel> (Okay, a const reference does maybe, but that's not an option here where it needs to be mutable.)
20170330 01:15:42< vultraz_iOS> variant holds its value as a shared_ptr
20170330 01:16:00< vultraz_iOS> does it matter if callable is a reference in the helper type class?
20170330 01:16:07< celticminstrel> I'm talking about a shared_ptr<formula_callable>
20170330 01:16:19< celticminstrel> It should be a shared_ptr, not a reference.
20170330 01:16:26< vultraz_iOS> alright
20170330 01:17:26< celticminstrel> You're not moving variant.?pp are you? Not sure how well that would go over when I rebase...
20170330 01:17:32< vultraz_iOS> no
20170330 01:17:39< vultraz_iOS> I'm adding a variant_private.*pp
20170330 01:17:46< celticminstrel> Oh my.
20170330 01:18:01< celticminstrel> I think normally you wouldn't have a variant_private.cpp though...
20170330 01:18:11< celticminstrel> At least, nothing else in Wesnoth does.
20170330 01:18:53< vultraz_iOS> right now i have nothing in the cpp
20170330 01:22:36< celticminstrel> Might as well delete it then? :P
20170330 01:26:40< vultraz_iOS> when I'm done
20170330 01:27:17< vultraz_iOS> celticminstrel: should callable be const shared_ptr<formula_callable> or shared_ptr<const formula_callable>
20170330 01:28:05< celticminstrel> To wrap "const X*" in a shared_ptr you do shared_ptr<cosnt X>
20170330 01:28:11< celticminstrel> ^const
20170330 01:30:10< vultraz_iOS> alright
20170330 01:30:54< vultraz_iOS> ok, now I need to implement the fact that all these ops take variants as their arguments and make new variants...
20170330 01:30:55< vultraz_iOS> hmmm
20170330 01:31:19< vultraz_iOS> technically, I could probably refactor out the intermediate creation of variants, though
20170330 01:31:26< celticminstrel> Uh, what?
20170330 01:33:14< vultraz_iOS> celticminstrel: well, for example, list_elements_add
20170330 01:33:25< vultraz_iOS> it creates a vector of variants
20170330 01:33:33< vultraz_iOS> by using operator+ on two variants
20170330 01:33:52< vultraz_iOS> then return a variant created from the vector of variants
20170330 01:33:58< vultraz_iOS> returns*
20170330 01:34:03< celticminstrel> What about it?
20170330 01:34:37< vultraz_iOS> I'm pondering whether I can skip the vector of variants and use a vector of variant_value_base
20170330 01:36:05< celticminstrel> That would have to be a vector of shared_ptr<variant_value_base>
20170330 01:36:05< vultraz_iOS> anyway, right now I need to merge variant_map and variant_list
20170330 01:36:10< celticminstrel> And I think I wouldn't really recommend it.
20170330 01:36:20< celticminstrel> And why on earth would you merge variant_map and variant_list?
20170330 01:36:30< celticminstrel> That doesn't make any sense, they're completely different things.
20170330 01:36:34< vultraz_iOS> their handling is almost identical
20170330 01:36:57< vultraz_iOS> I can make a single class template variant_container
20170330 01:39:01< vultraz_iOS> celticminstrel: look at how the class definitions are basically the same: https://pastebin.com/QBJ2xHHM
20170330 01:40:24< celticminstrel> get_container() should either be const or non-const, not a weird mixture of both.
20170330 01:41:32< celticminstrel> Hmm, I think I get why you'd want to merge them, though you'll probably find some problems with get_type().
20170330 01:42:05< celticminstrel> (To clarify - either make get_container() a const function, or make it return a non-const reference.)
20170330 01:42:17< vultraz_iOS> (done)
20170330 01:47:28< celticminstrel> (Both is actually an option too. :P )
20170330 02:50:53-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 02:53:50-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has joined #wesnoth-dev
20170330 03:08:44-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 03:26:45-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has joined #wesnoth-dev
20170330 04:02:27-!- JyrkiVesterinen [~JyrkiVest@87-100-152-202.bb.dnainternet.fi] has joined #wesnoth-dev
20170330 04:11:36-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds]
20170330 04:13:20< celticminstrel> vultraz_iOS: Another suggestion: instead of having get_type() return a string/enum pair, make it just return the enum, but use MAKE_ENUM so it's trivially convertible to string.
20170330 04:36:13-!- EliDupree2 [~quassel@2604:a880:400:d0::9bb:2001] has quit [Ping timeout: 246 seconds]
20170330 04:36:58-!- higgins [~higgins@68.ip-149-56-14.net] has quit [Quit: Leaving]
20170330 04:36:59-!- RatArmy_ [~ratarmy@om126237112041.9.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 04:37:25-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev
20170330 04:39:47-!- higgins [~higgins@68.ip-149-56-14.net] has joined #wesnoth-dev
20170330 04:50:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 04:55:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170330 05:11:33-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20170330 05:16:40-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20170330 05:33:25-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Ping timeout: 268 seconds]
20170330 05:33:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170330 05:54:13-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has joined #wesnoth-dev
20170330 06:00:33-!- JyrkiVesterinen [~JyrkiVest@87-100-152-202.bb.dnainternet.fi] has quit [Quit: .]
20170330 06:09:54< vultraz_iOS> celticminstrel: perhaps, perhaps
20170330 06:10:03< vultraz_iOS> but that's last
20170330 06:10:25< celticminstrel> Otherwise you're pointlessly constructing a string that's never used in cases where you only need the enum.
20170330 06:11:59< vultraz_iOS> well, it's static 
20170330 06:12:34< celticminstrel> But IIRC it was still constructing a new pair every time it was called.
20170330 06:12:50< celticminstrel> But, wait, why is it static?
20170330 06:12:52< vultraz_iOS> 		static variant_type_pair type {"map", TYPE_MAP};
20170330 06:12:52< vultraz_iOS> 		return type;
20170330 06:13:04< celticminstrel> Oh, that kind of static.
20170330 06:13:26< celticminstrel> Fair enough, I guess; though copy construction still potentially occurs.
20170330 06:31:46-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 06:31:47-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 06:34:43-!- JyrkiVesterinen [~JyrkiVest@85-76-135-236-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170330 06:39:12-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 06:41:34-!- celticminstrel is now known as celmin|sleep
20170330 06:43:52-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170330 06:47:20-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 06:47:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170330 06:59:21-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20170330 06:59:36-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170330 07:05:52-!- Kwandulin [~Kwandulin@p200300760F3E7DFA29B8D385D96E4508.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 07:12:07-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has joined #wesnoth-dev
20170330 08:23:10-!- Kwandulin [~Kwandulin@p200300760F3E7DFA29B8D385D96E4508.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170330 08:27:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 08:32:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170330 08:42:17-!- vincent_c [~bip@158.69.220.39] has quit [Quit: Coyote finally caught me]
20170330 08:42:50-!- vincent_c [~bip@vcheng.org] has joined #wesnoth-dev
20170330 08:46:02-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Read error: Connection reset by peer]
20170330 08:46:03-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 08:47:25-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20170330 08:49:06-!- JyrkiVesterinen [~JyrkiVest@85-76-135-236-nat.elisa-mobile.fi] has quit [Quit: .]
20170330 08:53:10-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has quit [Ping timeout: 264 seconds]
20170330 08:55:19-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has joined #wesnoth-dev
20170330 09:02:36-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 09:03:51-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Client Quit]
20170330 09:05:24-!- tomreyn [~tomreyn@megaglest/team/tomreyn] has joined #wesnoth-dev
20170330 09:15:46-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 09:20:48-!- midzer_ [~quassel@p5B05188A.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 09:23:04-!- midzer [~quassel@p5B051444.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]
20170330 09:24:19-!- JyrkiVesterinen [~JyrkiVest@85-76-135-236-nat.elisa-mobile.fi] has joined #wesnoth-dev
20170330 09:27:12-!- midzer_ is now known as midzer
20170330 09:50:50-!- Kwandulin [~Kwandulin@p200300760F3E7DFA60481007EADC4479.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 09:54:01-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has joined #wesnoth-dev
20170330 10:15:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 10:19:55-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 246 seconds]
20170330 10:26:34-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170330 10:57:44-!- RatArmy_ [~ratarmy@om126212092058.11.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 11:59:13-!- Kwandulin [~Kwandulin@p200300760F3E7DFA60481007EADC4479.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170330 12:04:03-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 12:08:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds]
20170330 12:12:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 12:15:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170330 12:29:03-!- RatArmy_ [~ratarmy@om126161114108.8.openmobile.ne.jp] has joined #wesnoth-dev
20170330 12:31:19-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170330 12:41:10-!- Duthlet [~Duthlet@dslb-188-106-146-119.188.106.pools.vodafone-ip.de] has joined #wesnoth-dev
20170330 12:43:05-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 12:45:15-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170330 12:46:47-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20170330 13:07:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170330 13:27:32-!- Kwandulin [~Kwandulin@p200300760F3E7DFAEC162986CADB9CE5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 13:45:27-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Read error: Connection reset by peer]
20170330 13:45:48-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20170330 14:24:50-!- JyrkiVesterinen [~JyrkiVest@85-76-135-236-nat.elisa-mobile.fi] has quit [Quit: .]
20170330 14:44:52-!- Kwandulin [~Kwandulin@p200300760F3E7DFAEC162986CADB9CE5.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds]
20170330 14:46:17-!- RatArmy_ [~ratarmy@om126161114108.8.openmobile.ne.jp] has quit [Read error: Connection reset by peer]
20170330 14:48:34-!- Kwandulin [~Kwandulin@p200300760F3E7DFAEC162986CADB9CE5.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 14:51:20-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20170330 15:30:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20170330 15:30:45-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20170330 15:42:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 16:22:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 16:22:40-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 16:22:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 16:22:53-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 16:38:10-!- Kwandulin [~Kwandulin@p200300760F3E7DFAEC162986CADB9CE5.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170330 17:05:48-!- Kwandulin [~Kwandulin@p200300760F3E7DFAC5E9E65C5B2CD3DD.dip0.t-ipconnect.de] has joined #wesnoth-dev
20170330 17:06:33-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20170330 17:10:31-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 17:12:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 17:17:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 17:19:35-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 17:26:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 17:27:38-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 17:27:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 17:29:40-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170330 17:29:56-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 17:38:00-!- JyrkiVesterinen [~JyrkiVest@78-27-71-105.bb.dnainternet.fi] has joined #wesnoth-dev
20170330 17:55:49-!- Nagi [5b9db676@gateway/web/freenode/ip.91.157.182.118] has joined #wesnoth-dev
20170330 17:57:58-!- Soliton [~Soliton@wesnoth/developer/soliton] has quit [Disconnected by services]
20170330 17:58:03-!- Soliton_ [~Soliton@wesnoth/developer/soliton] has joined #wesnoth-dev
20170330 17:58:23-!- Soliton_ is now known as Soliton
20170330 18:00:56< Nagi> hello
20170330 18:02:26< Nagi> Is there any work here for a beginner progprammer who wants to get some experience under his belt?
20170330 18:02:54< JyrkiVesterinen> Yes, see here: https://wiki.wesnoth.org/EasyCoding
20170330 18:03:53< Nagi> i'll give it a look
20170330 18:04:19< zookeeper> (one could argue that many of those aren't exactly "easy", but still a worthy list of things that could be done)
20170330 18:05:56< zookeeper> i'd expect to find quite a lot of sort-of-easy bugs to fix in the bug tracker
20170330 18:32:53-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170330 18:36:09< Nagi> heh, it was propably bit too ambitious for me to come offer my labor here
20170330 18:39:17< JyrkiVesterinen> We appreciate the offer anyway.
20170330 18:40:08< JyrkiVesterinen> The project suffers from chronic lack of manpower. People as much as attempting to help make us feel a bit better.
20170330 18:41:14-!- irker854 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20170330 18:41:14< irker854> wesnoth: Nils Kneuper wesnoth:master 2488e6521e45 / po/ (wesnoth-lib/en_GB.po wesnoth-sota/en_GB.po): updated British English translation https://github.com/wesnoth/wesnoth/commit/2488e6521e45be691cbd2cea008d393da5c5bda7
20170330 18:41:14< irker854> wesnoth: Nils Kneuper wesnoth:master 2abfec888023 / / (31 files in 30 dirs): updated Spanish translation https://github.com/wesnoth/wesnoth/commit/2abfec888023e5be7633eacb680ae818f5fe8446
20170330 18:52:26< Nagi> maybe I'll come back to you after the next Helsinki uni open course on C
20170330 18:53:02< zookeeper> Nagi, well, time is more or less the only restriction. no task is too ambitious if you have plenty of time to devote to it, but admittedly it might be hard to find something to do in very limited time.
20170330 18:58:02< Nagi> I've got plenty of time until the next autum at least
20170330 18:58:32< Nagi> i just need to find a way to familiarise myself with C
20170330 18:59:03< zookeeper> i believe c++ would be the more fitting characterization here
20170330 18:59:16< Nagi> yes ofcourse
20170330 18:59:28< JyrkiVesterinen> A significant portion of our code is in Lua, which is a significantly more simple language. You could start by working on the Lua side.
20170330 18:59:38< zookeeper> that too
20170330 19:00:32< JyrkiVesterinen> And we have a bunch of code in WML (Wesnoth Markup Language) as well. In that area even experienced programmers don't have much advantage (since no one other than Wesnoth developers / UMC authors has WML experience).
20170330 19:01:00-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 19:01:25< Nagi> i'm familiar with only java so far
20170330 19:01:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 19:02:25< JyrkiVesterinen> Programming languages don't have that much difference between each other in the end.
20170330 19:03:02< JyrkiVesterinen> Immediately after I graduated, I was hired into a team that worked with a mostly-Lua codebase, and I didn't have any pre-existing Lua experience.
20170330 19:03:27< JyrkiVesterinen> Learning enough of the language to start making changes took me only a couple of days.
20170330 19:05:55< Nagi> what programming enviroment should i download for lua
20170330 19:06:10-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 256 seconds]
20170330 19:06:55< JyrkiVesterinen> Any programming-oriented text editor will do. For example Visual Studio Code.
20170330 19:15:11-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20170330 19:17:00-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 19:21:00-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20170330 19:22:28-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 19:25:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 19:26:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 19:29:18< Nagi> i guess this is the source code https://github.com/wesnoth/wesnoth
20170330 19:30:09< JyrkiVesterinen> Yes, it is.
20170330 19:30:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds]
20170330 19:30:53< JyrkiVesterinen> C++ code is in src, WML can be found everywhere in data, and Lua code is in data/lua.
20170330 19:40:03-!- celmin|sleep is now known as celticminstrel
20170330 19:44:34< celticminstrel> JyrkiVesterinen, Nagi: Not all the Lua is in data/lua, some is in data/ai/lua.
20170330 19:45:25< celticminstrel> There's probably some Lua scattered around in other places too (like in campaigns).
20170330 19:50:07< Nagi> how do i compile the project in visual studio?
20170330 19:51:01< celticminstrel> Nagi: Download an appropriate package from https://github.com/aquileia/external
20170330 19:51:25< celticminstrel> That's the simplest way to get all dependencies for MSVC.
20170330 19:51:41< celticminstrel> May not have an MSVC2017 package yet though...
20170330 19:52:38< JyrkiVesterinen> Indeed, we don't have any simple way to compile the game with VS2017 yet.
20170330 19:53:21< JyrkiVesterinen> To begin with, the Boost libraries which we use excessively don't yet have full VS2017 support.
20170330 19:53:44< celticminstrel> "excessively" >_>
20170330 19:53:44< JyrkiVesterinen> I think I'm the only person who has compiled the game with VS2017.
20170330 19:54:58< JyrkiVesterinen> Oops. Meant to write "extensively". :D
20170330 19:55:44< celticminstrel> :P
20170330 19:57:10< Nagi> man this is way out of my league
20170330 20:00:07< zookeeper> if you have no prior experience then it can be quite an obtuse process to compile a big project like this with dependencies and whatnot... but i guess it's not terribly complicated as such. if you're lucky enough that things simply work the first time you try to follow the instructions.
20170330 20:01:16< celticminstrel> I have to say your timing probably isn't that great; if you'd shown up before MSVC2017 was released, or say in another month or two, there would probably be a ready-to-use package for you to build master. If you only want to work in WML/Lua, it might be possible for a week or so to work with the released 1.13.7 version.
20170330 20:05:13-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has joined #wesnoth-dev
20170330 20:07:34-!- JyrkiVesterinen [~JyrkiVest@78-27-71-105.bb.dnainternet.fi] has quit [Quit: Going to bed]
20170330 20:08:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 20:40:57-!- Nagi [5b9db676@gateway/web/freenode/ip.91.157.182.118] has quit [Quit: Page closed]
20170330 20:43:30-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 20:49:27-!- gfgtdf [~chatzilla@x4e3692e9.dyn.telefonica.de] has joined #wesnoth-dev
20170330 21:07:17-!- mjs-de [~mjs-de@x4db572a2.dyn.telefonica.de] has joined #wesnoth-dev
20170330 21:08:59-!- Kwandulin [~Kwandulin@p200300760F3E7DFAC5E9E65C5B2CD3DD.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20170330 21:10:23-!- mjs-de [~mjs-de@x4db572a2.dyn.telefonica.de] has quit [Remote host closed the connection]
20170330 21:27:45-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20170330 21:32:48-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Read error: Connection reset by peer]
20170330 21:32:54-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20170330 21:40:39-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20170330 21:41:19-!- irker854 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20170330 21:46:37-!- gfgtdf [~chatzilla@x4e3692e9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.0.2/20170323105023]]
20170330 21:51:32-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 21:56:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 22:01:34-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20170330 22:09:36-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 22:14:39-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 22:19:19< vultraz_iOS> celticminstrel: looks like I'm having to use boost::variant after all
20170330 22:20:23< celticminstrel> Oh, okay.
20170330 22:20:27< celticminstrel> What made you decide that?
20170330 22:20:31< vultraz_iOS> in addition to my impl
20170330 22:20:36< celticminstrel> Eh?
20170330 22:20:39< celticminstrel> Wait?
20170330 22:20:46< celticminstrel> I'm confused now.
20170330 22:21:44< vultraz_iOS> celticminstrel: since variant holds an object of type variant_value_base, any function called with it needs to be implemented there. since variant base types aren't related, there's no way to have a standard get_value getter in variant_value_base
20170330 22:22:58< celticminstrel> I still don't understand.
20170330 22:24:08-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20170330 22:27:01< vultraz_iOS> tl'dr: need common return type for virtual value getter in the base class
20170330 22:27:19< celticminstrel> Are you sure?
20170330 22:27:49< celticminstrel> Actually, perhaps a better question is, why do you have a virtual value getter in the base class?
20170330 22:27:58< vultraz_iOS> ...
20170330 22:28:04< vultraz_iOS> because there needs to be one?
20170330 22:28:07< celticminstrel> Why?
20170330 22:28:10< vultraz_iOS> or else the code won't build?
20170330 22:28:21< celticminstrel> That's not a reason.
20170330 22:28:27< vultraz_iOS> variant proper type is known at runtime not compile time
20170330 22:28:45< vultraz_iOS> it's like having a vector of styled_widgets and having your code call a label-specific function
20170330 22:29:11< vultraz_iOS> if there isn't a separate label value it won't work.
20170330 22:29:18< vultraz_iOS> s/value/variable
20170330 22:29:27< celticminstrel> Well, making a virtual value getter in the base class does not strike me as the right way to do this.
20170330 22:29:34-!- atarocch [~atarocch@93.56.160.28] has quit [Ping timeout: 240 seconds]
20170330 22:29:36< celticminstrel> Why do you need it?
20170330 22:29:42< celticminstrel> What uses this virtual value getter?
20170330 22:30:12< vultraz_iOS> implemented by derived classes to return their values
20170330 22:30:24< celticminstrel> That's ridiculous.
20170330 22:30:47< celticminstrel> But it also still doesn't answer my question of "why do you need it".
20170330 22:30:49< vultraz_iOS> then what do you propose
20170330 22:31:00< celticminstrel> Like... where is it called?
20170330 22:31:14< vultraz_iOS> where is *what* called
20170330 22:31:19< celticminstrel> The value getter.
20170330 22:31:28< celticminstrel> Which we've been talking about the entire time, I thought.
20170330 22:31:49< vultraz_iOS> well, say something like this
20170330 22:31:53< vultraz_iOS> 	game_logic::const_formula_callable_ptr as_callable() const
20170330 22:31:53< vultraz_iOS> 	{
20170330 22:31:53< vultraz_iOS> 		must_be(VARIANT_TYPE::TYPE_CALLABLE);
20170330 22:31:53< vultraz_iOS> 		return value_->get_callable();
20170330 22:31:53< vultraz_iOS> 	}
20170330 22:32:19< celticminstrel> What about it?
20170330 22:32:21-!- RatArmy_ [~ratarmy@om126204192100.6.openmobile.ne.jp] has joined #wesnoth-dev
20170330 22:32:47< vultraz_iOS> get_callable is only applicable if, indeed, the type is TYPE_CALLABLE in which case value_ is assigned a variant_callable ptr where get_callable() is implemented
20170330 22:33:05< celticminstrel> Right, so you need to dynamic_cast.
20170330 22:33:11< celticminstrel> Or dynamic_pointer_cast, one of those.
20170330 22:33:27< vultraz_iOS> unless you suggest I reimplement must_be in terms of dynamic_cast which is a little odd since the variable is already valid
20170330 22:33:53< celticminstrel> How did you implement must_be?
20170330 22:33:59< vultraz_iOS> i left it alone
20170330 22:34:12< celticminstrel> So it calls value->get_type() or something?
20170330 22:34:15< vultraz_iOS> thorw error if type() != t
20170330 22:34:21< celticminstrel> Okay.
20170330 22:34:57< celticminstrel> So, was this supposed to be an example of where you need this virtual value getter?
20170330 22:35:04< vultraz_iOS> yes
20170330 22:35:13< celticminstrel> Why do you need it here?
20170330 22:35:29< vultraz_iOS> doesn't build
20170330 22:35:31< celticminstrel> If type() == TYPE_CALLABLE, doesn't that mean value_ holds an instance of variant_callable?
20170330 22:35:39< vultraz_iOS> yes
20170330 22:35:53< vultraz_iOS> but that's done at runtime not compile time
20170330 22:35:54< celticminstrel> So return dynamic_pointer_cast<variant_callable>(value_)->get_callable()...
20170330 22:36:11< celticminstrel> You've used must_be() to ensure that the cast won't fail.
20170330 22:37:42< vultraz_iOS> hmmm
20170330 22:38:13< vultraz_iOS> and i guess i could also reimplement must_be as that, yes..
20170330 22:38:18< vultraz_iOS> that might solve problems
20170330 22:38:24< celticminstrel> Reimplement must_be as what now?
20170330 22:38:26< vultraz_iOS> is it no-op if the type is already the same?
20170330 22:38:35< celticminstrel> Is what a no-op?
20170330 22:39:02< celticminstrel> If you mean "is dynamic_pointer_cast<variant_value_base>(value_)" a no-op, well... I assume so?
20170330 22:39:04< vultraz_iOS> if value_ already holds a variant_callable 
20170330 22:39:28< celticminstrel> Um, that's the whole point of the dynamic_pointer_cast.
20170330 22:39:34< celticminstrel> To get the variant_callable.
20170330 22:39:42< celticminstrel> Remember, value_ is only a variant_value_base.
20170330 22:39:51< celticminstrel> As far as the compiler knows, at least.
20170330 22:40:09< celticminstrel> It may hold a variant_callable, and if so, you need the dynamic_pointer_cast to actually get that back.
20170330 22:40:35< celticminstrel> Obviously that won't be a no-op.
20170330 22:41:03< celticminstrel> Part of the cast is checking that ir really is the selected type.
20170330 22:41:04< vultraz_iOS> value_ is only variant_value_bast at compile time, yes
20170330 22:41:13< celticminstrel> ^it
20170330 22:41:34< vultraz_iOS> could be one of the derived types at runtime.
20170330 22:41:41< celticminstrel> Yes.
20170330 22:41:48< celticminstrel> [Mar 30@6:38:23pm] celticminstrel: Reimplement must_be as what now?
20170330 22:42:58< vultraz_iOS> reimplement must_be as a cast check
20170330 22:43:03< vultraz_iOS> ie, cast to T and see if not nullptr
20170330 22:43:22< vultraz_iOS> or perhaps it would never be nullptr
20170330 22:43:30< vultraz_iOS> since we're only casting to derived...
20170330 22:43:36< celticminstrel> ...
20170330 22:43:51< celticminstrel> THAT IS EXACTLY THE CASE WHERE IT COULD BE NULLPTR
20170330 22:44:15 * vultraz_iOS just woke up
20170330 22:44:17< celticminstrel> (Though I don't recall whether dynamic_pointer_cast throws or returns null upon a failed cast.)
20170330 22:44:52< celticminstrel> You don't want to be casting twice if you don't have to though.
20170330 22:45:15< celticminstrel> You could use a cast for must_be, but then I'd suggest making it return the casted value so that the caller doesn't have to cast again.
20170330 22:45:28< vultraz_iOS> ok, it seems I don't have a clear idea of what's at runtime vs compile time
20170330 22:45:39< celticminstrel> That said, it's probably fine to just leave must_be as it is now.
20170330 22:46:44< vultraz_iOS> speaking of casting, why does variant have these: https://github.com/wesnoth/wesnoth/blob/master/src/formula/variant.hpp#L102-L119
20170330 22:46:53< celticminstrel> Basically, your code has no idea what the actual type is until you do a cast.
20170330 22:46:54< vultraz_iOS> it seems to work specifically on the callable ptr...
20170330 22:46:58< celticminstrel> (Or a typeof.)
20170330 22:47:02< vultraz_iOS> but maybe that's due to the union?
20170330 22:47:08< vultraz_iOS> I have a feeling i should change this somehow
20170330 22:47:49< celticminstrel> The purpose of those are to convert the formula_callable to some specific formula_callable subclass (and return null if it's not of that type).
20170330 22:48:06< vultraz_iOS> I see
20170330 22:48:13< vultraz_iOS> name doesn't make that clear
20170330 22:48:17< celticminstrel> So yes, it's supposed to work on the callable pointer.
20170330 22:48:20< vultraz_iOS> it looks like a common cast
20170330 22:48:28< celticminstrel> True.
20170330 22:48:38< celticminstrel> IMO the code does make it clear though.
20170330 22:48:46< celticminstrel> What with checking is_callable() and such.
20170330 22:49:19< celticminstrel> I'm not sure why convert_to returns a pointer instead of a reference...
20170330 22:50:05< vultraz_iOS> i'll add a new private function to call d_p_c
20170330 22:51:11< celticminstrel> I don't quite get why you need a new private function for it, but whatever.
20170330 22:51:42< vultraz_iOS> to wrap a check for nullptr....?
20170330 22:51:55< vultraz_iOS> you said it could possibly be nullptr?
20170330 22:52:19< celticminstrel> I said I wasn't sure. Check the dynamic_pointer_cast documentation to see whether it throws or returns nullptr.
20170330 22:52:37< vultraz_iOS> "Otherwise, the new shared_ptr will share ownership with r, except that it is empty if the dynamic_cast performed by dynamic_pointer_cast returns a null pointer."
20170330 22:52:54< celticminstrel> Okay, so it returns nullptr on failure.
20170330 22:53:00< celticminstrel> In that case, fair enough.
20170330 22:53:21< celticminstrel> (Or an empty shared_ptr, rather.)
20170330 22:53:36< vultraz_iOS> hmm
20170330 22:53:51< vultraz_iOS> actually, how should I handle the check, then..
20170330 22:54:17< celticminstrel> The check as in... where you currently call must_be()?
20170330 22:54:54< vultraz_iOS> must_be is runtime, not compile time
20170330 22:55:07< celticminstrel> Yes, I know, but isn't this also runtime?
20170330 22:55:22< vultraz_iOS> eh, sure...
20170330 22:55:31< celticminstrel> You sound uncertain.
20170330 22:56:02< celticminstrel> It's entirely possible that you're right and I'm wrong, for example if you're talking about something different from what I think you're talking about.
20170330 22:56:02< vultraz_iOS> i need something to happen if the cast fails
20170330 22:56:10< celticminstrel> Throw an exception?
20170330 22:56:15< vultraz_iOS> alright
20170330 22:56:19< celticminstrel> Presumably the same exception must_be would throw.
20170330 22:56:27< celticminstrel> Is this going to replace must_be?
20170330 22:56:36< vultraz_iOS> not yet
20170330 22:56:46 * celticminstrel reads that as "eventually"
20170330 22:56:51< vultraz_iOS> probably
20170330 22:57:28-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 240 seconds]
20170330 22:57:33< vultraz_iOS> i assume .get() returns a nullptr in an empty shared_ptr?
20170330 22:59:14< celticminstrel> I assume so too, but why would you .get() a shared_ptr you know to be empty?
20170330 22:59:35< celticminstrel> if(value_) is the standard way to check if it's empty.
20170330 22:59:40< vultraz_iOS> oh
20170330 22:59:43< celticminstrel> Or if(!value_)
20170330 22:59:44-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 23:00:18< celticminstrel> I think it does work to write value_ == nullptr
20170330 23:00:27< vultraz_iOS> I'm constructing a new shared_ptr, not reassigning value_
20170330 23:00:29< celticminstrel> But I'd personally prefer not to.
20170330 23:00:57< celticminstrel> A newly constructed shared_ptr is empty unless you passed a pointer to the constructor.
20170330 23:02:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 23:02:33< vultraz_iOS> ok, this initially seems to work
20170330 23:02:39< vultraz_iOS> compiler passes that line
20170330 23:03:14< vultraz_iOS> btw
20170330 23:03:34< vultraz_iOS> in my work i discovered that string_cast, serialize_to_string, and debug_string return almost the exact same thing
20170330 23:03:52< vultraz_iOS> would be good to evaluate their use 
20170330 23:04:08< celticminstrel> Um, that's wrong.
20170330 23:04:48< vultraz_iOS> i don't think so?
20170330 23:04:53< celticminstrel> It is wrong.
20170330 23:05:20< vultraz_iOS> like, look: https://pastebin.com/wuUsgV8X
20170330 23:05:38< vultraz_iOS> I can use this function, with only the two flags, to handle the values for all three lists
20170330 23:05:46< vultraz_iOS> er
20170330 23:06:00< vultraz_iOS> to handle the string conversion for all three functions in the container type
20170330 23:06:05< celticminstrel> Well, the three have very different use cases.
20170330 23:06:05-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20170330 23:06:15< celticminstrel> string_cast is "Give me the value of this variant as a string".
20170330 23:06:28< celticminstrel> serialize_to_string is "Give me WFL code that evaluates to this variant".
20170330 23:06:47< celticminstrel> And debug_string is "Give me a string representing this value".
20170330 23:07:35< celticminstrel> Note that serialize_to_string can easily fail.
20170330 23:07:45< celticminstrel> Whereas debug_string must never fail.
20170330 23:07:55< celticminstrel> And string_cast... not sure.
20170330 23:08:12< vultraz_iOS> must never fail?
20170330 23:08:14< vultraz_iOS> hmm
20170330 23:08:17< celticminstrel> Ah, I'd forgotten that I already moved variant.?pp into the formula directory.
20170330 23:08:27< celticminstrel> Yes, debug_string is intended for displaying results to the user.
20170330 23:08:42< celticminstrel> For example in the formula debugger or in response to a formula evaluated from the formula console.
20170330 23:08:43< vultraz_iOS> well, I'll let you review everything later 
20170330 23:08:55< vultraz_iOS> my code removes a few asserts and throws
20170330 23:09:04< vultraz_iOS> mostly as default switch cases
20170330 23:11:17< celticminstrel> It seems to me that to_debug_string could drop its bool argument...
20170330 23:11:31< celticminstrel> (And instead just check whether seen is non-null.)
20170330 23:12:13< celticminstrel> It's probably fine to use a templated function like that to implement the three functions.
20170330 23:12:33< celticminstrel> Oh, I guess it's not a template function, whoops.
20170330 23:12:54< vultraz_iOS> I use a common private base func for most
20170330 23:12:55< celticminstrel> But I mean, factoring out common parts is fine, but the intent of the three are quite different.
20170330 23:15:05-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 23:17:47< vultraz_iOS> any objections if make the dtor of formula_callable public
20170330 23:18:10< vultraz_iOS> or does variant_callable need to inherit from formula_callable
20170330 23:19:34< celticminstrel> Why do you need it to be public?
20170330 23:19:58< vultraz_iOS> ..\..\src\formula\callable.hpp|120|error: 'virtual game_logic::formula_callable::~formula_callable()' is protected|
20170330 23:20:02< celticminstrel> TBH I'm not quite sure why it's protected though...
20170330 23:20:24< vultraz_iOS> when constructing variant_callable
20170330 23:20:41< celticminstrel> The constructor is even public.
20170330 23:22:17< vultraz_iOS> ill move it
20170330 23:25:47< vultraz_iOS> wonder if try_convert_variant et al should use DPC
20170330 23:26:09< vultraz_iOS> since you said callable should be handled with a shared_ptr
20170330 23:31:48-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has quit [Ping timeout: 252 seconds]
20170330 23:35:22< vultraz_iOS> now, how to handle the iterator
20170330 23:39:15-!- gfgtdf [~chatzilla@x4e3692e9.dyn.telefonica.de] has joined #wesnoth-dev
20170330 23:40:45< vultraz_iOS> HHHmm
20170330 23:40:47< vultraz_iOS> C:\Users\exodi\Documents\wesnoth\src\formula\variant.cpp|245|error: invalid new-expression of abstract class type 'game_logic::variant_int'|
20170330 23:40:49< vultraz_iOS> oh dear
20170330 23:41:57< vultraz_iOS> "because the following virtual functions are pure within"
20170330 23:42:02< vultraz_iOS> hmm
20170330 23:42:25< vultraz_iOS> i guess creating a new instance of a class that creates a new instance of the class you created it from doesn't work
20170330 23:42:27< vultraz_iOS> ponder
20170330 23:51:43-!- Duthlet [~Duthlet@dslb-188-106-146-119.188.106.pools.vodafone-ip.de] has quit [Quit: leaving]
20170330 23:52:15-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 23:53:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection]
20170330 23:53:47-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev
20170330 23:57:41< celticminstrel> vultraz_iOS: Well yes, try_convert et al should be using dynamic casts of some type.
20170330 23:58:02< celticminstrel> vultraz_iOS: What is it that gave you that error?
20170330 23:58:48< celticminstrel> Why is variant_int abstract anyway?
20170330 23:59:42< celticminstrel> BTW, it looks like the formula_callable might've been protected because of the intrusive_ptr stuff
--- Log closed Fri Mar 31 00:00:16 2017